Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Bug Reports / ABS command is far too slow (5.8)

Author
Message
spooky
21
Years of Service
User Offline
Joined: 30th Aug 2002
Location: United Kingdom
Posted: 20th Mar 2006 18:58
It has been found that ABS is at least 4 times slower than doing a manual function to achieve same answer. Lots of users that do many ABS calls per loops are finding frame rate drops rapidly.

I know it's not a bug and you are being ruthless at rejecting commands that are not bugs, but surely there is a bad coding bug in your command to make it so slow and could easily be fixed for next beta.

Yes, I'm still using 5.8 but I know many others using 6 betas are getting same results.

See here for main discussion.

http://forum.thegamecreators.com/?m=forum_view&t=74535&b=1

Simple code to demonstrate (by Lost in Thought);



PS. Keep up the good work. I will update my 5.8 to next beta version when you release it and recompile all my old programs. Hopefully I won't find too many problems.

Boo!
re faze
19
Years of Service
User Offline
Joined: 24th Sep 2004
Location: The shores of hell.
Posted: 20th Mar 2006 21:35
should be fast as hell, it only needs to set the leftmost bit to 0

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 20th Mar 2006 22:43
@spooky

The native abs() function can accept reals or integers. Perhaps you should rewrite your code so it works the same way for a fair comparison?
optical r
21
Years of Service
User Offline
Joined: 23rd Oct 2002
Location: Prime
Posted: 20th Mar 2006 22:58
perhaps looking up binary search using floor & ceiling method? cuts way half the work and doubles the time!
re faze
19
Years of Service
User Offline
Joined: 24th Sep 2004
Location: The shores of hell.
Posted: 20th Mar 2006 23:14
hmm, didnt think about reals, but surely it should be the same deal right? isnt there a sign bit in IEEE notation?

Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 20th Mar 2006 23:50
Quote: "It has been found that ABS is at least 4 times slower than doing a manual function to achieve same answer."


Not on my machine. I get about 140 vs 340 for homemade vs DBP when using integers, and 160 vs 280 when using reals. Still faster though. (I'm not sure how DBP handles the real vs integer thing though. Lee should know.) However, if you know you're only using integers then the homemade version does seem faster.
LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 21st Mar 2006 11:23
I would not class this as a U6 bug, more an optimization. If you find your own methods faster, use your own methods. This is the great thing about programming I have attached one of my own too. If you want to use ABS(), it is a trouble free way to do the functionality without the headache of figuring out how. If you want the pure speed, you need to know EXACTLY what you want, and nine times out of ten, you will have to do it yourself. There are easily over a thousand commands that 'could' be faster, the biggest question is where do we spend our time? It is not an easy question to answer as well!

"Small, smart, and running around the legs of dinosaurs to find enough food to survive, bedroom programmers aren't extinct after all "
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 21st Mar 2006 11:32 Edited at: 21st Mar 2006 11:35
This function will handle integers or floats and runs at the same speed. I didn't come up with this though, i merely turned it into a function. I think it was either Empty, IanM, or RobK that posted it ages ago trying to help someone do this very thing though I can't find the thread.



[edit] However when using it on double length data types it is about the same speed as the native command. Assuming the ABS() command works with these double types then it may explain the slow down.

LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 21st Mar 2006 11:40
Using my NOT + INC code, it should be quite fast if you can deposit a lot of integers into DWORD data structures, blast them for ABS calculations, and copy the results back to the integer pool. The key to the code is that there are no cast conversions once you have your DWORD and the NOT + INC code is entirely ASM, no calls to the core DLL (which ABS does, and does so at a cost of about 70+ CPU cycles, not counting the actual ABS function employed).

"Small, smart, and running around the legs of dinosaurs to find enough food to survive, bedroom programmers aren't extinct after all "
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 22nd Mar 2006 00:36
@Lost in Thought

You said:

Quote: "This function will handle integers or floats and runs at the same speed."


It doesn't - precision of high value integers is lost. Try it with, say, 10 digit integers. You need to do a bit more work to reproduce the built-in abs() function (with, presumably, a loss of speed).

As Lee says, it's an optimisation issue. If you know precisely what sort of things you are going to need in your programs you can sometimes rewrite standard functions to perform much faster. A good example is the basic2D line command - if you know you will always need horizontal, vertical or 45 degree lines you can write much faster code than the line command. But you have to spend time doing that - is it worth it? (It obviously is sometimes.)
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 22nd Mar 2006 01:57
Yes anything lower than -1073741824 will not work with that function and you will have to use the double length data types to calc. Which is slower. Thats why I posted:

Quote: "[edit] However when using it on double length data types it is about the same speed as the native command. Assuming the ABS() command works with these double types then it may explain the slow down."




Something is not right still though as the leftmost bit of the integer is ignored in that function I posted earlier. I'll look into it as it may be a bug

Login to post a reply

Server time is: 2024-03-28 11:30:58
Your offset time is: 2024-03-28 11:30:58