| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | Viva! Primeiro, para começar acho que vou tentar fazer um pequeno resumo do artigo em si. Pelo que percebi, o pessoal anda demasiado ocupado para ter tempo para estas coisas a não ser que se fale da Microsoft. ;) Aqui vai o resumo: 1) Foi realizado um primeiro teste de "context switching" ao nível de processos na platformas Winddws2000, XP e Linux (RH7.2). Os testes utilizavam pipes o que influenciou postivamente os reusltados para o lado do Linux (a dar uma ratada nos Wins). Este teste foi considerado injusto pelo próprio autor porque reflectia demasiado o fraco desempenho dos Wins ao nível dos pipes em vez de medir o desempenho em termos de "context switching". 2) Foi realizado um segundo teste mas desta vez foram utilizados o suporte próprio de cada plataforma e o context switching foi em termos de threads em vez de processos. Neste caso, os windows deram ratada no Linux. Agora a minha opinião. :) Conforme o próprio autor dos testes referiu depois no forum, estes testes pecam pelo menos em vários pontos: - os 2 testes referem-se a coisas diferentes: processos e threads. Pelo que os dois testes não devem ser directamente comparados entre si. - o primeiro teste utilizava pipes o que deixou ficar mal os wins e retira a sua credibilidade ao teste como medida de desempenho de "context switching" - o segundo teste apesar de mais apropriado por tentar fazer com que cada platforma deia o seu melhor, peca por ser um teste em que as threads não fazem praticamente mais nada a não ser tentar adquirir o lock. Ou seja pouco ou nada tem a ver como uma aplicação normal. Finalmente, o RH 7.2 está um pouco desactualizado. Acho que deveria ter sido utilizada uma distribuição com um kernel e uma glibc mais actualizados. O autor referiu que queria fazer a comparação sem fazer um tunning especial (não tinha tempo nem pahorra) e por isso só queria utilizar uma distribuição out of the box.
Acho o segundo teste mais fiável mas um pouco desajustado da realidade e gostava de o ver com um kernel uma glibc mais recente. ;) Fiquem bem!
JP
|
| | | | | | | - o segundo teste apesar de mais apropriado por tentar fazer com que cada platforma deia o seu melhor, peca por ser um teste em que as threads não fazem praticamente mais nada a não ser tentar adquirir o lock. Ou seja pouco ou nada tem a ver como uma aplicação normal. Pelo contrario -- o melhor teste e' exactamente quando a thread faz apenas um yield() por forma a perder a fatia de processador.
echo '[dO%O+38%O+PO/d00]Fi22os0CC4BA64E418CE7l0xAP'|dc
|
| | | | Acho que não me expliquei bem.
Em termos de "context switching" a nível de threads, o segundo teste parece-me adequado (se retirarmos aquele output de debug). Não consigo imaginar melhor. O que eu queria dizer é que não reflecte uma situação real e que se deve evitar extrapolar conclusões tipo: "Windows é mais rápido que Linux".
O que o teste demonstrou é que para aquela situação e com aquela configuração de hardware/Software o Windows é realmente mais rápido.
Mais uma vez, eu gostava de ver o mesmo teste com um kernel e uma glibc mais recente.
Peço desculpa por não ter sido mais claro. Fica bem!
JP
|
| | | | o segundo teste acho que é ajustado porque o que tu queeres ver é mesmo a velocidade de CS, portanto adquirir o lock e libertar é suficiente, e é o minimo que podes fazer..
Isto porque não se está a fazer um teste para simular uma aplicação normal.. apenas ver a velocidade de CS. No entanto não sei se o mutex da pthread será a melhor escolha para um secção critica em termos de velocidade.. sei que agora já existe um mutex muito rápido criado à pouco tempo (cujo nome me falha), mas não sei se o 2.4.2 já o tem implementado.. ou se mesmo para além desse existe outro mutex mais rapidinho, uma vez que se está a usar uma solução não standart em windows, podia-se fazer o mesmo em linux. Em relação a ser um MS vs RedHat. Bem.. este tipo anda a ver uma data de comparações de performance entre estas duas plataformas à já algum tempo, e é por ter feito artigos sobre criação de processos/threads, velocidade de pipes, copias de memória etc.. com exactamente as mesmas plataformas que o teste se mantém com essas plataformas e não com algo mais recente.
Além disso são produtos que senão estou em erro os windows sairam antes do redhat 7.2 portanto, a tecnologia do linux usado no teste é mais recente que a tecnologia do windows em causa. Vejam o resto dos artigos do gajo.. são muito fixes... Mas suspeito que a performance com threads em linux não seja tão boa como no win, 1º porque se o próprio windows usa extensivamente threads no explorer e outras aplicações, então a MS confia o suficientemente no seu código para threads para o usar no SO/Plataforma, e no linux está em desenvolvimento a NextGenerationPosixThreading o que me leva a pensar que a geração presente não é grande espingarda. ;-)
Miguel F. M. de Sousa Filipe handle: m3thos email: mmsf@rnl.ist.utl.pt More Human than Human.
|
| | | | Mais que a geração recente não ser uma grande espingarda, é um grande hack.
Gostava era de ver uma comparação de context switching entre Linux/w2000 *sem* threads. (com aplicações normalissimas...). Por exemplo, entre o exchange e o qmail ;->
-- |
| | | | | Concordo com a tua opinião. Conforme podes ver noutro post acima eu pedi desculpa por não ter sido suficientemente claro. Mais uma vez, com desajustado refiro-me a realidade em termos de aplicações como chamada de atenção para evitar extrapolações. O segundo teste parece-me bom mas os resultados têm de ser mantidos no contexto do teste. O desempenho de das aplicações a correr num SO dependem de mais coisas do que o desempenho em termos de "context switching" Fiquem bem!
JP
|
| | | | sabemos como o linux ao implementar os algoritmos de escalonamento de processos segue as normas posix, e assim alem do round-robin usa o fcfs para o escalonamento em temporeal, dividindo em duas clases, as quais adiciona, tambem niveis de prioridade.
Ora o problema esta em q pode existir a troca de processos segundo o round-robin se estes tiverem a mesmo nivel de prioridade.
Ou o mais importante é a limitacao de escalonar um processo de modo utilizador sobre um de modo kernel. Embora o "scheduler" faca o seu escalonamento o kernel nao garante a sua execucao imediata, mesmo q tenha nivel de prioridade mais elevado.
Ja pra nao falar no facto de tarmos a falar de threads vs processos. A verdade é q utilizam algoritmos bastantes diferentes, o windows2000 usa escalonamento de threads pelo nivel de prioridade, mais elevado, garantido q sera sempre este a correr.
Seria muito mais util uma comparacao Windows2000/Solaris.
E ja agora este teste nao foi feito num IBM Thinkpad 600, humm poracaso isto nao e um modelo de portatil q por acaso
é maioritariamente vendido com win2000 ?! É claro q ele nao se seguiu por tal principio mas obviamente q so lhe fica bem correr tal teste ;D
...no reino de Quelthalas...
im awake, im awake! |
| |
|
