Java vs C++ speed (IO & Sorting)

R

Razii

Every action has an equal and opposite reaction:

javac IOSort.java
java IOSort
Time for reading, sorting, writing: 2952 ms

That's Sun's VM, not JET native compiler (the post you replied to).
CC IOSort.cc -library=stlport4 -fast
./a.out
Time for reading, sorting, writing: 1100ms

So either my system has a poor Java implementation, or yours has a poor
C++ one. Which proves nothing.

C:\>CL /O2 IOSort.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

IOSort.cpp
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\xlocale(342) :
warning C
4530: C++ exception handler used, but unwind semantics are not
enabled. Specify
/EHsc
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.

/out:IOSort.exe
IOSort.obj

C:\>IOSort
Time for reading, sorting, writing: 6171 ms

C:\>IOSort
Time for reading, sorting, writing: 3953 ms

C:\>IOSort
Time for reading, sorting, writing: 3984 ms
 
R

Razii

Without any mention of the C++ compiler options used to build it.

How many times you need that info? I posted it in the first post and
several times after that.

C:\>CL /O2 IOSort.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

IOSort.cpp
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\xlocale(342) :
warning C
4530: C++ exception handler used, but unwind semantics are not
enabled. Specify
/EHsc
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.

/out:IOSort.exe
IOSort.obj

C:\>IOSort
Time for reading, sorting, writing: 6171 ms

C:\>IOSort
Time for reading, sorting, writing: 3953 ms

C:\>IOSort
Time for reading, sorting, writing: 3984 ms
 
C

Christopher

I think I will go cross post about how republicans are better than
democrats to NGs for both. Then I'll see how many posts it gets so I
can feel good about myself.

You still did not answer for the facts pointed out in my earlier
thread:
1) Measure from process enter to process exit ( Too hard for you? )
2) Limit execution and performance query to a single core (Also too
hard for you? )
3) Use a performance query with a guaranteed granularity of 1 ms.
clock has no such guarantee, not even close, it can be off by an
entire second!
4) Cheer that all you've proven is one particular code block runs
better or worse than another in your environment, with your tools.
5) Feel good that your thread grew by 1

Real computer _scientists_ would have a much larger sample size and
account for every factor. But you're not a scientist, you're a smelly
troll :)
 
R

Razii

1) Measure from process enter to process exit ( Too hard for you? )
2) Limit execution and performance query to a single core (Also too
hard for you? )
3) Use a performance query with a guaranteed granularity of 1 ms.
clock has no such guarantee, not even close, it can be off by an
entire second

You are posting nonsensical things that's why I didn't respond. We are
calculating only the time for reading, sorting, and writing (nor for
VM start up), and you don't need separate "performance query with a
guaranteed granularity of 1 ms". Who cares about "1 ms" or even "100
ms" anyway? It's irrelevant.
 
D

dave_mikesell

You are posting nonsensical things that's why I didn't respond. We are
calculating only the time for reading, sorting, and writing (nor for
VM start up), and you don't need separate "performance query with a
guaranteed granularity of 1 ms". Who cares about "1 ms" or even "100
ms" anyway? It's irrelevant.

Huh? Your results are in the 300 ms range, and an error of
potentially 100 ms doesn't bother you?

I'm convinced this is a joke now. Early April Fool's I guess.
 
R

Razii

Huh? Your results are in the 300 ms range, and an error of
potentially 100 ms doesn't bother you?

No, the difference of 100 ms doesn't bother me. It shows there is no
speed difference.
I'm convinced this is a joke now. Early April Fool's I guess.

You are the joke. You have no USENET history and most of your replies
are to this thread. Did I touch a nerve? Why are you so obsessively
posting to the thread, troll?
 
C

Christopher

You are posting nonsensical things that's why I didn't respond. We are
calculating only the time for reading, sorting, and writing (nor for
VM start up), and you don't need separate "performance query with a
guaranteed granularity of 1 ms". Who cares about "1 ms" or even "100
ms" anyway? It's irrelevant.

What's nonsensical about it?

Do you have no clue how timers work?
Do you not realize a start time could be on one core and an end
time on another? Hell, I could get a negative time if I tryed hard
enough.

Did you not pass high school math? Since when does 1 second = 100
ms? Last time I checked it was 1000

I think your a bit nonsensical :)
 
D

dave_mikesell

No, the difference of 100 ms doesn't bother me. It shows there is no
speed difference.


You are the joke. You have no USENET history and most of your replies
are to this thread. Did I touch a nerve? Why are you so obsessively
posting to the thread, troll?

You're right, I don't have your USENET street cred. For that, I'll
drop to my knees and thank God tonight.

Plenty of people with much more experience that I, however, have
driven gaping holes in your argument. I'm starting to question your
sanity in continuing.
 
R

Razii

This is weird. If the C++ library is so bad I do not understand why
the C++ code in your example is so much clearer than the Java
equivalent with an "endless" loop that is exited in the middle.

If C++ library is so great, can you write by only using standard c++
library code that can do the following (and your code must be simpler,
easier to read, and use only standard library) like I am doing below.

import java.math.*;
import java.util.*;
import java.io.*;
public class Prime {

public static void main(String[] args) throws Exception {

FileWriter fstream = new FileWriter("prime.txt");
BufferedWriter fout = new BufferedWriter(fstream);
PrintWriter out = new PrintWriter (fout);
int bits = 1000;

BigInteger bigInteger;
long start = System.currentTimeMillis();
for (int i = 0; i <= 10 ; i++)
{
bigInteger = BigInteger.probablePrime(bits,new Random());
out.println(bigInteger); out.println();
}
out.flush();
long end = System.currentTimeMillis();
System.out.println("Time for generating ten " + bits +
" bit prime numbers " + (end - start) + " ms");
}
}




Here is what it does: it generates ten 1000 bit prime numbers and
writes them to a file. (1000 bit means an integer with 301 digits in
it)

I ran it a a few times with such results...

Time for generating ten 1000 bit prime numbers 10203 ms
Time for generating ten 1000 bit prime numbers 17031 ms
Time for generating ten 1000 bit prime numbers 10172 ms
Time for generating ten 1000 bit prime numbers 11859 ms


Pleas show us the greatestness and simplicity of c++ standard library.
The out file (prime.txt) must look something like this with ten 100
bit prime numbers

----------- out put file (prime.txt) -------

6842254723349861748843666511662064828566534876628355397638542250959845743665351697255227934848482156894344866523784140126158352565945309867555596955179264268811303554610623299537017559218520998260126890669421170013094553214112988499526676482375353071911923101533507666402744156824755893599999340100039

9848648321151813357308534835626628679476461098165407388222336517490832458510672926299515789763227094026404809330108514662634001376874600327941826767246662005353936332269956613789129055242420454444820541158542651993392376425752312667969524325104139501376021913506959016046209547633260919705554429116957

7472464841209790781263623636615796696063008849158951320705532274543716175088447511478468738217459047280793122730986618530055469990170520637092471861656573404083673652252269395461121964962449683983703396496919624484535816579596847010140874266510985075440815394009983327150954852554698319713533791379351

10307661443841358703042499578335475669167539597638484071670840598460024065841392388829670463069085621250998375017313225187317191877437158721006546183087715067594632510292725466539662500002942009673358846734158857335390525432059296521738149709276331297942660035069645233021137424691400274642262813431743

9646399560455185301694828954906916750070648884857568971541459965770127506827253896121786333961281514135550865127250883333128665493840144605606702030252187296380861010724701091267251600797671154006173275374031756032389190673745898442648752134149486082663634202932288789638592154181262596505399198011499

5464104522187331267329792036943268562163662010826313167428236682292212471251253006159887248307492520536268339671206975636852612170286701846188506774200950309204678396738030162734821967950815398661534482769013763609307661014299189641931894663947535991003827610799697457317398005165341572114298969132119

8986916642188317055291435981557704758000970125943137197423439011525746036858282058344569686780852367757142493701994974271668292544581187527833663068924064401318327687566631978430854275350631507711906132491563930688957812901670932635095508760182677873923763628550923736738960671141108239714134899091859

6276685657926620279750831368313993843997469170105733612426682064744233764253914510057013843677656897638995342919260837956656593014230080133856778022055834763450499251347519655724230815974026067377317921799884910111659789204289025730212592107153924529970395158800961403239639973965644599264075923930743

6449473976940431985705116754023412206599611211984444557518153003140889617962537549197822342902685017344039507691145617625401593677823468136459328816011488688129050967390081901875306435168437003180364852877442035556030261006234175552168158246917246372733828393566865962430827532447416329242048968871133

9645462584641815985614567406765522289079385813376636777793253379649956921522143430515943252559790984289447485824485113580733229462265055509626681725512500798566395525436509873858977920237106477382712460314593005451787339196973168859381882333749970132286581447238781845665557466187650302560420122262091

6626649154643032194352836291684124036601901792249879123472876930930421377935289346502117906223474899887619118266933602848811210940591903741366432700900655773229650015847218925624874926977718157361713877846498350708402180443241389168320875916982789784809118258057259463970197729735869840964768378134459
 
C

Christopher

No, the difference of 100 ms doesn't bother me. It shows there is no
speed difference.


You are the joke. You have no USENET history and most of your replies
are to this thread. Did I touch a nerve? Why are you so obsessively
posting to the thread, troll?

*PLONK*
*WAVE*
 
R

Razii

Did you not pass high school math? Since when does 1 second = 100
ms? Last time I checked it was 1000

Where did I say 1 sec = 100 ms? If I said something like that, it was
a typo.
 
Joined
Mar 12, 2008
Messages
4
Reaction score
0
At work:

Software written in Java running on a Thin Client (Where you expect it to be efficient because of the crappy hardware inside the Thin Client): 0
Software written in C++ running on a Thin Client: 1

C++ Wins!
 
J

Jerry Coffin

I know and already tried that ... didn't compile...

Ah, it looks like VC++ 9 is checking the iterator category, which
earlier versions didn't. Fortunately, fixing the code is pretty trivial.
The code that was like this:

template <class T>
class ostream_iterator

needs to be changed to this:

template <class T>
class ostream_iterator
: public std::iterator<std::eek:utput_iterator_tag, T>

The code should theoretically have been like this all along, but with
the older compilers, it didn't make any difference.

Doing a quick test, it looks like with VC++ 9.0, this modification
doesn't gain quite as much as it did with the older compilers -- the
speed improvement with my code is now only about 2:1 instead of 2.5:1
(or so) with VC++ 7.1. The code seems to be about the same speed when
using /DCSTDIO, but the standard version (from about 250 ms to about 200
ms on my machine).
 
L

Lew

Mark said:
I'd like to ditto Eric's request. Can you elaborate on what you are
referring too here? Is it the lack of multiple inheritance in Java that
you feel prevents designing clean abstraction layers? Maybe it's the
lack of direct interface to system/external libraries (ie, one has to
use Java Native Interface to call libraries with C bindings.)?

Something else maybe?

It has not been my experience that Java in any way impedes the construction of
abstraction layers, clean or otherwise. I find the claim inflammatory at best
that it does.

First of all, no programming language completely lacks the "ability to build
clean abstraction layers", not even freaking binary zero-one machine language,
so let's tone the claim down to one at least marginally supportable. Let's
interpret the claim to be that Java does not support "clean abstraction
layers" as well as C++.

So, what makes abstraction layers clean? In addition to the questions the
others have asked, which are relevant.

Java has never impeded anyone's ability in my direct experience to create what
I call clean abstraction layers, or for that matter, to create clean, useful,
maintainable code that does what its sponsors want with acceptable performance
on time and on budget. I've known quite a few Java programmers, too.
 
L

Lew

lew says...
Jerry said:
You simply write code (like this) that almost certainly never does GC.
All memory it ever allocates remains allocated until the program
finishes execution, therefore there's never any garbage to collect. Yes,
it's theoretically possible that the garbage collector may run -- but
with nothing for it to really DO, the time taken is negligible.

By contrast, with a program that allocates and deletes memory on a
regular basis, the garbage collector actually DOES something when it
runs, and (no great surprise) the time taken to do something is greater
than the time taken to do nothing.

Which is still not the benchmark excluding GC time, only GC time not
happening. If GC decides to run, the benchmark code does nothing to prevent it.

This is a good thing, mind you.
 
L

Lew

So are you also discounting the time it takes the larger executable to
be loaded by the OS?

That all depends on what you're measuring. There is no One Right Benchmark.
Benchmarks are probes into specific aspects of system behavior, and at best
hints as to what one might expect in the real world. It's not so much what is
measured that counts, as that what is measured is precisely documented.

There is no more nor less validity to benchmarks that account for OS load time
than to those that don't, as long as the conditions are crystal clear. There
is a difference as to how useful such benchmarks are, but that utility depends
on the evaluator's circumstances and is not in the hands of the benchmark
publisher.
 
L

Lew

Major parts of the Java library also moved
to machine code - I believe that is why so many elementary classes in
the library are "final"; they are not byte code anymore and lose their
ability to be subclassed - a trade off from language purity to
efficiency.

Actually, no. The smaller point is that a machine code optimization in the
library shouldn't intrinsically make a class non-subclassable, but that's not
even relevant. Making a class 'final' is the API designer's way of preventing
you, personally, from extending that class. It's an entirely Java thing to
do, and has nothing to do with details of implementation.

Joshua Bloch, in his excellent and seminal /Effective Java/, a must-read for
everyone on the planet, discusses the dangers and responsibilities inherent in
making a class heritable, and when you should or shouldn't. Actually, it's
something that you should only do relatively rarely. The rest of the time,
you declare your classes 'final' so that they cannot be extended.

Programming looks different when you think about designing classes to force
people to use them correctly.
 
R

Razii

Ah, it looks like VC++ 9 is checking the iterator category, which
earlier versions didn't. Fortunately, fixing the code is pretty trivial.
The code that was like this:

template <class T>
class ostream_iterator

needs to be changed to this:

template <class T>
class ostream_iterator
: public std::iterator<std::eek:utput_iterator_tag, T>

That did improve the speed a bit .. especially for smaller 3 meg file
1 bible.

C:\>cl /DCSTDIO /O2 IOSort.cpp


Time for reading, sorting, writing: 156 ms
C:\>IOSort
Time for reading, sorting, writing: 156 ms
C:\>IOSort
Time for reading, sorting, writing: 156 ms

(for java the time was 265 ms to 300 ms)

For larger 43 meg file,

C:\>IOSort
Time for reading, sorting, writing: 4687 ms
C:\>IOSort
Time for reading, sorting, writing: 2453 ms
C:\>IOSort
Time for reading, sorting, writing: 3187 ms
C:\>IOSort
Time for reading, sorting, writing: 2593 ms
C:\>IOSort
Time for reading, sorting, writing: 4234 ms
C:\>IOSort
Time for reading, sorting, writing: 2750 ms
C:\>IOSort
Time for reading, sorting, writing: 3531 ms


And for Java

C:\>java -Xmx128m IOSort
Time for reading, sorting, writing: 4297 ms

C:\>java -Xmx128m IOSort
Time for reading, sorting, writing: 3140 ms

C:\>java -Xmx128m IOSort
Time for reading, sorting, writing: 2953 ms

C:\>java -Xmx128m IOSort
Time for reading, sorting, writing: 3062 ms

C:\>java -Xmx128m IOSort
Time for reading, sorting, writing: 2891 ms
 
J

Jerry Coffin

I hope the following makes you really happy

http://www.excelsior-usa.com/ (JET compiler can be found here)

Sure does! :)
Time for reading, sorting, writing: 203 ms (Java with JET)
Time for reading, sorting, writing: 203 ms (Java with JET)
Time for reading, sorting, writing: 188 ms (Java with JET)

(c++ using multiset)
Time for reading, sorting, writing: 328 ms (c++)
Time for reading, sorting, writing: 312 ms (c++)
Time for reading, sorting, writing: 312 ms (c++)

Just for fun, I downloaded and installed the Jet package on my machine,
and tried it out. The results I get do not match yours very well at all.

Time for C++, original code: 218 ms
Time for C++, modified code: 98 ms
Time for Java, Jet Compiled: 188 ms

That does show the Java as coming out ahead of the "stock" C++ code, but
the difference is smaller than I get between one run and the next of the
same code -- meaning much more careful timing would be needed to figure
out whether one is really faster than the other or not.

The modified C++ version clearly wins by a wide margin though.

Some other points are equally clear cut. Compilation speed for one:

Compile time with Jet compiler: 2 minutes, 57.64 seconds
Compile time with VC++ compiler: 0.4 seconds.

Executable size for another:

Executable from Java code, Jet Compiled: 5,322,240 bytes
Executable from C++ code, VC++ compiled: 92,160 bytes.

Of course, you can undoubtedly vary these somewhat with different
options (I didn't spend any time trying different flags to vary the
compile time or executable size in either case), but unless there's
something that makes a _big_ difference in the results from the Jet
compiler, it appears nearly unusable, at least for day-to-day
development.
10 bibles (43 meg file)

Time for reading, sorting, writing: 2453 ms (Java with JET)
Time for reading, sorting, writing: 2391 ms (Java with JET)
Time for reading, sorting, writing: 2344 ms (Java with JET)
Time for reading, sorting, writing: 2437 ms (Java with JET)

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++)

These don't seem to 1) make sense, or 2) match what I get at all.

Time for C++, original code: 2012 ms
Time for C++, modified code: 899 ms
Time for Java, Jet Compiled: 2306 ms

As before, each of these is the average of the times from five runs of
the program.

Unlike the times you've shown, these look reasonable and sensible.
You're showing the C++ code as slowing by a factor of about 15 to
process 10 times as much code. Since the I/O time dominates the
equation, it should take almost exactly 10 times as long to process 10
times as much data.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top