https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23283
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-23
14:51 ---
> It looks like the problem is that we don't remove the synchronization
> for nextDouble() even though the test case is single-threaded.
If we can remove even only half of the synchronization overhead, by
s
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-23
14:48 ---
Yes, I think that most invocations of next should be inlined, and wrapped in a
single synchronized block.
Apart from that, I am pretty sure that here
seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) -
--- Additional Comments From mark at klomp dot org 2005-08-23 14:31 ---
Subject: Re: Sun's JIT faster than gcc for
Random.nextDouble
It looks like the problem is that we don't remove the synchronization
for nextDouble() even though the test case is single-threaded.
qprof: /tmp/
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23
14:15 ---
I see this too.
Compiling with -fno-bounds-check helps, but not enough.
One possibility is simply that our implementation of nextDouble is
inefficient. I doubt this function was coded for maximum performan
--
What|Removed |Added
Summary|Sun's JIT faster than gcc |Sun's JIT faster than gcc
||for Random.nextDouble
http://gcc.gn
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-08
13:32 ---
Actually for me Sun's java and GCJ take about the same at the default settings
(well for GCJ compiled at
-O3).
Now if I change Sun's java to use the server tuned JIT, Sun's java is 2 seconds
while GCJ is
