Hi,
On Sat, 2007-09-29 at 08:38 +0200, Matthias Stiller wrote: > Hi, > > On Saturday 29 September 2007 05:21, Gerrit Voss wrote: > > 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 > > ;-( > > Hard to say. We are using AQTime (nice tool by the way) these days to > find out what is going on. But their pricing sucks, charging 3 times more for a floating license is ridiculous. > Especially the inlines are very surprising > (read frustrating). Most of them are completely ignored EVEN if you use > __forceinline. AFAIK inline is something like a hint for a compiler. inline and __inline in itself yes. But usually there must be a way of forcing the compiler to inline. Otherwise the compiler is unusable for anything that comes even close to high performance. It's a tool so it should never ever have a big impact on the design as long as the design is within the language specification, especially if other tools prove that it is possible. And it should always listen to the programmer who hopefully knows what he/she is doing ;-) > > > 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. > > Of course you can do template specializations but well then you are > going to rewrite most of them anyway :( 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. > Implementing the mentioned > specialized 2D case is only useful for very few people I think. Not unlikely, except if you do a lot of texture coordinate computation on the cpu. > > > > 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. > > Sorry, doesn't work. Can anyone supply some concrete examples, e.g which function and the calling place. I really would like to verify it. 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
