Java vs C++ speed (IO & Sorting)

[Chris Thomasson]

This topic was on these newsgroups 7 years ago

http://groups.google.com/group/comp.lang.c++/msg/695ebf877e25b287

I said then: "How about reading the whole Bible, sorting by lines, and
writing the sorted book to a file?"

Who remember that from 7 years ago, one of the longest thread on this
newsgroup

The text file used for the bible is here
ftp://ftp.cs.princeton.edu/pub/cs126/markov/textfiles/bible.txt

Back to see if anything has changed

(downloaded whatever is latest version from sun.java.com)

Time for reading, sorting, writing: 359 ms (Java)
Time for reading, sorting, writing: 375 ms (Java)
Time for reading, sorting, writing: 375 ms (Java)

Visual C++ express and command I used was cl IOSort.cpp /O2

Time for reading, sorting, writing: 375 ms (c++)
Time for reading, sorting, writing: 390 ms (c++)
Time for reading, sorting, writing: 359 ms (c++)

The question still is (7 years later), where is great speed advantage
you guys were claiming for c++?

[...]

Java is fast enough, C++ is fast enough. Whatever.

So many dependencies... What version of JVM... What STL... What compiler...
What architecture... I/O speed (e.g., hard disk model?)... ect, ect...

Have you coded this in C++ using nothing but handcrafted algorithms and
native platform API calls? Who cares, it might be 10 times slower; wow.

Some people say avoid STL because it can be slow, weeeee...

lol.

:^)

 

[Jerry Coffin]

[ ... ]

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)

IOW, to roughly as accurately as you're measuring things, the C++
version is twice the speed of the Java version.

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

This is a bit of a problem though: you're getting an average of 3348 ms,
but a standard deviation of 853.

And for Java

....an average of 3269, but a standard deviation of 583.

These high standard deviations mean that your results don't really mean
much. If you want to get meaningful results from a benchmark, you're
probably going to have to work quite a bit harder at ensuring that
machine is idle other than the benchmark code itself.

 

[Razii]

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.

Why would someone use JET compiler for day to day development? They
can use Javac and VM for development and when they are ready to
deploy, then can use JET (that is, if they want to compile it to
native machine code).

The file size .class is 1,576 bytes (58 times smaller than your exe
file for c++) and compile time (using javac) is also less.

 

[Razii]

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

And you are being dishonest here. You yourself admitted that the code
you were using didn't compline on the new VC version 9 but you still
used the same 98 ms.

Behavior like this shows you are not credible and everything else you
post regarding benchmark should be taken with grain of salt.

 

[Razii]

Hmm.. No one has yet posted the C++ code that does the same thing
(using standard libraries) that what Java code I posted does. I
thought that would be really given great power and depth of c++
libraries

Java

Oh, you can change that easily. It has nothing to library

while (null != (line = in.readLine()))
ar.add(line);


Happy now? No endless loop.

 

[stan]

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.

Why are you trolling comp.lang.c++? Feeling a little insecure? "Mine is
bigger than yours" games are juvenile, uninteresting, and a waste of time.
If you are truly interested in such games try advocacy groups.

Oh how I long for the good old days when this kind of noise was
generally limited to the begining of the school year.

 

[Razii]

Why are you trolling comp.lang.c++? Feeling a little insecure? "Mine is
bigger than yours" games are juvenile, uninteresting, and a waste of time.
If you are truly interested in such games try advocacy groups.

This is unmoderated USENET newsgroup. You can have a great time at c++
moderated group if you enjoy that atmosphere. At least I am posting
something on topic, instead of "Subject: Citizen Calibre 5000 Ladies
Watch FB1002-54D Replica"

Back to the topic. Where is c++ version that does the same thing that
I posted and uses the standard c++ libraries?

 

[Jerry Coffin]

[ ... ]

Why would someone use JET compiler for day to day development? They
can use Javac and VM for development and when they are ready to
deploy, then can use JET (that is, if they want to compile it to
native machine code).

I thought about that, but even for that, it seems nearly unusable.
Worse, the result is pretty well unusable in any case -- can you
honestly say you'd feel comfortable shipping a 5 megabyte executable for
such a trivial program as this?

The file size .class is 1,576 bytes (58 times smaller than your exe
file for c++) and compile time (using javac) is also less.

Sorry, but no, the compile time is NOT less. I timed it. If I've run the
compiler (or something in Java) recently enough that the JVM is already
loaded, it exactly matches VC++ (0.4 seconds). Otherwise, it's
noticeably slower (1.4 seconds).

It makes no sense at all to compare a java class file to a C++
executable (or any executable, for that matter). A class file isn't an
executable, so comparing it to one simply makes no sense.

In any case, the difference between ~1.5K and ~90K is fairly trivial
under most normal circumstances. Just for example, over a reasonably
fast network connection, either one downloads essentially
instantaneously (by human time frames, obviously). Most people perceive
anything under about 150-200 ms as instant, so increasing download speed
past that point accomplishes essentially nothing in terms of perceived
response time.

Unless you have a really fast machine connected to a really slow network
connection, the advantage for Java in this case is almost purely
theoretical. OTOH, if you look at executable vs. executable, the
difference becomes much more significant in a hurry -- even over a fast
connection, a 5 megabyte file takes a noticeable amount of time to
download.

 

[Jerry Coffin]

And you are being dishonest here. You yourself admitted that the code
you were using didn't compline on the new VC version 9 but you still
used the same 98 ms.

Nonsense. Rather than: "the same 98 ms", if you go back and check at:

http://groups.google.com/group/comp.lang.c++/msg/a4d5e78abdba8166

you'll see that with VC++ 7.1 the number I got was 93 ms, not 98 ms at
all. Given that both use parts of the library that haven't changed in
years, similarity between the results is hardly surprising -- but each
was independently measured and accurately reported.

Behavior like this shows you are not credible and everything else you
post regarding benchmark should be taken with grain of salt.

Nonsense. What we have here is a clearcut case of your making a false
accusation, nothing more and nothing less.

 

[Razii]

Of course there isn't. If there was the demand, bignums would be in the
standard library. There isn't, so they aren't. If you want a C or C++
bignum library, use GMP.

Exactly. There is no network, no threads, no bignum. No GUI. Nothing
really. And by the way, bignum is important. You can't do cryptology
without bignum.

Anyway, if you have GMP bignum library, can you post the c++ version
of java that I posted?

 

[Razii]

I thought about that, but even for that, it seems nearly unusable.
Worse, the result is pretty well unusable in any case -- can you
honestly say you'd feel comfortable shipping a 5 megabyte executable for
such a trivial program as this?

It depends if the startup time is important. I personally don't see a
need for it. JVM works fine.

It makes no sense at all to compare a java class file to a C++
executable (or any executable, for that matter). A class file isn't an
executable, so comparing it to one simply makes no sense.

In any case, the difference between ~1.5K and ~90K is fairly trivial
under most normal circumstances. Most people perceive
anything under about 150-200 ms as instant

The same applies to 100/200 ms speed difference. What human would
perceive even 500 ms time difference?

 

[Alf P. Steinbach]

* Razii:

Exactly. There is no network, no threads, no bignum. No GUI. Nothing
really. And by the way, bignum is important. You can't do cryptology
without bignum.

Anyway, if you have GMP bignum library, can you post the c++ version
of java that I posted?

Why do you need others to do it for you?

Plus, before Java's bignum was reimplemented in pure Java it was simply a
wrapper for GMP (if I recall correctly), so it's quite silly for a Java
programmer/troll to ask whether that functionality exists in C++.


Cheers, & dhth.,

- Alf

 

[Razii]

Plus, before Java's bignum was reimplemented in pure Java it was simply a
wrapper for GMP (if I recall correctly), so it's quite silly for a Java
programmer/troll to ask whether that functionality exists in C++.

It's not silly. Bignum doesn't exist in c++. Period. If you don't have
something in standard library, that means there is no guarantee that
you can port your code once you use that library. Same problem with
networking and threads. And when you switch third party libraries,
that means you will have to learn the new library all over again.

And post the c++ GMP version. Where is the documentation? It took me
about 10 minutes to come up with the idea, look up BigInteger class on
the web, write few lines, and post it here.

http://java.sun.com/j2se/1.4.2/docs/api/java/math/BigInteger.html

And I am not even Java expert. That's not what I do for living. Not
kidding. Maybe took even less than 10 minutes.

It's been 8 hours and no one has yet posted the c++ version. Why? How
come? Because it's much harder. You need to download GMP, find how it
works, even it works, and then you can't be sure your version will
work on say, Mac.

Post the C++ version. Where is it?

 

[Alf P. Steinbach]

* Razii:

It's not silly. Bignum doesn't exist in c++. Period. If you don't have
something in standard library, that means there is no guarantee that
you can port your code once you use that library. Same problem with
networking and threads. And when you switch third party libraries,
that means you will have to learn the new library all over again.

And post the c++ GMP version. Where is the documentation? It took me
about 10 minutes to come up with the idea, look up BigInteger class on
the web, write few lines, and post it here.

http://java.sun.com/j2se/1.4.2/docs/api/java/math/BigInteger.html

And I am not even Java expert. That's not what I do for living. Not
kidding. Maybe took even less than 10 minutes.

It's been 8 hours and no one has yet posted the c++ version. Why? How
come? Because it's much harder. You need to download GMP, find how it
works, even it works, and then you can't be sure your version will
work on say, Mac.

Post the C++ version. Where is it?

You have failed to write it.

Idiot.


Cheers,

- Alf

 

[Jerry Coffin]

[ ... ]

Back to the topic. Where is c++ version that does the same thing that
I posted and uses the standard c++ libraries?

The same place as a Java version of something that uses the Mersenne
twister random number generator using only the standard library.

In each case, one standard library has something other other is missing.
In both cases, that missing item is already available elsewhere quite
easily and portably, so the fact that it's not part of the standard
library doesn't mean much, and the restriction to using the standard
library is entirely artificial.

Now, if you want something interesting that really shows something about
the language instead of just grinding out code, take a look at
boost.spirit, and see how close you can come to duplicating it in Java.

 

[Jerry Coffin]

[ ... ]

Exactly. There is no network, no threads, no bignum. No GUI. Nothing
really. And by the way, bignum is important. You can't do cryptology
without bignum.

Yes, you can do cryptology without bignum. In fact, you can do it quite
nicely. There are a few symmetric ciphers that use big numbers, but
bignums only come into heavy use for public-key ciphers.

In any case, the fact that something isn't in the standard library
hardly means that it doesn't exist.

Anyway, if you have GMP bignum library, can you post the c++ version
of java that I posted?

I haven't used GMP much, but with the library I normally use (NTL) it
would look something like this:

#include <NTL/zz.h>
#include <fstream>
#include <time.h>
#include <iostream>

int main() {
int bits = 1000;
std:fstream out("prime.txt");

clock_t start = clock();
for (int i=0; i<10; i++)
out << NTL::RandomPrime_ZZ(bits) << "\n\n";
clock_t end = clock();

std::cout << "Time to generate ten "
<< bits
<< " bit prime numbers: "
<< float(end-start)/CLOCKS_PER_SEC
<< " Seconds\n";
return 0;
}

The result on my machine:

Time to generate ten 1000 bit prime numbers: 5.906 Seconds

Given the waste of space this thread constitutes in general, I suppose
including the numbers hardly makes a difference:

573222665908881845091466502342548421355689435142274936518940266894743477
413733222767241763937245479741145366326036028330221248267440197380973964
193471051085921714025259111962127334140451434217323701724156750463240092
184178704782712900793186907566913614608946012192287430915324099411931858
5172595982289

743297979050262160124590361507234251057802552296159558790449530687906086
012819339789698375941414330558978228161901837679825124685227698448719128
805787365762979897352686555912093986674111110370124513027629314405340151
847524035989122849408504775106273836612103664314605947548848599917304378
3672958178713

981424853859121698509960306466153706733858228672308093455889344619739811
673795411000453808557120560259135673647752225082952219395997357425658399
976962664708431826665500899978450997083739553986905992697177906637640455
805571998846902221093105543731215297295277450662210189013934962003504239
1814779674341

979903720903585432395761780593980883131841322654464102806914616445112724
279640101340839712033108265369504809789230299606549579135751249642827864
458981145503471038960834547560030254446690390187012965447327069752485315
364744313923379679478207783678944426611270482583722945698757838710591761
2344578879059

596790599596053296888911138030867893269833984898713137830188430061986347
237757097053584089346958636463825223033822009069074327716859180310790692
040507169713565160791658506266819685539984212852770183588414605754938667
170498068781639439555420687815354643745653591509883385976633927387856695
3289649155049

585669192532112906547638505139963499223830854918768256265800229466872344
887873308782651269814787227488957504502356536832385357751052797938284531
014686417743140474734306957381987388084066915217447894527905003886803844
023095907066370981249494571646345926631380180674807546351731560144480640
6995511826839

106890759185548666922882135258916517291668493407387545904847360302581417
354238588430742988821568026996437081046888009906066280779607592809688329
580613654724610967101923924836644089232959092934165704451851946541183139
362345178876358343660122229983074973411110065356091823719220674563393117
94752628064329

634741916523313163901118675303603480921095327705765789098192033572810249
102378196853891371494833932147723878509099246161753484541578342844672030
736988136520089676086980639986549067759482250919839138580897235250248139
975628769456346585806730760958864762087411399213719044408173061876550937
1241286199941

100261139705229304317914599756903898254394969860388432655919558814436872
694204691339061884007715404131937706091215782874966916665941991508115197
349857176366821590259377406090264343907135652761622422841981605685412918
101827273481137260872475906381578429866890990531228836218055231728157632
82500606433189

657467111127460290023894607229103006353962768843342864894035805431337357
137373981249271378545556181403491739858748095610542914895839104949626501
760168786019416356648663925507201256172862353926231013743345957695843369
414372585696129554750939592949640430609747156409968017125565006409790905
2274126349029

As I understand it, NTL _can_ use GMP for low-level primitives, but I've
never used it that way -- the time above is from NTL working on its own.

 

[Razii]

You have failed to write it.

If it was this easy, you would posted it. We both know you need to
download the library, read the documentation, and hope for the best.
That explains why you haven't posted it.

Idiot.

It's always nice to sign your name at the end.

 

[Jerry Coffin]

[ ... ]

It depends if the startup time is important. I personally don't see a
need for it. JVM works fine.

For some situations (especially servers) it works beautifully. For
others, it's completely unacceptable.

[ ... ]

The same applies to 100/200 ms speed difference. What human would
perceive even 500 ms time difference?

Nearly all. 500 ms is half a second, and nearly everybody seems to be
able to perceive that. When it's expected, they aren't necessarily
bothered a great deal by a 500 ms delay, but almost everybody perceives
it nonetheless.

 

[Ian Collins]

Now, if you want something interesting that really shows something about
the language instead of just grinding out code, take a look at
boost.spirit, and see how close you can come to duplicating it in Java.

Now that's something I really like to see

 

[Alf P. Steinbach]

* Razii:

If it was this easy, you would posted it. We both know you need to
download the library, read the documentation, and hope for the best.
That explains why you haven't posted it.


It's always nice to sign your name at the end.

So, you failed again?

ROTFLMAO


Cheers,

- Alf