ill take a look at it, but im still not entirely sure what your saying the problem is.
and yes, i promis not to share your code ;p
programing a raytracer
Hey oodmb ... you're making excellent progress.
Don't be fooled by the myths that Java is necessarily slower than C++ (especially for rendering!) ... there's no fundamental technical reason why it should be ... the compilation to native code just happens at a later point in time after all.
The best Java performance tips I've leant have been:
- static methods are good (as you've already found out)
- depending on the processor, double can sometimes be faster than float (at the expense of memory)
- try to make something "final" if appropriate. It certainly used to be the case that the JIT compiler would inline these more readily but I believe newer JIT compilers don't care that much (there's still no harm in doing it)
- avoid thread-safe Collection implementations (e.g. Vector) and use things like ArrayList instead (in fact, avoid any thread-safe libraries unless you really need it)
- for high-impact methods (e.g. triangle intersection test) try to avoid calling any other methods ... inline it all by hand, it makes a huge different.
- System.gc() can be your friend ... probably not applicable to you right now with renders that only take a few seconds, but definitely important if you ever go unbiased.
Feel free to send me a copy of your code and I'll take a look if I get some time.
I'm still not sure why you're having those problems with inverted triangle vertices
Ian.
Don't be fooled by the myths that Java is necessarily slower than C++ (especially for rendering!) ... there's no fundamental technical reason why it should be ... the compilation to native code just happens at a later point in time after all.
The best Java performance tips I've leant have been:
- static methods are good (as you've already found out)
- depending on the processor, double can sometimes be faster than float (at the expense of memory)
- try to make something "final" if appropriate. It certainly used to be the case that the JIT compiler would inline these more readily but I believe newer JIT compilers don't care that much (there's still no harm in doing it)
- avoid thread-safe Collection implementations (e.g. Vector) and use things like ArrayList instead (in fact, avoid any thread-safe libraries unless you really need it)
- for high-impact methods (e.g. triangle intersection test) try to avoid calling any other methods ... inline it all by hand, it makes a huge different.
- System.gc() can be your friend ... probably not applicable to you right now with renders that only take a few seconds, but definitely important if you ever go unbiased.
Feel free to send me a copy of your code and I'll take a look if I get some time.
I'm still not sure why you're having those problems with inverted triangle vertices
Ian.
lol?
Java is always a factor 2-4 slower than C. When it comes to rendering make that factor at least 10.... I am sure you can shoot ray packets using SIMD instructions using Java.... And of course your stream GPU processor is obviously programmable embedded in Java (NOT).
Of course a great java developer can make a moire efficient program than a crappy C programmer... but thats not really relevant here
Dont get discouraged by this! When you are learning things Java is a good choice because you can focus on the relevant stuff (like algorithms and math) but forget that a Java ray tracer is competitive in any way with a C ray tracer when it comes to speed.
IanT
Java is always a factor 2-4 slower than C. When it comes to rendering make that factor at least 10.... I am sure you can shoot ray packets using SIMD instructions using Java.... And of course your stream GPU processor is obviously programmable embedded in Java (NOT).
Of course a great java developer can make a moire efficient program than a crappy C programmer... but thats not really relevant here
Dont get discouraged by this! When you are learning things Java is a good choice because you can focus on the relevant stuff (like algorithms and math) but forget that a Java ray tracer is competitive in any way with a C ray tracer when it comes to speed.
IanT
Java is always a factor 2-4 slower than C.
Sweeping statement? This statement was true 5 years ago when Java was mostly interpreted but now it's not. The latest JIT compilers produce native code in exactly the same way a C++ compiler does (just at a different time). The JIT compiler has intimate knowledge of the architecture it's running on (SSE, SSE2, EMT64 etc. etc.) and can compile as appropriate. JRE's already do this and they get better at it all the time. A developer producing a .EXE using C/C++ has to choose the most likely common denominator for the target audience (usually SSE just like for Indigo
)
When it comes to rendering make that factor at least 10....
LOL ...
I am sure you can shoot ray packets using SIMD instructions using Java.... And of course your stream GPU processor is obviously programmable embedded in Java (NOT).
What does SIMD or GPUs have to do with software-based rendering (the very nature of this thread)? None of Indigo, Maxwell, Fryrender, Kerkythea, POV-Ray or any other renderer with a ray-tracing core run any faster with the latest whizz-bang graphics card, so not entirely sure how that's relevant?
Of course a great java developer can make a moire efficient program than a crappy C programmer... but thats not really relevant here
True.
Dont get discouraged by this! When you are learning things Java is a good choice because you can focus on the relevant stuff (like algorithms and math) but forget that a Java ray tracer is competitive in any way with a C ray tracer when it comes to speed.
Have you ever written one and tested it side-by-side with an equivalent written in C++? If you haven't, can you produce some references?
All a ray tracer is doing, 90% of the time, is throwing floating point instructions at a GPU and getting the results back. What would be the major technical reasons why a compiled Java program is 10 times slower at this than a C++ one?
It's true that Java programs can take a while to get up to speed and occasionally there's a blip for garbage collection, but this is largely a drop in the ocean when talking about renderers (especially unbiased ones that take hours to produce a final image anyway)...
<sigh>
Ian.
Sweeping statement? This statement was true 5 years ago when Java was mostly interpreted but now it's not. The latest JIT compilers produce native code in exactly the same way a C++ compiler does (just at a different time). The JIT compiler has intimate knowledge of the architecture it's running on (SSE, SSE2, EMT64 etc. etc.) and can compile as appropriate. JRE's already do this and they get better at it all the time. A developer producing a .EXE using C/C++ has to choose the most likely common denominator for the target audience (usually SSE just like for Indigo
)When it comes to rendering make that factor at least 10....
LOL ...
I am sure you can shoot ray packets using SIMD instructions using Java.... And of course your stream GPU processor is obviously programmable embedded in Java (NOT).
What does SIMD or GPUs have to do with software-based rendering (the very nature of this thread)? None of Indigo, Maxwell, Fryrender, Kerkythea, POV-Ray or any other renderer with a ray-tracing core run any faster with the latest whizz-bang graphics card, so not entirely sure how that's relevant?
Of course a great java developer can make a moire efficient program than a crappy C programmer... but thats not really relevant here
True.
Dont get discouraged by this! When you are learning things Java is a good choice because you can focus on the relevant stuff (like algorithms and math) but forget that a Java ray tracer is competitive in any way with a C ray tracer when it comes to speed.
Have you ever written one and tested it side-by-side with an equivalent written in C++? If you haven't, can you produce some references?
All a ray tracer is doing, 90% of the time, is throwing floating point instructions at a GPU and getting the results back. What would be the major technical reasons why a compiled Java program is 10 times slower at this than a C++ one?
It's true that Java programs can take a while to get up to speed and occasionally there's a blip for garbage collection, but this is largely a drop in the ocean when talking about renderers (especially unbiased ones that take hours to produce a final image anyway)...
<sigh>
Ian.
dude, java is just as fast as C. comparitivly i'm a noob at java (even if i am already way more advanced than everybody else in my class) and i already notice that my renderer is way faster than it should be given the speed drops your saying, maybe my computer is just realy fast, but my raytracer often seems to work as fast as blenders even with a more complicated scene.
as for:
i only have one word: sunflow
as for:
but forget that a Java ray tracer is competitive in any way with a C ray tracer when it comes to speed.
i only have one word: sunflow
a shiny monkey is a happy monkey
As a base point for the rest of this post: I like Java and I am a professional software developer.
Ok I can name 5 top of the line commercial ray tracers thats written in C/C++ but 0 ray tracers written in Java. Maybe its like that for a reason? (sunflow is not commercial and looks like a joke). Trust me they dont pick C because its harder to develop in and more error prone. They pick C/C++ for exact memory management without overhead. Close to hardwrae optimization and obviously speed. Think about it again.
http://www.freewebs.com/godaves/javabench_revisited/
http://www.irrlicht3d.org/pivot/entry.php?id=446
That ends that discussion...
Graphics cards have superior computation power and especially superior memory bandwidth today and they are fully programmable. In a few years many ray tracers will run a large chunk of their work load on the GPU. Then after that the unification of the CPU/GPU (multi core) will come to place and that will change stuff once again.
But you go ahead and live in your ignorance.
Ok I can name 5 top of the line commercial ray tracers thats written in C/C++ but 0 ray tracers written in Java. Maybe its like that for a reason? (sunflow is not commercial and looks like a joke). Trust me they dont pick C because its harder to develop in and more error prone. They pick C/C++ for exact memory management without overhead. Close to hardwrae optimization and obviously speed. Think about it again.
http://www.freewebs.com/godaves/javabench_revisited/
http://www.irrlicht3d.org/pivot/entry.php?id=446
That ends that discussion...
Graphics cards have superior computation power and especially superior memory bandwidth today and they are fully programmable. In a few years many ray tracers will run a large chunk of their work load on the GPU. Then after that the unification of the CPU/GPU (multi core) will come to place and that will change stuff once again.
But you go ahead and live in your ignorance.
Graphics cards have superior computation power and especially superior memory bandwidth today and they are fully programmable. In a few years many ray tracers will run a large chunk of their work load on the GPU. Then after that the unification of the CPU/GPU (multi core) will come to place and that will change stuff once again.
graphics cards do not necessarily have superior computation power. they have superior computation power for graphics related applications such as anything dealing with 3d math or color, because thats what they were made to do. anyway, how is this relevant?
sunflow is not commercial and looks like a joke
have you tried sunflow or are you just judging from the lack of good art on the site? because its java people seem to overlook it without realizing its potential. its fast, it has biased operations and unbiased operations, and it has programable shaders. at its current state its alot better than yafray, and yafray doesnt seem like a joke.
a shiny monkey is a happy monkey
Ok I can name 5 top of the line commercial ray tracers thats written in C/C++ but 0 ray tracers written in Java. Maybe its like that for a reason? (sunflow is not commercial and looks like a joke). Trust me they dont pick C because its harder to develop in and more error prone. They pick C/C++ for exact memory management without overhead. Close to hardwrae optimization and obviously speed. Think about it again.
Maybe because Java's only picked up speed in the last couple of years?
http://www.freewebs.com/godaves/javabench_revisited/
http://www.irrlicht3d.org/pivot/entry.php?id=446
I guessed you might produce a 2+ year old benchmark page
That ends that discussion...
(from a 2.5 year old page on the subject? ... seriously?)
So you conviction is not based on experience of coding a renderer but from reading old benchmarks?
Graphics cards have superior computation power and especially superior memory bandwidth today and they are fully programmable. In a few years many ray tracers will run a large chunk of their work load on the GPU. Then after that the unification of the CPU/GPU (multi core) will come to place and that will change stuff once again.
And then native compilation will be supported in the Java JVMs of the time.... not sure what your point is here. Will these CPUs run C++ natively or will they continue to run compiled machine code like they do today?
But your comment about rendering being 10 times slower was written like you were talking about "today" rather than "in the future"? Or did you mean something different? (in which case, why didn't you say so?)
But you go ahead and live in your ignorance
(... arrogance...)
I'll ask again ... when did you write a Java renderer and then compare its performance with another one? Where did you get "10 times slower" from? Experience or just an uninformed guess?
Also, what are the technical reasons why a compiled Java program should be any slower at feeding instructions to an FPU than a compiled C++ program? Java 1.6 (for rendering performance with one renderer) resulted in a 25% leap in base performance when it was released 6 months ago. How are 2 year old benchmarks applicable in this case?
Ian.
Maybe because Java's only picked up speed in the last couple of years?
http://www.freewebs.com/godaves/javabench_revisited/
http://www.irrlicht3d.org/pivot/entry.php?id=446
I guessed you might produce a 2+ year old benchmark page
That ends that discussion...
(from a 2.5 year old page on the subject? ... seriously?)
So you conviction is not based on experience of coding a renderer but from reading old benchmarks?
Graphics cards have superior computation power and especially superior memory bandwidth today and they are fully programmable. In a few years many ray tracers will run a large chunk of their work load on the GPU. Then after that the unification of the CPU/GPU (multi core) will come to place and that will change stuff once again.
And then native compilation will be supported in the Java JVMs of the time.... not sure what your point is here. Will these CPUs run C++ natively or will they continue to run compiled machine code like they do today?
But your comment about rendering being 10 times slower was written like you were talking about "today" rather than "in the future"? Or did you mean something different? (in which case, why didn't you say so?)
But you go ahead and live in your ignorance
(... arrogance...)
I'll ask again ... when did you write a Java renderer and then compare its performance with another one? Where did you get "10 times slower" from? Experience or just an uninformed guess?
Also, what are the technical reasons why a compiled Java program should be any slower at feeding instructions to an FPU than a compiled C++ program? Java 1.6 (for rendering performance with one renderer) resulted in a 25% leap in base performance when it was released 6 months ago. How are 2 year old benchmarks applicable in this case?
Ian.
Lol, failed to back up "Java is always a factor 2-4 slower than C. When it comes to rendering make that factor at least 10.... " ... convenient time to leaveDeus wrote:I am done. Good luck to you!
I do have a "tiny" bit of experience in the rendering field and have done plenty of my own tests Re: C++ vs. Java for software-based unbiased rendering ... 3 years ago it was 30-40%, now it's around 5-10% and closing. I suspect you have no experience in this field at all but hey ... one day you might
Ian.
Deus Who is online
Users browsing this forum: No registered users and 20 guests