Resolvi então baixar um programa de benchmark, mas só achei um bem velho (que usa como referência o Pentium 90, ou seja, muito velho) chamado nbench. Tentei rodar o programa, mas na versão 32 bits do linux não funcionou legal, só que como o autor explica esse não é um benchmark para máquinas multi-core, resolvi que vou adaptar (mas devagar né?) o programa (que já está pronto) para uma versão paralela a fim de testar máquinas multi-core.

De qualquer forma não serviu para o que eu queria, então resolvi fazer o mais básico possível, um simples programa de multiplicação de matrizes, baseado em pthreads usando memória compartilhada e rodar ele nas 3 máquinas a fim de chegar a alguma conclusão. Aí sim fez diferença! Para começar já abusei do gcc colocando os parâmetros -O3 e -march=amdfam10, que segundo o guia de referência da própria AMD são opções de otimização agressivas, com essas opções os resultados foram impressionantes! Depois eu coloco os números, mas o Phenom ficou 4x mais rápido que o Turion.

Agora quando utilizo a máquina virtual Lua com paralelismo, o programa no Phenom fica 2x mais lento que no Turion, ainda não consegui desvendar o mistério, acredito que tem a ver com erros de cache, troca de contexto e com a impossibilidade de aplicar as mesmas otimizações, o que me incomoda é que eu esperava pelo menos que ficasse igual, mas não pior.

De volta a prancheta.

Usando, BOINC, a mesma plataforma do projeto SETI@home (dedicado a procurar por vida extra terrestre), o projeto MilkyWay@home está aproveitando a colaboração de usuários do mundo todo para calcular de forma distribuída para mapear a forma de nossa galáxia. Atualmente essa plataforma superou, em poder de computação o segundo supercomputador mais rápido do mundo (atualmente claro, porque essa lista sempre muda, nota mental: “eu quero um supercomputador”) atingindo um petaflop (peta = 1.000 giga = 1.000.000 mega = 1.000.000.000 kilo = 1.000.000.000.000 operações de ponto flutante por segundo.)

Em paralelismo usamos essa conta de operações em ponto flutuante por segundo porque são as operações mais pesadas para um computador executar E são muito utilizadas em sistemas de computação científicos.

Na página do projeto BOINC podemos achar uma lista de projetos que usam essa plataforma variando de aplicações em astrologia, bioinformática até a jogos e aplicações matemáticas (eu já disse que eu quero um supercomputador?)

O interessante é que qualquer pessoa pode participar, basta instalar um programa em sua máquina que funciona de forma semelhante a um screensaver, ou seja, quando você deixa usa máquina parada (sim, quando você vai para o banho e deixa a máquina ligada baixando coisas) o programa entra em ação, recebe dados do servidor central e começa a usar o poder de processamento (calma, não vai atrapalhar seu download) para calcular alguma coisa útil para a humanidade.

Um projeto bem legal, mas que não consegui determinar se usa a plataforma BOINC é o folding@home, inclusive com uma versão para PS3 que pode ser baixada diretamente via PS3Network, e roda no PS3 como se fosse um jogo. Isso foi uma coisa que me interessou porque gostaria de disponibilizar minha plataforma de doutorado no PS3 dessa forma, mas quando entrei em contato com o pessoal de Stanford eles me disseram que foi um desenvolvimento em conjunto com a Sony, ou seja, eu não conseguiria fazer isso sozinho. Bom seria necessário um kit de desenvolvimento específico para o sistema do PS3 (GameOS) e é exatamente essa ferramenta que não está disponível, essa ferramenta permite compilar um programa para rodar no PS3 como se fosse um jogo, afinal jogos são programas de computador também

Eu nunca usei o produto, até porque nem tenho programas em COBOL, mas é uma alternativa interessante para quem precisa manter aqueles programas do legado e quer mais facilidades. Lembro que nos meus tempos de EDS havia um grande buzz em torno do conceito de Application Modernization (modernização de aplicações) foram inclusive considerados produtos que permitiam avalizar o fluxo de chamadas entre módulos de programas COBOL para poder identificar o que eram regras de negócio e o que precisava realmente ser abandonado.

O fato que ninguém quer assumir é que não dá para jogar fora programas com 30 anos de execução, que você SABE que funcionam pelo simples fato de estarem rodando há tanto tempo. Tentar reescrever muitas vezes é a receita para o desastre porque você terá que revalidar as novas aplicações e garantir que está tudo certo, mas não temos hoje nenhum método ou ferramenta de teste que garanta 100% de cobertura de testes, mesmo que tal ferramenta existisse, seria impossível garantir que todos os casos de teste foram pensados. Ao longo dos 30 anos de existência aqueles programas COBOL foram testados, corrigidos, modificados e isso é uma coisa que só com o tempo para garantir a estabilidade.

A própria IBM investiu em um caminho contraditório, disponibilizou para mainframe (plataforma Z/OS) o Websphere e o Java de forma que você pode dentro do seu programa COBOL (que funciona há 30 anos) fazer uma chamada para um novo componente EJB feito em Java, pode também encapsular seu módulo COBOL em um EJB e expor para o mundo via WebService. Aí você pensa “duvido! isso não funciona!” mas nesse caso eu posso dizer que funciona porque trabalhei em um projeto assim na EDS, aliás meu último projeto por lá. O único inconveniente (não sei como está agora) é que a própria IBM não tinha muita experiência nesse tipo de integração então algumas dúvidas ficavam muito perdidas. Uma das coisas que foi legal de descobrir futucando manuais,  experimentando e lendo código fonte de outras plataformas é que essa integração (do Enterprise COBOL 4.3 ou superior) com o Java é feita via JNI (Java Native Inteface) então quando você quer referenciar no COBOL uma classe Java precisa fazer isso usando “/” como separador de pacotes ao invés de “.” para ficar mais claro:

java/lang/String ao invés de java.lang.String

Mas fora isso funcionava bem direitinho.

Conversamos bastante sobre isso, é existem alguns pontos a se considerar, temos uma grande quantidade de código Java escrito para sistemas corporativos, realmente a representatividade do Java atualmente lembra a do COBOL. Eu ainda não sei se concordo totalmente, mas especula-se que o Java como linguagem esteja em seu momento de declínio, por ser mais difícil que as outras linguagens. Não sei se acho tão complicado assim, na verdade existe um grande fantasma que diz que Java é muito difícil (embora eu concorde que é necessário estudar bastante para dominar.)

Por outro lado a plataforma Java apresenta grande sucesso, tanto na parte de componentização atual quanto na questão do uso da máquina virtual Java mesmo para outras linguagens, atualmente existem implementações de outras linguagens para rodar sobre a máquina virtual, e acredito que principalmente porque é muito chato ter que recompilar a sua linguagem para cada uma das plataformas, se você pensar que já tem uma empresa (Oracle/Sun) que cria uma máquina virtual para diversas plataformas físicas e isso garante que o ambiente da sua linguagem vai rodar em outras plataformas, porque ter esse trabalho todo?

Uma coisa importante para se considerar sempre é o índice TIOBE que mantém um ranking das linguagens de programação e Java e C continuam lá no topo, outras linguagens têm subido e descido como sempre. Uma que ganhou muito espaço foi Objective-C, porque? Porque é a forma de criar aplicações para iPhone.

Acredito que outras tecnologias apresentam certas facilidades para desenvolver sistemas de forma rápida, tais como Ruby on Rails e até mesmo PHP, mas quando falamos de implementar a parte que dará suporte às regras de negócio, a parte de lógica ainda acredito em usar o Java, principalmente pela grande quantidade de facilidades que temos disponíveis para ajudar no desenvolvimento.

Vamos continuar acompanhando para saber o rumo dessas mudanças no mundo de desenvolvimento.

Já vinha planejando escrever sobre ICEFaces (http://www.icefaces.org) há algum tempo, mas estava esperando experimentar mais com a biblioteca. Há algum tempo através me solicitaram buscar uma solução para desenvolvimento de interfaces de usuário para web que fosse ágil e fácil de programar e, se possível, que permitisse edição visual. Com essas características eu pensei no projeto (agora extinto) Woodstock da parceria Sun/Netbeans que permitia a edição visual de telas baseado em tecnologia JSF, quando comecei a ler descobri que a Sun estava abandonando o projeto e passaria a apoiar a implementação ICEFaces, da ICESoft, que também provia uma forma visual de editar as páginas e estaria incorporando a compatibilidade com projetos Woodstock.

Na época o Netbeans estava na versão 6.5.1, fiquei animado e experimentei a ferramenta, fácil de usar, fácil de integrar, mas logo em seguida o Netbeans mudou a estrutura do núcleo e o resultado foi que cortaram o suporte a edição visual, mas a Sun continuou apoiando a implementação ICEFaces, embora a Sun forneça uma implementação de referência de JSF, existem por aí outras opções as mais expressivas são MyFaces (Apache), RichFaces (JBoss) e ICEFaces (ICESoft.)

A primeira coisa que me levou a considerar a implementação ICEFaces foi a questão de a própria Sun apoiar esse desenvolvimento, a partir disso eu comecei a procurar os componentes, na versão 1.8.2, que é a que estamos usando em projeto, existem mais de 54 componentes gratuitos, isto porque a ICESoft oferece um modelo de licenciamento para empresas que dá acesso a alguns outros componentes, além disso a parte de tutorial e exemplos é muito fácil de entender e usar.

Ao longo do projeto fomos descobrindo outras funcionalidades o que só confirmou a escolha acertada que fizemos em usar o ICEFaces, a parte de layout e de panéis e muito funcional, a demonstração dos componentes pode ser encontrada em ICEFaces Component Showcase e como era de se esperar o site deles é todo feito em ICEFaces. Outra característica interessante é o uso intenso de ajax de forma totalmente transparente, o usuário não precisa se preocupar, além disso os componentes funcionam em diversos browsers sem que seja necessário escrever nada de javascript.

O fórum também é bem ativo é costuma ser fácil de conseguir as respostas para os problemas mais comuns que temos, utilizamos o Facelets junto com o ICEFaces, sendo que já vem uma biblioteca de integração fácil de usar, uma ressalva importante é que foi muito mais fácil de fazer funcionar no Glassfish do que no JBoss, isto porque no JBoss já existem as bibliotecas do RichFaces então torna-se necessário indicar no web.xml que estamos fornecendo as bibliotecas de implementação. Um outro problema é que o JBoss (5.1) não consegue injetar dependências (tipo EJB3) em managed beans, apenas em classes que foram declaradas no web.xml tais como Servlets e Listeners, isso é uma coisa realmente incomoda (até porque no Glassfish isso funciona facilmente.)

Finalmente a única pendência que está me incomodando fortemente é que não temos uma solução de testes unitários funcionando corretamente, comecei a testar o JSFUnit desenvolvido pela JBoss, mas ele entra em loop durante o processamento, embora seja possível testar alguns componentes de tela eu estava mais interessado em testar os managed beans e isso ainda não é possível, está na minha lista de trabalho recompilar o JSFUnit com algumas modificações, mas isso está longe do topo de prioridades.

No total é uma ferramenta muito boa e fácil de usar, recomendo fortemente. Em breve vou começar as experiências com a versão 2.0 que implementa a especificação JSF 2.