Arnaldo Carvalho de Melo wrote:
>
> Em Tue, Aug 28, 2001 at 04:01:00PM -0300, Lisias Toledo escreveu:
> > Arnaldo Carvalho de Melo wrote:
[...]
> Espere, sua tradu��o ficou assim:
>
> "Um computador � uma m�quina de estados.
> Threads nunca devem ser usadas em hip�tese alguma"
>
> A minha ficou assim:
>
> "Um computador � uma m�quina de estados.
> Threads s�o para pessoas que n�o conseguem programar m�quinas de estados."
Bom... V� l�... Mas me baseei tamb�m dos demais coment�rios daquela thread que
vc forneceu. Li ela quase toda. E o Cox (IMHO) diz exatamente isto : acha
perda de tempo aprimorar o uso de threads no kernel porque eles s�o coisa de
programadores inaptos...
> Nada pejorativo, apenas a verdade, como voc� disse, o c�rebro n�o � uma
> m�quina de estados, se algu�m quer programar como acha que seu c�rebro
> funciona, est� livre para faz�-lo, n�o?
Sim. Mas se o kernel n�o d� suporte decente para as threads, meus programas
funcionar�o melhor em outros sistemas e n�o no Linux, o que � contra meus
interesses.
> Outra tradu��o poss�vel (da id�ia em ingl�s para um texto em portugu�s):
>
> "J� que um computador � uma m�quina de estados,
> se fizermos nossos programas como m�quinas de estados, teremos melhor
> desempenho"
>
> Mas isto n�o impede ningu�m de fazer a besteira ou genialidade que desejar.
Nem sempre � economicamente vi�vel resolver problemas usando m�quinas de
estados. Diga-se de passagem, a constru��o de compiladores sempre foi uma dor
de cabe�a fenomenal, at� que se inventou os "Compiler Compilers" da vida (aka
yacc, bison, etc), que automatizam o processo.
Al�m do mais, as threads tendem a otimizar processos que fazem uso intensivo
de IO. Se o processo � mono-threaded, ao entrar em modo de espera de IO ele
perde toda a fatia de tempo do processador. Se ele � multi-threaded, existe ao
menos a chance de que outra thread do mesmo processo utilize a fatia de tempo
fazendo alguma outra coisa.
> > Mas querer limitar o conhecimento humano � esta tecnologia � idiotice, e sim,
> > neste processo eles perderem efici�ncia, azar o deles.
>
> Bem, azar o de quem for usar algo n�o otimizado para o que pagou (n�o
> importa o pre�o).
Antes o computador que eu... Prefiro desperdi�ar em hardware (uma vez s�) que
em m�o-de-obra (que � paga todo m�s). Algumas economias n�o valem a pena.
[...]
> > computador hoje por uns 1000 reais. Por quanto eu compro um c�rebro novo
> > "thread-free" pra p�r na cuca?
>
> heh, finalmente descobrimos como o cer�bro funciona?
Assim que eu achar o meu, fa�o uma pesquisa... 8-)
[...]
> > > > Mais um motivo � o alto gasto de mem�ria das aplica��es POSIX. A POSIX � bem
> > [...]
> > > > gasto muito maior de mem�ria no Linux que no Windows.
> > >
> > > humm, eu diria mais que as interfaces gr�ficas no Linux ainda n�o est�o
> > [..]
> > > mem�ria por n�o serem compartilhadas.
[...]
> Hey, que peso � este? E quem disse que temos que usar POSIX para sempre se
> ele tiver este peso todo?
O overhead das permiss�es, por exemplo. Experimente dar um "kill -9" em um
processo de outro usu�rio sem ser superuser, por exemplo. Isto gasta mem�ria
pra guardar quem pode o que e aonde, e tempo pra verificar antes de executar.
Na Win32 (Win9x), por exemplo, isto praticamente n�o existe - a �nica
verifica��o de acesso � feita pelo Processador baseada em seus registradores
de segmento (que tbm gastam mem�ria e tempo, mas isto j� � outra hist�ria).
Existem centenas de chamadas POSIX que simplesmente n�o existem na Win32. Vc
percebe isto quando usa o CygWin : programas POSIX no cygwin possuem
performance bem pior que programas Win32 debaixo do Wine.
> > high end em vista. Um exemplo pr�tico disto � o enlighenment (putz... nunca
>
> sigh, se John Doe da Silva na Chech�nia fizer ainda mais um gerente de
> janelas que exija muito mais m�quina que o enlightenment n�o quer dizer que
> a "tend�ncia" do Linux (e aqui est� uma generaliza��o) � exigir mais m�quina.
KDE e Gnome. 8-P. Algu�m j� rodou o KDE2 numa Pentelhinho com 32 mega? ;-)
Usei o enlighenment porque ele � configur�vel, e fica f�cil ativar e desativar
os recursos pesados. Sem falar que gosto do bicho e o conhe�o o suficiente pra
falar dele sem dar muitas ratadas...
[...]>
> Hey, a Intel acabou de lan�ar m�quinas de 2 Ghz e a AMD tem m�quinas
> velozes (agora n�o ter�o mais seu clock revelado ;) ) ;)
Perfeito. Vamos fazer uma peti��o pedindo que o Silvio Santos passe a
vend�-las como micros populares...
8-)
Falando s�rio, a grosso das m�quinas que rodar�o Linux neste ano e no pr�ximo
com certeza rodar�o dentro do P-6 com 32 ou 64 megabytes SDRAM 3-2-2. Estou
falando de m�quinas de baixo custo que ser�o compradas � granel para a mir�ade
de farm�cias, lojas de autope�as, etc, e que � justamente onde a maioria dos
profissionais Linux v�o ganhar seu ganha p�o.
Mesmo as grandes empresas est�o entulhadas destes equipamentos (pra n�o falar
nos 486 pegando mofo no almoxarifado), e que v�o adorar se puderem botar estas
m�quinas nas mesas das secret�rias.
> > Pior ainda. A mesma m�quina, com a mesma mem�ria. S� com a placa de v�deo
> > chunda (j� fiz o teste). A placa simplesmente freia o resto do sistema no
> > englightement. Usando o fwvm, n�o.
>
> ent�o n�o use o enlightenment com esta placa "chunda"
Com certeza. Mas fica meio dif�cil n�o usar o KDE. E o KDE2 t� pesado pacas.
[...]
> e? O ponto aqui era mostar que n�o � porque algu�m implementa uma interface
> gr�fica pesada que devemos concluir que a tend�ncia � exigir mais m�quina
> de forma desnecess�ria. Existem op��es. Se nenhuma delas for satisfat�ria
> para algu�m, boa motiva��o para:
>
> 1. melhorar algo existente
> 2. reimplementar algo existente
> 3. inventar algo novo
Perfeito. � o que se est� fazendo com o projeto Gnome e o projeto KDE. E
adivinha? Est�o todos ficando cada vez mais pesados.
> Ou tem alguma empresa "por tr�s" do Linux? Lembre-se, esfor�o volunt�rio,
> quer seja de empresas, quer seja de pessoas. Afinal, como o KTB diz, n�o �
> gastando muito tempo para implementar algo e liberando "di gr�tis" que n�s
> tomaremos nossas cervejas de fim de semana.
Exatamente. Mas devemos lembrar tbm que a realidade tupiniquim � muito
diferente da realidade do primeiro mundo, onde costumam nascer tais projetos.
Aqui o cara rala 8 horas por dia, ganha pouco, e ainda tem que perder horas no
tr�nsito. Tranquilamente um programador m�dio em sampa deve ficar 11 ou 12
horas na rua. No in�cio da d�cada de 80, eu morava em Guarulhos, e meu pai
trabalhava na Capital. Ele ficava umas 10 horas na rua, e isto porque tinha
carro.
Assumindo que ele durma as 8 horas regulamentares, sobram 4 horas para o
lazer, a higiene pessoal e a fam�lia. Ahh... tinha esquecido das obriga��es
dom�sticas, como fazer supermercado...
No primeiro mundo, o cara ganha mais (e portanto pode pagar por pequenos
confortos que economizam tempo no dia a dia - como ter home banking em casa e
pagar as contas sem ter que ir ao banco ou comprar uma m�quina de lavar
lou�as), possui mais horas de lazer e, portanto, disp�e de mais tempo para
seus projetos pessoais sem negligenciar muito a fam�lia.
--
[]s,
([EMAIL PROTECTED])
Quote of week: The day Micro$oft makes something that doesn't suck is the day
they start selling vacuum cleaners.
Assinantes em 30/08/2001: 2280
Mensagens recebidas desde 07/01/1999: 130192
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
