Velocidade de cálculo de ints e floats

A resposta, é claro, é “depende”.

Há algoritmos que dependem mais do acesso à memória que propriamente da velocidade das operações aritméticas (tanto em ponto fixo quanto em ponto flutuante). Como o ViniGodoy havia dito antes, pode haver alguns problemas de “caching” que podem dar resultados muito diferentes para o mesmo algoritmo (em linhas básicas), só por causa de alguns detalhes.

As versões novas do Java podem usar automaticamente instruções SSE2/SSE3/SSE4.x para acelerar o acesso a ponto flutuante; em C, talvez você tivesse que setar algumas opções de compilação, e também usar alguns métodos “intrínsecos” do compilador para que as instruções especiais sejam acessadas diretamente.

Obviamente há aqueles algoritmos que foram extremamente otimizados em C e que provavelmente nunca irão rodar tão rápido em Java, até por efeito de todas essas otimizações que podem ser feitas em C e que não sejam automáticas do Java.

Realmente depende.

Note que a essas operações geram somente uma ou duas instruções de bytecode em Java, o que indica que não deve haver perda significativa de desempenho se comparado com C, por exemplo.

Isso sem contar que, em trechos que são executados frequentemente, o compilador JTI pode dar uma força.

Mas, novamente, cada caso é um caso. Talvez a melhor coisa a fazer seja realizar testes com um trecho dos cálculos que você pretende fazer em ambas as linguagens e verificar as diferenças.

Quanto a operações com tipos de dados primitivos( int, long, short), não há nenhuma perda de performance. O JIT compila o bytecode para código nativo. A perda de performance ocorre quando existe lixo de memória, e o coletor de lixo começa a atuar. Fora o coletor, não existe nada que possa “atrapalhar” a execução de um programa na jvm, e da jvm para o processador(JIT).

Dá uma olhada nesse tópico. O sergio postou um benchmark nele.

http://www.guj.com.br/posts/list/90/198295.java

A vantagem de você usar C++ nesses casos, é que você poderia baixar um compilador específico para o hardware que você irá rodar sua aplicação. Estou assumindo que trata-se de uma aplicação essencialmente matemática, e que você terá controle sobre o ambiente que ela será executada. Há exemplos de compiladores como esses aqui:

Nesse caso, haverá alguns níveis de otimização realmente agressivos para certos tipos de operações. E claro, o código gerado será realmente nativo. Uma covardia comparar com Java, que tem propósito de ser multiplataforma, e que tem como plataforma final o SO, não o processador.

Só para terem uma idéia do tipo de otimização que é feita pelo compilador da Intel, basta ver o trabalhão que o Andy Polyakov teve ao tentar criar uma versão otimizada, em Assembly de X64, para algumas rotinas do OpenSSL. O Andy simplesmente pegou o código original compilado pelo icc (compilador da Intel) e tentou ver o que era possível melhorar. Ele gastou um tempo considerável até conseguir algo que fosse só um pouco melhor que o gerado pelo compilador.

Para alguns firmwares tínhamos também um “manual de boas práticas” para o compilador. Víamos em quais instruções similares um código mais eficiente era gerado, e davamos preferência a essas instruções (por exemplo, era melhor usar cadeias de if, ou um switch?).

Em compiladores bem-feitos, como o da Intel, esse manual era praticamente vazio.

ViniGodoy:

Para alguns firmwares tínhamos também um “manual de boas práticas” para o compilador. Víamos em quais instruções similares um código mais eficiente era gerado, e davamos preferência a essas instruções (por exemplo, era melhor usar cadeias de if, ou um switch?).

Em compiladores bem-feitos, como o da Intel, esse manual era praticamente vazio.

Esse compilador é tão bom que até a ms usa para desenvolver os wins. Ela usa o intel e repassa o msc++ pra gente… hehe

Agora tem uma coisa interessante. Já tentaram fazer um benchmark de um programa que conta até 100000, usando gcc em unix e win32(mingw).

A diferença é enorme.

Um tempo atrás eu encontrei isso aqui sobre o OpenSSL: http://www.peereboom.us/assl/html/openssl.html