square a = a * a
 
square_of_sum a b = square (a + b)

Nesse exemplo, quando square_of_sum chama square, o parâmetro passado não é o resultado de a + b, mas sim algo próximo a uma closure que irá calcular a + b. Quando square for avaliada, ela precisará do valor de ‘a’, então usará a closure que recebeu como parâmetro para tal. Ou melhor, funciona quase assim, Haskell implementa um mecanismo chamado call-by-need, que resolve o valor uma única vez na primeira vez que for necessário memorizando o resultado. Isso significa que no caso de square ‘a’ será avaliada uma única vez. Por conta da memorização, não usamos o termo closure, mais sim thunk para descrever o que uma função passa para outra.

Outro detalhe importante, chamadas de função também são lazy evaluated, então tanto square, quanto square_of_sum na verdade retornam thunks para os valores em questão. Essa coisa toda pode parecer extremamente ineficiente a primeira vista e de fato é. Tanto que o GHC gera código sem uso de thunk sempre que conseguir provar que um pedaço de código pode ser strict evaluated [1].

Antes de imaginar como implementar isso em uma VM como a CLR, vamos traduzir nosso exemplo para C# [2]:

 
class Thunk<T> {
	T value;
	Func<T> closure;
	bool resolved;
 
	public Thunk (Func<T> closure) {
		this.closure = closure;
	}
 
	public T Value {
		get {
			if (!resolved) {
				value = closure ();
				resolved = true;
				closure = null;
			}
			return value;
		}
	}
}
 
Thunk<int> square (Thunk <int> a) {
	return new Thunk<int> (() => a.Value * a.Value);
}
 
Thunk<int> square_of_sum (Thunk <int> a, Thunk<int> b) {
	Thunk<int> a_plus_b = new Thunk<int> (() => a.Value + b.Value);
	return square (a_plus_b); //Já que square produz um thunk, não precisamos criar outro.
}

Bem confuso, de certo. Primeiro a implementação de Thunk, simples e direta, já square_of_sum precisa de uma variável local para ficar minimamente legível. Uma coisa é fato, C# não foi feita para ser usada com lazy evaluation.

Existe alguns problema quanto a eficiencia de fazer dessa forma. O maior deles é como lidar quando alguns valores já estão resolvidos e temos ainda assim criar um thunk para satisfazer o função chamada. A forma como GHC lida isso é passando todos parâmetros boxed de forma que é possível misturar thunks e valores sem problema. A função square, do nosso exemplo anterior ficaria assim:

 
Thunk<int> square (object a) {
	return new Thunk<int> (() => {
		int val;
		if (a is int)
			val = (int)a;
		else
			val = ((Thunk<int>)a).Value;
		return val * val;
	});
}

Outra forma de também lidar com esse problema é criar duas versões da mesma função, uma que recebe valores resolvidos e outra apenas thunks. Fazer dessa forma é vantagem quando podemos provar o uso estrito dos valores em questão. Por fim, acho que o maior problema ser achar uma forma de representar um thunk usando o mínimo possível de memória.

No nosso exemplo, em uma plataforma 32bits, Trunk usa 20 bytes, Func usa mais 40 e outros 8 da closure[3]. Ou seja, começa usando 68, coisa pacas. Podemos fazer algumas mudanças nisso. Dado que não existe null em Haskell podemos remover o atributo resolved e simplesmente verificar se closure é ou não null. Segundo, em vez criar 1 delegate toda vez podemos fazer caching dele e armazenar as variáveis capturadas no próprio thunk. Algo como:

abstract class Thunk<T> {
	public abstract T Value { get; }
}
 
class ThunkWithVars<T,V> : Thunk<T> {
	T value;
	Func<V, T> closure;
	V vars;
 
	public ThunkWithVars (Func<V,T> closure, V vars) {
		this.closure = closure;
		this.vars = vars;
	}
 
	public override T Value {
		get {
			if (closure != null) {
				value = closure (vars);
				closure = null;
				vars = default (V);
			}
			return value;
		}
	}
}
 
static Func<Thunk<int>, int> square_resolve = (a) => a.Value * a.Value;
 
Thunk<int> square (Thunk <int> a) {
	return new ThunkWithVars<int, Thunk<int>> (square_resolve, a);
}

Usando essa codificação Thunk continua usando 20 bytes porém nos livramos dos demais objetos, um ganho de 70% no final das contas. Poderíamos economizar outros 4 se juntarmos as variáveis closure e value em uma só caso T fosse do tipo referência – ou manter o resultado boxed. Mesmo sem isso, 20 bytes já é um valor razoável, conseguir o mesmo em uma JVM é basicamente impossível sem muita ginástica.

Qual a performance dessa solução? Segundo o pessoal do GHC, em média 95%-98% dos thunks gerados são resolvidos. Com um generational GC, a maioria vira lixo efêmero. Ou seja, não existe muita razão para uma VM tradicional ser mais lenta que a do GHC, o principal fator nesse caso é, sem dúvida, o compilador, que pode gerar pedaços de código inteiros sem uso de thunk.

[1] É muito comum em Haskell gerar código que não funciona sem lazy evaluation, como geradores de listas infinitas.
[2] Nesse exemplo vou trapacear e tornar as funções mono-mórficas e usar int no lugar de Number para simplificar o código.
[3] Nesse caso estou ignorando quanto de memória as variáveis capturadas usam.

Uma type class para os acostumados com OO pode ser vista como uma interface cuja implementações são externas aos tipos que estão atrelados. Um exemplo bem simples é Eq, que permite compar objetos do mesmo tipo:

class Eq a where
    (==), (/=) :: a -> a -> Bool
    x /= y = not (x == y)
    x == y = not (x /= y)

Para nos não iniciado em Haskell, linha um define a classe Eq e diz que ela possui um parâmetro polimófico; linha 2 diz que Eq tem 2 funções, “==” e “/=” cuja assinatura são dois valores do tipo ‘a’ e retorna um booleano; por fim, linhas 3 e 4 são implementações padrão das funções. Seria o equivalente, em pseudo-C#, ao seguinte:

interface Eq<T> {
   bool operator== (T a, T b) { return !(a != b); }
   bool operator!= (T a, T b) { return !(a == b); }
}

Uma das vantagens de type classes no Haskell é que elas podem fornecer implementações padrão para alguns de seus métodos. Bom, agora que temos Eq definida, para dizer que Listas a implementa usamos algo como:

instance Eq a => Eq [a] where
    [] == [] = True
    (x:xs) == (y:ys) = x==y && xs==ys
    _ == _ = False

Aqui vemos uma das melhores características do Haskell é explorada, que é pattern matching – e isso também é assunto para outro artigo. Como pode se notar, uma implementação de uma dada type class não está embutida na definição do tipo em questão, ou seja, não podemos interfaces como a CLR ou a JVM suportam.

A idéia é representar type classes de forma semelhante a como o ghc faz, usando dictionary passing[1], que é bem simples de entender e implementar. Para cada type class que uma função recebe nos seus parâmetros, passamos junto um objeto que representa as operações em questão. Em C# teríamos:

interface Eq<T> {
    bool op_eq (T a, T b);
    bool op_neq (T a, T b);
}
 
class Eq_Int : Eq<int> {
    public bool op_eq (int a, int b) { return a == b; }
    public bool op_eq (int a, int b) { return a != b; }
}
 
int Fun<T> (Eq<T> dict, T a, T b) {
    if (dict.op_eq (a, b))
        return 1;
    return 0;
}

Existe alguns problemas aqui, primeiro que estamos passando um parâmetro extra e segundo que não é possível eliminar a verificar por null pointer caso op_eq seja inlined. A solução é razoavelmente simples no caso do C#:

struct Eq_Int : Eq<int> {
    public bool op_eq (int a, int b) { return a == b; }
    public bool op_neq (int a, int b) { return a != b; }
}
 
int Fun<T, TD> (T a, T b) where TD: Eq<T> {
    if (default (TD).op_eq (a, b))
        return 1;
    return 0;
}

A grande mudança aqui é tornar a instância da typeclass um valuetype e construir um valor default para satisfazer o compilador. É uma pena que não podemos simplesmente chamar um método estático e TD, o que é uma limitação boba da CLR. Essa solução não é possível na JVM devido a inexistência de valuetypes e generics.

E quanto a performance dessa solução? Bom, no caso do mono, o JIT’er reconhece as chamadas como não virtuais e é capaz de fazer inline de forma bem agressiva – exatamente como desejado. Eu pensei em fazer um comparativo dessa solução com o equivalente em Java, mostrando como a CLR permite codificar tipos muito mais ricos e interessantes que a JVM – e como isso se traduz em performance. Mas realmente não estou afim de criar motivo para um flamewar por parte dos javeiros de plantão.

[1]Esse é o paper original que descreve type classes e a técnica utilizada: http://homepages.inf.ed.ac.uk/wadler/papers/class/class.ps.gz

A impossibilidade utilizar a unidade vetorial a partir de linguagens gerenciadas sempre foi uma das principais críticas dos desenvolvedores C e C++ sob a viabilidade em utilizá-las para código rico em calculo matemático. Isso agora é passado e usando mono e C# é possível gerar código com de alta performance similar ao possível com linguagens de baixo nível.

Para se ter uma ideia das possibilidades, um simples exemplo que transforma uma série de vetores com uma mesma matriz chega a ser 3x mais rápido usando Mono.Simd que o código não vetorial em C, Java ou C#. Isso sem perder as vantagens de se utilizar uma linguagem de alto nível e segura. Mas vamos ao código:

//Primeiro transformação usando ponto flutuante normal
    public static void Transform (ref Matrix matrix, ref Vector vector, ref Vector result)
    {
        result.x = vector.x * matrix.m00 + vector.y * matrix.m01 + vector.z * matrix.m02 + vector.w * matrix.m03;
        result.y = vector.x * matrix.m10 + vector.y * matrix.m11 + vector.z * matrix.m12 + vector.w * matrix.m13;
        result.z = vector.x * matrix.m20 + vector.y * matrix.m21 + vector.z * matrix.m22 + vector.w * matrix.m23;
        result.w = vector.x * matrix.m30 + vector.y * matrix.m31 + vector.z * matrix.m32 + vector.w * matrix.m33;
    }
 
//Agora usando Mono.Simd
    public static void Transform (ref Matrix4f matrix, ref Vector4f vector, ref Vector4f result)
    {
        Vector4f v = vector;
 
        Vector4f r0 = v.Shuffle (ShuffleSel.XFromX | ShuffleSel.YFromX | ShuffleSel.ZFromX | ShuffleSel.WFromX);
        Vector4f r1 = v.Shuffle (ShuffleSel.XFromY | ShuffleSel.YFromY | ShuffleSel.ZFromY | ShuffleSel.WFromY);
        Vector4f r2 = v.Shuffle (ShuffleSel.XFromZ | ShuffleSel.YFromZ | ShuffleSel.ZFromZ | ShuffleSel.WFromZ);
        Vector4f r3 = v.Shuffle (ShuffleSel.XFromW | ShuffleSel.YFromW | ShuffleSel.ZFromW | ShuffleSel.WFromW);
 
        r0 = r0 * matrix.row0;
        r1 = r1 * matrix.row1;
        r2 = r2 * matrix.row2;
        r3 = r3 * matrix.row3;
 
        result = r0 + r1 + r2 + r3;
    }

O código usando Mono.Simd fica um pouco mais complexo, principalmente até se entender como Shuffle e outros combinadores funcionam. Porém quando executado, a versão tradicional precisa executar 16 operações de multiplicação e 12 de soma contra 4 multiplicações 3 somas simd na versão vetorizada. A diferença é clara e o números também.

O release 2.2 foi o resultado de muito esforço pelo time por traz do mono e todos seus contribuidores. Esse release, porém, é especial para mim pois Mono.Simd é resultado de alguns meses de trabalho meu e fiquei muito feliz com a repercussão positiva que recebemos – vários projetos estão estudando como implementar bibliotecas de matemática vetorial usando ela.

Hoje a maioria ainda está no estágio de possuir um interpretador razoável e estar começando a investir em algum mecanismo primitivo de compilação para código nativo. Talvez a única diferença seja o uso de inline caches para resolução de nomes, que foi uma contribuição significativa do pessoal do Self no começo dos anos 90. Porém os principais resultados obtivos por pesquisas a um bom tempo, como tracing, especialização e especulação não deram as caras ainda.

Inline caching é uma optimização no qual o resultado da resolução de nomes, para dispatch de método por exemplo, é armazenado entre ativações distintas. O truque é introduzir uma clausula de guarda que verifica o tipo do objeto seletor e sua versão. Caches devem ser invalidados sempre que alguém alterar uma classe. Temos dois tipos de cache, os monomórficos que fazem caching de apenas uma invocação e os polimórficos, que armazenam uma série de resultados. Para melhor vamos exemplificar com pseudo código:


//ruby
def test (a)
a.foo
end

//pseudo-código do delegate depois de chamarmos test ("str")
object test_site_0_v2 (object _this) {
if (_this.Type == typeof (int) && _this.version == 1)
return ((int)_this).foo ();
if (_this.Type == typeof (string) && _this.version == 1)
return ((string)_this).foo ();
return ResolveAndInvoke (a, "foo", ref test_site_0);
}


Como fica claro pelo exemplo, um cache polimórfico tem uma performance superior pois usa literais e funciona muito melhor no caso de não existir um tipo dominante entre as ativações. Aqui fica clara a limitação de uma das implementações, o JRuby não pode se dar ao luxo de gerar tantos métodos pois cada um precisa de uma classe e um classloader novos, ou seja, abusa da PermGen do Java.

Apesar de inline caches resultarem em ganho expressivo de performance, estão longe de produzirem algo razoável. O grande problema continua sendo o enorme custo de dispatch para código simples. A chave disso é fazer inferência dos tipos, de forma a conseguir eliminar por completo o overhead dos caches e resolução de nomes. As atuais implementações não implementam se quer inferência estática, ou seja, código como “123.to_s” é executado sem qualquer conhecimento prévio de 123.

O grande avanço ocorre se fizemos inferência em tempo de execução. Ou seja, instrumentamos o código para coletar os tipos que aparecem pelo código durante a execução e baseado nisso a máquina virtual gera versões mais eficientes do código. Existem duas técnicas bastante difundidas de como fazer isso, uma é via especialização parcial de métodos e a outra é via trace-based optimization.

Trace-based optimization é a tecnologia adotada pela Tamarin, a próxima VM de Javascript da Mozilla. De maneira sucinta, essa técnica consiste em gravar os trechos, e os tipos encontrados, que executam mais freqüentemente e gerar código eficiente baseado nessa informação. Os trechos gravados costumam incluir vários métodos diferentes e suas ativações juntas. Suas principais vantagens é a conseguir fazer inlining de métodos de maneira muito eficiente e normalmente gastar menos tempo no JIT. Porém existem uma enorme quantidade de problemas complexos de serem resolvidos como limitar expansão descontrolada da quantidade de código gerado.

Especialização parcial de métodos também leva em conta os métodos que executam mais freqüentemente. Os tipos dos parâmetros e valores de retorno
são armazenados e posteriormente utilizados para gerar versões especializadas dos métodos em questão. Sua principal vantagem é a maior simplicidade
e o fato de existir muito mais literatura e ferramentas para gerar código eficiente nestes casos. Para se ter uma idéia do poder dessa técnica um exemplo cai bem:


//ruby
def fun (a, b)
2 * a - b
end

object fun_v1 (object a, object b) {
if (a.Type == typeof (int) && b.Type == typeof (int) && typeof (int).version == 1)
return fun_int_int ((int)a, (int)b);
object tmp = Invoke (2, "*", a"); //_this, nome do método, argumentos
return Invoke (tmp, "-", b);
}


Não precisa ir muito longe para imaginar a diferença de performance entre as duas versões. Porém entre descobrir os métodos as serem especializados e gerar código de máquina existe um Just-In-Time compiler que é, surpresa, surpresa, muito trabalhoso de ser escrito para executar rapidamente e gerar código eficiente.

Possui um bom JIT é atualmente um grande dilema entre as implementações de ruby. Pois ao usar o JIT de máquinas virtuais maduras, como HotSpot ou mono, a implementação fica limitada ao que é possível a linguagens gerenciadas. Em contrapartida, ao não utilizá-las, construções de baixo nível como profiler e interpretador podem ser implementadas de forma muito mais eficiente.

Apesar de do futuro parecer muito legal, futuras VMs terão o trabalho adicional de educar a comunidade de desenvolvedores sobre como escrever código rápido em ruby. Coisas como monkey patching furam qualquer esquema de caching ou especialização pois cada objeto passa a ter uma singleton class distinta.

Não existe solução fácil e todas implementações tem muito chão pela frente até Ruby ter uma performance competitiva com outras linguagens dinâmicas. Soluções como as aqui apresentadas devem conseguir melhorias de uma ordem de magnitude tranquilamente, de acordo com os resultados já encontrados. Performance é um problema que é resolvido via muito suor, com uma contínua série de melhoras, atacando um pouco por vez.

No primeiro dia, vale a pena contar, que estávamos discutindo sobre a abertura do evento e lembrei de toda palhaçada envolvendo o pagamento de cartões de crédito pelo ministro hacker Gilberto Gil a seus assessores diretos. Disso veio a idéia de protestarmos e surgiu o “Paga meu visa também”. Minha contribuição se resumiu ao “MEU” e dar pilha aos mais criativos que estávamos comigo. Nenhum de nós imaginou que isso geraria qualquer repercussão, mas fico feliz de saber que foi o contrário.

Continuando, participei da criação de um pong usando Quartz Composer com o Villela e o Fabricio. Foi bem divertido e me abriu os olhos para essa ferramenta – definitivamente irei brincar mais com ela.Além disso, aprendi um pouco como usar o pure data, não consegui fazer nada razoavelmente audível, mas é um começo. Aproveitei para ajudar um desenvolvedor do Inkscape com uns problemas relacionados ao C++.

Fora isso descobri que escrever um seletor de instruções na mão é muito penoso e resolvi gerar o código dele a partir de um script escrito em Ruby com várias dicas do Phillip. Assim que o projeto amadurecer e tiver algo para mostrar com certeza irei escrever um artigo sobre o resultado desse experimento.

No geral foi uma semana muito produtiva e divertida. Fiquei inclusive com vontade de ir na edição espanhola do evento. Aos que não foram, a cobertura da imprensa poder dar uma boa idéia da dimensão que foi o CampusParty.

Tive o prazer de conhecer o Rodrigo Oliveira, autor da linguagem boo. Fiquei feliz em vez que finalmente implementaram code quotation, ou quasi-quotations para quem preferir, e pattern matching, de maneira a tornar divertido o uso macros e não a tarefa penosa que era antes disso. Discutindo com ele sobre o DB4O, fiquei muito interessado na forma como eles pretendem implementar transações usando STM. Pessoalmente acho que sistemas prevalentes, o prevayler em especial, são implementações patéticas de um problema que não existe. Por outro lado, com Software Transactional Memory é possivel eliminar aquela coisa horrivel que é a exigência de toda mutação ocorrer através de comandos.

Discuti, ou melhor, tive uma aula com o Massi sobre como fazer a transição para forma SSA de maneira barata e quase linear, além disso ele me apresentou ao conceito de HSSA (Hashed Static Single Assignment), que permite realizar enumeração global de valores enquanto faz a renomeação para SSA – que permite eliminar redundâncias de forma mais agressiva que via CSE. Fora isso ele falou da idéia de que é viável construir um bom alocador de registradores como um passo unificado ao que sai do formato SSA, aproveitando que SSA dá quase que de graça use-def e liveness.

Conheci o Jim Purbrick, o cara da LidenLabs que está usando mono para executar as bilhões de linhas de código de LSL do Second Life. O “pequeno” problema que eles tem é que são dezenas de milhares de scripts executando em paralelo em um mesmo simulador – algo que não é fácil de fazer usando threads. A solução que eles adotaram foi implementar um compilador que transforma todos IL em Continuation Passing Style. Basicamente criando suporte a micro-threading e scheduling cooperativo. Não é algo para quem tem estomago fraco, mas funciona e eles esperam ganhos de performance de duas ordens de magnitude.

Foi muito interessante discutir com meus colegas que também contribuem no runtime e pude verificar que não sou o único que acha que generics é uma coisa extremamente complexa. Em breve estará sendo publicada o roadmap do projeto para o ano de 2008 e tem muita coisa legal adiante – aguardem.

Primeiro instalar o toolchain do OpenMoko segundo essa página do wiki. Lembrando que o monotone por algum motivo não aparece no repositório padrão de pacotes, então tem que baixar via software search. Instalado isso, basta seguir as instruções do wiki e esperar “um pouco” – umas 12 horas em uma workstation rápida.

Agora que o ambiente básico está instalado, importe as variáveis de ambiente do script “setup-env” que está no diretório raiz do toolchain. Instale os pacotes devshell, glib-2.0 e perl-native via bitbake.

Pronto, agora execute a devshell, que deve estar em “tmp/deploy/glibc/addons/”. Vá para o diretório onde está sua árvore do mono que acabou de dar checkout e aplique o patch “/openembedded/packages/mono/files/configure-svnr87352.patch”. Feito isso coloque as autotools para funcionar com “./autogen.sh –without-tls –disable-mcs-build –host=arm-angstrom-linux” e com um pouquinho de sorte o configure executará com sucesso.

Feito isso é só make e “make install DESTDIR=…” para instalar o mono no diretório de destino desejado. Copie para o dispositivo ou o emulador e aproveite!

Eu fiquei por conta de criar um Desklet de calendário e até que me saí bem, dado que desconhecia o WPF pro completo até ontem. Ele ainda tem alguns ajustem a serem feitos e gostaria de se der tempo integrar com o Google Calendar. Por isso se alguém souber como fazer essa integração usando C# por favor entre em irc.gnome.org #desklets e nos ajude a fazer isso, vamos ser muito gratos por isso. ;)