Todo mundo fala que existe um deficit de profissionais de tecnologia enorme. Aquele mítico número de cem mil profissionais que ninguém consegue achar. Que isso é um fato, não ha de se discutir, todas empresas com que tenho contato próximo possuem varias vagas em aberto a muitos meses.
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.
Acabou de ser lançado versão 2.2 do Mono. Foram vários meses de trabalho e muito suor em corrigir centenas de bugs para podermos fazer nosso melhor release de todos os tempos. Dentro das novidades gostaria de destacar duas relativa ao time que participo. A primeira é o novo JIT baseado em uma representação intermediaria linear, os ganhos de performance podem chegar em até 50% e, também importante, o código do JIT ficou muito mais simples e extensível. A segunda novidade, resultado da maior flexibilidade do mono, é a disponibilização preliminar da biblioteca Mono.Simd, que permite usar a unidade vetorial de processadores modernos.
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:
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.
A parte que mais odeio no C é ser minha melhor opção. Sim, sério, para aquilo que faço hoje em dia, realmente não existe linguagem melhor. E isso de deixa maluco pois se trata de uma linguagem anacrônica, cheia de problemas enormes que aparentemente toda comunidade de PLR esqueceu de tentar resolver.
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.
Em artigosanteriores eu descrevi algum dos problemas associados com herança, ou subtipagem, e questões ligadas a co/contravariância. Porém outra questão me chamou muito a atenção recentemente, é o fato de classes e objetos como normalmente vemos em linguagens com tipagem explícita são uma mistura de conceitos que talvez não deveriam estar juntos.
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”.
Um pais pode aceitar um terrorista convicta como ministro? E que tal um assaltante de bancos? Por que não os dois? Afinal temos um descontrolado que entregou a casa civil à Dilma Rousseff.
O Presidente Inácio anunciou que ela é sua favorita para 2010. A noticia é boa em um aspecto, significa ainda mais o fim da Marta - e que esta um dia explique seu envolvimento com ONGs durante sua prefeitura.
Porém como eu posso não ficar apavorado com a idéia de ter uma mulher que ficou nacionalmente conhecida pelos escândalos do dossiê dos gastos do FHC e da venda da Varig?
Vamos realmente querer essa mulher, que acredita em sacrificar inocentes* para atingir seus objetivos, como presidente? A hora de agir é essa, não podemos permitir que o Bêbado da Silva use a máquina estatal para fazer a campanha de uma assaltante.
* Ou alguém por acaso acha que o Banespa estava vazio em 1968?
Como podemos produzir uma representação visual da evolução de um projeto? O pessoal do projeto code swarm tem uma ótima resposta. Um vídeo gerado a partir do histórico de commits do projeto.
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.
Interpretadores voltaram a ser um assunto muito discutido devido aos resultados alcansados pela SquirrelFish (interpretador de javascript do Webkit) e ao fato da VM do Android também usar um. Curiosamente, ambas VMs são baseadas em registradores em vez de pilha, como as máquinas virtuais tradicionais como JVM e CLR.
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'
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.
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
lê a variavel local X
lê o endereço atual do topo da pilha
escreve X no topo da pilha
incrementa e armazena o novo valor para topo da pilha
mul / add
lê o endereço atual do topo da pilha
lê o valor do topo da pilha
lê o valor abaixo do topo da pilha
escreve o resultado no local abaixo do topo da pilha
decrementa e armazena o novo valor para topo da pilha
push_const X
lê o endereço atual do topo da pilha
escreve X no topo da pilha
incrementa e armazena o novo valor para topo da pilha
store_local X
lê o endereço atual do topo da pilha
lê o valor no topo da pilha
escreve o valor em X
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
lê o valor da variavel local Y
escreve o valor no registrador X
mul / add X <= Y, Z
lê o valor do registrador local Y
lê o valor do registrador local Z
escreve o valor no registrador X
load_const X <= Y
escreve o valor de Y no registrador X
store_local X <= Y
lê o valor do registrador Y
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.
Otimização não é difícil apenas pelo fato de que tornar um pedaço de código mais rápido seja uma tarefa complicada, mas também por nem sempre ser possível ter oque medir ou mesmo saber como medir.
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.
Hoje fiquei sabendo através de um amigo que o sistema de chamados da anatel possui um furo de segurança que expõe todos dados dos chamados feitos por qualquer pessoa. Incluindo usuário e senha. Sim, isso mesmo, usuário e senha. A vulnerabilidade é tão grande que permite coletar os dados de todos usuários do sistema de maneira trivial por qualquer pessoa que entenda o básico de como funciona a web.
Os irresponsáveis pelo sistema permitem consultar os dados de um chamado sem qualquer forma de autenticação. Basta acessar essa url e trocar o ZZZ pelo número do chamado. Fosse apenas esse o problema não estaria eu tão assustado, porém se olharmos com cuidado para o problema vamos notar uma série de agravantes.
A página inclui uma enorme quantidade de dados pessoais do usuário, desde endereço a telefone e CPF. Estes são dados mais que suficientes para realizar vários tipos de fraudes. Fosse apenas este o problema não estaria tão assustado, pois seria necessário saber o código da solicitação para ler tais informações.
Vamos então verificar a segurança do código do chamado. Abra dois chamados, um em seguida do outro, e note que se trata de um número seqüencial pequeno sem qualquer forma de verificação ou randomização. Ou seja, é trivial coletar todos chamados com ferramentas simples disponível em qualquer computador pessoal.
Finalmente vem a cartada final, reparem nos dados exibidos na página, eles incluem email e cpf. Até ai tudo bem, até você ir para a página de login do sistema e descobrir que para entrar você deve informar, acredite, seu email e cpf. Ou seja, temos como fazer não só harvesting de dados dos usuários, mas de suas senhas também.
Segurança como essa é inadmissivel para um órgão governamental. Isso é ridículo, é um afronte a nossa privacidade. Os amadores que fizeram esse sistema ignoraram todas regras básicas de segurança que qualquer desenvolvedor safo tem a obrigação de saber. Anatel, corrija isso com urgência e tome as devidas medidas administrativas para esse tipo de desastre não ocorra novamente. Por favor, a todos que lerem este texto, liguem já para a Anatel no 0800 33 2001, registrem uma reclamação formal e divulguem esse problema para o quanto antes ser solucionado.
Performance nunca foi um assunto fácil. Medir é complicado, comparar resultados é quase irrelevante, comparar linguagens é inútil. Porém as pessoas continuam insistindo no assunto, de um lado os que defendem linguagens gerenciadas dizendo que elas são tão rápidas quanto C ou C++; do outro lado ficam a demonstrar como isso não é possível.
Não se trata apenas do uso de micro-benchmarks, ou de otimizar melhor um alvo, ou da metodologia ser falha. Se trata apenas de falta de comprometimento. Não se pode medir performance daquilo que não se está envolvido pois o resultado é irrelevante. Qualquer tentantiva nessa direção só vai provar que a pessoa é tola.
Quando falo em compromisso me refiro ao fato de que não adianta tentar medir a performance sem estar envolvido na melhora dela. Medições devem ser feitas em softwares reais, não de fabricações de Oz. E o corolário disso é que comprar linguagens é um exercício de futilidade, pois não faz sentido manter o mesmo programa em Java e C++, por exemplo.
A performance de um programa é fator de muito mais coisas que apenas a velocidade bruta do meio de execução - seja uma VM ou código nativo. Principalmente para grandes sistemas, a complexidade arquitetural e características sistêmicas tem muito maior influencia. Já vi isso acontecer demais para ignorar.
Isso significa que micro-benchmarks são irrelevantes e pura obra do ego de seus criadores? Não, pelo contrário, diz apenas que quase sempre as pessoas envolvidas não estão comprometidas com os resultados. Um exemplo prático, medir a performance com ponto flutuante do gcc só é útil aos seus desenvolvedores, pois somente estes tem o compromisso em melhorá-la, para os demais é uma enorme perda de tempo.
Toda discussão de “Minha linguagem é mais rápida que a sua” parece esquecer de que para aplicações de significativa complexidade a maioria dos micro-benchmaks usados são irrelevantes. Para a maioria dos projetos, oque importa é quanto a plataforma torna fácil escrever programas que sejam rápidos. Não adianta ser super veloz se o desenvolvedor vai precisar fazer uma enorme série de sacrifícios para manter sua produtividade.
Existe uma série de exemplos bem intrigantes de como escolhas óbvias trazem resultados não óbvios em termos de performance. Desde gerenciamento de memória a execução especializada de código. Porém não espero ver as pessoas se eduquem nesse ponto, pois é uma causa fundamentalmente perdida, já que não existe razão suficiente contra um ego ferido e o fato de alguém na internet estar errada.