[JOODE] Contribution

[biggeruniverse]

@darkprophet

non-x86 platform? So that implies PPC right? Which means older macs and PS3.

Try SPARC, anything MIPS, or Cell.

@darkprophet

If you read above, the Accuracy VS Speed is configurable depending on the number of loops on the last line. As for the accuracy of JOODE, your depending on LCP in the first place, which isn’t highly accurate, but achieves visually convincing results and is stable. If you want accuracy, im afraid your going to have to change all of JOODE.

*Is JOODE accuracy v. speed configurable

@darkprophet

If you want to re-prove what Quake3 and I (and countless others) already have proved that it is a worthwhile optimisation, then by all means go ahead

Did they prove it in Java?

If you look at the change log, you will notice that this code is already in place (with a different initial value). I put it there myself (well, with Amos’ help). However, I left it commented out, since there is currently no way to choose, nor was there a concensus on its use.

[darkprophet]

Sorry, only machine I have and is accessible to me is a AMD Athlon X2. I doubt anybody with a SPARC/MIPS will run JOODE tho given that SPARCS or MIPS aren’t exactly gaming machines

In any case, what basis do you have for the results being different other than “just in case”?

1: Java gurantees that the code runs the same on all platforms and as swpalmer noted, its all IEEE 754…
2: In that paper you referenced in the comments, it clearly states it works on common hardware.

I think you are not giving me the real reason why you dont want this included and frankly, I dont care anymore. Like I said before, its a contribution, the polite thing to do say thanks for the contribution, encourage more people to contribute and do what the hell you please with the code thats given. I personally doubt I will be contributing to JOODE again given the poor spirit of the project.

DP

[biggeruniverse]

Don’t take me as any indication of the larger project community. It is still a very young project, and has no general “spirit” yet. Tom has already stated he’s happy with the contrib, and the thread is becoming an off-topic about Java portability when using “magic” algorithms that rely on specific standards and/or architectures.

I don’t like to simply say “Thanks for the contribution, move along.” I prefer a public discussion of the patch, what the submitter has done and why, as per the spirit and guidelines of the project. It leads to a better quality of patches. I’m not saying it has to be a hearing before a committee either, but it does not justice to the patch writer to simply take their patch and trash it.

I hope that you will contribute in the future, and I hope you will at least consider JOODE for volatile.

[cylab]

This algorithm is actually covered in a book of mine (3D Game Engine Architecture) and is part of the Wild Magic 3d Engine . It seems to be a quote common “hack” in 3D engines, so I believe it’s save. It is described here and here. The documentation section on http://www.geometrictools.com has a lot of probably useful stuff…

[eMKa]

@biggeruniverse

Well, what accuracy is JOODE guaranteeing to the user? Is accuracy v. speed configurable? At what point of accuracy is this slower than Math.sqrt?

Why not let the user configure that ?
Just a “Math Optimizations” Enable/Disable options.

@biggeruniverse

JOODE is Java, that code is converted C code. It was written to be close to the hardware, which of course makes me suspicious of it. Has this Java code been shown to work on any non-x86 environment? (It should of course, but better to test these things before they are relied upon to be always correct)

biggeruniverse, see the beginning of this thread. It has been reported to work on a 64bit processor.

@biggeruniverse

I hope we take it, as it is faster, but first it has to be proven out.

See DP benchmark. Or were you talking about non-x86 platform compatibility ?

@biggeruniverse

Well, first thing first, let me finish the conversion to pure vecmath. I’ll branch it for easy testing, and then it can be decided what to do about optimizations.

OK, no problem.
Anyway, change from sun vecmath to our modified vecmath is pretty straight-forward.

[biggeruniverse]

@Amos Wenger

Why not let the user configure that ?
Just a “Math Optimizations” Enable/Disable options.

That’s what I was getting at.

@Amos Wenger

OK, no problem.
Anyway, change from sun vecmath to our modified vecmath is pretty straight-forward.

cool. I plan to commit the branch (mostly complete) this evening.

[swpalmer]

@darkprophet

Sorry, only machine I have and is accessible to me is a AMD Athlon X2. I doubt anybody with a SPARC/MIPS will run JOODE tho given that SPARCS or MIPS aren’t exactly gaming machines

In any case, what basis do you have for the results being different other than “just in case”?

1: Java gurantees that the code runs the same on all platforms and as swpalmer noted, its all IEEE 754…
2: In that paper you referenced in the comments, it clearly states it works on common hardware.

I think you are not giving me the real reason why you dont want this included and frankly, I dont care anymore. Like I said before, its a contribution, the polite thing to do say thanks for the contribution, encourage more people to contribute and do what the hell you please with the code thats given. I personally doubt I will be contributing to JOODE again given the poor spirit of the project.

I don’t think the hostility in your message is warranted. I see no hidden motives for rejecting the code, only straight-forward, honest inquiry as to whether it works in all Java environments, where the JOODE project as a whole is drawing the line in terms of trade-off vs. speed, and how this fits in with those decisions.

I also don’t think dismissing SPARC/MIPS is in the “spirit” of Java. JOODE may be developed primarily for game physics, but there is no reason to limit it to gaming unless there is a significant gain.

I agree with the idea of a on/off switch for faster less-accurate math routines, but I wonder if adding such an option will impose a performance penalty of its own? I would hope that if the math code is called through an interface that HotSpot will inline the virtual calls since there will likely only be one implementation in use anyway.

[eMKa]

@swpalmer

I agree with the idea of a on/off switch for faster less-accurate math routines, but I wonder if adding such an option will impose a performance penalty of its own? I would hope that if the math code is called through an interface that HotSpot will inline the virtual calls since there will likely only be one implementation in use anyway.

Yeah just what I thought… but are calls via an interface inlined ? (I have very limited knowlege of the JVM internals)

[cylab]

An option could be to use a preprocessor (e.g. vpp) to produce two different vecmath-jars, an accurate and a fast one, so you could at least change the implementation by setting up the classpath accordingly.

[darkprophet]

I don’t think the hostility in your message is warranted. I see no hidden motives for rejecting the code, only straight-forward, honest inquiry as to whether it works in all Java environments, where the JOODE project as a whole is drawing the line in terms of trade-off vs. speed, and how this fits in with those decisions.

I also don’t think dismissing SPARC/MIPS is in the “spirit” of Java. JOODE may be developed primarily for game physics, but there is no reason to limit it to gaming unless there is a significant gain.

Your using java, yet your questioning its most core value before you have even tested the code out on the various archs ? Just seems a bit naff to me to be honest. Its like saying “oh, i shouldn’t take a step forward, because the marble floor infront of me has a slightly different shade than the one im stepping on now, lets test it with an anvil!”

Also, the LCP iterator is pretty much usless for simulations anyway, so im not sure what applications JOODE or even ODE has outside of gaming…

cylab: why vpp? you could use APT which comes with javac and eclipse these days anyway. LWJGL uses it for generation of their GL classes and extensions. Saves introducing another dependancy, but thats up to you guys.

DP

[cylab]

@darkprophet

cylab: why vpp? you could use APT which comes with javac and eclipse these days anyway. LWJGL uses it for generation of their GL classes and extensions. Saves introducing another dependancy, but thats up to you guys.

Vpp was just an example and I wasn’t aware, that apt could be used under this circumstances. I am still not sure, how to implement something like

#ifdef USE_FAST_MATH
  float result= FastMath.invSqrt(value);
#else
  float result= 1/Math.sqrt(value);
#endif

with apt. How would you do this?

[darkprophet]

you would use annotations, so you have a template and from the template, you create your sources…

so for example:

@FastInvSqrt
public float invSqrt(float v);

and its up to the processor that you create to take what FastInvSqrt means and convert that into legible code.

[t_larkworthy]

[quote]Also, the LCP iterator is pretty much usless for simulations anyway, so im not sure what applications JOODE or even ODE has outside of gaming…
[/quote]
ODE is very popular for robotics researches wanting a cheap simulation environment. At the end of the day a high fidelity system is not going to come close to capuring a real world environment. There are too many parameters for anyone to configure (I mostly talking about surface parameters). The major opinion is that a robot shown to work in simulation won’t show that it works in real life, no matter how accurate the simulation environment is. So why bother trying. ODE and JOODE basically captures the really important stuff, joints swing about like they should do, masses have momentum etc.

Nick Jakobi suggests that to increase the chances a controllor for a robot developed in smimulation will transfer to real life involes injecting huge amounts of noise into the simulation, thus kind of negating much of the gains in a high fidelity system, see:
“Evolutionary Robotics and the Radical Envelope-of-Noise Hypothesis” Nick Jakobi