Java vs C++ speed (IO & Sorting) - Java

On Mar 20, 7:51 am, Razii <DONTwhatever...@hotmail.com> wrote:
> On Thu, 20 Mar 2008 12:45:49 +0200, Juha Nieminen
>
> <nos...@thanks.invalid> wrote:
> > 1) 300 ms is too short of a time for any reliable comparison.
>
> I made bible.txt 10 times and made it a 43 meg file
>
> C++ is doing far worse now (the code used was multiset version)
>
> Time for reading, sorting, writing: 2047 ms (java)
> Time for reading, sorting, writing: 2016 ms (java)
> Time for reading, sorting, writing: 2016 ms (java)
> Time for reading, sorting, writing: 2015 ms (java)
>
> and for c++
>
> Time for reading, sorting, writing: 5281 ms (c++)
> Time for reading, sorting, writing: 5703 ms (c++)
> Time for reading, sorting, writing: 3921 ms (c++)
> Time for reading, sorting, writing: 3718 ms (c++)
>
> How come? c++ is at least 45% times slowe (if using 3718 ms)


I'm sure your deltas are not significant in terms of computer
architecture and maybe not statistically either. I've done other
benchmarks on JVM versions and you'll get variance based on disk IO.
once you run from RAM you get fairly comparable results but certainly
you'd need to drop to runlevel 1 or something (boot into ksh?) to get
close to a bare-metal comparison. Maybe that was discussed before as I
read only this posting.

Anyways, what I see is Java is fairly fast once it gets into RAM. Of
course you can code something faster in C (not C++ even). Some
companies used to even hand-code assembly! I'm sure the compiler,
compiler options, hardware architecture, etc. are a big factor in C/C+
+. Time was every major tech company had a compiler team just for that
reason. Until you have tailored the assembly output by the C code then
you are not being fair. E.g. the JVM is architecture dependent and
init'ed for that hardware at the time at which you start your clock.
You'd need to likewise have optimized assembly output for the C binary
to make an apples comparison. Not just compiled with -o or -g or
whatever but with architecture specific flags at least.

If you think performance is not too important anymore then you are
right. Modern OS's do not perform anywhere in the ballpark as fast as
old ones, for instance.

Best,
TimJowers

On 2008-04-10 05:40, ldv@mail.com wrote:
> On Apr 9, 7:05 am, asterisc <Rares....@ni.com> wrote:
>> For small benchmarking problems (which are some structured algorithms)
>> if you compileJavainto ASM (and an exe file) then it may be as fast
>> as C/C++. But then you will loose the portability. For being fast, it
>> need to be native, which isn't portable.
>
> I do not get your point here. A portable C++ program loses portability
> when you compile it for a particular platform. A Java program loses
> portability if it uses a native library specific to a particular
> platform (e.g. to access Windows registry).
>
> However you define "portability", programs are not written for the
> sake of being portable, they are written to solve problems. The only
> exception I can think of are programs written specifically to teach
> the concept of portability.

True, but one of the advantages of Java is that you can "write once, run
everywhere", by compiling to native you lose that kind of portability.

--
Erik Wikström

On Thu, 10 Apr 2008 16:38:56 GMT, Erik Wikström
<Erik-wikstrom@telia.com> wrote:

>True, but one of the advantages of Java is that you can "write once, run
>everywhere", by compiling to native you lose that kind of portability.

If the criteria is "compile once, run everywhere" only then you lose
that kind of portability. In this case, you still have the original
source code that you can compile to bytecode that will run on JVMs.

On Apr 10, 11:16 am, Razii <DONTwhatever...@hotmail.com> wrote:
> On Wed, 9 Apr 2008 20:40:12 -0700 (PDT), "l...@mail.com" <l...@mail.com>
> wrote:
>
> >Finally,ExcelsiorJETis not the only spec-compliantJava
> >implementation with an Ahead-Of-Time compiler. IBM has it in WebSphere
> >Realtime:
>
> I found a few more that can compile bytecode to native machine code.
>
> gcjhttp://gcc.gnu.org/java/

JNC is just a graphical front-end to GCJ.

GCJ itself is not Java spec-compliant, so it would not be fair to use
it for performance comparison.

ARM Jazelle supports AOT compilation, but that's a Java ME solution.

LDV

On Fri, 11 Apr 2008 05:52:34 -0700 (PDT), "ldv@mail.com"
<ldv@mail.com> wrote:

>GCJ itself is not Java spec-compliant, so it would not be fair to use
>it for performance comparison.

I tried GCJ for this word counting program. It was slightly slower
than Jet and slightly faster than JVM. If -Xms64m flag is added to
JVM, which gains around 50 ms, then GJC and JVM were about same -- 670
ms.