Java vs C++ speed (IO & Sorting)
Razii
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 Code -------------- (same as 7 years ago :)
import java.io.*;
import java.util.*;
public class IOSort
{
public static void main(String[] arg) throws Exception
{
ArrayList ar = new ArrayList(5000);
String line = "";
BufferedReader in = new BufferedReader(
new FileReader("bible.txt"));
PrintWriter out = new PrintWriter(new BufferedWriter(
new FileWriter("output.txt")));
long start = System.currentTimeMillis();
while (true)
{
line = in.readLine();
if (line == null)
break;
if (line.length() == 0)
continue;
ar.add(line);
}
Collections.sort(ar);
int size = ar.size();
for (int i = 0; i < size; i++)
{
out.println(ar.get(i));
}
out.close();
long end = System.currentTimeMillis();
System.out.println("Time for reading, sorting, writing: "+
(end - start) + " ms");
}
}
--------- C++ Code ---------------
#include <fstream>
#include<iostream>
#include <string>
#include <vector>
#include <algorithm>
#include <ctime>
using namespace ::std;
int main()
{
vector<string> buf;
string linBuf;
ifstream inFile("bible.txt");
clock_t start=clock();
buf.reserve(50000);
while(getline(inFile,linBuf)) buf.insert(buf.end(), linBuf);
sort(buf.begin(), buf.end());
ofstream outFile("output.txt");
copy(buf.begin(),buf.end(),ostream_iterator<string>(outFile,"\n"));
clock_t endt=clock();
cout <<"Time for reading, sorting, writing: " << endt-start << "
ms\n";
return 0;
}
Tim H
> 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 :)
>
Did this include JVM startup time? What were the memory footprints?
Razii
wrote:
>Did this include JVM startup time? What were the memory footprints?
Read the code.. you will see where the time comes from. What does
start time of virtual machine has to do with the time for reading,
sorting and writing file?
jason.c...@gmail.com
> The question still is (7 years later), where is great speed advantage
> you guys were claiming for c++?
Well I was not involved in that original topic, but I can tell you
that Java has improved a lot over the years. VM startup times aside,
there are VM's that will compile to native code on the fly, the byte
code optimizers have been greatly improved, there are even CPU's that
execute Java byte code directly (not on your test platform, but you'll
find these on devices like PDAs and mobile phones).
C++ will bring you closer to the hardware you are developing for, that
is one of the strengths of the language, but Java can be just as
respectable as far as performance goes. It really just depends on what
you are using the language for. Use the most appropriate tool for the
job.
Also, comparing to your results 7 years ago, it looks like Java has
slowed down a bit, relatively. :-D
Jason
Razii
>Also, comparing to your results 7 years ago, it looks like Java has
>slowed down a bit, relatively. :-D
Slowed down? It was 2080 ms in the google link that I posted. It's 359
ms this time (however, the bible.txt file was different back then. So
there can't be any comparison with the old times).
jason.c...@gmail.com
> On Wed, 19 Mar 2008 23:57:25 -0700 (PDT), "jason.cipri...@gmail.com"
>
> <jason.cipri...@gmail.com> wrote:
> >Also, comparing to your results 7 years ago, it looks like Java has
> >slowed down a bit, relatively. :-D
>
> Slowed down? It was 2080 ms in the google link that I posted. It's 359
> ms this time (however, the bible.txt file was different back then. So
> there can't be any comparison with the old times).
Key word: relatively. I was making a joke that the old C++:Java ratio
was 3400:2080 (1.0:0.6), and the new one is 375:370 (1.0:1.0).
Jason
Ian Collins
>
> --------- C++ Code ---------------
>
> #include <fstream>
> #include<iostream>
> #include <string>
> #include <vector>
> #include <algorithm>
> #include <ctime>
#include <iterator>
Is required for ostream_iterator.
> using namespace ::std;
>
>
> int main()
> {
> vector<string> buf;
> string linBuf;
> ifstream inFile("bible.txt");
> clock_t start=clock();
> buf.reserve(50000);
>
>
> while(getline(inFile,linBuf)) buf.insert(buf.end(), linBuf);
> sort(buf.begin(), buf.end());
Why not use a sorted container? Your example takes 120mS on my box,
using std::multiset reduces this to 90.
> ofstream outFile("output.txt");
> copy(buf.begin(),buf.end(),ostream_iterator<string>(outFile,"\n"));
> clock_t endt=clock();
> cout <<"Time for reading, sorting, writing: " << endt-start << "
> ms\n";
endt-start is in what ever unit the system returns from clock(), it
should be scaled by CLOCKS_PER_SEC.
--
Ian Collins.
peter koch
> 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 :)
>
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. 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.
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.
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.
/Peter
(*) Simpler measures such as adjusting the buffers of the streams
could also have an effect.
jason.c...@gmail.com
> Why not use a sorted container? Your example takes 120mS on my box,
> using std::multiset reduces this to 90.
What kind of super computers are you guys using? I mean my machine is
a little over a year old but... took me 790ms on a 2.16GHz Core Duo,
7200 RPM SATA something or other hard drive, with GCC -O2 (MinGW, GCC
3.4.5), using QueryPerformanceCounter for timings. Multiset reduced it
to about 720; with 380 for read + sort and 340 for write.
Jason
Razii
>Key word: relatively. I was making a joke that the old C++:Java ratio
>was 3400:2080 (1.0:0.6), and the new one is 375:370 (1.0:1.0).
Read the whole thread.. (700+ posts .. is that still a record in this
group?) :)
In the end they whined, made me change compilers, then after I got
VC++, claimed there is a bug in VC++ 5.0 library, . I had to fix the
bug. c++ ended up slightly faster after all that. even then there was
nothing to brag about.
Ian Collins
multiset, 20mS writing.
--
Ian Collins.
Razii
wrote:
>Why not use a sorted container? Your example takes 120mS on my box,
>using std::multiset reduces this to 90.
Two chapters in the bible are identical. If you used set, that won't
include duplicates.
Both java and c++ used the same code, so what's the problem?
Funny that in 2001 when I first posted this I used set. Some guy, Pete
Becker, claimed I was comparing apples and oranges and must use
vector.
Ian Collins
> On Thu, 20 Mar 2008 21:20:19 +1300, Ian Collins <ian-...@hotmail.com>
> wrote:
>
>> Why not use a sorted container? Your example takes 120mS on my box,
>> using std::multiset reduces this to 90.
>
> Two chapters in the bible are identical. If you used set, that won't
> include duplicates.
>
You're requirement was "How about reading the whole Bible, sorting by
lines, and writing the sorted book to a file?"
Reading into a multiset and then writing out meets those requirements.
--
Ian Collins.
Lionel B
> On Thu, 20 Mar 2008 21:20:19 +1300, Ian Collins <ian-...@hotmail.com>
> wrote:
>
>>Why not use a sorted container? Your example takes 120mS on my box,
>>using std::multiset reduces this to 90.
>
> Two chapters in the bible are identical. If you used set, that won't
> include duplicates.
That's probably why he suggested using `multiset'.
> Both java and c++ used the same code, so what's the problem?
"Same code" seems like stretching it a bit to me...
> Funny that in 2001 when I first posted this I used set. Some guy, Pete
> Becker, claimed I was comparing apples and oranges and must use vector.
Does Java have a `multiset' equivalent? If so, maybe try a comparison
using that.
--
Lionel B
Razii
<peter.ko...@gmail.com> 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?
>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.
No, it's generally accepted that developing in C++ is much slower and
difficult due to pathetic c++ library, no thread support, no network
library. As for the length of code I posted, I can jumble everything
together and make Java code look short :)
import java.io.*; import java.util.*; public class IOSort
{public static void main(String[] arg) throws Exception {
ArrayList<String> ar = new ArrayList<String>(50000); String line = "";
BufferedReader in = new BufferedReader( new FileReader("bible.txt"));
PrintWriter out = new PrintWriter(new BufferedWriter(new
FileWriter("output.txt"))); long start = System.currentTimeMillis();
while (true) { line = in.readLine(); if (line == null) break;
ar.add(line); } Collections.sort(ar); int size = ar.size();
for (int i = 0; i < size; i++) { out.println(ar.get(i));}
out.close(); long end = System.currentTimeMillis();
System.out.println("Time for reading, sorting, writing: "+ (end -
start) + " ms"); } }
I hope you are satisfied :))
On a serious note, I also removed an unneeded line, (if (line.length()
==0) continue;) that was in the loop. That probably helped in speed.
>So all in all, the above benchmark could never make me consider
>switching languages.
Yawn. I really care what language you use (NOT).
Juha Nieminen
> The question still is (7 years later), where is great speed advantage
> you guys were claiming for c++?
1) 300 ms is too short of a time for any reliable comparison.
2) With heavy I/O, as in this case, the bottleneck is not in the
language but in the I/O system, which is often independent of the
language (and more dependent on the hardware and somewhat on the
operating system).
Just because Java can read and write files at the same speed as C++
doesn't mean that it's equally fast in general. (OTOH, it doesn't mean
the contrary either, of course.)
jason.c...@gmail.com
> On Thu, 20 Mar 2008 01:16:58 -0700 (PDT), "jason.cipri...@gmail.com"
>
> <jason.cipri...@gmail.com> wrote:
> >Key word: relatively. I was making a joke that the old C++:Java ratio
> >was 3400:2080 (1.0:0.6), and the new one is 375:370 (1.0:1.0).
>
> Read the whole thread.. (700+ posts .. is that still a record in this
> group?) :)
I most certainly will not read the whole thread; because I do not
care. Also I'm happy for your record. Makes for a good resume, I
guess...? At least you'll be able to have fun trolling with the rest
of the people here that will be taking the bait for the next few days.
Good luck, I'll pop in and say high when this thread beats the old
one.
Jason
jason.c...@gmail.com
>
> <jason.cipri...@gmail.com> wrote:
> >Key word: relatively. I was making a joke that the old C++:Java ratio
> >was 3400:2080 (1.0:0.6), and the new one is 375:370 (1.0:1.0).
>
> Read the whole thread.. (700+ posts .. is that still a record in this
> group?) :)
>
> In the end they whined, made me change compilers, then after I got
> VC++, claimed there is a bug in VC++ 5.0 library, . I had to fix the
> bug. c++ ended up slightly faster after all that. even then there was
> nothing to brag about.
Anyways, if you use Java, it should be because of it's rich component
library, cross-platformness, and other great strengths -- not because
some strange test case out-performed another language by a few
milliseconds. You are testing all the wrong things. What you really
need to do is use whatever tool is most appropriate for the job at
hand, not whatever tool sorts the bible 4 milliseconds faster than the
other one...
James Kanze
> 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
> hereftp://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++?
Who ever claimed a speed advantage for C++? I've said it more
than once, I can write a benchmark in which C++ will beat Java
hands down. Or vice versa. It happens that C++ will beat Java
in the type of code I'm working on now, but 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.
For those who want to prove C++ faster, just do something with
large arrays of user defined types having value semantics. For
those who want to prove Java faster, use large arrays of basic
types, or where you can swap the pointers, rather than the
values. Like this particular example:-)---I'm really surprised
that Java didn't do a lot better.
For those who are concerned with performance in your actual
work, of course, write a benchmark which simulates your actual
work (I don't know of too many people just sorting lines in a
single large text corpus), and benchmark it, on the machine
you'll actually be running on. (The quality of Java---and
C++---implementations varies a lot.) In theory, Java has the
advantage in array accesses (because of the lack of aliasing);
C++ when it comes to handling user defined value types (no
allocation is even cheaper than garbage collected allocation).
In practice, however, it will depend on the implementation.
--
James Kanze (GABI Software) email:james...@gmail.com
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
James Kanze
> Razii wrote:
> > --------- C++ Code ---------------
> > #include <fstream>
> > #include<iostream>
> > #include <string>
> > #include <vector>
> > #include <algorithm>
> > #include <ctime>
> #include <iterator>
> Is required for ostream_iterator.
Nothing to do with this thread, but I'll bet you caught that
error with code review, and not with a unit test:-).
Razii
wrote:
>That's probably why he suggested using `multiset'.
By the way, have look at 2001 post where I used set...
http://groups.google.com/group/comp.lang.c++/msg/695ebf877e25b287
In that case, it didn't make a difference because bible.txt I was
using had verse numbers (so there could be no duplicates). A few here
(including Pete Becker from dinkumware) claimed that I used set and it
was unfair...
In any case, I can use 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 a little improvement only...
For Java I can try TreeSet
http://java.sun.com/javase/6/docs/api/java/util/TreeSet.html
(which I asume does something similiar -- if not, any Java expert can
correct it).
Time for reading, sorting, writing: 359 ms
Time for reading, sorting, writing: 360 ms
Time for reading, sorting, writing: 359 ms
Not much changes here ...
------ c++-------
#include <fstream>
#include<iostream>
#include <string>
#include <set>
#include <algorithm>
#include <ctime>
using namespace ::std;
using namespace std;
void main()
{
multiset<string> buf;
string linBuf;
ifstream inFile("bible.txt");
clock_t start=clock();
while(getline(inFile,linBuf))
buf.insert(linBuf);
ofstream outFile("output.txt");
copy(buf.begin(),buf.end(),ostream_iterator<string>(outFile,"\n"));
clock_t endt=clock();
cout <<"Time for reading, sorting, writing: " << endt-start << "
ms\n";
}
-------- java -----------
import java.io.*;
import java.util.*;
public class IOSort
{
public static void main(String[] arg) throws Exception
{
Collection<String> ar = new TreeSet<String> ();
String line = "";
BufferedReader in = new BufferedReader( new
FileReader("bible.txt"));
PrintWriter out = new PrintWriter(new BufferedWriter(new
FileWriter("output.txt")));
long start = System.currentTimeMillis();
while (true)
{ line = in.readLine();
if (line == null)
break;
ar.add(line);
}
int size = ar.size();
for (String c : ar)
{
out.println(c);
Razii
<james...@gmail.com> wrote:
>Who ever claimed a speed advantage for C++?
You were here 7 years ago ... I remember your name. Are you claiming
no one has ever said c++ has huge speed advantage? If that's your
claim, then you are either being dishonest or have a bad memory
Ian Collins
> On Thu, 20 Mar 2008 10:36:20 +0000 (UTC), Lionel B <m...@privacy.net>
> wrote:
>
>> That's probably why he suggested using `multiset'.
>
> By the way, have look at 2001 post where I used set...
>
> http://groups.google.com/group/comp.lang.c++/msg/695ebf877e25b287
>
> In that case, it didn't make a difference because bible.txt I was
> using had verse numbers (so there could be no duplicates). A few here
> (including Pete Becker from dinkumware) claimed that I used set and it
> was unfair...
>
> In any case, I can use 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 a little improvement only...
>
multiset implementation. Try checking the read and write times on your
original code.
--
Ian Collins.
Yannick Tremblay
If you don't care about what language other peoples use, why are
trying to start a flame war across 2 newsgroup?
Razii
<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)
Razii
wrote:
>So you have a slow system that may be I/O bound, or you have a poor
>multiset implementation. Try checking the read and write times on your
>original code.
Well, the java code is running on the same "slow system"
And see the other post .. make bible.txt 10 times bigger by copying
and pasting 9 more times. Make it 43 meg file. After that,...
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++)
c++ performed even worse...
Razii
wrote:
>If you don't care about what language other peoples use, why are
>trying to start a flame war across 2 newsgroup?
It's not a flame war. It's a discussion and testing. If you are not
interesting in it, just move on to next thread.
Razii
<DONTwha...@hotmail.com> wrote:
>c++ performed even worse...
k, I figure out the reason .. there are no duplicates in TreeSet in
Java :)
peter koch
> On Thu, 20 Mar 2008 03:01:28 -0700 (PDT), peter koch
>
> >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?
>
> >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.
>
> No, it's generally accepted that developing in C++ is much slower and
> difficult due to pathetic c++ library, no thread support, no network
> library.
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.
Apart from that, the C++ philosophy is very different from the Java
one: Java has an "everything in one package" whereas in C++ you
typically use add-on packages. So if you use threading and networking,
just use e.g. Posix or Corba or boost which gives you everything.
As for the length of code I posted, I can jumble everything
> together and make Java code look short :)
>
> import java.io.*; import java.util.*; public class IOSort
> {public static void main(String[] arg) throws Exception {
> ArrayList<String> ar = new ArrayList<String>(50000); String line = "";
> BufferedReader in = new BufferedReader( new FileReader("bible.txt"));
> PrintWriter out = new PrintWriter(new BufferedWriter(new
> FileWriter("output.txt"))); long start = System.currentTimeMillis();
> while (true) { line = in.readLine(); if (line == null) break;
> ar.add(line); } Collections.sort(ar); int size = ar.size();
> for (int i = 0; i < size; i++) { out.println(ar.get(i));}
> out.close(); long end = System.currentTimeMillis();
> System.out.println("Time for reading, sorting, writing: "+ (end -
> start) + " ms"); } }
>
> I hope you are satisfied :))
Right. But count the number of statements: they are the same. And
still the same half time longer.
>
> On a serious note, I also removed an unneeded line, (if (line.length()
> ==0) continue;) that was in the loop. That probably helped in speed.
It did? That would give you more lines to sort, wouldn't it?
>
> >So all in all, the above benchmark could never make me consider
> >switching languages.
>
> Yawn. I really care what language you use (NOT).
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?
/Peter
Cory Nelson
> On Thu, 20 Mar 2008 04:12:33 -0700 (PDT), James Kanze
>
> >Who ever claimed a speed advantage for C++?
>
> You were here 7 years ago ... I remember your name. Are you claiming
> no one has ever said c++ has huge speed advantage? If that's your
> claim, then you are either being dishonest or have a bad memory
This specific test has a lot of room to be specialized. A quick
example: arenas and intrusive containers. Near zero-overhead paged
allocation means less memory usage and much faster execution, and
boost.intrusive's multiset container can give less overhead than a
std::multiset and better locality.
Is such optimization usually needed? No. But after you've profiled
if you decide your approach isn't adequate, C++ gives you a lot more
freedom than Java to do so when you need it. Apples to apples
comparisons are silly: in what real-world situation would you limit
your app design because another language can't do something?
And I question both benchmarks' timing methods. On Windows, clock()
will return wall time. On *nix it will return real processor usage
time. These should both be measuring processor usage, not wall time.
Roedy Green
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
Razii
<DONTwha...@hotmail.com> 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)
James Kanze
> On 20 Mar., 07:10, Razii <fdgl...@hotmails.com> wrote:> 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 :)
> [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.
Razii
<peter.ko...@gmail.com> 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.
dave_m...@fastmail.fm
> On Thu, 20 Mar 2008 06:55:27 -0500, Razii
>
> >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?
Razii
<james...@gmail.com> 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/gclist/1997-November/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_Boehm/gc/nonmoving/html/slide_4.html
Lew
> On Thu, 20 Mar 2008 03:01:28 -0700 (PDT), peter koch
> <peter.ko...@gmail.com> 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
Michael....@gmail.com
> 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.
Razii
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?
Lew
> 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
dave_m...@fastmail.fm
>
> 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
> On Thu, 20 Mar 2008 01:10:17 -0500, Razii <fdg...@hotmails.com>
> 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
Unfair. Java gets the benefit of dynamic optimization. Let C++ have one, too.
--
Lew
Michael DOUBEZ
> 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 :)
>
> 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
Razii
wrote:
>On 20 Mrz., 11:01, peter koch <peter.koch.lar...@gmail.com> 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.
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.
Paavo Helde
@mid.individual.net:
> jason.c...@gmail.com wrote:
>> On Mar 20, 4:20 am, Ian Collins <ian-n...@hotmail.com> wrote:
>>> Why not use a sorted container? Your example takes 120mS on my box,
>>> using std::multiset reduces this to 90.
>>
>> What kind of super computers are you guys using? I mean my machine is
>> a little over a year old but... took me 790ms on a 2.16GHz Core Duo,
>> 7200 RPM SATA something or other hard drive, with GCC -O2 (MinGW, GCC
>> 3.4.5), using QueryPerformanceCounter for timings. Multiset reduced it
>> to about 720; with 380 for read + sort and 340 for write.
>>
> 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
> On Thu, 20 Mar 2008 04:12:33 -0700 (PDT), James Kanze
>
> <james.ka...@gmail.com> wrote:
> >Who ever claimed a speed advantage for C++?
> 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.
Paavo Helde
news:67n4u3h9g166rh2ah...@4ax.com:
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_m...@fastmail.fm
>
> 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.
Razii
<michael...@free.fr> wrote:
>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++)
James Kanze
wrote:
> On Thu, 20 Mar 2008 01:10:17 -0500, Razii <fdgl...@hotmails.com>
> 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. 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
news:eue4u3dnkbif9tvve...@4ax.com:
>>So all in all, the above benchmark could never make me consider
>>switching languages.
>
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.
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_m...@fastmail.fm
> Razii <DONTwhatever...@hotmail.com> wrote innews:eue4u3dnkbif9tvve...@4ax.com:
>
> >>So all in all, the above benchmark could never make me consider
> >>switching languages.
>
> > Yawn. I really care what language you use (NOT).
>
> 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.
Razii
wrote:
>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.
dave_m...@fastmail.fm
> On Thu, 20 Mar 2008 06:35:56 -0700 (PDT), dave_mikes...@fastmail.fm
> wrote:
>
> >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).
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.
Paavo Helde
news:fol4u3hu7dkma0ctc...@4ax.com:
> 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.
--
Lew
Joe Greer
news:a20f9c4d-a843-47af...@2g2000hsn.googlegroups.com:
> 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.)
In my opinion, there are several things that stand in the way of this.
First, there is more to look and feel than properly drawn controls. This
makes a generic GUI feel just a little wrong everywhere. Second,
interfacing to native code from Java, while doable, is a pain. Third,
there aren't as many folks worried about GUI portability as you might
imagine. There just isn't the bang for the buck you want in order to go
through the porting effort.
joe
Razii
<james...@gmail.com> wrote:
>(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
Lew
> 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.
Sorry, but that is not accurate. Java does not have templates. Java has
generics, which use a typographical notation similar to templates, but are
neither called "templates" nor work the way C++ templates do.
Generics were introduced in Java 5, some three-plus years ago. Unlike C#
generics they pertain only to the compile phase, not to run-time types. Java
generics are quite powerful, but the lack of reification is a major complaint
in the Java universe. Java programmers are used to run-time typing and seem
to resent that generics aren't part of it.
Personally, while I agree that generic type erasure is annoying, I find the
discipline of separating run-time and compile-time notions to be a powerful
aid to reasoning about my programs, especially in a dynamic language such as
Java or C#.
--
Lew
Razii
<wit...@averagesoftware.org> wrote:
>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.
I never claimed Java is faster. People in this newsgroup have claimed
that java is *much* slower. In other words, you must show significant
speed advantage in this test case.
Razii
wrote:
>Which you did not do in your test.
I am compiling with JET now..
>
>> 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.
Nope. VM load time has nothing to do with what we are testing. C++
code also only times needed for reading the file, sorting and writing
the file.
witmer
32% is extremely significant.
Michael DOUBEZ
On my system, c++ has a penalty with writing to the disk.
If you remove writing, you lower the noise on the measurement. I guess
the STL I use could benefit of some optimisation in this part.
I for one never claimed java is *much* slower, JIT do wonders. Truly and
I expect increased processor power will lessen the gap. Nowadays, it is
more I/O access that are the bottlenecks.
Here are the results of the modified versions (removing the write part):
D:\gnuwin32>java IOSort && IOSort.exe
Time for reading, sorting, writing: 1448 ms
Time for reading, sorting, writing: 1167 ms
D:\gnuwin32>java IOSort && IOSort.exe
Time for reading, sorting, writing: 1402 ms
Time for reading, sorting, writing: 1183 ms
D:\gnuwin32>java IOSort && IOSort.exe
Time for reading, sorting, writing: 1417 ms
Time for reading, sorting, writing: 1183 ms
--- Inverting order -------
D:\gnuwin32>IOSort.exe && java IOSort
Time for reading, sorting, writing: 1152 ms
Time for reading, sorting, writing: 1183 ms
D:\gnuwin32>IOSort.exe && java IOSort
Time for reading, sorting, writing: 918 ms
Time for reading, sorting, writing: 1354 ms
D:\gnuwin32>IOSort.exe && java IOSort
Time for reading, sorting, writing: 1074 ms
Time for reading, sorting, writing: 1386 ms
Michael
Lew
Perhaps I am wasting time, indeed even by participating in Benchmark Wars at
all, but I suspect you misconstrue. My point was that any memory
de-allocation in Java is pretty much unavoidable, as it's built into the JVM,
and therefore that all Java benchmarks will be affected by it. I was
responding to another poster, <peter.ko...@gmail.com>:
>> >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.
I was not disagreeing with your point at all. I didn't say that the C++
version de-allocated memory, only that de-allocation in the Java version,
*should it occur*, would perforce be measured.
So settle down, and get back to your Benchmark Wars already in progress. No
need to go all /ad hominem/ on me.
--
Lew
dave_m...@fastmail.fm
> >Complete nonsense. If you are using the VM to load and run your class
> >file, the time must count.
>
> Nope. VM load time has nothing to do with what we are testing. C++
> code also only times needed for reading the file, sorting and writing
> the file.
If you're testing the Java solution to this problem, you are by
definition testing the performance of the runtime.
It's like you saying you can get a kite to 200 feet faster from the
top of a 15-story building, than I can from the ground, but we can't
count the time it took you to take the elevator.
Lew
That depends on what you're measuring. For many server applications, startup
time is a negligible fraction of the application's uptime. If you want to
know how fast the Hotspot-optimized version of an algorithm is, you'll not
only factor out the JVM startup time, but you'll run the loop a zillion times
before starting the clock in order to give Hotspot a chance to care. If
you're intellectually honest.
--
Lew
Lew
Apples and oranges. It's all about what you intend to measure. Demanding
that he intend to measure something different isn't fair. He's disclosed the
limits of his testing, that's all that's required of intellectual
responsibility. It's up to you to decide the relevance of that limit, not him
to change it.
As I mention elsewhere, for many applications and architectures JVM startup
time is irrelevant. What you want is granular predictability - know how much
JVM overhead contributes, and separately how long the algorithm will take.
Add them together if that's relevant to your analysis, don't if it isn't.
--
Lew
Razii
More results this time java.class compiled to native Windows (instead
of using VM) by using JET compiler.
http://www.excelsior-usa.com/ (JET compiler can be found here)
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++)
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++)
Razii
wrote:
>> 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.
I hope the following makes you really happy
dave_m...@fastmail.fm
> On Thu, 20 Mar 2008 06:56:06 -0700 (PDT), dave_mikes...@fastmail.fm
> wrote:
>
> >> 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.
>
> I hope the following makes you really happy
Very good. You've proven beyond a shadow of a doubt that Java is the
better language for this particular toy benchmark, at least on your
machine.
Jerry Coffin
fdg...@hotmails.com says...
> This topic was on these newsgroups 7 years ago :)
[ ... ]
> Back to see if anything has changed
Not much -- you're still a troll, and people still respond to trolls.
[ ... ]
> The question still is (7 years later), where is great speed advantage
> you guys were claiming for c++?
Anybody who claims a major speed advantage for C++ (or much of anything
else) on an application that's mostly I/O bound is nuts. I doubt anybody
has claimed any such thing.
While C++ iostreams are extremely versatile, they're not necessarily the
most efficient way to do I/O. This has little to do with the language,
per se, and a great deal to do with consious tradeoffs. While it's
theoretically possible to design around most of those tradeoffs to
improve speed, most vendors seem uninterested.
I don't really care all that much about your Java code (which won't even
run for me) but just for fun, let's take a look at what happens to the
C++ version with a minor modification:
#include <fstream>
#include <iostream>
#include <string>
#include <vector>
#include <algorithm>
#include <ctime>
#include <iterator>
#include <set>
// the main modification is here
#ifdef CSTDIO
#include "cstdio.h"
namespace s = JVC;
#else
namespace s = std;
#endif
// I've also gotten rid of the "using namespace std;" and explicitly
// qualified the names below.
//
int main() {
typedef std::multiset<std::string> mss;
mss buf;
std::string linBuf;
s::ifstream inFile("bible.txt");
clock_t start=clock();
while(s::getline(inFile,linBuf)) buf.insert(buf.end(), linBuf)
;
s::ofstream outFile("output.txt");
std::copy(buf.begin(),buf.end(),
s::ostream_iterator<std::string>(outFile,"\n"));
clock_t endt=clock();
std::cout <<"Time for reading, sorting, writing: " <<
double(endt-start)/CLOCKS_PER_SEC * 1000 << " ms\n";
return 0;
}
Now a few numbers, generated with VC++ 7.1:
compiled with: cl /O2b2 /G7ry /arch:SSE2 sort_bible.cpp
average speed for five runs: 230 ms
compiled with: cl /O2b2 /G7ry /arch:SSE2 /DCSTDIO sort_bible.cpp
average speed for five runs: 93 ms
As you can see, with a relatively trivial change, we've improved speed
by almost 2.5:1. That doesn't require a great deal of tricky coding or
anything like that either. The cstdio.h that's being included above
looks like this:
#include <stdio.h>
#ifndef JVC_STREAM
#define JVC_STREAM
namespace JVC {
class ofstream {
FILE *file;
public:
ofstream(char const *name) { file = fopen(name, "w"); }
ofstream &write(std::string const &s) {
fputs(s.c_str(), file);
return *this;
}
};
ofstream &operator<<(ofstream &os, std::string const &s) {
return os.write(s);
}
class ifstream {
FILE *file;
bool good;
public:
ifstream(char const *name) { file = fopen(name, "r"); }
ifstream &read(std::string &s) {
static char buffer[1024*1024];
good = fgets(buffer, sizeof(buffer), file);
s = buffer;
return *this;
}
operator void *() { return (void *)good; }
};
ifstream &getline(ifstream &is, std::string &s) {
return is.read(s);
}
template<class T>
class ostream_iterator {
ofstream &os_;
bool has_delim;
std::string delim_;
public:
ostream_iterator(ofstream &os) :
os_(os), has_delim(false)
{ }
ostream_iterator(ofstream &os, std::string const &delim) :
os_(os), has_delim(true), delim_(delim)
{ }
ostream_iterator &operator=(T const &t) {
os_ << t;
if (has_delim)
os_ << delim_.c_str();
return *this;
}
ostream_iterator operator*() { return *this; }
ostream_iterator operator++() { return *this; }
ostream_iterator operator++(int) { return *this; }
};
}
#endif
Of course, the benefit of this (if any) depends heavily upon the
compiler and standard library implementation you're using. With a really
efficient implementation of iostreams, this could reduce speed. With the
iostreams included with the versions of VC++ I've tried, the difference
is substantial enough to justify its use in quite a few cases.
The speed of this code depends almost entirely upon the implementation
of the standard library. For example, going from gcc 3.4 to gcc 4.3
roughly doubles the speed of the code (on my machine it's about 175-300
ms with gcc 3.4 and about 150-175 ms with gcc 4.3).
All in all, you've managed to do a better job than most: you're
obviously a troll. While many trolls are fond of meaningless benchmarks,
you've nearly set a new record for the worst benchmark ever!
--
Later,
Jerry.
The universe is a figment of its own imagination.
Jerry Coffin
l...@lewscanon.com says...
[ ... ]
> I have a hard time imagining any simple way NOT to include GC time in the Java
> timings.
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.
kasthurira...@gmail.com
I understand JVM makes java platform independent, but JVM should
definitely be platform dependent(and also optimized). I would say it
would be fair if we compile c++ with optimization option(atleast with -
O3 in gcc) and then compare, sticking strictly to the post of java vs c
++ speed(i/o & sort). Also request to add unitbuf option to the
ofstream as well.
Thanks,
Balaji.
Steve Wampler
> Complete nonsense. If you are using the VM to load and run your class
> file, the time must count.
Do you count the time to boot the computer when running C++? :)
[Yes, I agree that if you did you'd have to the same for Java!]
I have an environment where I can leave the JVM running and
load/run/unload class files. Why should the time to start
up that JVM matter in this test?
--
Steve Wampler -- swam...@noao.edu
The gods that smiled on your birth are now laughing out loud.
Razii
wrote:
>Anybody who claims a major speed advantage for C++ (or much of anything
>else) on an application that's mostly I/O bound is nuts. I doubt anybody
>has claimed any such thing.
This shows that you are either lying or have a bad memory. The last
time I checked the group, many here were claiming that Java IO is much
slower.
Have a look at this post by Pete Becker Dinkumware, Ltd.
(http://www.dinkumware.com) posted to this very newsgroup...
http://groups.google.com/group/comp.lang.java.programmer/msg/1313c62be872ba7c?dmode=source
What is he trying to prove with these fake benchmarks?
Since you have been proven a liar by claiming no one has ever said IO
is slow in Java, I will ignore the rest of your post without bothering
to read.
dave_m...@fastmail.fm
> Since you have been proven a liar by claiming no one has ever said IO
> is slow in Java, I will ignore the rest of your post without bothering
> to read.
OK, not only is this a troll, I'm starting to think it's a joke. Is
that Phil Hendrie behind the keyboard?
Razii
wrote:
>
Cut and pasted above to IOSort.cpp. Didn't do anything...
C:\>cl IOSort.cpp /O2
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.
C:\>IOSort
Time for reading, sorting, writing: 328 ms
C:\>IOSort
Time for reading, sorting, writing: 328 ms
C:\>IOSort
Time for reading, sorting, writing: 312 ms
C:\>IOSort
Time for reading, sorting, writing: 328 ms
C:\>IOSort
Time for reading, sorting, writing: 312 ms
C:\>IOSort
Time for reading, sorting, writing: 312 ms
C:\>IOSort
Time for reading, sorting, writing: 328 ms
That's same I got berfore. Chaging the file bible2.txt (43 meg file)
C:\>IOSort
Time for reading, sorting, writing: 6938 ms
C:\>IOSort
Time for reading, sorting, writing: 3812 ms
C:\>IOSort
Time for reading, sorting, writing: 3828 ms
C:\>IOSort
Time for reading, sorting, writing: 4250 ms
C:\>IOSort
Time for reading, sorting, writing: 4750 ms
No improvement
Jerry Coffin
DONTwha...@hotmail.com says...
[ ... ]
In other words, you really DID read the rest, and since it proved you
(badly) wrong, you chose to find any kind of excuse you could to ignore
it!
Your logic is lousy in any case -- even if my doubt was proven wrong, it
means I was _wrong_, not that I'm lying. Looking at Pete's earlier post,
I find that I wasn't wrong either. While Pete posted some numbers and
you might _infer_ from those numbers that he claimed C++ would have a
major speed advantage on an I/O bound application, that's purely an
inference on your part. Pete did not say any such thing.
I'm left wonder if you don't really work on behalf of a C++ compiler
vendor, trying to smear the Java community by associating yourself with
them, and by that association trying to make it look like Java
programmers as a whole are stupid, illogical and dishonest.
Jerry Coffin
DONTwha...@hotmail.com says...
[ ... ]
> Cut and pasted above to IOSort.cpp. Didn't do anything...
Now you've proven that you really did lie. You previously claimed that
you didn't look at this at all, but now you've proven that you really
have looked at it!
> C:\>cl IOSort.cpp /O2
Perhaps you need to work on your reading skills as well. As I clearly
pointed out in my previous post, for this code to make any difference,
you have to define "CSTDIO" when you compile it. That would be done with
something like:
cl /DCSTDIO /O2 IOSort.cpp
As it stands, you're effectively compiling exactly the same code as
before, so it's no surprise that you got the same result.
Razii
wrote:
>In other words, you really DID read the rest, and since it proved you
>(badly) wrong, you chose to find any kind of excuse you could to ignore
>it!
I didn't read the rest of it when I posted the response.
>Your logic is lousy in any case -- even if my doubt was proven wrong, it
>means I was _wrong_, not that I'm lying. Looking at Pete's earlier post,
>I find that I wasn't wrong either. While Pete posted some numbers and
>you might _infer_ from those numbers that he claimed C++ would have a
>major speed advantage on an I/O bound application, that's purely an
>inference on your part. Pete did not say any such thing.
You are a fool. Read the entire thread and all old posts. It was
usual claim that Java IO is slow.
>I'm left wonder if you don't really work on behalf of a C++ compiler
>vendor, trying to smear the Java community by associating yourself with
>them, and by that association trying to make it look like Java
>programmers as a whole are stupid, illogical and dishonest.
Whatever, moron. You are the one making an ass out of yourself.
And guess what? My c++ code that you were whining about (the vector
version) was posted by your guru Pete Becker
I never claimed to be a "programmer" of Java or C++ .
Razii
wrote:
>Now you've proven that you really did lie. You previously claimed that
>you didn't look at this at all, but now you've proven that you really
>have looked at it!
You have proven that you are an idiot. When I posted the response, I
said I am not going to bother reading the rest of it. Like right now I
am responding to you without any clue what's below the text. After a
quick scroll when I saw some code, I changed my mind and read what you
are babbling about. How does that prove that I lied?
>cl /DCSTDIO /O2 IOSort.cpp
>
>As it stands, you're effectively compiling exactly the same code as
>before, so it's no surprise that you got the same result.
No improvement...
C:\>cl /DCSTDIO /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
IOSort.cpp(12) : fatal error C1083: Cannot open include file:
'cstdio.h': No suc
h file or directory
C:\>IOSort
Time for reading, sorting, writing: 6750 ms
C:\>IOSort
Time for reading, sorting, writing: 3781 ms
C:\>IOSort
Time for reading, sorting, writing: 3859 ms
dave_m...@fastmail.fm
> dave_mikes...@fastmail.fm wrote:
> > Complete nonsense. If you are using the VM to load and run your class
> > file, the time must count.
>
> Do you count the time to boot the computer when running C++? :)
> [Yes, I agree that if you did you'd have to the same for Java!]
>
> I have an environment where I can leave the JVM running and
> load/run/unload class files. Why should the time to start
> up that JVM matter in this test?
OK, I'll cede the point. When you carve away all of the costs of
running a Java program, like startup and GC (as Jerry pointed out),
and though not on-topic in this particular benchmark - memory
footprint (which I found to be on average 300% greater in the Java
version) - Java can perform about the same as C++.
But in real world applications, those things matter, which is why
seven years later you still see Java and C++ largely being used in the
same application domains that they were then.
Razii
<DONTwha...@hotmail.com> wrote:
>C:\>cl /DCSTDIO /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
>IOSort.cpp(12) : fatal error C1083: Cannot open include file:
>'cstdio.h': No suc
>h file or directory
ops... I missed that
Razii
<DONTwha...@hotmail.com> wrote:
>>IOSort.cpp(12) : fatal error C1083: Cannot open include file:
>>'cstdio.h': No suc
>>h file or directory
>
>ops... I missed that
And since your code didn't compile, that's the end of that.
Michael....@gmail.com
> On Thu, 20 Mar 2008 05:53:57 -0700 (PDT), Michael.Boehni...@gmail.com
> wrote:
> >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++.
The choice of language should not make a big difference, at least no
longer. In ancient times, Java was executed as byte code only and
there was no JIT-Compiler. 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. There may be other reasons, though, I do not claim to be a
Java wizard.
I can only assume, the complaints in the ancient thread about slow I/O
in java are just unchecked repetitions of "wisdom of the old", but
things changed while they were not looking.
> >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.
Agreed. I removed the line from the C++ code completely and saw no
effect, too.
> >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.
Eh? I used Visual Studio 2005 Pro for my peek on the code - 17kB size
of the optimized executable. Did you forget to strip debug
information?
The C++ program's size is a little burdened by the use of STL style
programming. Templates like this are not part of a link library, they
need to be compiled and linked into the executable, increasing the
size compared to a mere reference into a dynamic link library. [C++
fans, don't misunderstand me here - I really appreciate the STL and
think its one of the most versatile parts of the language, well worth
the little increase in exe file size.]
I do not think the global memory footprint is favouring the Java side,
though - the Java interpreter and JIT compiler and libraries are
loaded in addition to your .class file. Also, have a look at the JIT
cache in the filesystem, where your .class file gets a way larger
machine language duplicate.
Disregarded the cache, you need to have large programs, or a lot of
them, to compensate for the runtime environment. Asymptotically, Java
wins here, of course :-)
best,
Michael.
Jerry Coffin
> On Thu, 20 Mar 2008 11:00:31 -0500, Razii
>
> >>IOSort.cpp(12) : fatal error C1083: Cannot open include file:
> >>'cstdio.h': No suc
> >>h file or directory
>
> >ops... I missed that
>
> And since your code didn't compile, that's the end of that.
Go back and re-read what was posted. The code is in two parts, one a
modified version of your program, the other the header file you need
to save (with the correct name). That header is conditionally included
into the modified version of your program, and used when CSTDIO is
defined.
Eric.Ma...@gmail.com
> On Mar 20, 2:34 pm, Paavo Helde <nob...@ebi.ee> wrote:
> > 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.)
This makes me curious: Could you elaborate?
Christopher
> This topic was on these newsgroups 7 years ago :)
>
>
> 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 hereftp://ftp.cs.princeton.edu/pub/cs126/markov/textfiles/bible.txt
>
> Back to see if anything has changed
>
>
> 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++?
>
>
> import java.io.*;
> import java.util.*;
> public class IOSort
> {
> public static void main(String[] arg) throws Exception
> {
> ArrayList ar = new ArrayList(5000);
>
> String line = "";
>
> BufferedReader in = new BufferedReader(
> new FileReader("bible.txt"));
> PrintWriter out = new PrintWriter(new BufferedWriter(
> new FileWriter("output.txt")));
>
> long start = System.currentTimeMillis();
> while (true)
> {
> line = in.readLine();
> if (line == null)
> break;
> if (line.length() == 0)
> continue;
> ar.add(line);
> }
>
> Collections.sort(ar);
> int size = ar.size();
> for (int i = 0; i < size; i++)
> {
> out.println(ar.get(i));
> }
> out.close();
> long end = System.currentTimeMillis();
> System.out.println("Time for reading, sorting, writing: "+
> (end - start) + " ms");
> }
>
> }
>
> --------- C++ Code ---------------
>
> #include <fstream>
> #include<iostream>
> #include <string>
> #include <vector>
> #include <algorithm>
> #include <ctime>
>
> int main()
> {
> vector<string> buf;
> string linBuf;
> ifstream inFile("bible.txt");
> clock_t start=clock();
>
> while(getline(inFile,linBuf)) buf.insert(buf.end(), linBuf);
> sort(buf.begin(), buf.end());
> ofstream outFile("output.txt");
> copy(buf.begin(),buf.end(),ostream_iterator<string>(outFile,"\n"));
> clock_t endt=clock();
> cout <<"Time for reading, sorting, writing: " << endt-start << "
> ms\n";
> return 0;
>
> }
I like how you start the time _after_ allocations and initializations
for Java, but _before_ them in C++.
Also, clock has granularity has big as my toe. I've seen it skew as
much as a second on some machines. There are several pages on Google
on how to do _REAL_ performance time measurements. It gets even worse
on multi-core systems.
To be completely fair, I'd start a performance timer, start another
process to do the work, let the process exit, stop the timer. I'd also
limit both to a single core, and use a timer that has a guaranteed
granularity of 1 ms. Only then could you say ,"Java parsed and sorted
this particular example faster than C++" and that would be all you
could say.
I'm not trying to say one language performs better than the other.
Frankly, I don't care. But your experiment defies several laws of
scientific testing.
Mark Space
>> 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.)
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?
Razii
<jerry....@gmail.com> wrote:
>Go back and re-read what was posted. The code is in two parts, one a
>modified version of your program,
I know and already tried that ... didn't compile...
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\xutility(764)
: error C2
039: 'iterator_category' : is not a member of
'JVC::ostream_iterator<T>'
with
[
T=std::string
]
C:\Program Files\Microsoft Visual Studio
9.0\VC\INCLUDE\xutility(2553) :
see reference to class template instantiation
'std::iterator_traits<_Iter>' bei
ng compiled
with
[
_Iter=JVC::ostream_iterator<std::string>
]
IOSort.cpp(37) : see reference to function template
instantiation 'JVC::
ostream_iterator<T>
std::copy<std::_Tree<_Traits>::iterator,JVC::ostream_iterato
r<T>>(_InIt,_InIt,_OutIt)' being compiled
with
[
T=std::string,
_Traits=std::_Tset_traits<std::string,std::less<std::string>,std::al
locator<std::string>,true>,
_InIt=std::_Tree<std::_Tset_traits<std::string,std::less<std::string
>,std::allocator<std::string>,true>>::iterator,
_OutIt=JVC::ostream_iterator<std::string>
]
<snip>
Razii
<cp...@austin.rr.com> wrote:
>I like how you start the time _after_ allocations and initializations
>for Java, but _before_ them in C++.
that was actually some kind of typo as I posted it here. In ay case,
the result didn't change. It had no effect on time.
翁
> 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 have to say, your program is not powerful to show Java is faster
than C++.
Such as your C++ code is not very good.
Do you run it with CLR?
"Razii" <fdg...@hotmails.com> wrote in message
news:lou3u35seg71hu37k...@4ax.com...
Ian Collins
--
Ian Collins.
Ian Collins
> More results this time java.class compiled to native Windows (instead
> of using VM) by using JET compiler.
>
> http://www.excelsior-usa.com/ (JET compiler can be found here)
>
> 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++)
>
Every action has an equal and opposite reaction:
javac IOSort.java
java IOSort
Time for reading, sorting, writing: 2952 ms
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.
--
Ian Collins.