Java vs C++ speed (IO & Sorting)

[dave_mikesell]

All you do with C++ is write drivers and that can be done just fine
with C.

Drivers, graphics, games, financial and trading software, database,
telecom, embedded systems, desktop applications, etc. Think of all
of the different software needed to provide web access to Usenet
groups (browser, DB, server OS, networking, JVM, app server, etc.) and
what language was used to write these components. Your Java code
serving the content is really a small part of the big picture.

 

[Lew]

Unfair. C++ gets the benefit of a static optimisation. Let Java have
one too. see http://mindprod.com/jgloss/jet.html

Unfair. Java gets the benefit of dynamic optimization. Let C++ have one, too.

 

[Razii]

Quick check, comment out the std::sort() call:
with std::sort(): 375ms
w/o : 281ms
I seem to have a similar machine in terms of performance, compared to
the original poster

The program's runtime is dominated by the I/O, executed in both cases
by the same OS back-end functions.
The rest of the program is mainly comparing and shoving around memory
segments, I assume in both cases executed by library *machine* code.
Its only natural to me, the execution time is near identical.

It's not that "natural". If you go back and read the old thread, you
will see that the claim by many people was that IO is really slow in
Java compared to C++. I posted this (that was 2001) and asked why I
see no great speed advantage for C++.

However, the Java code pre-allocates 5000 lines, the C++ version
50000. Somebody with a Java environment may check out what happens if
the number is adjusted.
(The example text is ~31,000 lines).

I noticed that. The C++ version was posted to this group by someone
named Pete Becker (from dinkumware). My version was using set. It
didn't make much difference in Java (or even C++) whether I use 5000
or 50000 so I ignored that part.

Plus, the considerable effort for loading and initialization, and
garbage collection of the Java VM is not included.

It's irrelevant to reading, writing and sorting. If you are going to
include everything like Java virtual machine load time, how about the
fact that IOSort.exe is 135 KB and IOSort.class is only 1 kb. Count
that as an advantage for Java The file size is 135 times smaller.

 

[Michael DOUBEZ]

Razii a écrit :

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

My system tells otherwise
D:\gnuwin32>java IOSort
Time for reading, sorting, writing: 629 ms

D:\gnuwin32>IOSort.exe
Time for reading, sorting, writing: 429 ms

I compiled with java 6 update 5 and gcc 3.4.5:
javac IOSort.java
g++ IOSort.cpp -o IOSort.exe


Michael

 

[Paavo Helde]

Super computer? Just an AMD FX74 3Ghz, Sun CC. 70mS reading to
multiset, 20mS writing.

Note that these 20 ms measure most probably measure the time data reached
the disk cache. Actual writing to the disk file appears later. So for more
fair comparison you both should give your RAM size and the amount of other
concurrent programs occupying that RAM and the amount left free for file
caching... followed by a fierce argument about different OS strategies of
using free RAM for disk caching...

Paavo

 

[Razii]

Where on earth is the Java code NOT releasing its unused memory?
How is the time for Java to release memory NOT being measured?

You are wasting time and trolling. Memory allocation is no issue in
the part we tested, as someone else also noted.

 

[James Kanze]

You were here 7 years ago ...

Sorry, but I wasn't "here" 7 years ago. (My participation in
this group goes back over 15 years, but 7 years ago, I was
working as a Java expert, and my C++ postings were limited to
the moderated group.)

I remember your name. Are you claiming no one has ever said
c++ has huge speed advantage?

No matter what the claim, somewhere, some idiot has made it. No
one competent would claim that there is anything intrinsic in
C++ that would make it faster than Java.

 

[Razii]

My system tells otherwise
D:\gnuwin32>java IOSort
Time for reading, sorting, writing: 629 ms

D:\gnuwin32>IOSort.exe
Time for reading, sorting, writing: 429 ms

Run it three or four times... Also, remove if (line.length() == 0)
continue; from while loop.

Try testing it with pre-allocating 50000 instead of 5000 for Arraylist
(though that didn't make any difference for me).

In any case, 629 and 429 is not much difference

with 10 bibles 43 meg file I got

Time for reading, sorting, writing: 4203 ms (java)
Time for reading, sorting, writing: 3141 ms (java)
Time for reading, sorting, writing: 3203 ms (java)
Time for reading, sorting, writing: 2954 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++)

 

[Paavo Helde]

It took me seven years? What the heck? I posted this 7 years ago and
you (and by that I mean these two newsgroups) failed to show c++ is
faster. I came back 7 years later and posted the same thing and you
still failed to show c++ is faster.

What does that have to do with what I did for 7 years?

Good, it shows that Java is performance-wise a usable language, at least
in the case of the data types and usage pattern used in this example.
There are some upper limits set by hardware which you cannot exceed in
any language, except of devising of a better algorithm to accomplish
something.

This still does not convince me to dump C++ and switch over to Java,
first because of continuous casting and second, because of inability to
build clean abstraction layers. Maybe I'm wrong, I have not touched Java
in several years, but even if they appear equal now I still would not
switch because of inertia. Java should be at least twice as fast and
provide more convenient abstraction layers before I would think of
switching languages.

All the best
Paavo

 

[dave_mikesell]

It's irrelevant to reading, writing and sorting. If you are going to
include everything like Java virtual machine load time, how about the
fact that IOSort.exe is 135 KB and IOSort.class is only 1 kb. Count
that as an advantage for Java The file size is 135 times smaller.

You can't run the Java version without the VM. It's perfectly
reasonable (and intellectually honest) to count the VM startup time.

 

[James Kanze]

Unfair. C++ gets the benefit of a static optimisation. Let Java have
one too. seehttp://mindprod.com/jgloss/jet.html

Unfair: Java gets the advantage of garbage collection and no
array aliasing.

At the level of what's being measured here, the two languages
are largely equivalent, and given a high quality optimizer, I
would expect similar performance from both. For this particular
benchmark (which actually seems pretty irrelevant with regards
to what people actually do)---I've said it before: pay me to
write a benchmark to show that Java is significantly faster than
C++, and I'll do it; pay me to show that C++ is significantly
faster, and I'll do that too. In fact, I think I could even
arrange it so that the two looked superficially very, very
similar.

(FWIW: he didn't really show us the invocations he used to
compile and run either. It's probable that he's not really
optimizing either.)

 

[Paavo Helde]

Yawn. I really care what language you use (NOT).

So why you keep posting? What is your point?

Paavo

 

[witmer]

In any case, 629 and 429 is not much difference

Excuse me? Those numbers show a 32% variance while yours show a 38%
variance in the other direction. If 629 and 429 aren't much
difference, than neither are your numbers.

 

[Razii]

You can't run the Java version without the VM. It's perfectly
reasonable (and intellectually honest) to count the VM startup time.

No, you can compile .class file to exe file if you want to using a
compiler like JET (I will post that result next). You don't need a VM.
In any case, VM start up time has nothing to do with the part that was
tested .. that is, reading file, sorting, and writing file.

 

[James Kanze]

[...]

Good, it shows that Java is performance-wise a usable
language, at least in the case of the data types and usage
pattern used in this example.

Surely you didn't need his benchmark to conclude that. (Well,
modulo the "this example" part.) There are probably some
applications where Java will not be acceptable for performance
reasons (and some where C++ will not be acceptable), but they're
certainly the exceptional cases.

There are some upper limits set by hardware which you cannot
exceed in any language, except of devising of a better
algorithm to accomplish something.

It's true that his measurements are a pretty good indication
that C++ and Java use the same algorithm in their sort
functions.

This still does not convince me to dump C++ and switch over to
Java, first because of continuous casting

Modern Java has templates, and even back when I was using it
regularly, before it had templates, we didn't have to cast that
much.

and second, because of inability to build clean abstraction
layers.

That's the real problem. It makes for a lot of extra work when
using Java in large applications. (For small applications,
Java's actually not too bad. Although I find that once you've
gotten used to programming cleanly, it's frustrating to not be
able to.)

 

[dave_mikesell]

So why you keep posting? What is your point?

Indeed. This guy's been trolling for years, probably at some public
university on my dime.

http://tinylink.com/?pqsUOXkpTf

 

[dave_mikesell]

No, you can compile .class file to exe file if you want to using a
compiler like JET (I will post that result next).

Which you did not do in your test.

You don't need a VM.
In any case, VM start up time has nothing to do with the part that was
tested .. that is, reading file, sorting, and writing file.

Complete nonsense. If you are using the VM to load and run your class
file, the time must count.

 

[Razii]

(FWIW: he didn't really show us the invocations he used to
compile and run either. It's probable that he's not really
optimizing either.)

I did say it what command line I used

C:\>cl IOSort.cpp /O2

 

[Paavo Helde]

As for library, that's the problem with c++. You have to use third
party libraries for something as basic and important as networking
and threading. In 99% of software today, threading and networking is
needed. That's a very good reason why not to use c++ and why there is
no c++ on web, commerce, business apps etc. Where is c++ on server

C++ can use C libraries for threading and networking - it's simple as that.

side apps for example? No where. Why did c++ lose so much ground to C#
and Java in last 8 years?

In our company (8500 employees) there are several server components written
in C++. I have never heard of Java in company meetings (though C# is
lurking its head - I suspect you have to change partners if you want to
continue attacking C++ ;-)

Regards
Paavo

 

[Lew]

This still does not convince me to dump C++ and switch over to Java,
first because of continuous casting and second, because of inability to
build clean abstraction layers. Maybe I'm wrong, I have not touched Java
in several years, but even if they appear equal now I still would not
switch because of inertia. Java should be at least twice as fast and
provide more convenient abstraction layers before I would think of
switching languages.

The voice of reason - there are many reasons to choose a programming language,
many more than mere "performance" for various values of the term. Robustness,
mentioned upthread, is arguably far more important. Expertise in the language
is important - if you are productive in C++ (or whatever) you might not want
to make the investment in becoming equally proficient in another language.

Java and C++ clearly both have their strengths, and having seen these
Benchmark Wars before I can reasonably conclude that they're roughly
comparable, at least both usable. Most benchmarks I've seen do seem to give
C++ the edge for CPU-bound processes by around 2:1, but none conclusively so.
Throughput measures for realistic applications do seem to tend toward
Java-based solutions, but a lot of that is attributable to the integration of
enterprise components more than the strength of the JVM per se.

Java-based enterprise systems tend to support operations better than C++-based
ones. Java platforms are highly amenable to instrumentation and operational
control. Operations presents a much higher portion of cost and risk than the
development phase of an application. Operations is far more important than
development. Developers tend to forget that.

Real mastery comes with fluency in a variety of languages, at least one in
each major category (systems/applications - C??/Java/COBOL, script -
JS/Ruby/Python/EL, shell - csh/bash/ksh). Use what's best for the project at
hand. To be a carpenter takes more than a hammer.