Datacom - Tavares wrote:
On Sat, 2005-10-29 at 10:23 -0200, Marcos Lazarini wrote:
Datacom - Tavares wrote:
On Tue, 2005-10-11 at 23:17 -0300, Marcos Lazarini wrote:
E tem um problema, se voce habilitar na Bios o HT e usar um kernel nao
SMP ou um windows 98 sem suporte a SMP, o sistema ficará instavel..
Isso eu já nao sei não, veja os e-mails do Francisco que iniciou a
thread - ele usava um HT com kernel 2.4 não smp. E só comecou a travar
depois que comecou a brincar com essas coisas.
Partindo do principio q se vc tiver 2 cores e um kernel nao SMP, somente
o core 1 serah usado, com HT o mesmo pode ocorrer, correto? Nao
aproveitando o hardware do sistema de forma plena e deixando parte
processador ocioso..
Isso é instavel? Veja o que voce mesmo falou acima
Independente..
Pra que voce vai usar um sistema com HT configurado de maneira
incorreta?
Veja o caso do Francisco, pois ao ligar o HT a CPU esquentou demais e
comecou a travar!
Nao sei se eh instavel pois nunca o usei configurado incorretamente para
testar se fica instavel..
Bom, não é o que vc mesmo disse lá no comeco.
Quando comprei a maquina a 3 anos atras (aproximadamente) li textos que
afirmavam que essa possibilidade existia..
Aqui vc tirou o corpo da reta... :-)
[........]
Exemplo: Ao carregar o windows tens bem poucas threads gerenciando todo
o ambiente grafico.
No linux, o ambiente grafico se resume a um grande conjunto de
programas, por exemplo, gerenciador de janelas, font-server, desktop,
painel, etc, etc, etc, e cada um com suas n threads.. entende agora o q
quis dizer?
A natureza do linux eh muito mais paralelizavel do q a do windows,
portanto uma maquina com linux com HT teria um ganho bem maior em
comparacao a uma sem HT do q se compararmos a uma maquina com windows
com HT e sem HT. Fui claro agora na minha explicacao? :)
Agora tá entendido o seu conceito, só não sei se há relação direta com o
numero de processos (ou threads) rodando com a capacidade de
paralelização como vc assume (e consequente ganho de velocidade).
Na verdade, todo esse assunto eh bem complicado e cheio de variaveis..
Acho que somente no final consegui explicar o que estava querendo
dizer.. :)
Bom, conversando com o meu personal linux guru :-), cito alguns pontos
importantes em relação a processos e threads, só pra esclarecer:
1- um processo é uma entidade completamente independente dos demais. Cada
processo carrega uma tonelada de tabelas, que registram todos os dados e
passos do processo (memória alocada, registros, etc etc).
2- Com essas tabelas, o kernel sabe dizer, pra qquer bit alocado, qual
processo é dono e consegue manter a independencia das coisas, de modo que um
processo somente possa atuar na sua área de direito. Por isso existem
segmentations faults da vida.
3- Toda essa verificação causa um enorme overhead pro kernel (que, apesar de
ruim, é fundamental), que tem que ficar verificando um monte de coisas,
carregando tabelas, etc e tal.
4- Por causa disso surgem uma série de inconvenientes pra fazer comunicação
inter-processos (named pipes, sockets, etc)
a- threads surgiram como processos 'economicos': threads podem compartilhar
a maioria das tabelas que um processo possui. Vantagem: pouquissimo
overhead, o que as deixa bem mais rápidas que processos inteiros.
Desvantagem: aquela isolação perfeita entre os processos (garantida pelo
kernel) foi por água abaixo - virou festa e uma thread pode escrever na
memória da outra, de boa.
Como o kernel 2.6 implementa essas coisas eu nao estou bem a par, mas sei
que há uma diferença sim em relação aos outros SO. No caso, me parece que
tem a ver com o copy-on-write, devido a característica do processo de
criação de processos novos (fork) - que não vem ao caso agora (pq é assunto
pra muitos e-mails)
Voltando agora....
No caso do windows, temos bem menos processos pq muitas coisas por lá são
tratadas pelo kernel, como som e vídeo. Não há processos separados pra
várias coisas já embutidas lá dentro. Isso pode ser até uma vantagem, já que
há menos troca de contexto entre os diversos processos e vc tem mais
controle sobre o que acontece. Obviamente, se essas partes fizerem cacas, vc
recebe uma bela tela azul de presente... :-)
Definitivamente, pra monoprocessado, quanto mais coisa em kernel space, mais
rápida a maquina fica, porém os riscos de problemas sérios aumentam
exponencialmente.
Falando agora em relação a multiprocessamento, vamos falar primeiro do HT. o
HT não é dual de verdade, ele apenas duplica as unidades de controle e
execução internas, pra decodificar duas instruções ao mesmo tempo. Se elas
utilizarem recursos diferentes da CPU, elas podem ser executadas ao mesmo
tempo. Senão, entra na fila e vira uma só CPU. Na prática, é dificil
comparar com um dual de verdade, mas o desempenho varia muito com a
atividade e em geral é consideravelmente abaixo do dual.
Agora sim: se você tem um processo, não é possível dividí-lo entre as CPUs.
Dois ou mais processos, são escalonados de acordo. Nesse ponto, vamos pensar
o que é mais rápido: 100 processos que precisam de 1s cada pra processar, ou
10 processos de 10s cada? E quem teve mais trabalho? Sem mencionar
comunicação inter-processos aqui, pra nao ficar complicado.
Aonde eu quero chegar: 'paralelizar' uma coisa sem reimplementar o algoritmo
(pensando em aproveitar a parelização) muda pouca coisa (tanto no windows
como no linux), pois quem vai estar trabalhando mesmo é o escalonador de
cada um. Pelo meu ponto de vista, o ganho vai ser mais ou menos o mesmo em
ambos os casos.
--
Marcos
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
