Je suis sous Windows 8.1 64 bits avec Java 7 update 45 x 64 (n ° 32 bits de Java installée sur une Surface Pro 2 comprimé.
Le code ci-dessous prend 1688ms lorsque le type de i est une longue et 109ms quand je est un int. Pourquoi est long (64 bits type) d'un ordre de grandeur inférieure à celle de l'int sur une plateforme 64 bits avec une JVM 64 bits?
Ma seule la spéculation est que le CPU prend plus de temps pour ajouter un 64 bits en entier de 32 bits, mais cela semble peu probable. Je soupçonne Haswell ne pas utiliser ripple carry additionneurs.
Je suis de l'exécution de cette dans Eclipse Kepler SR1, btw.
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;
}
}
Edit: Voici les résultats de l'équivalent de code C++ compilé par VS 2013 (ci-dessous), même système. long: 72265ms int: 74656ms Ces résultats ont été en debug 32 bits mode.
En 64 bits mode de diffusion: long: 875ms long long: 906ms int: 1047ms
Ceci suggère que le résultat que j'ai observé est de la JVM d'optimisation de la folie plutôt que de CPU limites.
#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;
}
Edit: Juste essayé une fois de plus à Java 8 RTM, aucun changement significatif.
