1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

interface A<in B> { }
 
interface B<in A> { }
 
class X : A<B<X>> { }
 
class Y : B<A<Y>> { }
 
class Test
{
	static void Main ()
	{
		A<Y> x = new X ();
	}
}

O código é um enrolado. A parte mais importante é entender interface A<in B> que é a declaração de A contravariante em B. Isso significa, a grosso modo, que A<object> instanceof A<string> == true.

A dúvida é se a atribuição A<Y> x = new X (); é válida. Vou usar <: como notação para
pode ser atribuido em, como em string <: object.

X <: A<Y> //X é uma classe e A uma interface, logo verificamos as interfaces de X
A<B<X>> <: A<Y> //Duas instâncias diferentes do mesmo tipo genérico. Por ser contravariante no primeiro parâmetro, verificamos ele
 
//Note que contravariância significa verificar na ordem inversa
Y <: B<X>  //Y é uma classe e B uma interface, logo verificamos as interfaces de Y
B<A<Y>> <: B<X> //Novamente duas instancias de um tipo contravariante, verificamos o primeiro parâmetro
 
X <: A<Y>

Calma la, voltamos a definição original! Sim, voltamos, existe um ciclo nessa verificação e ela não pode ser decidida. Tanto o compilador como o sistema de tipos são não capazes de decidir. A solução pragmática é simplesmente recusar essa atribuição.

Quem imaginaria que o novo sistema de tipos do C# possui casos que não decidíveis. Pois é, e não fica só nisso, existem outros problemas envolvendo variância como ambiguidade no caso de últimas interfaces que merecem outro artigo.

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

Cada um destes valores possui um forma, que é a representação concreta para o conceito abstrato que cada um significa. Um array de bytes e uma lista de chars são duas maneiras de representar uma string – um conceito abstrato. Forma admite composição e extensão, mas isso é razoavelmente óbvio.

Por comportamento me refiro a um grupo que operações definido que operam em um dado conjunto de valores. Repetindo nosso exemplo, strings, podemos definir particionamento, remover espaços em branco e pois ai vai. Ou seja, nada mais simples que um conjunto de funções.

Por fim, taxonomia é como damos nomes a conjuntos de valores. Ruby, que usa um sistema nominal de tipos, damos um nome explicitamente a um dado conjunto de valores que irão habitar uma classe. Outro aspecto importante é que podemos usar os operadores da teoria de conjuntos para definir relações entre pares. Voltando a Ruby, a única relação é a de subconjunto, que é a herança entre duas classes.

São três elementos bem distintos, porém, linguagens OO misturam dois, as vezes mesmo todos. Por exemplo, classes são os três ao mesmo tempo, atributos a forma, métodos o comportamento e a taxonomia vem através da relação herança entre duas classes. Interfaces misturam comportamento e taxonomia. Mixins misturam forma e comportamento. O problema disso é quando você quer manipular apenas um e os outros vem de brinde.

Linguagens funcionais costumam lidar de forma mais efetiva com esse problema. Haskell separa muito bem isso, com datatypes para forma, funções lidam com o comportamento e typeclasses resolvem a questão da taxonomia. Dessa forma é possível focar apenas em um dos três sem nenhuma bagagem extra.

Um problema com haskell é que uma typeclass classifica todos habitantes de um dado tipo, não é possível fazer isso com uma parte apenas. Nesse sentido Qi possui um sistema de tipos muito interessante, baseado em sequent calculus, permitindo definir de forma mais precisa quais valores compõe um dado tipo.

Eu acredito que essa limitação da orientação a objetos é a razão pelo qual tantas pessoas preferem fugir para linguagens OO dinâmicas, que aliviam boa parte do problema dado que forma e taxonomia poder ser consideradas ad-hoc, agrada a vários, mas realmente não me agrada para construir sistema de grande escala.

Para quem já programou em C, ou mesmo C++, e em uma linguagem de alto nível tais quais C#, Haskell ou LISP sabe o tamanho do sofrimento que é trabalhar com uma ferramenta tão primitiva. Aos incautos não estou me referindo nem me referindo as vantagens óbvias dessas linguagens como gerenciamento automático de lixo, um sistema de tipos rico ou tipagem ou dinâmica[1].

Quando se programa próximo do metal ter um controle e visão muito clara daquilo que é gerado é muito importante, então coisas como verificações inseridas pelo compilador, não ter controle fino sobre a representação dos dados ou simplesmente não podem burlar o sistema de tipos inviabilizam o uso de uma linguagem – por mais estranho que pareça.

Entretanto usar destes argumentos para defender as relíquias que são C e C++ é temerário. Ambas linguagens foram construídas sob as bases do que era avançado em termos de compiladores nos anos 70 e para a capacidade de processamos do começo dos anos 90. Muita coisa mudou de lá para cá, menos o fato de C++ demorar horrores para compilar.

A primeira grande falha do C, e uma que chama muito a atenção, é o sistema de módulos e compilação separada. Que realmente não existe. Em ambas as linguagens se usa inclusão textual de cabeçalhos com declarações supostamente exportadas por outros módulos do sistema e pronto. O problema disso é óbvio se já tiver trabalhado em projetos grandes. O tempo de compilação individual aumenta sem razão aparente, conflitos com o nome de símbolos ocorrem e, em geral, atrapalham a vida de todos.

Continuando com a questão de processamento de texto. Macros em C provavelmente são o recurso mais importante da linguagem, aquele que a tira da lista de inúteis. É bem freqüente encontrar uma infinidade de truques feitos usando macros para sanar a falta de expressividade da linguagem. Porém tão comum quanto é encontrar gente frustada com a dificuldade de depurar um sistema rico em macros. Ao mesmo tempo, programando um dia com LISP qualquer um enxerga que um grande sistema de macros faz qualquer linguagem medíocre ir muito longe.

Por fim, minha última reclamação é devido ao fato de estar em 2009 e ainda ser obrigado a usar uma linguagem sem inferência de tipos. O artigo do Robin Milner tem quase 31 anos e ainda assim sou obrigado a pagear o compilador com aquilo que ele consegue descobrir sozinho. Inferência de tipos é um recurso ainda mais importante quando falamos de sistemas de tipos mais ricos.

Ainda assim, por algum motivo que me escapa, não existe um substituto usável para C ou C++. Talvez seja pelo fato de tal linguagem não possuir muito acadêmico em termos de papers e PHDs, ou que a enorme parte da comunidade de programadores destas linguagens é cega por achar que são o último biscoito do pacote.

[1]Ou latente, caso tenha um fetiche pelo Fowler.

O que exatamente objetos de linguagens comuns, feito C++, oferecem? Basicamente três coisas: layout, interfaces e subtipagem. Uma classe derivada define uma estrutura de dados que é uma extensão do layout daquelas de seus parentes; o mecanismo de funções virtuais é a única forma sã de se definir interfaces; e, por fim, herança é a forma de se definir uma relação de subtipagem entre dois tipos, no caso do C++ classes.

As duas primeiras propriedades são realmente úteis, a terceira é questionável – mas não vamos atentar para isso agora. Não existe uma razão óbvia para deixar extensão estrutural e interfaces atadas uma a outra. De fato, é uma enorme limitação. Java e C# possuem o mecanismo de interfaces para resolver isso, porém ambas exigem que todas sejam definidas de antemão, ou seja, são uma minúscula fração do número potencial de interfaces que suportam. Ou seja, adora um modelo de interfaces prescritivo e não latente.

Algumas linguagens funcionais resolvem este problema adotando alguma forma de tipos de alta ordem*, que permitem uma função ser definida em termos da interface exigida de um objeto e basta este atendê-la para poder ser usado, independente de herança. Pode ser visto, a grosso modo, como um mecanismo equivalente à interfaces no Java ou C# onde cada classe não precisa definir quais suportam, basta implementar os métodos relacionados.

À primeira vista, tipos de alta ordem, ou classes de tipos na terminologia e implementação do Hakell, podem parecer a mesma coisa que templates do C++, porém a semelhança fica apenas na superfície, templates são um mecanismo de macro-expansão estruturada, não existe como validar uma função em sua definição ou uso, é necessário sempre fazer sua expansão para verificar sua validade. Outra diferença gritante é a ampla possibilidade de compartilhar código entre as várias instanciações de uma função que usa tipos de alta ordem. Existe uma longa literatura sobre o assunto e várias formas de favorecer uso de memória ou performance.

Mas voltando a questão de se subtipagem é uma propriedade interessante ou não para uma linguagem ter. Bom, teoricamente é muito interessante poder definir relações de substituibilidade, mas na prática, a maioria dos frameworks não se valem de tal princípio. Um bom exemplo é o pacote de coleções do Java, ela é toda construída em termos de interfaces e herança é usada como uma forma tosca de promover reuso de código.

O súbito interesse por linguagens funcionais nesses últimos anos vem trazendo a tona uma série de avanços que estas linguagens possuem e estavam até então restritos à comunidade científica. Está mais que na hora para começarmos a repensar todos os antigo erros e quimeras que as linguagens de programação de mercado promovem e começar a pensar como produzir algo que nos permita dar o mesmo salto dos anos 60 que Algol e Fortran garantiram – e dessa vez nenhum idéia pode ser refém.

*A wikipedia, apesar de extensão não tem uma referencia para tipos de alta ordem, então vou me valer como referencia lógica de alta ordem e deixar como exercício a aplicação do mesmo para teoria de tipos. Type classes do Haskell podem ser construídas aplicando lógica de alta ordem à um sistema de tipos básico como o descrito em “Basic Simple Type Theory – Hindley, J. Roger”.

A grande diferença está na forma como valores intermediários são calculados. Em uma VM baseada em pilha, operandos são adicionados ao topo da pilha enquanto operadores os retiram e realizam alguma operação. Uma máquina baseada em registradores usa de variaveis para armazenar resultados intermediários.

Para exemplificar melhor, o código “a = b * c + 10″ ficaria algo como:

Máquina de pilha:

push_local 'b'
push_local 'c'
mul
push_const 10
add
store_local 'a'

Máquina de registradores:

load_local R0 <= 'b'
load_local R1 <= 'c'
mul R2 <= R0, R1
load_const R3, 10
add R4 <= R2, R3
store_local 'a' <= R4

A primeira vista a diferença é quase que estética, porém se considerarmos quanto espaço precisamos para representar o código e o número de operações de leitura e escrita à memória cada uma faz, vamos notar como são técnicas fundamentalmente diferentes.

Vamos assumir um formato bem simples para representar o código de ambas, que é um byte para designar a operação seguido de um byte para cada operando. Aplicando esta forma, temos.

Máquina de pilha:

push_local 'b' //2 bytes
push_local 'c' //2 bytes
mul //1 byte
push_const 10 //2 bytes
add //1 byte
store_local 'a' //2 bytes

Total: 10 bytes

Máquina de registradores:

load_local R0 <= 'b' //3 bytes
load_local R1 <= 'c' //3 bytes
mul R2 <= R0, R1 //4 bytes
load_const R3 <= 10 //3 bytes
add R4 <= R2, R3 //4 bytes
store_local 'a' <= R4 //3 bytes

Total: 20 bytes

Fica claro aqui que uma máquina de pilha admite uma representação muito mais compacta do mesmo programa. Em geral essa relação não é tão gritante, pois existe uma série de formas de diminuir o número de instruções necessárias para uma máquina de registradores.

Agora vamos analisar quantas operações de memória cada máquina faz, verificando cada instrução individualmente.

Maquina de pilha:

push_local X

1. lê a variavel local X
2. lê o endereço atual do topo da pilha
3. escreve X no topo da pilha
4. incrementa e armazena o novo valor para topo da pilha

mul / add

1. lê o endereço atual do topo da pilha
2. lê o valor do topo da pilha
3. lê o valor abaixo do topo da pilha
4. escreve o resultado no local abaixo do topo da pilha
5. decrementa e armazena o novo valor para topo da pilha

push_const X

1. lê o endereço atual do topo da pilha
2. escreve X no topo da pilha
3. incrementa e armazena o novo valor para topo da pilha

store_local X

1. lê o endereço atual do topo da pilha
2. lê o valor no topo da pilha
3. escreve o valor em X
4. decrementa e armazena o novo valor para topo da pilha

Aplicando esses valores ao programa em questão temos um total de 25 operações.

Máquina de registradores:

load_local X <= Y

1. lê o valor da variavel local Y
2. escreve o valor no registrador X

mul / add X <= Y, Z

1. lê o valor do registrador local Y
2. lê o valor do registrador local Z
3. escreve o valor no registrador X

load_const X <= Y

1. escreve o valor de Y no registrador X

store_local X <= Y

1. lê o valor do registrador Y
2. escreve o valor no registrador X

Fazendo a conta, temos um total de 13 operações.

Ironicamente neste caso, uma máquina de registradores leva uma significante vantagem em relação a uma máquina de pilha. Apesar de se tratar de uma simplificação, na prática o resultado é o mesmo. Em máquinas modernas onde o custo de acessar a memória principal é muito grande, uma máquina de registradores tem o potencial de ser mais rápida.

Essas dicotomia entre qual admite uma representação mais compacta e qual permite uma implementação mais eficiente é fundamental na arquitetura de qualquer máquina virtual. Apesar disso, existe muito além da simples forma de funcionar do interpretador que define a real performance da VM, ainda mais se falarmos de linguagens dinâmicas. Em um artigo futuro pretendo mostrar uma implementação de exemplo de ambos os tipos de máquinas virtuais.

A atenção excessiva na meta-recursividade do sistema, assim como ser trivial criar e integrar novas gramáticas a linguagem, me faz pensar qual seria o limite de duas propriedade com emergence como essas. O efeito imediato é no compilador, que tem suporte direto a PEGs e pattern matching.

O compilador é capaz de se adaptar a mudanças nas regras de sintaxe e passar a usá-las instantaneamente apos serem definidas, ou seja, você pode definir uma mini linguagem em 5-10 linhas e usá-la logo em seguida. Não só isso, mas elas possuem escopo e podem operar em apenas um bloco de texto do seu fonte. Junta isso ao fato de que PEGs poderem ser compostas facilmente e o compilador suportar staged compilation que o resultado é ter uma linguagem que é maleável ao extremo.

A outra é a máquina virtual, que é construída com essa nova linguagem, de forma que ela mesmo siga o modelo de protótipos e delegação na sua implementação. Isso permite que ela seja tão flexível e dinâmica quanto suas aplicações. Essa é, de longe, a característica mais interessante, pois nenhuma linguagem baseada e máquina virtual que eu conheço chega a esse ponto.

Mas quais seriam aplicações reais disso? Aquilo que hoje fazemos com frameworks e bibliotecas, poderíamos fazer com DSLs. Então em vez de aprender um enorme framework que precisa seguir às regras da linguagem, bastaria aprender uma pequena nova linguagem. Da mesma forma, muita coisa que hoje se traduz em referencia direta ao código de bibliotecas, poderia ser feito como uma série de modificações à gramática corrente.

Porém eu acho que é possível ir muito mais além, com uma VM flexível, seria possível ajustar o modelo de execução para melhor realizar a tarefa que o programa deseja. Como, por exemplo, introduzir processos leves ao estilo do Erlang simplesmente incluindo uma biblioteca.

Quem ainda não se ligou o que gente como Ian Piumarta e Alan Kay tem feito no Viewpoints Research Institute deve parar um pouco e se dedicar àquilo que um dia poderia ser o próximo passo na evolução da computação.

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.

Sistemas grandes e complexos exigem que seus componentes sejam isolados o máximo possível entre si para minimizar a interferência que um pode causar no outro. Em linguagens como Java, com um sistema de tipos simples, normalmente isso se resume a usar interfaces para delimitar fronteiras e protocolos de comunicação inter-módulo. Porém quando temos classes abertas o problema é muito maior, já que o sistema todo pode ser modificado de um único lugar. Permitir que a modificação de classes fundamentais como Kernel em um canto do sistema influencie todo o resto é um sério problema pois fica difícil controlar o estrago que essas mudanças causam.

O problema com Ruby pode ser entendido melhor se olharmos para ele segundo o a classificação de domínios de page-jones. Segundo o mesmo, podemos classificá-los em fundamental, arquitetural, negócios e aplicação; sendo que a especificidade aumenta na mesma ordem. Outro ponto é que o domínio menos específico não deve depender de um mais específico, assim como dependências laterais devem ser evitadas. Por essa ótica, código da aplicação alterando uma classe fundamental do sistema é uma clara violação desse modelo.

O motivo pelo qual Ruby viola o modelo de page-jones é por não ser possível definir um escopo que não seja global para alterações feitas a classes externas a código em questão. Outro problema que agrava a situação é a impossibilidade de realmente controlar o mecanismo de resolução de nomes de um bloco de código, isso é um grande problema para criação de DSLs que acabam por fazer enormes cirurgias no core da linguagem ou apelam para o monkeypatching, uma “solução” muito menos intrusiva.

Existem duas formas de ser realizar meta-programação; uma é a intrínseca, a qual se permite operar sobre a definição dos tipos e, uma vez feita a alteração, ela é visível a todos usuários do dado tipo, podemos dizer também que é meta-programação no ponto de definição; a outra é a extrínseca, na qual se altera o mecanismo de resolução de nomes para um dado corpo de código, isso permite realizar as mesmas operações que o método anterior, porém todo código precisa informar direta ou indiretamente se existe algo alterando tal mecanismo, podemos dizer também que é meta-programação no ponto de uso.

A vantagem do primeiro é simplicidade e alcance, uma vez feita a modificação nada mais precisa ser feito para sua aplicação utilizar a versão modificada do tipo, porém também é sua fraqueza, pois se uma função depender explicitamente do comportamento anterior ela não mais funcionará – Ruby é um ótimo exemplo de meta-programação intrínseca. Já a segunda técnica é quase o oposto, pois exige que as modificações sejam explicitamente ativadas, que é sua principal vantagem, pois permite facilmente compor conjuntos de alterações e restringir seu escopo, em contrapartida é sua fraqueza pois não permite que uma dada alteração seja definida por completo em um único lugar – extension methods do C# 3.0 é um exemplo simples de meta-programação extrínseca.

Tentar comparar ambas as técnicas e concluir qual a melhor é um exercício fútil, pois sempre existirão fartos casos no qual uma falha e a outra brilha. Assim como achar que Ruby é uma linguagem quebrada por possuir seus defeitos, pois apesar de tudo é um modelo ao mesmo tempo muito rico e simples de usar.