Shootout: the benchmarks game ... continues.

java-programmer, Shootout: the benchmarks game ... continues. On Wed, 30 Apr 2008 08:00:38 -0700 (PDT), Isaac Gouy
<email***@***.com> wrote:

>You've spent 10 days making untrue claims:

No, you are wrong. There is no -Xms when you click on show tab from
the main page. You know that very well. Why waste time on quibbling?

>Why don't you go through all...

Let's continue. The only thing changed is my OS (Vista) and computer
which is now 3 core phenom. Also, instead of > /dev/null on cygwin, I
will use > \Null (since that seems to be 200 times faster on windows).
benchmark: fasta
java version:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=java&id=2
C++ version
http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=gpp&id=4

As a great example of c++ portability, this doesn't even compile with
my version of g++ (mingw), so I will use cygwin to compile. gcc
version 3.4.4 (cygming special)

g++ -pipe -O3 -fomit-frame-pointer -mfpmath=sse -msse2 fasta.cpp -o
fasta.exe

jc -inline+ fasta (jet)

N 250,000 2,500,000 25,000,000
g++ 0.166s 0.954s 8.884s
java 0.297s 1.347s 11.699s (-Xms64m -server)
jet 0.420s 1.701s 14.602s

(note this guy uses -Xbatch flag everywhere. I have to see how that
helps anywhere. It's just slightly slower with -Xbatch flag if
anything).

HotSpot VM is faster than native Jet compiler once again? That's three
in a row. g++ is only slightly faster, not 50 or 100 times as some
think.

java-programmer >> Shootout: the benchmarks game ... continues. On Wed, 30 Apr 2008 23:43:33 -0500, Razii <email***@***.com>
wrote:

>g++ -pipe -O3 -fomit-frame-pointer -mfpmath=sse -msse2 fasta.cpp -o
>fasta.exe

By the way, using the flags -mfpmath=sse -msse2 means the compiled
version won't run on anything without an sse2 instruction set (that
means no Athlon XP).

That's the problem with compiled version that a JIT compiler doesn't
have since it knows on what processor it's running. Removing these
flags makes g++ version about 25% slower.

java-programmer >> Shootout: the benchmarks game ... continues. Razii wrote:
> On Wed, 30 Apr 2008 23:43:33 -0500, Razii <email***@***.com>
> wrote:
>
>> g++ -pipe -O3 -fomit-frame-pointer -mfpmath=sse -msse2 fasta.cpp -o
>> fasta.exe
>
> By the way, using the flags -mfpmath=sse -msse2 means the compiled
> version won't run on anything without an sse2 instruction set (that
> means no Athlon XP).
>
> That's the problem with compiled version that a JIT compiler doesn't
> have since it knows on what processor it's running.

That's just not true, because the JIT compiler cannot do any magic
here.

If it really can run fast enough on an Athlon XP, just compiler for
that. On anything faster, it will just fly.

> Removing these
> flags makes g++ version about 25% slower.

Is that fast enough? Otherwise skip that target and compile with SSE2.

With JIT it will still be 25% slower. What's the advantage?

Bo Persson

java-programmer >> Shootout: the benchmarks game ... continues. On Thu, 1 May 2008 15:34:18 +0200, "Bo Persson" <email***@***.com> wrote:

>Is that fast enough? Otherwise skip that target and compile with SSE2.

If you are selling commercial software, why would you want to skip
Athlon XP? It's still widely used. JIT doesn't have that problem. It
knows what processor it's running on.

>With JIT it will still be 25% slower. What's the advantage?

JIT is new and evolving. It will get faster. In any case, as shown in
this benchmark, java VM was faster in this benchmark than the native
java compiler.

java-programmer >> Shootout: the benchmarks game ... continues. Razii wrote:
> On Thu, 1 May 2008 15:34:18 +0200, "Bo Persson" <email***@***.com> wrote:
>
>> Is that fast enough? Otherwise skip that target and compile with
>> SSE2.
>
> If you are selling commercial software, why would you want to skip
> Athlon XP?

I would if it isn't fast enough to run the software. If it is fast
enough, everything else is as well.

> It's still widely used. JIT doesn't have that problem. It
> knows what processor it's running on.

If it runs well enough on an Athlon XP, compile for that. It will run
extremenly well on an overclocked Core 2 Quad.

>
>> With JIT it will still be 25% slower. What's the advantage?
>
> JIT is new and evolving. It will get faster. In any case, as shown
> in this benchmark, java VM was faster in this benchmark than the
> native java compiler.

It can't get faster on old hardware. If your program needs SSE2 and
the processor doesn't have it, how is the JIT compiler supposed to fix
that?

Bo Persson

java-programmer >> Shootout: the benchmarks game ... continues. On Apr 30, 9:43 pm, Razii <email***@***.com> wrote:
> On Wed, 30 Apr 2008 08:00:38 -0700 (PDT), Isaac Gouy
>
> <email***@***.com> wrote:
> >You've spent 10 days making untrue claims:
>
> No, you are wrong. There is no -Xms when you click on show tab from
> the main page. You know that very well. Why waste time on quibbling?

Now instead of admitting that your claims were wrong, you've changed
what you claim.

> >Why don't you go through all...
>
> Let's continue. The only thing changed is my OS (Vista) and computer
> which is now 3 core phenom. Also, instead of > /dev/null on cygwin, I
> will use > \Null (since that seems to be 200 times faster on windows).
> benchmark: fasta
> java version:http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta鈱?j...
> C++ versionhttp://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta鈱?g...
>
> As a great example of c++ portability, this doesn't even compile with
> my version of g++ (mingw), so I will use cygwin to compile. gcc
> version 3.4.4 (cygming special)
>
> g++ -pipe -O3 -fomit-frame-pointer -mfpmath=sse -msse2 fasta.cpp -o
> fasta.exe
>
> jc -inline+ fasta (jet)
>
> N 250,000 2,500,000 25,000,000
> g++ 0.166s 0.954s 8.884s
> java 0.297s 1.347s 11.699s (-Xms64m -server)
> jet 0.420s 1.701s 14.602s
>
> (note this guy uses -Xbatch flag everywhere. I have to see how that
> helps anywhere. It's just slightly slower with -Xbatch flag if
> anything).
>
> HotSpot VM is faster than native Jet compiler once again? That's three
> in a row. g++ is only slightly faster, not 50 or 100 times as some
> think.

The numbers you've created show more difference between the c++
program and the java program, show the c++ program as even faster,
than the measurements on the benchmarks game.

http://shootout.alioth.debian.org/gp4sandbox/fulldata.php?test=fasta&p1=gpp-4&p2=gpp-4&p3=javaxx-2&p4=java-2

java-programmer >> Shootout: the benchmarks game ... continues. On Thu, 1 May 2008 11:10:48 -0700 (PDT), Isaac Gouy <email***@***.com>
wrote:

>Now instead of admitting that your claims were wrong, you've changed
>what you claim.

You are a quibbling fool and have wasted enough of my time. The claim
was always very clear as even Bo Person understood it very well. There
is no -Xms64m if you click show from the main page and only same kind
of flags are used in every benchmark.

Stop wasting my time with quibbling about something that is clear.

java-programmer >> Shootout: the benchmarks game ... continues. On Thu, 1 May 2008 18:47:35 +0200, "Bo Persson" <email***@***.com> wrote:

>If it runs well enough on an Athlon XP, compile for that. It will run
>extremenly well on an overclocked Core 2 Quad.

It could have run 25% faster on Core2. It's running 25% slower on Core
2 Quad because the package was compiled to include Athlon XP.

What's so hard to understand here??

>It can't get faster on old hardware. If your program needs SSE2 and
>the processor doesn't have it, how is the JIT compiler supposed to fix
>that?

The JIT compiler fixed it by not penalizing Core 2 Quad just because
Athlon XP doesn't have sse2. It runs on Core2 with sse2 enabled, and
it runs on Athlon XP. In the case of pre-compiled version, it either
has sse2 enabled for Core2 and doesn't run on Athlon Xp or it has sse2
disabled for both.

What's so hard to understand here?

java-programmer >> Shootout: the benchmarks game ... continues. Razii wrote:
> On Thu, 1 May 2008 18:47:35 +0200, "Bo Persson" <email***@***.com> wrote:
>
>> If it runs well enough on an Athlon XP, compile for that. It will
>> run extremenly well on an overclocked Core 2 Quad.
>
> It could have run 25% faster on Core2. It's running 25% slower on
> Core 2 Quad because the package was compiled to include Athlon XP.
>
> What's so hard to understand here??

That there is no need for it, except in benchmarks.

If some software can render a video correctly on an Athlon XP, there
is just no need for it to run 25% faster on a newer machine. Should
the film run faster?!

>
>> It can't get faster on old hardware. If your program needs SSE2 and
>> the processor doesn't have it, how is the JIT compiler supposed to
>> fix that?
>
> The JIT compiler fixed it by not penalizing Core 2 Quad just because
> Athlon XP doesn't have sse2. It runs on Core2 with sse2 enabled, and
> it runs on Athlon XP. In the case of pre-compiled version, it either
> has sse2 enabled for Core2 and doesn't run on Athlon Xp or it has
> sse2 disabled for both.
>
> What's so hard to understand here?

If the program isn't fast enough without SSE2, what does the JIT
compiler do on the old Athlon?

If it is fast enough without SSE2, why bother using it?

The benefit of a JIT compiler is that some programs can be made to run
on Windows, Linux, and OS X without recompilation. Not that it runs
faster on a Quad - everything does that anyway!

Bo Persson

java-programmer >> Shootout: the benchmarks game ... continues. On Fri, 2 May 2008 18:35:34 +0200, "Bo Persson" <email***@***.com> wrote:

>That there is no need for it, except in benchmarks.
>
>If some software can render a video correctly on an Athlon XP, there
>is just no need for it to run 25% faster on a newer machine. Should
>the film run faster?!

No, there could be a need for it say in a chess engine. The faster the
chess engine, the stronger it plays. The stronger it plays, more chess
enthusiasts are likely to buy it. Now, if you compile it for Athlon
XP, Core2 would take the penalty because it would run 25% slower. If
you compile it for Core2 by including sse2, it won't run on Athlon XP.

java-programmer >> Shootout: the benchmarks game ... continues. On 2 Maj, 21:04, Razii <email***@***.com> wrote:
> On Fri, 2 May 2008 18:35:34 +0200, "Bo Persson" <email***@***.com> wrote:
> >That there is no need for it, except in benchmarks.
>
> >If some software can render a video correctly on an Athlon XP, there
> >is just no need for it to run 25% faster on a newer machine. Should
> >the film run faster?!
>
> No, there could be a need for it say in a chess engine. The faster the
> chess engine, the stronger it plays. The stronger it plays, more chess
> enthusiasts are likely to buy it. Now, if you compile it for Athlon
> XP, Core2 would take the penalty because it would run 25% slower. If
> you compile it for Core2 by including sse2, it won't run on Athlon XP.

Well, for a chess engine it is going to be more or less the same. A
25% change in capacity is not going to change the playing level so
much. A better example would have been for some kind of server where
the processing is CPU-dominated. Here, 25% more capacity would mean
25% more clients possible. But when you write programs for a server,
you normally can allow yourself to write code for the newest
processors only.

/Peter

java-programmer >> Shootout: the benchmarks game ... continues.
"Razii" <email***@***.com> wrote in message

> No, there could be a need for it say in a chess engine. The faster the
> chess engine, the stronger it plays. The stronger it plays, more chess
> enthusiasts are likely to buy it.

hmm... Well That pretty much rules out Java Don't it. Java's slow as old
boots. I'd suggest using C++, or if C++ is too difficult for you to
understand... use C.

regards
Andy Little

java-programmer >> Shootout: the benchmarks game ... continues. "Razii" <email***@***.com> wrote in message
news:email***@***.com...
> On Sat, 3 May 2008 03:58:00 +0100, "kwikius"
> <email***@***.com> wrote:
>
>>hmm... Well That pretty much rules out Java Don't it. Java's slow as old
>>boots....
>
> Well, that's the topic, isn't it? We have yet to see any proof that
> C++ is faster by any order of magnitude except by a small margin. In
> some cases, it's downright slower like in allocating dynamic memory.

The JVM your using is most likely written in C/C++. That means that the
memory allocator is written in C/C++. Your comparing an allocator created in
C/C++ which Java likely is using, to other allocators created in C/C++.

Notice any pattern in there?

java-programmer >> Shootout: the benchmarks game ... continues. On Sat, 3 May 2008 03:58:00 +0100, "kwikius"
<email***@***.com> wrote:

>hmm... Well That pretty much rules out Java Don't it. Java's slow as old
>boots....

Well, that's the topic, isn't it? We have yet to see any proof that
C++ is faster by any order of magnitude except by a small margin. In
some cases, it's downright slower like in allocating dynamic memory.

java-programmer >> Shootout: the benchmarks game ... continues. On Fri, 02 May 2008 21:40:02 -0700, Chris Thomasson wrote:

> The JVM your using is most likely written in C/C++. That means that the
> memory allocator is written in C/C++. Your comparing an allocator
> created in C/C++ which Java likely is using, to other allocators created
> in C/C++.
>
> Notice any pattern in there?
>

On a tangent, how did that "Java computer" which Sun touted years ago
work? What sort of OS did it have?

-Thufir

java-programmer >> Shootout: the benchmarks game ... continues. On Fri, 2 May 2008 21:40:02 -0700, "Chris Thomasson"
<email***@***.com> wrote:

>The JVM your using is most likely written in C/C++.

Jet native compiler is not written in C++.

>That means that the memory allocator is written in C/C++.

True, for Hotspot VM where probably VM, written in C++, allocates
memory.

However, getting back to the original claim of kwikius that Java is
way slower than C+; there is nothing magical about C++. Both Java and
C++ are compiled to native machine code. In the case of C++, this
happens at compile time. The speed depends on the quality of machine
code generated by the compiler. The compiler itself doesn't have to be
fast (you can even write a compiler in Perl) but it has to generate
machine code that is as best optimized as possible.

Same thing happens in C# and Java where JIT compiles bytecode to
machine code at run time. A perfectly optimized machine code will run
exactly at same speed on the same machine, regardless of what language
was used to write the original source code. In other words, kwikius
is a fool. There is nothing magical about C++ other than it probably
has the compilers.

At least theoretically, even if it's not yet true, it's possible that
C#/Java can even be faster than C++ in some cases since JIT compiler
has more info about the machine it's running on, available memory,
registers, and the code it's compiling. This might not be true right
now but JIT compilers are improving; so theoretically there is no
reason why JIT compiled language can't be just as fast if not faster
than precompiled languages like C++.

java-programmer >> Shootout: the benchmarks game ... continues. kwikius wrote:
> "Razii" <email***@***.com> wrote in message
>
>> No, there could be a need for it say in a chess engine. The faster the
>> chess engine, the stronger it plays. The stronger it plays, more chess
>> enthusiasts are likely to buy it.
>
> hmm... Well That pretty much rules out Java Don't it. Java's slow as old
> boots. I'd suggest using C++, or if C++ is too difficult for you to
> understand... use C.
>
> regards
> Andy Little
>
>
>

Actualy, Java is usually way faster than C++ or C when it comes to
memory allocation.

http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends

Leonard

--
Simplicity is the ultimate sophistication.
-- Leonardo da Vinci

java-programmer >> Shootout: the benchmarks game ... continues. On Fri, 2 May 2008 17:03:54 -0700 (PDT), peter koch
<email***@***.com> wrote:

>Well, for a chess engine it is going to be more or less the same. A
>25% change in capacity is not going to change the playing level so
>much.

Sticking with chess a little more. A 64-bit compiled chess engine can
be significantly faster than 32-bit. That is because many chess
engines use 64-bit word to represent the chess board. In precompiled
languages like C++, you will need to compile two versions, one 64-bit
and one 32-bit. That won't be a problem with JIT compiled version.

java-programmer >> Shootout: the benchmarks game ... continues. On Sat, 03 May 2008 07:14:05 GMT, thufir <email***@***.com>
wrote:

>On a tangent, how did that "Java computer" which Sun touted years ago
>work? What sort of OS did it have?

http://en.wikipedia.org/wiki/JavaOS

"Sun now officially considers JavaOS a legacy system" according to
Wikipedia.

However, there is new upcoming JavaFX Mobile but the kernel in that
case is Linux

http://en.wikipedia.org/wiki/JavaFX_Mobile

"JavaFX Mobile is a Java operating system for mobile devices initially
developed by SavaJe Technologies and purchased by Sun Microsystems in
April 2007. It is part of the JavaFX family of products. The JavaFX
Mobile operating system provides a platform for PDAs, smartphones and
feature phones. It features a Java SE and Java ME implementation
running on top of a Linux kernel."

There are apparently many other open source Java OS; though I am not
sure if any of them are any successful.

http://en.wikipedia.org/wiki/JNode

"JNode (Java New Operating System Design Effort) is an open-source
project to create a Java platform operating system. The project has
taken the unique direction of creating all the software in Java
itself, with the exception of some assembly language to boot and load
the system. The JVM compiler (which normally uses just-in-time
compilation) is used to build native binaries out of the core Java
code. In this way, nearly the entire system is capable of being
written in the Java programming language."

Latest release 0.2.6 / February 22, 2008

http://en.wikipedia.org/wiki/JX_%28operating_system%29

"JX is implemented as an extended Java Virtual Machine (the JX Core),
adding support to the Java system for necessary features such as
protection domains and hardware access, along with a number of
components written in Java that provide kernel facilities to
applications running on the computer. Because Java is a type-safe
language, JX is able to provide isolation between running applications
without needing to use hardware memory protection. This technique,
known as language-based protection means that system calls and
inter-process communication in JX does not cause a memory space
switch, an operation which is slow on most computers. JX runs on
standard PCs, with support for a limited range of common hardware
elements. It is open source software, developed by the University of
Erlangen."

Latest stable release 0.1.1 / October 10, 2007

java-programmer >> Shootout: the benchmarks game ... continues.
"Razii" <email***@***.com> wrote in message
news:email***@***.com...
> On Fri, 2 May 2008 21:40:02 -0700, "Chris Thomasson"
> <email***@***.com> wrote:
>
>>The JVM your using is most likely written in C/C++.
>
> Jet native compiler is not written in C++.
>
>>That means that the memory allocator is written in C/C++.
>
> True, for Hotspot VM where probably VM, written in C++, allocates
> memory.

<...>

> The compiler itself doesn't have to be
> fast (you can even write a compiler in Perl) but it has to generate
> machine code that is as best optimized as possible.

The only people that would write a compiler for a serious programming
language in Java are those that have to ;-)
And you can bet they'd be itching for the day they can bootstrap it.

> At least theoretically, even if it's not yet true,

Nah... Everybody knows Java's slow as old boots. Take my advice. Don't write
your compiler in Java. It'll be too clumsy for any serious use.

regards
Andy Little