quinta-feira, 22 de abril de 2010

Resenha sobre artigo: A Thread Performance Comparison: Windows NT and Solaris on A Symmetric Multiprocessor

Olá pessoal,

A partir de hoje vou postar algumas trabalhos que tenho feito no mestrado e acho que pode contribuir com o meio acadêmico e tecnológico.
Hoje, vou postar uma resenha que escrevi para a disciplina de SO sobre o artigo: A Thread Performance Comparison: Windows NT and Solaris on A Symmetric Multiprocessor.

Caso queiram ler o artigo original esse é o link: http://www.sagecertification.org/publications/library/proceedings/usenix-nt98/full_papers/zabatta/zabatta.pdf

RESENHA

Resenha sobre a obra: A Thread Performance Comparison: Windows NT and Solaris on A Symmetric Multiprocessor. Autores: Fabian Zabatta e Kevin Ying

A obra acima citada, um artigo, é um estudo comparativo do desempenho de threads em dois Sistemas Operacionais distintos: o Windows NT e o Solaris. O autor apresenta, através de experimentos, os resultados de desempenho de cada Sistema em distintas etapas de execução de determinados processos em situações diversas.
O artigo é iniciado com um breve histórico dos processadores: custo e desempenho do mesmo. É então citada a criação do processador Pentium Pro (PPro), pelo fabricante Intel, onde o autor alega que esse é um processador de alto desempenho construído como suporte para o propósito do multiprocessamento. Em seguida, o autor aborda o assunto de multiprocessamento simétrico (SMP) definindo-o como uma arquitetura paralela primária onde os processadores compartilham a mesma unidade do sistema operacional assim como compartilham memória, barramento e dispositivos de entrada e saída. O autor aborda o conceito de processo e o define como objetos de execução, e os classifica em multitarefa quando aborda sobre concorrência e paralelismo; ainda fala sobre mutex. O autor inicia a explanação sobre os sistemas operacionais descrevendo as características dos SO’s Windows NT e Solaris, afirmando que ambos são sistemas que utilizam prioridades básicas, tempo de partida e algoritmos multitarefa para escalonar seus objetos de nível de kernel.
Ao abordar o assunto de threads, o autor explica que no Windows NT a menor unidade de execução no nível de usuário é a fibra (fiber).
Assim, um thread é constituído de múltiplas fibers que conseguem acessar os threads aleatoriamente. No Solaris, a menor unidade de execução no nível de kernel é o LWP (light weight process), sendo esses os constituintes dos processos do Solaris. Diferentemente do NT, no Solaris, a menor unidade de execução no nível de usuário é a thread, e assim como as fibers, essas não executam sozinhas. No caso do Solaris elas são implementadas e controladas pela biblioteca de sistema. A biblioteca de threads no Solaris define dois tipos de threads, a thread bound (encadeada) e a thread unbound (independente).
Na seção de experimentos, o autor elenca sete experimentos que, segundo o mesmo, foram importantes para determinar se as diferenças na implementação, design e camadas de threads produziriam diferenças de desempenho significantes. São eles:
1. Medida do número máximo de threads de kernel que poderia ser criada por cada sistema;
2. Medida do tempo de execução da criação de threads;
3. Medida da velocidade de criação de thread quando se força o processador com vários processos em execução;
4. Determinar como cada implementação de threads de sistemas operacionais desempenharia em processos com threads em intensivo processamento que não requereram nenhuma sincronização;
5. Determinar como cada implementação de thread desempenharia em processos de processamento intensivo que solicitaram sincronização extensa;
6. Determinar o desempenho de cada implementação do sistema operacional em pesquisas paralelas implementadas com threads;
7. Determinar o desempenho de cada implementação do sistema operacional nos processos com threads que tiveram os requisitos de processador espalhados.
Quanto ao ambiente dos experimentos, trata-se de uma mesma máquina para ambos os sistemas, com PPro SMP e 512Mb de RAM e um grande HD. O modo de instalação do SO foi dual-boot, com as versões de Solaris 2.6 e Windows NT Server, versão 4.0. O compilador utilizado foi o GNU gcc versão 2.8.1.
Para descrever os experimentos a seguir, será usado em conjunto a análise crítica dos resultados apresentados a cada etapa.

O primeiro experimento mensura a quantidade máxima de objetos do nível de kernel que cada SO poderia criar. Para o NT em 24.12 segundos foram criados 9817 threads contra 2294 threads no Solaris em apenas 2.68. Contudo para o Windows foram necessários 68MB de memória enquanto no Solaris apenas 19MB. Porém, o objetivo desse primeiro processo era observar a quantidade de threads que cada sistema conseguiria criar e nesse ponto o Windows NT obteve um melhor resultado como visto acima, pois no Solaris, quando se obteve o número de 2294 apresentou uma falha.

No segundo experimento foi abordada a velocidade de criação dos threads. Os sistemas operacionais Windows NT e Solaris apresentaram um desempenho parecido, no caso do Solaris para Threads agregadas. Segundo o autor isso pode ser atribuído devido o fato de que cada SO requer System Call (chamadas de sistema) para a criação dos threads. Quando o Solaris utilizou apenas uma chamada da biblioteca o desempenho do mesmo superou o NT, através dos threads independentes. Para o caso do CL=4 no Solaris apresentou um bom desempenho, porém muito inferior ao caso dos threads independentes. Com esse segundo experimento pode-se observar que para o caso dos threads independentes, onde há uma chamada à biblioteca de threads o desempenho supera o NT e até mesmo as outras formas de criação utilizadas no Solaris. Isso pode ser observado através dos tempos apresentados na tabela 2 da seção 3.2.
Também abrangendo a criação de threads tem-se o terceiro teste. Nesse caso, mediu-se a velocidade de criação dos threads da mesma forma que o teste anterior, porém com sobrecarga de threads no processador. Mais uma vez nesse caso o Solaris superou o Windows NT. O terceiro experimento retrata uma realidade corriqueira para os processadores e processos e através do teste em questão se pôde observar a veracidade dos fatos.

No quarto experimento foi determinado o desempenho que cada implementação de thread poderia atingir para os processos sem requisição de sincronização. O thread teria que ficar ociosa por 10 segundos até ser concluído, após sua conclusão o processo de criação poderia se findar. As diferenças entre os dois SO’s são sutis, exceto para os threads unbound, que apresentaram valores muito acima do NT. Devido à ligação entre o thread unbound e a CL=4, essa última impactou no tempo de chamada do thread unbound o que fez com que a mesma executasse em tempo 10N.

O quinto teste é semelhante ao quarto, contudo, a sincronização nesse caso é requerida. Para tanto, utilizou-se o programa “array.c” que implementa a criação de threads para modificar dados compartilhados em uma estrutura de 10.000 iterações. A cada momento que um thread necessitava modificar um dado compartilhado era requisitada uma exclusão mútua. O Windows NT apresentou dois objetos de exclusão mútua: o mutex e a sessão crítica. Já o Solaris utilizou apenas o mutex. O desempenho no Solaris foi consideravelmente melhor especialmente com o processo de CL=4. Contudo o NT apresentou bons resultados quando utilizou sessão crítica. Acredita-se que essa otimização é devido o fato de que na sessão crítica há um objeto usuário simples que apresenta um estado global.

O sexto teste aborda a pesquisa paralela com threads que requisitam sincronização limitada. O autor implementa nesse teste o problema do caixeiro viajante. Os threads foram implementados no paradigma de pilha de trabalho. Como resultado, o NT apresentou um desempenho fraco quando uma sincronização foi requisitada. O interessante nesse experimento é que o NT supera ligeiramente o Solaris. Um resultado surpreendente, visto que no teste anterior, utilizando chamada síncrona o NT apresentou um desempenho inferior. Outro ponto interessante apresentado pelo autor é que utilizando uma ou mais thread unbound no Solaris o desempenho foi o mesmo que utilizando dois threads encadeados no mesmo SO.

O último experimento demonstra como cada implementação de thread de sistema operacional desempenharia em processos que apresentam muitos threads com explosão (espalhamento) de CPU (bursts). Pode-se citar como exemplo os processos de E/S como, uma rede ou uma aplicação de cliente/servidor. O tempo de espera foi determinante nesse teste e no desempenho dos SO’s. O Solaris utilizando concorrência restrita apresentou um resultado um pouco melhor que o NT.
Enfim, o autor conclui o estudo afirmando que ambos os Sistemas Operacionais foram aptos para a utilização de multiprocessadores. Um fator pertinente para o problema de desempenho de cada sistema foi a falta de documentação. O sistema Windows NT apresentou ótimos resultados quando se utilizou a sessão crítica, porém, na maioria dos outros testes o Solaris apresentou melhores resultados, algumas vezes muito próximo ao NT, especialmente na utilização das unbounds threads. Realmente esses aspectos foram observados no estudo. Ele cita ainda, o POSIX (Portable Operating System Interface) como solução para padronização de threads e assim, quem sabe, uma otimização gradual dos threads em todos os Sistemas Operacionais, presentes ou futuros.

O estudo demonstra ainda que embora o Solaris seja um Sistema considerado em alguns pontos superior aos demais, alguns aspectos precisam ser melhores aproveitados. Já o Windows NT, um sistema criado pela Microsoft para complementar as distribuições do Windows, com foco empresarial, demonstra alguns pontos inferiores ao Solaris, contudo, o mesmo pode ser explorado para programação paralela e sessão crítica.
Enfim, com esse estudo, pode-se observar que do ponto de vista de Sistemas Operacionais e seus recursos, tudo é relativo, ou seja, cada categoria de thread é melhor ou pior em determinados momentos e com determinados ambientes, tanto no Windows NT quanto no Solaris.


Resenha escrita por:
Daniel H. Carrara de Azevedo
Mestrando em IA - UFU
E-mail: dhcarrara@gmail.com