Hi, On Fri, 2007-09-28 at 14:14 -0500, Dirk Reiners wrote: > Hi Michael, > > Michael Nikelsky wrote: > > Did you look at the generated assembly code? Because the trouble with > > templates is: The functions quite often don´t get inlined (at least not > > with MSVC8) which really slows you down a lot.
Is the compiler really that bad, I thought they were making progress and brought in some people who actually know how to write compilers ;-( > > Especially using templates in basic math classes like Vec3f/Pnt3f and so > > on is probably the worst thing one can do since some functions in OpenSG > > (like operator+ for Pnt3f) don´t get inlined. Not to mention: you loose > > some chances for optimizations (SIMD for example could be pretty > > difficult to use in templates when you want to use the same code for > > Vec2f/Vec3f/Vec4f). This is only a half an argument as you can (and always have to) specialise the SIMD part as there are platforms which do not support it, e.g. ia64 or ppc platforms. Furthermore in order to use SIMD for non 128 bit structures you have to specialise/reorganise on an even higher level like having a specialised MFVec2f which can handle two two value vectors combined. > > I finally got used to use my own math classes and do a simple > > reinterpret cast on values stored in multifields - got me quite some > > speedup since the compiler does correct inlining. > > Do you have some benchmark results you can share? If there is a significant > impact we need to change things... Before we start changing code and design, I would like to verify if this is a MSVC only problem. If it is I'm tempted to say bad luck, if they still don't know how to build a proper compiler. I mean they seem to have managed to add ipo and pgo. Anyway usually there should be way to force the compiler to inline functions, something like __forceinline. So before changing code I would go for that. I'm pretty sure the code the math classes originally came from was as fast as the macro heavy C implementation at that time, though I don't know if anything changed to the worse in the meantime. And yes this was based on doing timings, IRIX and Linux. Just curious, did they manage to remove the rather stupid memory de-allocation from their stl container clear functions with 2008 ? > SIMD: you're probably right on that one. Allen: did you ever get around to > doing > SIMD in GMTL? I.e. if we switch to GMTL, will we get SIMD for free? even if GMTL would do SIMD you can not just pop it in there, it is not a simple drop in replacement for some math. Having worked with it you have to carefully fine tune you memory layouts as there are alignment requirements on the simd structures. Also for whatever you need you have to store 128 bit values. In order to really utilise SIMD you are usually required to redesign your structures and algorithms. For example simd rays use 3 128 bit values to store the directions, one for the 4 x, another for the 4 y and the last for the 4 z values. So you work with a single 4 ray class instead of 4 ray classes using SIMD structures internally. kind regards, gerrit ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
