[quote=sergiotaborda]A grande vantagem de todas as linguagens com VM , não apenas o java, é que existe sempre a opção de recompilar. Isto é simplesmente impossivel em linguagens como C++. C++ é uma linguagem, java é uma plataforma. São mundos diferentes. Comparar os dois não é honesto.
O JVM da Sun é uma das VM mais evoluidas, senão a VM mais evoluida. Isto porque existe empenho acadêmico em torná-la sempre melhor.
O problema da JVM é que existem duas JVM , a server e a client. Tradiconalmente a server sempre foi mais rápida e é mais rápida que C++, enquanto a cliente é mais lenta. (http://kano.net/javabench/data). Isto vai mudar na JVM 7 em que muitas das otimizações da jvm server irão passar para a jvm client.
Muitas evoluções acontece de forma muito inteligente , como por exemplo remover os monitores de concorrencia ou eliminar a verificação de limites de arrays que faz parte da especificação. Isto sem mexer na linguagem ou fazer o programador usar outro tipo de objeto ou artefato.
Dizer que java é mais rápido que C++ não tem significado. É preciso dizer qual JVM contra qual processador. Já que nem todas as JVM são igualmente rápidas e nem todo o C++ corre com a mesma velocidade. A JVM pode compilar codigo e recompilar sempre que achar necessário. Ela acumula estatisticas e outras informações ( a maior parte as mesmas que são transmitidas via o protocolo de profiling) que permitem tomar decisões sobre o quê compilar, quando e como. E depois de compilado ainda ha a opção de apagar e começar de novo. Isto não existe em C++ simplesmente porque não ha uma VM para C. Aliás esse é o objetivo do C: controlar a máquina real. Mas existem muitas máquinas reais, portanto as otimizações são limitadas.
Um outro problema é que, mesmo quando o C++ é mais rápido - por exemplo em calculos de matrizes, ele é menos exato. Não ha garantia que um calculo feito em C++ em máquinas diferentes terá o mesmo resultado. Isto é normalmente esquecido. Quando se diz que C não é portável não significa apenas que não roda em máquinas diferentes, significa que tem resultados diferentes em máquinas diferentes. Em java isto também acontece, mas a JVM dá garantias. Java implementa o padrão IEEE para numeros de ponto flutuante e dá garantias de ulp. Estes erros, em cadeias grandes de calculos, podem provocar diferenças obseráveis nos resultados.
Enfim, velocidade é inutil se o resultado não é reprodutivel.
Mesmo que o Java não tenha melhor velocidade hoje, com certeza terá melhor amanhã. O fato é real. A velocidade das JVM desde 1.0 até hoje vem aumentando. Em certo ponto ela irá ultrapassar a velocidade do C, C++ e outras linguagens estaticamente compiladas. Hoje estamos chegando perto disso. Muito perto…
P.S. embora não existe uma VM , per se, em C++ existem VM que correm a partir de codigo C++ tentando trazer para o ambiente estático algum dinamismo. http://llvm.org/. Isto significa que o uso de VM passa a ser obrigatório daqui para a frente ( dos anos 90 para frente, na realidade, mas só agora temos provas disso). E a performance, e outras qualidade de runtime passam a depender de algoritmos evoluidas das VM e não de “espertezas” dos programadores. Não é por acaso que todo o mundo quer ter sua linguagem sobre a JVM e até sobre a VM do .NET. Afinal fazer VM é dificil e altamente académico.
[/quote]
Concordo que ter uma máquina gerenciando seu programa é uma coisa muito boa, mas não tem como um bytecode correr mais rápido que um assembly nativo, por razões físicas. A vm precisa conversar com o processador real de qualquer forma.
O Jit hoje, compila o bytecode em assembly nativo, fazendo otimizações, e essa foi a grande evolução da jvm. Mas a vm pioneira disso foi a da microsoft, o .net.
Quando o bytecode ou il estiver correndo super rápido o e liso nos SOs, o assembly nativo vai estar a 1 passo afrente, justamente por ser nativo e não precisar de nenhum tipo de conversão, ou diálogo entre 2 processadores diferentes.