[SP-pm] Map Reduce

[Alexei Znamensky]

2011/1/13 Eden Cardim <edencardim em gmail.com>

> >>>>> "Alexei" == Alexei Znamensky <russoz em gmail.com> writes:
>
>     Alexei> O meu cotidiano no trabalho, right now, consiste, dentre
>    Alexei> outras coisas, de instalar binários (.class compilados em
>    Alexei> máquinas Windows/Intel de desenvolvimento) para executar em
>    Alexei> JVMs que rodam em AIX/PowerPC. Seria muito difícil ter isso
>    Alexei> sem VMs. Sem VMs, todos os developers (quase
>    Alexei> que-independentemente da linguagem a ser escolhida) seriam
>    Alexei> obrigados a usar algum servidor AIX para compilar e testar
>    Alexei> seu código. Como os ciclos de desenvolvimento, hoje, estão
>    Alexei> extremamente calcados em tentativa-e-erro (por vários
>    Alexei> motivos que não vou entrar no mérito agora), o tempo gasto
>    Alexei> para desenvolver o mesmo código caiu drasticamente, pois o
>    Alexei> developer pode usar sua CPU e SO baratos para malhar o
>    Alexei> código e rodar testes unitários, e o binário que ele gera
>    Alexei> localmente pode ser simplesmente copiado para o servidor de
>    Alexei> testes, onde será novamente, e mais duramente,
>    Alexei> sabatinado. Não é preciso recompilar (ou, não seria, mas
>    Alexei> nunca subestime a estupidez humana).
>
>    Alexei> Por outro lado, VMs têm o custo de performance associado à
>    Alexei> interpretação/execução dos opcodes virtuais, então com o
>    Alexei> tempo, os implementadores de JVMs acabaram fazendo essas
>    Alexei> "traduções" de opcodes virtuais para nativos em tempo de
>    Alexei> execução, para melhorar esse ponto. Me parece uma evolução
>    Alexei> quase que "natural" do conceito.
>
> Certo, mas porque não pegar os opcodes, distribuir, e compilar para
> código nativo na máquina-alvo antes de rodar, já que tudo vai
> eventualmente ser compilado de qualquer forma.
>

Para que inventar um passo a mais no processo? Manda o bytecode em um
formato padrão, e cada JVM que se vire. Essa 'recompilação', que eles chamam
de JIT ("Just In Time" Compiling) é feita uma vez somente, então o impacto
disso a longo prazo no tempo de execução é diluído, praticamente desprezível
se pensarmos em termos de aplicações Java em servidores 24x7.

Além disso, o JIT é habilitado por default nos servidores, mas ele pode ser
desabilitado no ambiente de desenvolvimento - o código 'inlined' pelo JIT
não gera algumas informações específicas em stack traces (por exemplo, o
código executado em JIT não informa o número da linha, na 'recompilação'
essa informação se perde).

Além disso, para efetivamente gerar binários da plataforma-alvo você entra
em uma outra categoria de problemas, envolvendo linkers, bibliotecas
instaladas, pacotes, ferramentas de compilação específicas de cada
plataforma, etc... você vai ter algum ganho de desempenho no executável, ok,
enquanto que o seu processo de build vai deixar de rodar uma vez e vai ter
de rodar em cada plataforma-alvo. Do ponto de vista de processo, me parece
uma grande cagada.

[...]

>    Alexei> Digo mais (sob o risco de polemizar ainda mais o tópico): se
>    Alexei> o Perl tivesse uma versão que gerasse bytecode no padrão de
>    Alexei> JVM, aí sim a linguagem iria abocanhar de volta uma gorda e
>    Alexei> suculenta fatia do mercado (claro que não seria somente
>    Alexei> isso, não é bala de prata, mas isso ajudaria bastante,
>    Alexei> IMHO).  </disclaimer>
>
> É isso que o pessoal do parrot está tentando fazer.
>

What's keeping them?

Já posso rodar:

java -jar Papagaio.jar -MData::Dumper -E 'say Data::Dumper( { a => 1, b =>
2, c => 3 } )'


???

[]s,
-- 
Alexei Znamensky [russoz_gmail_com] [russoz.wordpress.com] [
www.flickr.com/photos/alexeiz]
«Only love / Can bring the rain / That makes you yearn to the sky»
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110113/6cc91d43/attachment-0001.html>