gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
Context switching
Contribuído por scorpio em 24-07-02 11:11
do departamento benchmarks
Linux Sam escreve "Have you ever wondered how the overhead of switching context compared between Linux and Windows? This article compares programs that were compiled and run on Windows 2000 Advanced Server Service Pack 2, Windows XP Professional, and Linux 2.4.2 from Red Hat 7.2. The programs demonstrate the effect of the choice of context token when measuring context switch times. It covers measuring the scheduler overhead and context switching using the proper primitives. "

Passatempos de férias | IBM has released DB2 v8.1 for Linux  >

 

gildot Login
Login:

Password:

Referências
  • Linux
  • Red Hat
  • Sam
  • switching context
  • Mais acerca Linux
  • Também por scorpio
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Um pouco desajustado... (Pontos:3, Esclarecedor)
    por Eraser em 24-07-02 19:40 GMT (#1)
    (Utilizador Info)
    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


    Re:Um pouco desajustado... (Pontos:2)
    por leitao em 24-07-02 20:53 GMT (#2)
    (Utilizador Info) http://scaletrix.com/nuno/
    - 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

    My fault! (Pontos:2)
    por Eraser em 24-07-02 22:03 GMT (#3)
    (Utilizador Info)
    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


    Re:Um pouco desajustado... (Pontos:2, Informativo)
    por m3thos em 25-07-02 1:35 GMT (#6)
    (Utilizador Info) http://mega.ist.utl.pt/~mmsf
    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.

    Re:Um pouco desajustado... (Pontos:2)
    por ribeiro em 25-07-02 5:58 GMT (#7)
    (Utilizador Info) http://ruka12.tripod.com
    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 ;->
    --
    Re:Um pouco desajustado... (Pontos:2)
    por Eraser em 25-07-02 9:02 GMT (#8)
    (Utilizador Info)

    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


    linux e escalonamente em temporeal (Pontos:2)
    por racme em 24-07-02 23:50 GMT (#5)
    (Utilizador Info)
    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!

     

     

    [ Topo | FAQ | Editores | Contacto ]