CTime::getPerformanceTime / CTime::ticksToSecond, ASM, and multi-core processors
I've just read that a bug (see http://dev.ryzom.com/boards/18/topics/3102) has been fixed by keeping Ryzom from using several cores!
To me, it feels somehow wrong, and so, I had a look to time_nl.cpp, and especially the CTime::getPerformanceTime function.
First thing I've done is to read its description, that seems quite off...
"Return the time in processor ticks."
Ok. Is that really what you want? If I understand well, mach_absolute_time returns an arbitrary value, that isn't the "time in processor ticks".
"Use it for profile purpose."
Obviously, it's used all around NeL and Ryzom, not only for profile purpose.
"If the performance time is not supported on this hardware, it returns 0."
Reading that, I'm thinking that's something minor, but it is not.
Ok, then, the function itself. Are those ASM bits really needed? Having a look at the SDL sources, it appears they are using the same thing for Windows, and clock_gettime or (depending on compile-time configuration) gettimeofday.
clock_gettime provides a monotonic time expressed in seconds + nanoseconds, if you don't want "time in processor ticks", I think we can use it, throwing away (or using only as a fallback) the ASM code, while getting a core-independant time (so, we can enable all cores again).
We can use gettimeofday, too. As said earlier, it's used by SDL by default, and I've never seen any SDL app do hops in time, so, it should be ok. Its resolution is seconds + microseconds.
RE: CTime::getPerformanceTime / CTime::ticksToSecond, ASM, and multi-core processors - Added by rti over 2 years ago
there is an issue for that #150