A
asterisc
So you compare STL vs Java library!
I agree that Java library is also larger. Java can create Applets as
well.
Do we care? I don't think so!
So you compare STL vs Java library!
I agree that Java library is also larger. Java can create Applets as
well.
Do we care? I don't think so!
T
Tris Orendorff
Razii said:We have reached the conclusion! You can write a program in Java that
can be as fast as anything. This benchmark is on U++ home page as an
example of U++ especially optimized non:std String and map. And Mirek
Fidler asked me to write one in Java (no matter how I do it or what
method I use) that can be faster than U++.. Well, I got some help from
pmk and the debate is over. Java can be faster than U++)> [...]
The only conclusion the I can reach is that you can program C-style in some languages including Java. This isn't really a Java program, it's much more like a C program---all char arrays and no standard collection classes.
--
Tris Orendorff
[ Anyone naming their child should spend a few minutes checking rhyming slang and dodgy sounding names. Brad and Angelina failed to do this when naming their kid Shiloh Pitt. At some point, someone at school is going to spoonerise her name.
Craig Stark
A
asterisc
What HDD do you have?
It's hard to believe that your java is reading a 400MB (5 files * 80mb
each) in 5 seconds (that's a 80mb/second).. and that's just reading
the file from the HDD.
Something is strange there!
A
Alex Buell
Why are you not showing the results of your first run from cold?
You are taking advantage of the fact that with enough RAM you can
cache things like this in memory which would give you these quite
improbably high figures.
Until you show figures from a cold start, then I for one won't believe
it.
C++ is a lot faster, C is still a _lot_ faster. These two doesn't need
to go through the JIT compiler or the interpretative stage that Java
requires your code to go through.
A
asterisc
Give this a try and post the results, along with your fastest java
version:
http://pastebin.com/m18bf3320
However, to be fair, we should start the timer only after the whole
file is in a String, char *, byte *, or a similar variable.
We (or I at least) don't know how makes Java use of caching (when the
Garbage collector run).
A
asterisc
You have some weird results there. I got 20 "zealously" when compiled
with my Visual C++ 7.1.
However, if you are compiling with gcc on a windows machine.. that's
not pretty fair. I bet you can compile using a borland 3.11 compiler
(16bit only) and the results will be very bad.
Try compiling and running on a g++ version 4.xx on a linux box or
using a Visual Studio 2008 compiler on a M$ Windows platform.
My "hello world" application had almost 1MB on the cygwin-g++ compiler
and under 700bytes in Visual Studio 2005.
The compiler is the difference!
A
asterisc
Visual C++ 7.1 (2003):
yet, 5570
yield, 300
yielded, 80
yieldeth, 40
yielding, 70
yoke, 590
yoked, 10
yokefellow, 10
yokes, 40
yonder, 60
you, 25890
young, 2920
younger, 310
youngest, 180
your, 17430
yours, 50
yourselves, 1900
youth, 700
youthful, 10
youths, 20
zeal, 140
zealous, 80
zealously, 20
Time: 3234ms
g++ in cygwin on the same machine, did several runs (same output):
yokes, 40
yonder, 60
you, 25890
young, 2920
younger, 310
youngest, 180
your, 17430
yours, 50
yourselves, 1900
youth, 700
youthful, 10
youths, 20
zeal, 140
zealous, 80
zealously, 20
Time: 18969ms
A
asterisc
Oh come on man!
I can compile (probably) your version of Java on a Microsoft J++
thing.. and probably be really slow!
What about if you compile your Java version on a JDK1.0 ?
I thought you were comparing cut edge Java compiler with its c++
equivalent.
Try building it with Borland C++ 3.11, and you will wait like two days
to count the words.
A
Alan Krueger
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
Looking to beat the record, are we?
A
asterisc
Alright man, let's do it another way.
Try this:
http://pastebin.com/d43068295
Here is my output:
yet, 5570
yield, 300
yielded, 80
yieldeth, 40
yielding, 70
yoke, 590
yoked, 10
yokefellow, 10
yokes, 40
yonder, 60
you, 25890
young, 2920
younger, 310
youngest, 180
your, 17430
yours, 50
yourselves, 1900
youth, 700
youthful, 10
youths, 20
zeal, 140
zealous, 80
zealously, 20
Time: 1000 ms
Where yours is:
10 Ziphron
70 Zippor
30 Zipporah
10 Zithri
10 Ziz
20 Ziza
10 Zizah
70 Zoan
100 Zoar
20 Zoba
110 Zobah
10 Zobebah
40 Zohar
10 Zoheleth
10 Zoheth
20 Zophah
10 Zophai
40 Zophar
10 Zophim
80 Zorah
10 Zorathites
10 Zoreah
10 Zorites
30 Zorobabel
50 Zuar
30 Zuph
50 Zur
10 Zuriel
50 Zurishaddai
10 Zuzims
dictionaryCount: 37717
Time 1531 ms
What about now?
E
Erik Wikström
C++ is very portable, that does not mean that everyone can write a
compiler and library that works correctly. Or that the code you tested
works correctly, it might be that the errors manifests differently using
different compilers.
A
asterisc
I'm sorry about that. The printf was wrong, it should have been
something like: %.0f.. and (float) in front of every number.
However, I have reproduced your algorithm in C++.
I have better results than the Java version. I tried it on two
marchines and it seems faster!
Altought is not correct (it puts lowercase in front of uppercase,
which is not ok) it behaves exactly like the Java version. Same
output, same algorithm, only a bit faster.
Here is the link:
http://pastebin.com/m1c5271bf
Try it and post the results on your machine.
I don't care about MinGW compiler. I compiled it successfull on both VC
++ 2003 on winXP and GCC 4.1.2 p1.0.2 on my Gentoo machine.
Regards,
A
asterisc
As a conclusion, post any Java version, I'll write it in C++ and I'll
prove you it's faster than the Java equivalent.
Your times were better because of the algorithm, not because of the
language!!! And in my previous post you have the proof.
A
asterisc
Good job
I don't have better result than Jet version. I get about the same
result.
30 Zuph
50 Zur
10 Zuriel-
50 Zurishadda
10 Zuzims-
Time: 625ms
That's ~ same as Jet (but Jet was slightly faster)
It's easy to fix upper and lower case ... just remove ^32 .. see this
versionhttp://www.pastebin.ca/977458that sorts with lower cases
first.
My version was before your last update. I'll post in 10 minutes the
"updated" C++ version as well, to compare it with your latest java
version.
C++ must be faster!
A
asterisc
Just as in the case of U++, it has special optimized Strings.
The same is true the other way. This trie algorithm was initially
posted by Brettschneider as C++ version.. I converted it to Java
Nice trick, huh?
However, the structure was improved into one array by pmk. That's what
made it beat U++.
As I said, here is the link, after I "updated" the c++ code as well
(removing the ^ 0x7f and & 32 ). I didn't have time to check if you
changed anything else.
Here it is:
http://pastebin.com/d2938fd5e
What do you mean "has optimized Strings". Right now, there is no
string at all. I use only char *.
Please post times for this version as well as for your latest jet
thing. I'm curious which one is the faster.
And please compile it using optimizations! (-O3 -fomit-frame-pointer
on GCC, if it works), or (-Ox [full-optimizations] on VC++).
Right now I got better times on two machines ( 440ms c++ vs. 550ms
java.. (that was before updating) )
And in this time, I don't wait for any JVM to get loaded.
A
asterisc
Try #include <cstdlib> (it should be declared in <cstdio> as well, but
you can give a try. It works smooth on both my linux box (GCC) and my
xp machine (VC++).
No, I don't have Jet and I don't want to install it just for this
test.
From that site:
"In addition, Excelsior JET doesn't let the Java components become
performance bottlenecks of the entire application. Its static compiler
aggressively optimizes your Java class files and translates them to
Intel x86 native code, thus raising the Java performance level up to
that of C/C++."
So, it translates Java files into assembly. (doing that, won't affect
the portability?)
And the conclusion is also there, once again:
"thus raising the Java performance level up to that of C/C++."
So I think you can "adjust" your blog comments:
http://razi2.blogspot.com/2008/04/why-is-c-slower-than-java.html
A
asterisc
So that's faster than Jet. You said that 590ms was about the same as
the Jet version. (maybe you post the exactly time got with Jet)
Depends on what are you working on.
For small benchmarking problems (which are some structured algorithms)
if you compile Java into ASM (and an exe file) then it may be as fast
as C/C++. But then you will loose the portability. For being fast, it
need to be native, which isn't portable.
The new C++ standard will introduce some new features which will make
STL a bit faster (like right value references).
Never heard of U++ before, but if it's C/C++ standard compliance, it
should be exactly as fast as C++.
In our example I didn't use any C++ feature (classes, streams,
exceptions, ... ) because they are kind of slow.
Probably U++ made exactly these features faster than the STL.
It looked like you were starting a flame, but constructive discussions
should always be encouraged.
Have a good day!
M
Mirek Fidler
I am pretty sure Java version will be faster than UPP.
Even C++ version that uses the same algorithm? Why do you think it
should be faster?
Well, your code works quite well, but do not you see that you have
basically removed all language specific issues? C++ version would me
almost the same code, most likely compiled into very similar target
code.
Mirek
Even C++ version that uses the same algorithm? Why do you think it
should be faster?
Well, your code works quite well, but do not you see that you have
basically removed all language specific issues? C++ version would me
almost the same code, most likely compiled into very similar target
code.
Mirek
M
Mirek Fidler
Well, we can declare victory now
Well, Mirek Fidler wanted to benchmark String and Map performance
Mirek
Would Mirek Fidler add this to the site now? I doubt it
Well, Mirek Fidler wanted to benchmark String and Map performance
Mirek
M
Mirek Fidler
Nope. I guess, bible2.txt is your already "repeated" bible.txt 40MB
class, so this is not an example to show to problem.
Well, the repeating of the same text will not create the typical input
data of wc utility.
Basically, what you are doing here is finetuning input data TOGETHER
with algorithm to get best result.
Mind you, the U++ version was optimized for "Alice30.txt" type of
input. Your clever Java code is optimized to best handle 800MB of
repeated bible.txt. OK, you have won there.
Obviously, such great performance will tell only a little about real-
world performance of language. Whereas original benchmark and original
dataset were there to show how D or C++ or U++ will affect performance
of e.g. web applications - because in such application mathing strings
and finding them in maps has huge impact.
Anyway, the real point was that over time, you were finetuning input
data and algorithm and test method at the same time.
Who needs to cound words in 800MB of repeated bibles anyway?
Mirek