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.

DarkBASIC Professional Discussion / any one know how fast does "inc" or "dec" count?

Author
Message
Section 812
18
Years of Service
User Offline
Joined: 24th Feb 2008
Location:
Posted: 20th Feb 2013 23:56
I am just wondering if inc increments according to the syncrate or
does it go by the timer.
I am interested to know what the speed of inc is.

This is probably a useless question but I'd like to know my DBPro
a little more intimately.

Section 812
18
Years of Service
User Offline
Joined: 24th Feb 2008
Location:
Posted: 21st Feb 2013 01:36 Edited at: 21st Feb 2013 01:38
I did a little test and came up with this.
in 1 second inc reaches 1086909
little faster than a millisecond.

this is the code I used:


mabe no one cares... or mabe they do!

now I wonder if inc could be used as a faster timer.

Section 812
18
Years of Service
User Offline
Joined: 24th Feb 2008
Location:
Posted: 21st Feb 2013 01:46
triple post:

I just found out that value varies on a different cpu speed
so I'm guessing it goes by syncrate.

thenerd
17
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 21st Feb 2013 03:05
For every time you execute the inc command, it will increase your variable by the amount given. If you provide no value, the default increase is one.

So, inc Variable will increase the variable by 1.
The result you're getting in your code just shows how many times your computer can run the loop in one second. A faster computer is capable of running the loop faster, so the inc command will be called more and generate a higher value. However, every time you call the command it is still adding 1.

Section 812
18
Years of Service
User Offline
Joined: 24th Feb 2008
Location:
Posted: 21st Feb 2013 06:30
I figured that out and thanks for confirming it

the code was just to see what it did in one second, then I tried it on another pc and saw a difference. and after playing with the sycrate I found that it responds to that as well.

but even so these findings, it does appear to count faster than timer().

my thoughts now are what if I made a timer function using inc.
1. is there a downside, besides the fact it doesn't count as high as timer()
2. is this just another stupid idea to cure boredom.

Phaelax
DBPro Master
23
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 21st Feb 2013 06:52
Quote: "1. is there a downside, besides the fact it doesn't count as high as timer()"

It'll count as high as you want it to count. It's only limitation is the data size of the variable.

And no you wouldn't want to increment a variable in order to track time.

For example:


The speed at which 'stuff' would happen would be dependent upon the speed of the computer. Therefore, results would be faster or slower depending on who's computer was running the program.

"You're all wrong. You're all idiots." ~Fluffy Rabbit
Libervurto
20
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 21st Feb 2013 13:35
Have you tried testing inc x vs x = x+1? I'd be interesting if there's any speed difference.

pcRaider
19
Years of Service
User Offline
Joined: 30th May 2007
Location:
Posted: 21st Feb 2013 13:42
Quote: "Have you tried testing inc x vs x = x+1? I'd be interesting if there's any speed difference."



X=X+1


INC X
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 21st Feb 2013 13:45 Edited at: 21st Feb 2013 13:46
There is, but it differs from CPU to CPU; with or without the additional INC/DEC step parameter the difference is insignificant compared to other DBP performance costs.

Using the Matrix1 Ticker commands is the tidiest timing procedure.

Section 812
18
Years of Service
User Offline
Joined: 24th Feb 2008
Location:
Posted: 21st Feb 2013 14:38
thanks Phaelax, I was curios and I see the logic now. not a good timer.

I would have thought that x = x+1 would be the same as inc, is it faster than inc? even if slightly, I would use this instead of inc then just to squeeze out all I can get.

I forgot all about Matrix1 ticker commands, now I'm gonna have to compare it to DBPro's native timer.

Dar13
18
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 21st Feb 2013 14:59
Quote: "I would have thought that x = x+1 would be the same as inc, is it faster than inc? even if slightly, I would use this instead of inc then just to squeeze out all I can get."

x = x + 1 would be the same as inc if the DBP compiler could inline the inc function. Since it can't AFAIK, there is a very small overhead incurred because it has to call a function contained within an external DLL.

Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 21st Feb 2013 15:22 Edited at: 21st Feb 2013 15:27
Quote: "is it faster than inc? "


The answer will not make your life any easier or better, so forget it; much more important things to worry about. Use which ever is easiest to read in the given situation. On one PC, it is slower on another it is faster, but you will not notice the difference, your talking about around a 100,000th of a second or so. Check out my need for speed thread for benchmark tests for a little evidence; but again it differs from PC to PC, situation to situation, number of cores, quality of programming and state of user operating system, hardware and handheld/laptop battery life.

The only area of performance worth thinking about is number of IF statements (or similar condition checks), number of bytes read or sent to hard disk or network location, number of objects on screen, number of 2D drawing commands, number of bones, number of sprites on screen, number of collision checks and number of Object/Limb/Vector queries (such as Object Position X, Vector X, Limb Angle Y); these kinds of things are more likely to drop FPS by 100 fold over number incrementation, especially number of objects on screen (not so much polygons, object count in particular) and also CPU based collision checks.

Section 812
18
Years of Service
User Offline
Joined: 24th Feb 2008
Location:
Posted: 22nd Feb 2013 03:04
there's no argument with your post Chris Tate, and your "need for speed" thread has been more than useful to me. I wasn't trying to make things easier, just exploring DBpro more intimately.

mabe the speed of inc is insignificant, but what dar 13 said, about using the math over the function, makes sense to me that solving the math would be more efficient than searching a library for a function that solves the math. and also it's pretty much universal, I've used this in other languages but never gave it thought in DBPro.

Thank you all for your advice.

summary:
Inc counts according to cpu and syncrate
using inc for a timer is insane.
x=x+1 - doing the math is more efficient than using the command.
Chris Tate is a party pooper. (just kidding, I see your point though)

Ortu
DBPro Master
18
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 22nd Feb 2013 04:37
Quote: "Inc counts according to cpu and syncrate"


well sort of but not really, it counts according to the number of times its called.

you can do this



and in ten loops it will be the same as



in one loop

and the same as



in one loop

with no bearing on sync rate.

the only way in which syncrate/framerate affects inc is in the number of times it gets called over a given amount of time which is constantly changing, even on the same machine. its a counting mechanic not a metrics gauge. you should really try not to associate inc with time or performance, and just think in terms of how much do i want to modify something in a given loop, mostly in my experience this isnt even a main game loop but more often something like this



Login to post a reply

Server time is: 2026-07-07 18:44:36
Your offset time is: 2026-07-07 18:44:36