Estoy ejecutando Windows 8.1 x64 con la actualización de Java 7 45 x64 (sin Java de 32 bits instalado) en una tableta Surface Pro 2.
El siguiente código toma 1688ms cuando el tipo de i es largo y 109ms cuando i es un int. ¿Por qué long (un tipo de 64 bits) es un orden de magnitud más lento que int en una plataforma de 64 bits con una JVM de 64 bits?
Mi única especulación es que la CPU tarda más en agregar un entero de 64 bits que uno de 32 bits, pero eso parece poco probable. Sospecho que Haswell no usa sumadores de transporte de ondas.
Estoy ejecutando esto en Eclipse Kepler SR1, por cierto.
public class Main {
private static long i = Integer.MAX_VALUE;
public static void main(String[] args) {
System.out.println("Starting the loop");
long startTime = System.currentTimeMillis();
while(!decrementAndCheck()){
}
long endTime = System.currentTimeMillis();
System.out.println("Finished the loop in " + (endTime - startTime) + "ms");
}
private static boolean decrementAndCheck() {
return --i < 0;
}
}Editar: Aquí están los resultados del código C ++ equivalente compilado por VS 2013 (abajo), mismo sistema. largo: 72265ms int: 74656ms Esos resultados se obtuvieron en el modo de depuración de 32 bits.
En modo de liberación de 64 bits: largo: 875ms largo largo: 906ms int: 1047ms
Esto sugiere que el resultado que observé es una rareza de optimización de JVM en lugar de limitaciones de CPU.
#include "stdafx.h"
#include "iostream"
#include "windows.h"
#include "limits.h"
long long i = INT_MAX;
using namespace std;
boolean decrementAndCheck() {
return --i < 0;
}
int _tmain(int argc, _TCHAR* argv[])
{
cout << "Starting the loop" << endl;
unsigned long startTime = GetTickCount64();
while (!decrementAndCheck()){
}
unsigned long endTime = GetTickCount64();
cout << "Finished the loop in " << (endTime - startTime) << "ms" << endl;
}Editar: Intenté esto nuevamente en Java 8 RTM, sin cambios significativos.
currentTimeMillis(), ejecutar código que trivialmente se puede optimizar completamente, etc. huele a resultados poco confiables.