Leandro A. F. Pereira

Fiz o upload do AutoPackage do beta do HardInfo 0.4.3. Esta versão inclui algumas novidades:

• Benchmarks com suporte a processadores multicore
• Suporte à interfaces de rede sem fio (mostra coisas como SSID, potência de transmissão, etc)
• Suporte à DMI (mostra o fabricante da placa mãe, etc)
• Exibição da alocação de recursos de I/O (portas de I/O, memória e DMA)
• Suporte à nova interface de USB do kernel 2.6
• Polimento da interface gráfica
• Melhorias na estabilidade, consumo de memória, etc

Está disponível aqui, por enquanto apenas para x86. Agradeço quem puder testar e comentar.

A OpenMP é fantástica: poderosa, fácil de usar e há suporte para vários compiladores. Entretanto, nem sempre é possível (ou desejável) usá-la; eu não gosto de aumentar o número de dependências dos meus programas, portanto tento encontrar soluções “feitas em casa” quando possível. Reinventar a roda também é uma boa maneira para aprender como as coisas funcionam.

Uma das funcionalidades que os usuários do HardInfo mais pedem é a realização de benchmarks levando em consideração máquinas multiprocessadas. Somente depois de conhecer o modelo fork-join que a OpenMP usa, que eu consegui implementar isso no HardInfo. Para quem não conhece esse modelo, é bem simples: em pontos paralelizáveis de seu código, n linhas de execução são criadas (aqui, n equivale ao número de núcleos) — e a execução linear do programa só retoma após um ponto de encontro. A criação das threads é o “fork”, e o ponto de encontro é o “join”.

A OpenMP facilita a vida provendo alguns #pragmas: o compilador com suporte a ela, então, gera o código responsável pela criação das threads e pelo ponto de encontro. Um desses pragmas é o “parallel for“, que divide um laço ao estilo do for em n linhas distintas. Essa construção tem suas limitações — só deve ser usada em laços vanilla: aqueles que apenas contam de um número até outro (a linguagem C permite fazer praticamente qualquer coisa num for e isso não é suportado pela OpenMP).

Como os benchmarks do HardInfo são geralmente feitos dentro de um laço for, repetindo testes pequenos várias vezes e contando o tempo (o que causa alguns problemas de precisão, mas ainda não consegui encontrar maneira melhor), recriar essa construção do OpenMP foi a saída mais natural.

A recriação foi trivial: o modelo é simples e eu tenho como obter o número de núcleos tranquilamente (afinal, o HardInfo é um programa de informações de hardware). Como a implementação foi feita sem requerer suporte do compilador (apenas usando funções), há a necessidade da criação de uma função, e da substituição do laço por uma chamada de função.

Por exemplo, se houvesse o interesse em paralelizar o seguinte código:

for (i = 0; i < 1000; i++) {
    vetor[i] = i * 3;
}

Eu criaria uma função:

void preenche_vetor(guint start, guint end, gpointer data)
{
    int *vetor = (int *)data;
    for (i = start; i < end; i++) {
        vetor[i] = i * 3;
    }
}

E substituiria o laço por uma chamada ao paralelizador de for:

parallel_for(preenche_vetor, 0, 1000, vetor);

A função parallel_for então determinaria o número de núcleos, criaria uma linha de execução para cada elas, e se encarregaria de esperar pelo término de todas elas. Como bônus, ela também retorna o tempo gasto desde a criação das threads até o término de todas elas — ignorados neste exemplo.

Paralelizei dois benchmarks no HardInfo: o de compressão/descompressão com a zlib, e o ray tracer. O ganho, em um Pentium Dual Core (E2160), foi da ordem de 1,86x mais rápido no caso da zlib, e 1,41x no caso do ray tracer.

O código está disponível no repositório git mestre do HardInfo, disponível na minha conta do github.

Depois de realmente testar a D945GCLF, posso falar sobre a placa. Usei esta placa como meu computador pessoal durante uma semana. Usei o Leopard como sistema operacional.

Obviamente que meu Macbook (com um Core 2 Duo de 2.16GHz) come com farinha o Atom de 1.6GHz. Mas a plaquinha se mostrou valente e, para tarefas básicas — que, no meu caso, inclui não somente a internetada básica de todo dia, mas programação leve, edição de textos, — eu diria que é mais que o suficiente. O único porém, é que coisas como vídeos no YouTube (e outros sites de vídeo) dão uma certa engasgaada… mas video em Flash judia até mesmo o C2D, então é perfeitamente perdoável.

Por exemplo: do boot loader até o desktop do Leopard, são apenas 28 segundos. É fato que a instalação do sistema no meu Macbook é mais antiga, mas ela demora pelo menos o triplo disso. E os discos e o chipset das duas máquinas são equivalentes.

Enfim: quem quiser um Macintosh barato, é uma opção legal. Por US$79 (mesmo com o dólar disparado como está), é um excelente negócio. Mas quem quiser um computador secundário (como máquina de downloads, servidor de arquivos caseiro, ou simplesmente para as tarefas do dia-dia), que consome pouco e é muito silencioso, é uma opção tão boa quanto.

Eu gostei bastante da placa. Tanto que eu a vendi! Quando vi que a Intel tinha lançado a D945GCLF2, com o Atom 300 (dual core) e, principalmente, saída S-Video, precisei vender e comprar o modelo mais novo… eu estava querendo montar um HTPC já faz um tempo e essa placa (nova) veio bem a calhar.

O kov escreveu sobre o novo interpretador de JavaScript do WebKit, o SquirrelFish Extreme, e levanta a questão da razão do Google ter desenvolvido o V8 sem real necessidade (já que iriam usar o WebKit de qualquer maneira como motor de renderização de HTML).

Eu poderia dizer que, a princípio, é apenas mais um caso de síndrome de NIH.

Acho que o Google só não reinventou o WebKit pq um interpretador de JavaScript é mais fácil fazer. E o lançamento do compilador Java para o Android, IMHO, diz que o povo lá em Mountain View gosta de brincar com compiladores e interpretadores.

Para fazer um interpretador mais rápido que outro feito por especialistas, requer gente muito foda. E é isso que tem nos times do SF, V8 e SM: cara bão de código. Mesmo acreditando que concorrência seja uma boa idéia, se juntassem os esforços (afinal é tudo free — o problema de licenciamento é “resolvível” com boa vontade) e fizessem uma única implementação teríamos, provavelmente, algo muito legal por aí.

Mas a síndrome de NIH não deixa isso acontecer. Reinventar a roda é bom e às vezes necessário.

O interesse por linguagens dinâmicas está crescendo muito ultimamente. Acho que nenhuma empresa fazendo um novo interpretador de JavaScript esteja dando ponto sem nó: provavelmente estão usando isso como desculpa para desenvolvimento (ou o aprimoramento) de novas técnicas. E é sempre mais fácil trabalhar no seu próprio código que modificar o código dos outros — principalmente quando se está falando de uma reestruturação completa da sua arquitetura.

Eu não tenho acompanhado artigos sobre compilação/interpretação, mas o (antigo, confesso) material impresso que tenho acesso sobre compiladores fala principalmente sobre linguagens de tipagem estática. Isso, em minha opinião, é reforçado ainda mais pela característica acadêmica tanto do Google quanto da Apple.