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.

Primeiro, é necessário saber um pouco de assembly e entender como funciona a calling convention de um pc 32bit. Feito isso o próximo passo é baixar os manuais da plataforma, sejam os da Intel ou da AMD. Estou acostumado com os da Intel, inclusive tenho eles em árvore morta.

Depois disso, precisamos aprender a usar a ferramenta mais importante para quem quer se aventurar nessa área, o disassembler. No meu caso, usei o objdump da gnu. Instalei via macports no OSX é o gobjdmp por algum motivo.

São dois comandos essenciais que vamos usar, o primeiro é o “gobjdump -d” que disassembla um binário padrão da plataforma, vamos usá-lo para roubar o assembly necessário para nossa função a ser compilada. O segundo é “gobjdump -D -b binary -m i386″ que desassembla um blog binário não estruturado, essa usamos para fazer dump em arquivos do nosso código gerado e verificar seu o conteúdo.

Feito isso, compilamos o código C da nossa função e o assembly dela é algo como:

1
2
3
4
5
6
7

<_foo>:
    push   %ebp
    mov    %esp,%ebp
    sub    $0x8,%esp
    mov    $0xa,%eax
    leave  
    ret

Curto e simples, entender oque cada instrução faz deixo como exercício ao leitor porém. Para gerar essa seqüência em runtime precisamos saber como encodificar cada instrução e um manual da arquitetura é a melhor forma para tal. Por sorte não é necessário saber de nenhuma das formas avançadas de ModRM.

Mas primeiro precisamos alocar um bloco de memória no qual podemos escrever e executar. No caso de sistemas unix usamos a função mmap que permite mapear um bloco anônimo de memória [1] no processo corrente. Com C# no OSX isso é tão trivial quanto o seguinte[2]:

1
2
3
4
5
6

	[DllImport ("libc", EntryPoint="mmap")]
	public static extern IntPtr mmap (IntPtr addr, IntPtr len, int prot, int flags, uint off_t);
 
	int prot = 0x1 | 0x2 | 0x4; //PROT_READ | PROT_WRITE | PROT_EXEC
	int flag = 0x1000 | 0x0002; //MAP_ANON | MAP_PRIVATE
	var res = mmap (IntPtr.Zero, (IntPtr)4096, prot , flags, 0);

Para escrever nesse bloco de memória recém alocado usamos UnmanagedMemoryStream que é uma bela mão na roda para esses casos. Por fim, para invocarmos o código usamos outra facilidade do framework, o método Marshal.GetDelegateForFunctionPointer. Quando fiz isso em Java a alguns anos esses 3 passos foram muito mais difíceis.

Enfim, chega de enrolação, o código completo para nosso super JIT é o seguinte:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

using System;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
using System.IO;
 
public delegate int NoArgsReturnInt ();
class Test {
	[DllImport ("libc", EntryPoint="mmap")]
	public static extern IntPtr mmap (IntPtr addr, IntPtr len, int prot, int flags, uint off_t);
 
	public static unsafe void Main () {
		int prot = 0x1 | 0x2 | 0x4; //PROT_READ | PROT_WRITE | PROT_EXEC
		int flag = 0x1000 | 0x0002; //MAP_ANON | MAP_PRIVATE
		var res = mmap (IntPtr.Zero, (IntPtr)4096, prot , flags, 0);
		var mem = new UnmanagedMemoryStream ((byte*)res, 4096, 4096, FileAccess.ReadWrite);
 
		//push ebp
		mem.WriteByte (0x50 + 0x05);
 
		//mov esp, ebp
		mem.WriteByte (0x89);
		mem.WriteByte (0xE5);
 
		//mov 10, eax
		mem.WriteByte (0xB8 + 0x00);
		mem.WriteByte (0x0A);
		mem.WriteByte (0x00);
		mem.WriteByte (0x00);
		mem.WriteByte (0x00);
 
		//leave
		mem.WriteByte (0xC9);
 
		//ret
		mem.WriteByte (0xC3);
 
		NoArgsReturnInt dele = (NoArgsReturnInt)Marshal.GetDelegateForFunctionPointer (res, typeof (NoArgsReturnInt));
 
		Console.WriteLine (dele ());
	}
}

Incrivelmente simples e curto. Tudo bem que não dá nem para chamar de um brinquedo, porém seu propósito é explorar os princípios básicos por traz de um JIT compiler. Um próximo passo para ele seria gerar 1 função que recebe 2 ints e os soma. Ou tornar o código
menos tosco e mais OO.

[1] mmap permite que bloco de memória seja mapeado para um arquivo
[2] Os valores de prot e flag são específicos ao OSX, então talvez não funcionem em outros derivados unix. Esses valores costumam ficar em /usr/include/sys/mman.h

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.

A primeira solução que vem à cabeça de todos são as faculdades, afinal, uma boa graduação em ciências da computação é uma sólida fundação para um profissional da área. Devem faltar vagas ou coisa parecida, não?

Não, os números da educação superior em computação podem ser entendidos por sórdidos ou desastrosos – ao gosto do leitor. Segundo esse artigo são ofertadas todos os anos 150 mil vagas pelas faculdades. Porém apenas noventa mil se inscrevem nos processos seletivos e, pasmem, apenas 44mil se matriculam de fato em algum curso.

Não satisfeito com tal injúria, informo que apenas 17 mil destes se formam todos os anos. Assustador, no mínimo. Porém sejamos realistas, de seus colegas graduados quantos realmente ingressam na área? No meu caso, digo que esse número é próximo da metade.

Por essa análise, a cada ano o pais oferece 150mil vagas que resultarão em 8.500 novos profissionais ou, em termos relativos, uma taxa de aproveitamento de 5.6%. Pífio, péssimo, patético. Agora de quem é a culpa disso? Provavelmente minha, e sua, de todos nós. Está mais que na hora de fazermos algo pelos alumni de tecnologia deste pais.

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.

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”.

O mais legal disso tudo é que o software é de código aberto, então qualquer um pode produzir vídeos também. Resolvi então fazer uma série deles baseados no mono. Abaixo está o primeiro deles, mostrando o moonlight. Fico devendo o áudio para o próximo.

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.

Nessas duas últimas semanas passei por isso, estou trabalhando em um novo recurso do JIT do mono e tinha que medir qual era o ganho de performance possível. Meu primeiro problema foi encontrar um benchmark que representasse uso real e que fosse significativo o suficiente para os números não ficarem perdidos no meio de muito barulho.

Uma vez que encontrei qual era um bom programa para medir a performance, me deparei com outro problema, o tamanho do working set. CPUs modernas trabalham com até três níveis de caching antes de ir à memória principal. O custo de um acesso a memória pode chegar a uma centena de ciclos, o suficiente para calcular o produto de uma matriz 4×4 por um vetor. Logo não importa o quao significante for o benchmark, se o working set dele não for realístico, o teste é inválido pois tudo executara do cache, bem diferente no mundo real.

Ou seja, é necessário dimensionar e modelar o teste para cada ciclo não utilizar dados que sobraram em cache da execução anterior. Para isso é preciso conhecer o tamanho e a hierarquia de cache do seu processador, mesmo porque isso tem um impacto muito significativo na forma que o código deve ter.

Isso leva ao último desafio que tive de enfrentar, indeterminismo nos resultados do benchmark, a variância dos resultados era grande demais para ser apenas interferência externa, ela chegava a 30% para execuções de de algumas dúzias de segundos. A única diferença eram os endereços de alguns arrays usados extensivamente. Mais precisamente, a discrepância era no alinhamento dos elementos. Nos testes lentos eram múltiplos de 4, nos rápidos eram de 16. Novamente uma peculiaridade dos processadores modernos, que preferem os dados alinhados em endereços múltiplos de 8 ou 16.

Pode até parecer piada, mas o mesmo teste, depois de ajustado todos os detalhes aqui descritos, saiu de um ganho de 10% para 300%. Diferença essa que não é só resultado de um benchmark, mas aplicável ao uso real que esperamos que veja a tenha. Recurso esse que espero integrar ao mono muito em breve.