AOT Java compiler

[shumy]

Boas.

O meu interesse na plataforma Java tem aumentado significativamente.

Agora... Anteriormente recusava programar em Java devido á sua fraca performance, uma coisa que tem vindo a ser alterada ultimamente, e o que me faz pensar nesta alternativa.

Gostava de saber se alguem tem alguma informação sobre um compilador AOT (Ahead-Of-Time) para Java que fosse free. A unica coisa que encontro é um da Excelsior que não é grátis, mesmo grátis... 🙂

[Johnny Digital]

boas

antes de mais quero discordar com a ideia da fraca performance do Java, visto q performance é smp algum mt subjectivo

fiz uma pesquisa no google por AOT javac no google e surgiram alguns resultados de software free.. mas n tenho experiencia com nenhum deles :/

[shumy]

Voltando a desenterrar este tópico, e o motivo pelo qual foi iniciado.

Java é potente e bem mais portavel que C++, sim senhor. Mas convem saber o que se está a trocar.

Encontrei um link interessante sobre isso:

http://www.jelovic.com/articles/why_java_is_slow.htm

[badas]

Isso está longe da realidade. Eu programo java mas gosto mto de c++, por isso não me considero muito biased.

Java era lento no início, sim.

Java é lento a inicializar, sim (poderá mudar com o novo consumer JRE - o quickstart).

O Java é monolítico e grande, sim, mas vai mudar com o novo java kernel.

Mas actualmente, o java é altamente performante, podes ler aqui vários benchmarks e umas explicações no fim.

Há em Portugal exemplos de aplicações de baixo-nível que se baseiam em java, que funcionam quase em tempo real e em larga escala. O melhor exemplo disso é a via verde, que é toda implementada com java e jini. E é só pensar para ver que é um sistema bastante complexo. As aplicações bancárias, quando migradas, são-no para java e não para C/C++ por causa do perigo que advém da gestão de memória manual. Sistemas altamente transaccionais e em grelha são implementados correntemente em java por todo o mundo. Temos o Java RTS 2.0 para sistemas em tempo real...

A questão da performance má do java é um pouco um mito, especialmente quando se trata de escalabilidade.

[shumy]

O artigo dos benchmarks tem alguns pontos interessantes, mas falha em comentar o que acontece na realidade em comparação com benchmarks.

Por exemplo, são boas as razões em "The cost of missing the cache" quando falam do GC, mas esquecem-se de referir que uma miss na memória virtual (com acesso ao disco) bem mais grave, basicamente, a malta que se desenrasque e compre mais memória.

O processamento numérico foi abordado no outro artigo, e acho que não deve ser considerado tendo em conta que soluções foram apresentadas para ambas as linguagens.

Juntando as vantagens das duas linguagens, e o que me parece ser o maior forte de cada uma seria C++ (templates) e Java (JIT compilation). Faz prever que C# tem tudo para vencer em todos os aspectos. O que não me agrada muito de facto...

Para assinalar que também gosto de Java, e estas discusões bem orientadas são sempre positivas, alias agradou-me bastante a ideia do "java kernel". Espero isso

[badas]

No caso dos misses na memória, em java é uma questão de parametrizar a vm quando arrancas o java com parametros com o minimo e maximo tamanho da heap (Xms e Xmx). Se se souber a memória que tipicamente a aplicação ocupa, isto aumenta muito a performance.

Quanto ao que falas dos templates no C++, eu por acaso prefiro muito os generics de java, que servem o mesmo propósito. Com a diferença que no c++ os templates funcionam mais como macros. Na realidade, até prefiro a implementação do C# de generics que tem umas coisas mais engraçadas que o java, e nisso concordo em parte contigo. O que a meu ver vai realmente fazer diferença nas linguagens vão ser os closures (java) e o LINQ (.net).

E sim, também acho que estas discussões se impõem 😛 Para o Java Kernel não deves ter que esperar muito, chega no próximo update do Java SE 6.

[shumy]

O tamanho da heap é o maior possível, mas claro tem de existir espaço para outros programas. O sistema de memória virtual já faz gestão automática para aumentar a memória real reservada para a aplicação, se aumentam os pages fault então o sistema dá mais memória real ao programa.

O problema é que o java tanto ocupa mais com o GC e o lixo que vai contendo entre "colects", como com o proprio JIT Compiler que  gasta memória e processos de compilação. Mas a memória é limitada, e os efeitos notam-se em máquinas menos artilhadas, com acessos ao disco constantes.

Já em servidores artilhados a performance parece aumentar já que são aplicações que correm durante tempo indeterminado, permitindo o JIT compiler fazer optimizações estatisticas e adaptações de memória.

Neste aspecto o Java parece-me mais adequado para aplicações em alojadas em servers.

Para desktop as aplicações C++ parecem-me responder melhor.   

Closures java desconhecia, estive a ver a parecem-me ser basica ponteiros para funções (mas sem recorrer a ponteiros claro)

Era capaz de estar a fazer falta em Java.

LINQ já conhecia. Faz-me uma certa comichão, da forma como apresentam a tecnologia até parece que vai ser utilizado como BD, só espero que o programador tenha inteligência para perceber as grandes diferenças e não use a tecnologia como tal.

Se não for para guardar dados em XML, então será para implementar alguma forma de comunicação, e para isso já existem tecnologias bem melhores (Web Services). Sinceramente não vejo muita utilidade nisto. Acho que é adicionar mais complexidade sem tirar grande partido nisso.

[Knitter]

O artigo apresentado pelo shumy está completamente fora de prazo 😄

Este mito da velocidade existirá sempre, e o que acho mais giro é que o .Net é mais lento que o Java e mesmo assim ninguém fala nisso. E quando digo que é mais lento, foi algo que um empregado da Microsoft reconheceu como sendo um feature e não um bug, isto numa conferência a que assisti aqui na ESTG Leiria.

Há muito que me deixei de preocupar com isso, há muito que reconheço isso como mito. Existem várias justifcações das duas partes para mostrar o quão certas estão.

Na verdade, ao ler o artigo apresentado e a conclusão que o Java nunca será mais rápido, por melhor que sejam as JVMs, lembro-me do que o patrão da Microsoft disse há uns anos atrás, "640K de memória serão sempre suficientes", isto para dizer que ninguém pode prever como será o software daqui a alguns anos.

Ainda ontem estive numa conferência onde se falou em usar sistemas baseados na forma como o nosso sistema imunitário funciona para desenvolver software com capacidade de aprender, uma forma completamente diferente de pensar a cognição artificial.

[badas]

O tamanho da heap é o maior possível, mas claro tem de existir espaço para outros programas. O sistema de memória virtual já faz gestão automática para aumentar a memória real reservada para a aplicação, se aumentam os pages fault então o sistema dá mais memória real ao programa.

O problema é que o java tanto ocupa mais com o GC e o lixo que vai contendo entre "colects", como com o proprio JIT Compiler que  gasta memória e processos de compilação. Mas a memória é limitada, e os efeitos notam-se em máquinas menos artilhadas, com acessos ao disco constantes.

Já em servidores artilhados a performance parece aumentar já que são aplicações que correm durante tempo indeterminado, permitindo o JIT compiler fazer optimizações estatisticas e adaptações de memória.

Neste aspecto o Java parece-me mais adequado para aplicações em alojadas em servers.

Para desktop as aplicações C++ parecem-me responder melhor.

Sim, é normal C++ ser melhor para desktop, especialmente em windows em que acede directamente às Win32 API 😄    

As closures são na realidade mais do que apontadores para funcoes, permitem programar de forma funcional. É tipo cálculo lambda e é normal ver isto em linguagens funcionais como Scheme ou ML. Pode mudar muito o modo como se desenvolve em java.

O linq vem tentar também retirar aquela separação entre dados e código, um pouco como as frameworks de ORM fizeram para se fugir ao sql. Embora tenha sido essa a génese, o linq também me parece que está a evoluir para algo um pouco estranho. Enfim.

[shumy]

Só convem não esquecer que não é só o Java que evolui.

C++ foi e continuará a ser pensado para performance, quando assim deixar de o ser morre.

Ao contrário do que possam pensar da minha opinião, tanto me faz que morra ou não, se aparecer uma melhor para a substituir assim seja.