[ODE] More speed???

[Gary R. Van Sickle]

> >>> NO NO NO!!!
> >>> please, keep in mind that ODE is 'ONLY' the PHYSIC ENGINE.
> >>> So, any reference to a graphic API must be avoided (exept for exemple,
> >>> testing, ...) But not in the core!
> >>> Please, keep DirectX out of this!
>
> AP>> Well, D3DX math library isn't tied to any graphics part at all.
> It doesn't
> AP>> even know about any D3D device. But probably it isn't the best
> solution...
>
> OVS> And it's slow, as well, even on SSE/3Dnow! enabled CPUs.
> OVS> Typical operation consists of:
> OVS>         * push arguments
> OVS>         * [static] call
> OVS>         * [static] jump
> OVS>         * ...calculation...
> OVS>         * return
>
> Just looked, at the asm, this is not "[static] jump", it's "jump int
> the table", so, even slower :)
>

Slower than, say, a non-SIMD 4x4*4x4 matrix multiplication?  Without seeing any
numbers I find that almost impossible to believe, even on the freakshow that is
the Intel x86 architecture.

> I've strongly against using D3DX in ODE, especially in performance
> critical code.

Well, I'm strongly for trying it, but I more than likely won't be writing the
code, so until somebody does this or something else, both our strongly held
beliefs are pretty academic.

> Conditional compilation and larger-grade performance
> optimized functions is much better, IMHO.
>

Conditional compilation is what I'm advocating.  DirectX on Windows (if indeed
it improves performance), the existing code otherwise until somebody comes up
with a viable alternative for Unii etc.

> BTW. This is for dx9.0 summer update SDK
> P.S. And I think all of this is just a job for compilers, but they
> aren't mature enought at SIMDizing, yet :(
>

Our grandchildren will be grandchildren before they are ;-).

--
Gary R. Van Sickle