Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Java vs C++ speed (IO & Sorting)

Reply
Thread Tools

Java vs C++ speed (IO & Sorting)

 
 
Roedy Green
Guest
Posts: n/a
 
      03-20-2008
On Thu, 20 Mar 2008 01:10:17 -0500, Razii <(E-Mail Removed)>
wrote, quoted or indirectly quoted someone who said :

>------------------- Java Code -------------- (same as 7 years ago


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

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
 
 
 
Razii
Guest
Posts: n/a
 
      03-20-2008
On Thu, 20 Mar 2008 06:51:05 -0500, Razii
<(E-Mail Removed)> wrote:

>
>C++ is doing far worse now (the code used was multiset version)


In Java TreeSet has no duplicates .. so I will put back ArrayList()

with 10 bibles 43 meg file

C:\>java -Xmx128m IOSort

Time for reading, sorting, writing: 4203 ms
Time for reading, sorting, writing: 3141 ms
Time for reading, sorting, writing: 3203 ms
Time for reading, sorting, writing: 2954 ms


and for c++ (using multiset)

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

 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      03-20-2008
On Mar 20, 11:01 am, peter koch <(E-Mail Removed)> wrote:
> On 20 Mar., 07:10, Razii <(E-Mail Removed)> wrote:> This topic was on
> these newsgroups 7 years ago


> >http://groups.google.com/group/comp....5ebf877e25b287


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


> [snip]
> First of all, I believe this is a bad test. A lot of the time
> will be involved with I/O which the compilers cant really
> affect.


If most of your application is involved with doing I/O, it could
be a valid measurement. If your application is CPU bound with
floating point operations, it's totally irrelevant. If your
application is sorting large text files, it's very relevant.
For most applications, I suspect, it's somewhere in between.

> I also notice that the time included does not involve
> releasing memory used by the Java-program which is unfair as
> this time was measured in the C++ version.


Yes and no. This could be considered a constraint inherent in
C++---that you can't defer releasing memory until later. (It
would be interesting to see the times for C++ with the Boehm
collector. Interesting, but not necessarily relevant to
anything in particular either.)

> Be that as it is, I notice that the C++ version is fifty
> percent shorter which suggests that developing with C++ will
> be quite a lot faster.


That's pretty much an established fact.

Seriously, it depends on what you're developing. When
reliability is important, C++ tends to win out. For
applications where it's not too important, there are some
domains where Java is particularly well integrated---it's
certainly a lot less work to develop a few beans for your web
server than it is to write CGI programs in C++. (Curiously, one
of the application domains where I think Java would have the
edge would be light weight graphic clients---a very good, fully
integrated GUI library and portability of the compiled code
would seem to be major trump cards for that. But it doesn't
seem to be widely used there.)

> I also wonder what happens in the hypothetical case where you
> were told that the solution produced was simply to slow. I
> know that C++ offers you lots of flexibility where you could
> program towards a certain environment, using e.g.
> memory-mapped I/O. (*) So all in all, the above benchmark
> could never make me consider switching languages.


That's not the purpose of it. The purpose is just to try to get
an argument going.

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
Razii
Guest
Posts: n/a
 
      03-20-2008
On Thu, 20 Mar 2008 05:08:08 -0700 (PDT), peter koch
<(E-Mail Removed)> wrote:

>I do not know your purpose of that test, but to me it confirms that
>you should use C++ and not Java. I guess that must be of relevance
>somewhere?


No, the test says nothing about c++ or java usage. It's about IO and
sorting speed and the test shows c++ has no advantage in speed. The
java code is cleared and easier to understand but even that has
nothing to do with this test.

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
side apps for example? No where. Why did c++ lose so much ground to C#
and Java in last 8 years?

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


 
Reply With Quote
 
dave_mikesell@fastmail.fm
Guest
Posts: n/a
 
      03-20-2008
On Mar 20, 7:05*am, Razii <(E-Mail Removed)> wrote:
> On Thu, 20 Mar 2008 06:55:27 -0500, Razii
>
> <(E-Mail Removed)> wrote:
> >c++ performed even worse...

>
> k, I figure out the reason .. there are no duplicates in TreeSet in
> Java


So over the last seven years that it took you to craft a benchmark in
Java's favor, you didn't learn what the basic containers in each
language can do?
 
Reply With Quote
 
Razii
Guest
Posts: n/a
 
      03-20-2008
On Thu, 20 Mar 2008 05:25:25 -0700 (PDT), James Kanze
<(E-Mail Removed)> wrote:

>(It
>would be interesting to see the times for C++ with the Boehm
>collector.


Boehm collector will be always slower than languages with built-in GC.
It's implemented via library. Retrofitting a language with gc means it
will be always slower than language designed for gc.


the following was posted to this group before (credit John Harpo)

http://lists.tunes.org/archives/gcli...er/001291.html

Such optimisations require the optimiser in the compiler to know the
details of the memory allocator and collector, i.e. the GC. This is
not possible if the GC has been retrofitted onto the language as a
library. The compiler's optimiser does not have the necessary
information to make the optimisations.


"Because it is hard to move objects for C programs", i.e. retrofitting
limits choices which limits performance.

"Many Java/ML/Scheme implementations have faster garbage collectors
that may move objects..." - Hans Boehm
http://www.hpl.hp.com/personal/Hans_...l/slide_4.html
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      03-20-2008
Razii wrote:
> On Thu, 20 Mar 2008 03:01:28 -0700 (PDT), peter koch
> <(E-Mail Removed)> wrote:
>
>> I also
>> notice that the time included does not involve releasing memory used
>> by the Java-program which is unfair as this time was measured in the C+
>> + version.

>
> You are not making sense. Where on earth is c+ releasing memory in the
> code that I posted?


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

I have a hard time imagining any simple way NOT to include GC time in the Java
timings.

--
Lew
 
Reply With Quote
 
Razii
Guest
Posts: n/a
 
      03-20-2008
On Thu, 20 Mar 2008 05:41:14 -0700 (PDT), http://www.velocityreviews.com/forums/(E-Mail Removed)
wrote:

>So over the last seven years that it took you to craft a benchmark in
>Java's favor, you didn't learn what the basic containers in each
>language can do?


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?
 
Reply With Quote
 
Michael.Boehnisch@gmail.com
Guest
Posts: n/a
 
      03-20-2008
On 20 Mrz., 11:01, peter koch <(E-Mail Removed)> wrote:
> First of all, I believe this is a bad test. A lot of the time will be
> involved with I/O which the compilers cant really affect.


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.
Memory allocation seems to be no issue, at least not for C++ - if I
comment out the buf.reserve() call, no change in runtime is
noticeable.
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).

One more thing caught my eye: The bible file contains a single empty
line that is processed by the C++ version but not by the Java version.
One extra empty line is not much, but induces O(log n) extra steps for
the sorting. If I modify the C++ program to disregard the empty line,
computing time goes down to 358ms (or 94ms --> 77ms for the sorting
only!).

> I also
> notice that the time included does not involve releasing memory used
> by the Java-program which is unfair as this time was measured in the C+
> + version.


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

> Be that as it is, I notice that the C++ version is fifty percent
> shorter which suggests that developing with C++ will be quite a lot
> faster.


While I agree in part, IMHO you are not referring to the right reason.
The physical typing of the programs should not make a big difference -
in C++ you can use really nifty constructs that save plenty of source
bytes. However, most other developers will have problems reading your
code - even you yourself may not be able to explain a code snippet you
wrote "ad hoc" only one week later.
Just as example, the infamous Ackerman function:

int ack( const int m, const int n ) {
return m?n?ack(m-1,ack(m,n-1)):ack(m-1,1):n+1;
}

This *is* valid C++ code - a real space-saver, horrible style. I would
prefer the more typing intensive, but better manageable version:

int ack( const int m, const int n ) {
if ( m == 0 ) return n+1;
if ( n == 0 ) return ack( m-1, 1 );
return ack( m-1, ack( m, n-1 ) );
}

Both versions are not identical in run-time efficiency: the "nifty"
version takes 5,4s on my system for ack(4, 1), the lengthy one 3,6s
only. I have no quick explanation for the difference, though.
For my feeling, too, the Java version looks clumsy style - it is
harder to understand.

just my EURO.02,

Michael.
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      03-20-2008
James Kanze wrote:
> the real reason I
> use C++ is because my applications have to be robust, and it's
> easier to develop correct code with C++ than with Java.


YMMV. I find that Java supports correct code, robustness and scalability a
LOT more than C++. But then, I like emacs better than vi, too.

Neither one of us can claim that either language makes it "easier to develop
correct code" without a whole lot of evidence, and factoring in the impedance
match to the developer's mind.

The best you can aver is that you /feel/ that C++ makes it easier /for you/ to
develop correct code, for certain values of "correct".

--
Lew
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Reported Wireless speed w/ repeater 7-9x Measured Speed Lance Wireless Networking 0 10-31-2004 09:31 PM
I need speed Mr .Net....speed Ham ASP .Net 6 10-29-2004 08:04 AM
speed speed speed a.metselaar Computer Support 14 12-30-2003 03:34 AM
java tool to test disk i/o, processor speed, and network speed efiedler Java 1 10-09-2003 03:36 PM
USB High Speed against USB Non High Speed DannyD1355 Computer Support 1 09-07-2003 02:59 AM



Advertisments