speed of simple loops: comparison to other language

[Steve White]

Osvaldo,

Thanks for this information.  I wasn't aware that the distro VM on the
x86_64 was compiled with the server option.

Certainly, for many applications, start-up time is crucial, and I 
appreciate efforts to streamline that.

However, does better execution time necessarily imply slower start-up time?
If the only switches available are -server or -client, then we're stuck.
But maybe this just reflects an unfortunate division of the issues.
Frankly it surprises me that better optimization necessarily implies
substantially slower start-up time. 

Is it really either/or? 

Just a thought: it's kind of poor that the determination has to be made
when building the VM.  It would be much cooler to have launch-time switch
that would choose such behavior.

I can tell you, coming from scientific and clinical data processing 
communities, the decision makers frown on a factor of 3 in raw speed.
(Even though, of course, we know the real issues are much more complicated!)

It would be really cool to show these guys that algorithms written in
their beloved Fortran runs at essentially the same speed in Java.
(This is mostly the case on my x86-64 tests vs gfortran.)

To these guys, it sounds like idiocy to say that much more complex code
could be written in Java that might be faster than their Fortran.
But one could argue that the same algorithm runs at the same speed
in the two environments, and a more sophisticated one written in the
more modern language could be yet faster.

Anyway, a lot of our machines here happen to be x86_64, and now I have
an explanation for the phenomena.

Thanks a lot for your help, all of you!


On  1.07.10, Osvaldo Doederlein wrote:
> Hi,
> 
> On 30.06.10, John Pampuch wrote:
> > >
> > > If you are using the same code generation (see further down), this may be
> > > a combination of the reduced number of registers available in 32 bit
> > mode,
> > > combined with some anomaly of the benchmarks that allow Java to fit
> > > critical fields more fully into registers in the 64 bit mode.
> >
> > What anomoly would that be?
> >
> 
> Perhaps the single "anomaly" in these tests, is the fact that the 64-bit
> HotSpot doesn't have a Client VM, so it uses the Server VM by default. This
> is constant cause of benchmark confusion because the 32-bit VM will default
> to the Client VM, which has a weaker code optimizer. A fair comparison
> should use "-server" on the 32-bit VM.
> 
> 
> > The efficiency of complex code hangs on the choice of algorithm, the level
> > where programmers should concern themselves.
> >
> > But if such a simple operation as aritmetic iterations is slow, it will be
> > very hard for Java to compete efficiency-wise on any level.
> >
> >
> The simpler Client VM is a well-known tradeoff. It has substantial
> advantages in both memory usage and startup time. The Server VM is the only
> one that really competes with C/C++, but it's much more heavy-weight. And
> even with the Client VM being the default in the JRE installed in hundreds
> of millions of consumer PCs, Java already has a bad rep for its loading time
> and resource usage (although Sun/Oracle has been sweating to reduce these
> issues since JDK 6u10). This makes easy to understand the reason that Server
> is not the default, and it won't be any time soon. In fact, the only reason
> that a 64-bit port of the Client VM is not available, is that 64-bit
> consumer/desktop stuff is generally not very widespread yet (most browsers
> are 32-bit; there's no 64-bit port of other plugins like Adobe flash, etc.).
> But I hope this will change soon, I'd kill for a 64-bit JRE that includes
> the Client VM so I can make my Windows7-64 setup more "pure".
> 
> On Java competitiveness, with the client VM we're talking about desktop
> software for which resource usage and startup time are at least as critical
> as speed, so the Client VM is the right choice (or at least, the best
> possible choice with the Sun/Oracle JDK; for an alternative that approaches
> a combination of Client-like resource usage with Server-like optimization
> [but then has other tradeoffs], look at the JET static compiler). People who
> run Java servers know that they must put "-server" in the launch scripts,
> then all is well.
> 
> 
> A+
> Osvaldo
> 
> 
> > --
> > | -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
> > | Steve White                                             +49(331)7499-202
> > | E-Science                                        Zi. 27  Villa Turbulenz
> > | -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
> > | Astrophysikalisches Institut Potsdam (AIP)
> > | An der Sternwarte 16, D-14482 Potsdam
> > |
> > | Vorstand: Prof. Dr. Matthias Steinmetz, Peter A. Stolz
> > |
> > | Stiftung privaten Rechts, Stiftungsverzeichnis Brandenburg: III/7-71-026
> > | -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
> >

-- 
| -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
| Steve White                                             +49(331)7499-202
| E-Science                                        Zi. 27  Villa Turbulenz 
| -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
| Astrophysikalisches Institut Potsdam (AIP)
| An der Sternwarte 16, D-14482 Potsdam
|
| Vorstand: Prof. Dr. Matthias Steinmetz, Peter A. Stolz
|
| Stiftung privaten Rechts, Stiftungsverzeichnis Brandenburg: III/7-71-026
| -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -