Hi, On Sat, 2007-09-29 at 17:54 +0200, Michael Nikelsky wrote: > > Gerrit Voss schrieb: > > > >>> Is the compiler really that bad, I thought they were making progress > >>> and brought in some people who actually know how to write compilers > >>> ;-( > > Yes, of course the compiler should do the job. But it doesn´t, and > programming something that should work but doesn´t is programming > without considering reality.
A Mircosoft reality yes. Given I'm heavily biased towards ignoring MS crap when it comes to changing design for performance. But that's one reason we really need Dirk ;-), to kick me and counterbalance me a little bit when I do so ;-) So forgive me on that one ;-) > Also: What are the other options? Given for MS I guess nothing (but I don't really know). > Well, there is a way to force inline with msvc8, but it is not used in > OpenSG (means: there is only inline used everywhere, not __forceinline - > a define would be better here). I will look into it. But I would like to refrain from adding it just everywhere. Especially now before we made a decision to use GMTL or not. > > not really, comparing the size of a completely (e.g. type, size and > > simd/altivec) unrolled implementation against a templated/specialised > > one I would still say the templated version is smaller. And more > > important if you have to fix a bug you don't have to trace it through n > > unrolled version. > > Certainly, the bug thing is nice and templates have their advantages. > But basic math classes are the absolute basic for rendering applications > and losing performance here means you loose performance everywhere. > Also, how likely is it that you will change these classes once they are > up and running? And a Vec3f is NOT the same as a Vec4f, there are pretty > great differences (homogene coordinate!), so you will need to > reimplement most functions anyway since a simple loop will not work. So > with both options: Reimplement everything from scratch with the > possibility to optimize as far as it gets (using SIMD, intelligent > functions doing only the work that is necessary) or Reimplement most of > the class and using templates loosing every chance to do specific > optimizations for certain classes, I would definetly choose the first > option. Sorry but this is at least partially wrong. In order to get more performance out of any c++ class based math implementation you need templates. OpenSG is lacking those (partly because I didn't have time to put them in, and weren't allowed to ;-)) ). This is the reason we are discussing using GMTL, to get more templates not to get less. You really need them to get close to FORTRAN performance (and this is still the benchmark). And your example goes exactly into this direction because it is not just inlining. You collapsed one of the two loops present in the C++ code into the other. And this collapse is where some of the real performance bottlenecks are hidden. Ok, besides all the MS bashing I see your point and I'm happy to hear that __forceinline seems to work in the latest ms compiler version. For the upcoming decision on the math implementation I keep you comments in mind. Would it be ok if I send you some GMTL based test to see if the final performance meets your expectation ? This might take a second because I just started looking into it in more detail. > > Can anyone supply some concrete examples, e.g which function and the > > calling place. I really would like to verify it. > > Here we go, the manual inlined version is about 1.9 times faster than > the not inlined opensg version for me: ok, I'll give it a try. Just a short check, one wish would you try that with Vec3f instead of Pnt3f. I just want to make sure we don't run through any weired type conversions. I'll try to get it running on Windows. And once I have more information on the technical details I get back. thanks 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
