Re: Problem with Java and Xeon Processors

Since you mentioned that your 2nd chip has less cache, I'ld suspect that=
  =

first (though I don't know of any modern Xeons with a cache size that =

small).

Try this:

int limit=timeCall/secsDefSimul;
for (int i=0; i<=limit; i++){
     int offset1 = diaOffset+offset-i;
     if (offset1>=0) arraySimul[offset1]++;
}

limit=3600*hourInterval/secsDefSimul;
for (int i=limit-1; i>=0; i--){
     if (maxSimultaneas<arraySimul[i]) maxSimul = arraySimul[i];
}

The idea is that if you must transverse an array twice, and one pass is =
 =

independant of the direction of transversal, then it is usually much =

faster to structure your traversals in the direction of the most recentl=
y =

seen elements, as you will increase the probability of a cache hit. Eg: =
 =

start -> limit -> start or limit -> start -> limit.


It is also possible (but not likely) that your Xeon is burning more cloc=
k =

cycles for a mul or div, but computing the loop limit in advance should =
 =

help regardless.

Other thoughts:

Are any variables in your loop floating point? long? Or all int? Are the=
y =

all primitive (and not java.lang.Integer / java.lang.Long being autoboxe=
d =

by the compiler)?

32 or 64 bit: the VM? the OS? values of your variables?

Check that you are running the Hotspot Server VM on both machines? (java=
  =

-server)
Any other threads running (are you deploying this logic into a server wi=
th =

other apps loaded and running)?

for benchmarking, try wrapping your code with

final Thread me=Thread.currentThread();
final int old_priority=me.getPriority();
me.setPriority(Thread.MAX_PRIORITY);
Thread.yield();
final long start_timestamp=System.nanoTime();
try {
    runMyCode();
} finally {
    me.setPriority(old_priority);
}
long elapsed_time_ns=System.nanoTime()-start_timestamp;

And be sure to run it a few times be sure you're not measuring the time =
 =

for the HotSpot compiler, or just class load time.

HTH,

-Zig