Naquele momento, sabia apenas que em um mês faria uma prova de admissão para o bacharelado em fotografia no Senac e cria que minha vida seguiria dali. E de fato seguiu, mas não pelos rumos delineados: no meio tempo encontrei minha esposa, mudei-me de Brasília para São Paulo e para o Rio e por fim retornei ao ramerrame que havia deixado em janeiro de 2004, cansado de uma carreira que até então via como limitada. Era necessário pagar as contas.

Eu não esperava encontrar, todavia, o interesse pela escovação de bits que me guiva lá pelos meus 15 anos. Tirei teias do pouco que sabia e desde então adquiri um gosto que às vezes me impressiona. E que também angustia. Gostar tanto de novo faz com que eu queira trilhar caminhos um tanto mais íngremes e perigosos quando se passa de uma certa idade.

O renascimento do prazer em me aprofundar traz aquelas dúvidas sobre o que fazer, e aí se sobressai a inconsistência nos planos: começo com um que repenso por dias a fio e se transforma em outro, que rui para dar espaço a mais um outro, até que me vejo fazendo nada. O meu SICP figura sobre a mesa branca que comprei com Bia uma tarde dessas, e que de tanto gosto, mas não consigo fazer nada com ele. Não me decido se me encafurno num curso universitário, mesmo que particular, e saio de lá com um papelito que me dê acesso às coisas que me interessam ou se apenas aproveito esse ímpeto para ser o melhor auto-didata possível. Estou engessado, no momento.

Há três anos eu seria fotógrafo em 2007. Profissional, encerrado em cliques e sombrinhas e smart sharpens. Em 2007 eu quero ser um bom pensador da computação, descambar pro mercado financeiro, e ser pai e legal com minha esposa. Ainda não sei como conciliar isso tudo. Que será que me aguarda em 2010?

O gráfico está dividido em duas partes. À esquerda, o algoritmo calcula as correntes para todos os naturais entre 1 e 999999 e retorna a maior delas. Analisando o problema, percebi logo que as maiores correntes acontecem em números ímpares, então refiz os testes pulando os números ímpares. Curiosamente, pular os ímpares na versão com RubyInline (Ruby + C no gráfico) fez com que o programa ficasse um pouco mais lento.

A YARV executou a primeira versão em 32″ (contra 22″ do C# rodando no mono e 15″ no Java 6), e em 18″ na segunda (contra 9″ no C# e 8″ no Java 6). Se compararmos à do Ruby puro, é um ganho de 87% na primeira versão e de 76% na segunda. Nada mau, mesmo, Koichi.

Só para constar, testei o Python 2.5, que teve uma performance bem superior à do Ruby puro — mas nada de encher os olhos. C é hors concours, e executou em 1″ na primeira versão e em 0.8″ na versão pulando os pares.

Levando em conta o caráter experimental da YARV e as prováveis otimizações vindouras, acho que posso ficar tranqüilo quanto ao futuro da linguagem. Sei que para muitos casos Ruby resolve e que muita gente está feliz, mas todo mundo se beneficiará de um segundinho a menos aqui ou acolá. Esse nível de performance com a flexibilidade que experimentamos no Ruby 1.8 me põe um sorriso no rosto.

Como a intenção é me divertir e aprender mais Matemática, escolhi o Ruby pra ser meu amigo na jornada. É o que me dá aquela sensação de bem estar agradável, e eu confesso que adoro escrever array.inject {|k, v| k * v} e alterar Fixnum para colocar um método factors babaca.

O lance é que eu não sou lá brilhante, então nem sempre tenho a abordagem mais eficiente de cara (ou mesmo o ferramental matemático para chegar até ela). Alguns dos problemas também exigem um pouco de força bruta, então quando chega na hora do bichinho ter de fazer muitas multiplicações e divisões para ficar dentro da marca ideal de no máximo um minuto de execução, Ruby fica mais pra Rubinho.

Sabendo que seria assim, decidi que seria o melhor momento para ver qual é a do RubyInline. Eu tinha escrito métodos para fatorar e verificar se um número é primo que se comportavam bem com números abaixo de 10 mil, mas que começavam a tartarugar acima disso. Num problema como o décimo, em que deve-se obter a soma de todos os números primos abaixo de um milhão, a performance era risível.

Reescrevi os meninos todos em C. De três minutos para o problema 10 em Ruby puro, passei para 13 segundos (com a compilação do módulo inline). E não tem nada demais na versão em C, nenhum deslocamento de bit maluco, nada. Minha implementação original para problema 14, totalmente força-bruta, teve um ganho ainda maior: saiu de aproximadamente 4’30″ para 3.6″.

É muito reconfortante ter a opção de melhorar dramaticamente a performance quando necessário. É óbvio que ter um runtime tão pouco eficiente quanto o interpretador do Matz não ajuda muito a linguagem (ao menos até a maturidade da YARV), e que isso deve ser consertado quanto antes. Mas a API em C super bacana e a robustez da mais tried-and-true das linguagens faz com que a ponte fique muito fácil de se atravessar.