+- Forums (https://www.vdrift.net/Forum)
+-- Forum: Project (https://www.vdrift.net/Forum/forumdisplay.php?fid=4)
+--- Forum: Development (https://www.vdrift.net/Forum/forumdisplay.php?fid=9)
+--- Thread: Fixing tacho band and needles in HUD (/showthread.php?tid=733)
Pages:
1
2
- joevenzon - 07-31-2007
bugsyv Wrote:surely, function call overhead would negate any performance benefits fancy assembly code in memcpy got you. However, I ran some tests, and over 1 billion iterations the memcpy is 2 seconds faster than the three assignments ( 23 vs 21 ) on my machine.
I know, it seems weird! I think it's because the compiler ends up inlining the memcpy and just spits out assembly for a block memory copy instead of assembly for 3 memory copies for the assignments... but who knows. I profiled VDrift quite a bit with the new "scenegraph branch" code (which is now merged in the trunk); that's where this came from.
- kidrock - 07-31-2007
I didnt have any problems at all with the main menu or driving. I also updated the data at the same time... could that be it? :?: :?: :?: :?:
- bugsyv - 08-01-2007
Like I said... it's a truly bizarre situation.
I don't think the data in question has anything to do with it.
- thelusiv - 08-01-2007
kidrock, bugsyv is on a PPC machine, so things are a little different for him (he eats the egg from the big end first - weird I know!
).The memcpy statement in question should be separated out by a ifdef with the version that works for bugsyv only compiled in for PPC versions, and the regular version compiled in otherwise.
- joevenzon - 08-01-2007
The corrected "regular" version works for bugsy (memcpy but with this as the first argument).