Optimise my ray tracer

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. :)
 
R

Remon van Vliet

Jon Harrop said:

I just read up on Ocaml and i found out the entire discussion comparing it
to Java is manky. Apparently your natively compiling your benchmark instead
of running the bytecode version. This makes comparing it to Java unfair at
best. One of Java's main features is the fact that it is portable due to the
bytecode runtime compiliation and execution. This enables mana of
Java'sstrong features. I'd be interested in the benchmark results when
running the bytecode version of your tracer, a much fairer comparison i
would say.

Also, on an unrelated note, i'm finding the OCaml language itself a small
dissaster but that's most likely related to being used to different
languages. I see the reasoning behind these kind of languages (in the scope
of it's scientific background it's okay) but i wouldnt call this a viable
alternative for general day-to-day projects.

Remon
 
J

Jon Harrop

Remon said:
I just read up on Ocaml and i found out the entire discussion comparing it
to Java is manky. Apparently your natively compiling your benchmark
instead of running the bytecode version. This makes comparing it to Java
unfair at best. One of Java's main features is the fact that it is
portable due to the bytecode runtime compiliation and execution. This
enables mana of Java'sstrong features. I'd be interested in the benchmark
results when running the bytecode version of your tracer, a much fairer
comparison i would say.

Yes, Java lacks a decent native code compiler.
Also, on an unrelated note, i'm finding the OCaml language itself a small
dissaster but that's most likely related to being used to different
languages. I see the reasoning behind these kind of languages (in the
scope of it's scientific background it's okay) but i wouldnt call this a
viable alternative for general day-to-day projects.

Can you give any specific reasons for thinking this?
 
R

Remon van Vliet

Jon Harrop said:
Yes, Java lacks a decent native code compiler.
It's more that Java isnt all that suitable for one. Also, Java is based on a
few underlying principles, one of which is portability. And like i said,
there are a few obvious language features that make native compiling an
issue. Tried the OCaml bytecode interpreter?
Can you give any specific reasons for thinking this?
Most application development nowadays revolves around web-based applications
or applications heavy on database support, and user interaction. I have yet
to find any of these as an inherent part of the language, as opposed to Java
(in order; J2EE, JDBC, Swing), i did find some 3rd party libraries for some
of this.
 
J

Jon Harrop

Remon said:
It's more that Java isnt all that suitable for one.

Note that gcj is a Java native code compiler. Its performance is aweful,
much worse than Sun's JIT.
Also, Java is based on
a few underlying principles, one of which is portability.

Sure, and that can be a big plus. It just isn't relevant for me and,
therefore, to this thread.
And like i said,
there are a few obvious language features that make native compiling an
issue. Tried the OCaml bytecode interpreter?

Someone seems to have taken the OCaml bytecode results off the shootout, but
they were over an order of magnitude slower. However, this is still
irrelevant because I wouldn't use OCaml byte code for this. Indeed, I only
use OCaml's bytecode for fast compilations.
Most application development nowadays revolves around web-based
applications or applications heavy on database support, and user
interaction. I have yet to find any of these as an inherent part of the
language, as opposed to Java (in order; J2EE, JDBC, Swing), i did find
some 3rd party libraries for some of this.

Ok, that makes sense and I can well believe that Java is ideal for this.

For me, I'm interested in applications which make use of complicated data
structures and algorithms and where brevity and expressiveness is
important. Speed is much less important but I'm still interested to see big
performance differences (like 5x). I had expected all modern languages to
be within a factor of 2 of each other but that clearly isn't always the
case.

I think Java is just the wrong tool for this job.
 
B

Bjorn Borud

["Remon van Vliet" <[email protected]>]
|
| Most application development nowadays revolves around web-based
| applications or applications heavy on database support, and user
| interaction.

it is tempting to assume that what you see every day is what everyone
else is seeing every day.

-Bjørn
 
B

Bjorn Borud

[Jon Harrop <[email protected]>]
|
| For me, I'm interested in applications which make use of complicated
| data structures and algorithms and where brevity and expressiveness
| is important.

could you give some examples of complicated data structures that you
find hard to implement in Java? (you did graphics, right? a topic I
unfortunately know very little about)

the brevity and expressiveness in Java, as far as application
development is concerned in general, is that Java has so much in its
standard library that most of the time I do not have to waste time
designing and implementing rather mundane things.

even more advanced things are starting to crop up, like the
java.util.concurrency things, which I find very useful in my work
since they provide good implementations, but more importantly, good
APIs, which I can build my applications upon. things I'd have to
hand-craft each time, or make some (sometimes exclusive) decision
about what implementation to use in C or C++ are just *there* in Java
-- and the quality is rather good. so it doesn't matter if defining a
class involves a bit of typing for me -- I still save a lot of work by
having appropriate abstractions around to build on.

also, I find Java's lack of syntactical and paradigmatic diversity to
be a big advantage. it helps write more homogenous code, more
disciplined code. look at C++ and Perl for instance. there is a
*lot* of code out there where you really have to stop and wonder
exactly what the code is doing and then try to go from there and
reason yourself back to the intention.

-Bjørn
 
R

Remon van Vliet

Jon Harrop said:
Note that gcj is a Java native code compiler. Its performance is aweful,
much worse than Sun's JIT.
Hence me saying it isnt all that suitable for one, some features are hard or
near impossible to compile to a native executable.
Sure, and that can be a big plus. It just isn't relevant for me and,
therefore, to this thread.
Fair enough
Someone seems to have taken the OCaml bytecode results off the shootout, but
they were over an order of magnitude slower. However, this is still
irrelevant because I wouldn't use OCaml byte code for this. Indeed, I only
use OCaml's bytecode for fast compilations.
Agreed, which doesnt change the fact that it's a crooked comparison. By
their very nature JVM based execution will be slower than native compiled
code. The fact that Java JIT VM's get so close to native program performance
is quite impressive, which was my point from the start.
Ok, that makes sense and I can well believe that Java is ideal for this.

For me, I'm interested in applications which make use of complicated data
structures and algorithms and where brevity and expressiveness is
important. Speed is much less important but I'm still interested to see big
performance differences (like 5x). I had expected all modern languages to
be within a factor of 2 of each other but that clearly isn't always the
case.
Java is suitable for this, although i'll be the first to agree to OCaml
seems to be a more natural language for these things. I fail to see how
that's relevant for a speed comparison thread still though.
I think Java is just the wrong tool for this job.
I'll try making a version in Java that stays within 50-90% of your OCaml
version (i.e. within your point of staying within a factor 2). Can you mail
me the OCaml executable?
 
R

Remon van Vliet

Bjorn Borud said:
["Remon van Vliet" <[email protected]>]
|
| Most application development nowadays revolves around web-based
| applications or applications heavy on database support, and user
| interaction.

it is tempting to assume that what you see every day is what everyone
else is seeing every day.

-Bjørn

Look it up, i'm a game programmer, i have little to do with either ;) But
your point is fair, although it is an established fact that more web apps
are made than raytracers (or even any other kind of graphical app)...i
wouldnt be surprised if the ratio is like 100:1 actually.
 
R

Remon van Vliet

Tor Iver Wilhelmsen said:
Which of the existing ones (GCJ, TowerJ, possibly others) have you tried?

On this i sorta have to agree with Jon though, i tried most i could find,
performance is similar or worse than the server VM in all instances i tried
them. I must point out that this was over half a year ago though.
 
J

Jon Harrop

Remon said:
Look it up, i'm a game programmer, i have little to do with either ;) But
your point is fair, although it is an established fact that more web apps
are made than raytracers (or even any other kind of graphical app)...i
wouldnt be surprised if the ratio is like 100:1 actually.

Speaking as someone who has never managed to get another person's Java web
app to work but who has played a lot of games, I'm not sure that's
true. :)
 
J

Jon Harrop

Remon said:
Agreed, which doesnt change the fact that it's a crooked comparison.

Well, no. If you are trying to compare languages which must be executed via
a bytecode then yes, this benchmark isn't doing that. But the fact that
Java compiles to bytecode and then to native code is irrelevant for me (and
therefore, for my benchmark) save for the fact that it might be the cause
of Java's slow run-time performance.
By
their very nature JVM based execution will be slower than native compiled
code. The fact that Java JIT VM's get so close to native program
performance is quite impressive, which was my point from the start.

Yes, it is impressive. Unfortunately it is also useless for me. But it is
still impressive.

There is actually a JIT for OCaml bytecode, maybe I should try the ray
tracer with that...
Java is suitable for this, although i'll be the first to agree to OCaml
seems to be a more natural language for these things. I fail to see how
that's relevant for a speed comparison thread still though.

I wrote my ray tracer to compare implementations as well as speed. This
thread was about the Java implementation's poor performance but brevity is
still important to me.
I'll try making a version in Java that stays within 50-90% of your OCaml
version (i.e. within your point of staying within a factor 2). Can you
mail me the OCaml executable?

It's on that web page.
 
J

Jon Harrop

Bjorn said:
could you give some examples of complicated data structures that you
find hard to implement in Java? (you did graphics, right? a topic I
unfortunately know very little about)

Yes, I used to do scientific computing but my work is now more on graphics.

Here is one of the examples from my book on OCaml:

http://www.ffconsultancy.com/products/ocaml_for_scientists/complete/

which computes the "n"th nearest neighbour of the "i" vertex in an
infinitely tiled graph. The code of the OCaml code is:

let rec nth = function
0 -> singleton
| 1 -> fun (i, io) ->
let nn = bonds.(i - 1) in
if io = zero then nn else
let aux (j, jo) s = add (j, add_i io jo) s in
fold aux nn empty
| n -> fun ((i, io) as iio) ->
let pprev = nth (n-2) iio and prev = nth (n-1) iio in
let aux j t = union (nth 1 j) t in
let t = fold aux prev empty in
diff (diff t prev) pprev

In mathematics, you would write set union when describing the algorithm.
Note that in OCaml you write "union". In C++ (and Java AFAIK) the built-in
union functions are so much slower than OCaml's that you have to roll your
own by carefully reusing old sets and mutating the ones that you don't
need.
the brevity and expressiveness in Java, as far as application
development is concerned in general, is that Java has so much in its
standard library that most of the time I do not have to waste time
designing and implementing rather mundane things.

OCaml has lots of useful things in its standard library but, IMHO, the
language features are much more important. This is discussed in the context
of the ray tracer (vs C++, but Java is almost identical) on this page:

http://www.ffconsultancy.com/free/ray_tracer/comparison.html

In particular, look at the use of a variant type and pattern matching in the
OCaml compared to an inheritance hierarchy and member functions in the
C++/Java.
even more advanced things are starting to crop up, like the
java.util.concurrency things, which I find very useful in my work
since they provide good implementations, but more importantly, good
APIs, which I can build my applications upon. things I'd have to
hand-craft each time, or make some (sometimes exclusive) decision
about what implementation to use in C or C++ are just *there* in Java
-- and the quality is rather good. so it doesn't matter if defining a
class involves a bit of typing for me -- I still save a lot of work by
having appropriate abstractions around to build on.

Yes. The fact that OCaml functions are inferred to be polymorphic whenever
possible is one such abstraction. The ability to use higher-order functions
is another. Both are vastly more useful than objects (but OCaml has these
too!).

For example, to accumulate a value of any type over a list in OCaml you
write something like:

List.fold_left f accu l

For example, to sum a list of integers you fold the integer add function "+"
over the list, starting with the integer zero:

# let sum l = List.fold_left ( + ) 0 l;;
val sum : int list -> int = said:
also, I find Java's lack of syntactical and paradigmatic diversity to
be a big advantage. it helps write more homogenous code, more
disciplined code. look at C++ and Perl for instance. there is a
*lot* of code out there where you really have to stop and wonder
exactly what the code is doing and then try to go from there and
reason yourself back to the intention.

Indeed. :)
 
R

Remon van Vliet

Jon Harrop said:
Speaking as someone who has never managed to get another person's Java web
app to work but who has played a lot of games, I'm not sure that's
true. :)
Well i did say more are being made, not used :) (i.e. more people are
involved in web development compared to game development, and i doubt the
1:100 ratio is very unrealistic, but it is little more than a hunch).
Getting a web app to work is a whole different matter altogether, and i'm
embarrassed to admit the succesful first attempts i had with getting
existing ones to work can be counted on one hand probably. That and i have a
moderate dislike for webapps to begin with. Gimme games, raytracers,
scientific apps and the like any day. Unfortunately getting a job in one of
the above isnt all that easy, so i should be happy i actually found one.

Remon van Vliet
 
R

Remon van Vliet

Jon Harrop said:
Well, no. If you are trying to compare languages which must be executed via
a bytecode then yes, this benchmark isn't doing that. But the fact that
Java compiles to bytecode and then to native code is irrelevant for me (and
therefore, for my benchmark) save for the fact that it might be the cause
of Java's slow run-time performance.
Hm, fair enough. If you know you'll run a time-critical app on platform X
and are not tied to a specific language then i see how it's irrelevant. It's
quite often you know what platform you'll deploy to anyway.
Yes, it is impressive. Unfortunately it is also useless for me. But it is
still impressive.
Indeed ;)
There is actually a JIT for OCaml bytecode, maybe I should try the ray
tracer with that...
Yeah do that, JIT tecnhology is quite interesting, would be fun to see how
ell they did it for OCaml. The fact that it can be natively compiled easily
without having the Java issues might even make it more suitable when
creating a high-speed JIT VM for the language.
I wrote my ray tracer to compare implementations as well as speed. This
thread was about the Java implementation's poor performance but brevity is
still important to me.
Oh okay. Out of pure curiousity by the way (since i couldnt find anything
about it), does OCaml support threading/synchronization and such? How much
control does it offer?
It's on that web page.
Thanks. URL please? my newsreader lost the first few posts.

Remon van Vliet
 
B

Bjorn Borud

["Remon van Vliet" <[email protected]>]
|
| Look it up, i'm a game programmer, i have little to do with either
| ;) But your point is fair, although it is an established fact that
| more web apps are made than raytracers (or even any other kind of
| graphical app)...i wouldnt be surprised if the ratio is like 100:1
| actually.

oh, I don't doubt for a second that there is more web development
going on than development on raytracers. at least not in quantity.
:)

what I was thinking about was the software development you don't
really see. almost everything around us these days has lots of
software. my mobile, my TV, my musical instruments, my stereo, my
iPod, my car. heck, my car even has computers talking to computers
within the car. not to mention all the software taking care of your
business transactions in banks, insurance companies, the government.
much of this software is significantly harder to write and maintain
than web software.

-Bjørn
 
R

Remon van Vliet

Bjorn Borud said:
["Remon van Vliet" <[email protected]>]
|
| Look it up, i'm a game programmer, i have little to do with either
| ;) But your point is fair, although it is an established fact that
| more web apps are made than raytracers (or even any other kind of
| graphical app)...i wouldnt be surprised if the ratio is like 100:1
| actually.

oh, I don't doubt for a second that there is more web development
going on than development on raytracers. at least not in quantity.
:)

what I was thinking about was the software development you don't
really see. almost everything around us these days has lots of
software. my mobile, my TV, my musical instruments, my stereo, my
iPod, my car. heck, my car even has computers talking to computers
within the car. not to mention all the software taking care of your
business transactions in banks, insurance companies, the government.
much of this software is significantly harder to write and maintain
than web software.

-Bjørn

True ;)
 
R

Remon van Vliet

I think Java is just the wrong tool for this job.
Thanks. URL please? my newsreader lost the first few posts.
Ah, i only see the source version. Any chance you can send me the EXE? I've
tried setting up the OCaml compiler, but it needs third party assemblers and
whatnot, which is a bit of a hassle. Thanks

Remon van Vliet
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top