J
Jon Harrop
Remon said:Well, if this is the case, could you please post a page where you have the
benchmarks downloadable for the mentioned languages, if anything i'm quite
interested in observing the differences and maybe finding out why the
differences are so excessive. Like i mentioned before i ported a raytracer
to Java once and the spead decrease was in the single digits percents, not
a factor 5..
My ray tracers are on this page:
http://www.ffconsultancy.com/free/ray_tracer/languages.html
True, but at the risk of repeating myself, just claiming it's inefficient
is a bit easy. I just dont get how on earth you can get such huge
performance differences. It's simply so far from my practical experience
that i do not understand how you can get those results. Do note that i'm
only familiar with C <-> Java conversions.
My straightforward C implementation is almost as slow as Java on this test.
Hm, test this, it's entirely possible OCaml's object managment is faster
than Java's, but you should see a significant decrease in performance.
Ok, I was completely wrong there. I just reimplemented the OCaml ray tracers
using objects instead of records for 3D vectors and the time taken went
from 3.5s up to 26.4s!
No idea why...
If you argue that object creation slows the Java version down by a factor
5 than designing/implementing it in such a way that object creation is
extensive is not a good design no?
I'm under the impression that there are no decent alternatives in Java: no
tuples, no records, no variant types and certainly nothing more
sophisticated.
If you reply with that it shouldnt
matter because a proper OOP design should be executed efficiently in an OO
language than i can only agree. But as mentioned before i have trouble
believing Java's object instantiating is so much slower than other VM
languages. Although i'll be the first to admit i can easily be proved
wrong with a simple object creation benchmark, or even a 3D vector math
benchmark.
Well, Java beats OCaml when the OCaml is made to use objects. This is
probably another reason why OCaml programmers rarely use OO.
Like i said, my knowledge of the other languages is limited, if you say
similar things can be done i'll take your word for it. It's the magic of
them doing the same thing 5 times as fast that i find hard to believe. If
they offer the same benefits that Java offers at 5 times the speed people
should seriously consider moving to these alternatives
I really think they should. Although I wouldn't have written a book on it if
I didn't think so.
That's for your benchmark though. I know it's factually untrue that C++ is
more than 3 times faster than Java per definition.
I'm willing to accept that this benchmark hits weak points of Java. It hits
weak points of SML/NJ as well.
Cant say, something is up with your Java VM and/or config though. My
-server VM runs all math/vector/object intensive programs at least 30-50%
faster and you hardly see any difference.
I just tried it again and I get 8.3s with -client and 7.8s with -server.
That's only 6% faster. Maybe if I did a longer run...
Just did it again and got 34.7s -> 29.8s. That's 14% faster, which is more
like it.
You use the Java Collection Framework for inner workings of raytracers you
might have found your performance issue of you use the wrong/synchronized
collections. But i trust you didnt. You're still testing very limited
functionality in the stress part of your benchmark though.
All of the implementations use a linked list.
Anyway, like i suggested, how about you make your benchmark programs
public and we can run them on our systems for more benchmark test results.
I'm sorry, they have been public the whole time. I gave the link in the
original post that started this thread but I've updated it with the page at
the top of this post.
Apart from us disagreeing on some points it's quite helpful to actually
test these things properly. I'm quite interested in comparing VM
languages' performance in terms of object/instance managment, garbage
collection (or related features), vector math, integer math, collections
etc...what do you think? Let me know if i can help in any way with making
this happen. Perhaps we can define a benchmark that tests language
features that often cause performance issues in cpu-intensive
applications.
I have a hunch that Java will be as good as C at handling float arrays
because it doesn't require GC and object creation. Unfortunately I don't
have many applications that require this, even as a computational
scientist.