System Key Timers 2

[Jesus4Lyf]

Yeah, this discussion is fine now.

>Feel free to post "KT2 is faster with one instance than TT" wherever you want though.

Correction; faster with one item of code for x instances of it.

And, if you know how the systems work, you'll know that the different pieces of code make no difference to how fast they run. So the logical conclusion (but still untested until we get to Cohadar's test) is that KT2 is faster, regardless.

>Vexorian would bitchslap you for that.
LOL. He sure would.

We now have two bench testing methods. Zero-period method (for testing execs/sec for code attachments using any timer system, not the most reliable theoretically but seems to at least say which is faster and give a reasonable percentage), and the StopWatch method (times from when the timer starts firing the loop code to when it finishes). The Zero-period method is what I was using until that last test, the StopWatch method cannot be used for non-multi-instancing timer systems because it will grossly favour them (because it doesn't include the time it takes for a timer to fire in the first place, which is probably their greatest overhead).

Edit: Completed Cohadar's test by executing his code. Had to add the call TT_Init() line, not that it matters. Silly. I know.

Anyway... Really nice test. Quite a flashy effect you got there. Doesn't lag.

KT2 - ~199 loops/sec.
TT - ~181 loops/sec.

KT2 was 10% faster.

Of course, people should know that all this test did was add a large, consistent overhead to both systems, so all it did in effect was dilute the percentage, and hopefully satisfy Cohadar.

Cheers.

Edit: Spent 2.5 hours and completed the graphing (for my own sake, wouldn't mind the rep, though XD). I will compare any other graphs to my own. This was completed using the Zero-period method, which I have previously explained (and there is a 1 line summary in the spreadsheet). That probably concludes bench testing, for me.

 

[Jesus4Lyf]

May I ask for an explanation as to why this is in the graveyard, please?

 

[Andrewgosu]

May I ask for an explanation as to why this is in the graveyard, please?

All this arguing made me forgot it has received several updates.

Moved it to the submissions forum before approving it.

 

[Cohadar]

KT2 was 10% faster.

Of course, people should know that all this test did was add a large, consistent overhead to both systems, so all it did in effect was dilute the percentage, and hopefully satisfy Cohadar.

Cmon, be fair now. Tests were well designed to simulate real map situation.
That is the only situation speed should be of concern anyways.

If you are interested why percentage went down for KT2 I believe it is because there were 10 different conditions (spells) in the benchmark so KT2 actually had to swap between them when executing (which was not the case with your tests) so we finally had the chance to see how our swapping algorithms affect performance.

============================
Graveyarding a resource without explanation is really the worst kind of moderating. Who ever did it please correct your mistake by ungraveyarding this or by adding a valid explanation.

 

[Jesus4Lyf]

>Cmon, be fair now. Tests were well designed to simulate real map situation.
>That is the only situation speed should be of concern anyways.

Yeah, no problem with that.

If you are interested why percentage went down for KT2 I believe it is because there were 10 different conditions (spells) in the benchmark so KT2 actually had to swap between them when executing (which was not the case with your tests) so we finally had the chance to see how our swapping algorithms affect performance.

What? I think you need to go read the code. KT2 generates a new boolexpr EVERY TIME you call Add. And this is never reused. So different code being attached makes no difference, as it's still a new boolexpr.

all this test did was add a large, consistent overhead to both systems, so all it did in effect was dilute the percentage

It's because it's a large, consistent overhead.

Graveyarding a resource without explanation is really the worst kind of moderating.

I recieved quite a shock when it was suddenly in the graveyard. I thought KT2 was done with the graveyard. But there you go, it's made two visits now. Slowly getting used to it.

But I'd like the moderators to know that I've been working on this system or bench testing it for 2 hours a night for the last 2 weeks or so. Finding it in the graveyard was not pleasant. Do you think I do all this work for myself? Just so I can proove to myself what I already know, for the 20th time?

Andrewgosu, your graphs are attached 4 posts above...

 

[Cohadar]

What? I think you need to go read the code. KT2 generates a new boolexpr EVERY TIME you call Add. And this is never reused. So different code being attached makes no difference, as it's still a new boolexpr.

No it isn't.
Blizzard has a little optimization for conditions because they are evaluated(no threads) so they don't need multiple instances of them.

//===========================================================================
scope Test initializer Init

//===========================================================================
private function Periodic takes nothing returns boolean
    return false
endfunction

//===========================================================================
private function Actions takes nothing returns nothing
    local boolexpr first = Condition(function Periodic)
    local boolexpr second = Condition(function Periodic)
    if first == second then
        call BJDebugMsg("same")
    else
        call BJDebugMsg("not-same")
    endif
endfunction

//===========================================================================
private function Init takes nothing returns nothing
    local trigger trig = CreateTrigger()
    call TriggerRegisterTimerEvent(trig, 1.0, false)
    call TriggerAddAction( trig, function Actions )
endfunction

endscope

Also like I said before(two times) absolute categories have no effect on relative ones,
thus overhead (if it is equal in both cases) cannot affect the percentage difference.

PS: (really)Proving to yourself should be the only proof that matters.

 

[Azlier]

In the function Add, there is usage of the And() native. Does that not create a new boolexpr every time?

 

[Cohadar]

In the function Add, there is usage of the And() native. Does that not create a new boolexpr every time?

It does, the And condition is always new, but the condition for user function inside it is not.

 

[Jesus4Lyf]

Cohadar,
Please follow this.
>Also like I said before(two times) absolute categories have no effect on relative ones,
>thus overhead (if it is equal in both cases) cannot affect the percentage difference.

Spoiler

Let's say KT2 takes (1 second / 684.2 loops/second) seconds to execute a loop of 100 instances of VERY light code --> 0.0015 seconds.
TT takes (1 second / 483 loops/second) seconds to execute the very same code --> 0.0021 seconds.

Changing the test from my initial test to yours did not change the number of instances running. Therefore, I say the overhead added was purely the time it took to execute the attached code, which should then be constant. KT2 goes to (1 second / 199 loops/second) which is 0.0050 seconds.
TT goes to (1 second / 181 loops/second) which is 0.0055 seconds.

Now, let's compare the difference in speed, to see if the overhead added was consistent within some reasonable margin of error.
KT2 --> 0.0050 - 0.0015 = 0.0035.
TT --> 0.0055 - 0.0021 = 0.034.

Oh look, they're practically identical (within ~3% of eachother).

What's my point? The max difference added then, according to what you said, could be about 3%.

And this nearly constant amount dilutes the percentage. It makes sense - if you attach code that reads and writes from gamecache 50 times for some reason, the overhead of the timer system diminishes by comparison to the time it takes to execute the code attached, yielding a much lower percentage difference between the two systems.

Anyway, this shows that "overhead (if it is equal in both cases)" does indeed "affect the percentage difference". In fact, it's gauranteed to.

If you disagree with this, feel free to state so, and we can simply agree to disagree. :thup:

>Proving to yourself should be the only proof that matters.

I try to back up everything I say. I'm trying to gain credibility, I suppose.

Looking forward to having this system approved again, some time.

 

[Hatebreeder]

Ok, so KT2 is faster than TT...
But how about it's safeness?
I mean, I as a "normal user" don't realy need Speed that only makes a small difference, thuss any difference at all... You need to be convincing me to use this system over Cohadars one. And, since I don't code as efficient as you, safty makes a great difference.

 

[Jesus4Lyf]

Understood. If you're considering using KT2 as a replacement for TT (as in use one period, that period being something like 0.03125 or 0.04) and concerned about safety... The only relevant restriction is from the cons list is: "The code passed into KT2 must call KT_GetData exactly once."

So TT's code...

TT_Start(userFunc, struct)
// and
TT_GetData()

becomes

KT_Add(userFunc, struct, 0.03125) // As long as the period is divisible by 0.00125
// and
KT_GetData()

And you check that your userFuncs do in fact use GetData exactly once (which, most likely, they already do).

That is the only stability difference, and it's obviously not a very scary one.

If you're worried you'll accidentally type KT_GetData() again or something, stay with TT.

From next version, I intend to make KT2 spit errors about anything else that's wrong anyway (ie. the period not being divisible by 0.00125).

Nothing to stop you trying and seeing for yourself.

 

[Cohadar]

If you disagree with this, feel free to state so, and we can simply agree to disagree. :thup:

Why should we agree/disagree when we can test it.
If KT2 percentage drop is really from overhead and not from the fact there are multiple instances being run than you could comment out the lightning effect part from my tests and test again to see if percentage stays the same.

private struct Data
    integer ticks
    //lightning light
    //real x
    //real y
    
    static method create takes nothing returns Data
        local Data data = Data.allocate()
        set data.ticks = R2I(10.0 / 0.04) // 10 seconds or 250 ticks
        //set data.x = GetRandomReal(-1024.0 , 1024.0)
        //set data.y = GetRandomReal(-1024.0 , 1024.0)
        //set data.light = AddLightning("CLPB", true, 0, 0, data.x, data.y)
        return data
    endmethod
    
    method Tick takes nothing returns boolean
        //set .x = .x + GetRandomReal(-64.0 , 64.0)
        //set .y = .y + GetRandomReal(-64.0 , 64.0)
        //call MoveLightning(.light, false, 0, 0, .x, .y)
        set .ticks = .ticks - 1
        return .ticks <= 0
    endmethod
    
    method onDestroy takes nothing returns nothing
        //call DestroyLightning(.light)
    endmethod
endstruct

 

[emjlr3]

what he Jesus says makes sense

if 95% of execution time is not system dependant, even if there is a 20% difference in the remaining 5%, it still only 1% of a difference, in the grand scheme of things

a much better representation of real life usage speed differences - rather, what is actually important

 

[Jesus4Lyf]

Completed the requested test.

KT2 - 404 loops/sec.
TT - 326 loops/sec.

KT2 being 24% faster.

So your previous test did indeed dulite the percentage.

Now, I'd like to be honest... I'm tired of bench testing. Let's move on, and say we've exhaustedly benchmarked KT2 and found that yeah, it's fast. Very fast. :shades:

On to issues like Hatebreeder's. I think in the next version I'll finally implement error checking on the period.

I was also thinking of implementing a margin of error constant (of about 0.2 by default). This would remove the inaccuracy of the first period procuring by making it expire as many times as it needs to along the way to increase the accuracy. In theory, this executes more often, which is less efficient. In practise, this doesn't matter because all it does is add an invisibly small overhead to the map. KT2 will then be able to replace any generic timer system, such as TU/ABCT, and still be more efficient in practise. I can implement this without changing the interface, and everything will be backwards compatible. Thoughts?

PS. emjlr3: "if 95% of execution time is not system dependant" According to our tests, 50% is a more reasonable estimate, here. Hence a 10% difference over all, which is pleasant to have. ^_^ But you're right, still nothing major. So on to more interesting topics! USABILITY!

 

[Cohadar]

Completed the requested test.

KT2 - 404 loops/sec.
TT - 326 loops/sec.

KT2 being 24% faster.

So your previous test did indeed dulite the percentage.

Ok guess I was wrong about that one.
Not that it matters but 326/404 is 20.4%
You are starting to see numbers in your favor now
Just joking...

 

[emjlr3]

50% is a more reasonable estimate

should be dependant upon the amount of non-system code

in your test all you did was move a lightning effect - which is quite menial compared to most spells

 

[Sim]

Having a way to use a single wait without the hasardeous first-period wait would be very optimal.

Do you think it is possible jesus?

 

[Jesus4Lyf]

Yeah. I'm on it.

Actually, it was keeping me awake last night (sounds odd XD). I can reduce the first period inaccuracy to 0.1 seconds max. I came up with some clever idea to hook it into KT2.

I'm thinking for periods greater than 0.5 seconds, have KT2 automatically attach it differently. I can make this number a constant. If it is greater than 0.5 seconds, it will attach it to a ridiculously hardcoded timer (tm ) that will count it down, then fire the code. This timer will run on 0.1 seconds by default (also a constant). Therefore, people will be able to set the accuracy of KT2 manually. Furthermore, add a KT_AddImprecise version of KT_Add for people who want to force KT2 to use the multi-instancing. And prehaps a KT_AddPrecise.

Then KT2 can be a substitute for any timer system, apply it's crazy efficiency for low periods, and apply it's awesome interface for high periods (and still run efficiently, but not as much so - no this can't be benchmarked, I can only assure you that I can make the speed irrelevant by breaking up the points at which things expire, and hence it will be very efficient anyway). This will shave another 2 cons off the system.

In fact, all that will be left is call KT_GetData() exactly once, and period must be divisible by 0.00125. (And actually, technically those will only apply to periods below 0.5 or whatever that constant is set to, or things added through AddImprecise generally.)

Not only is it possible, I've planned for it. :thup:

 

[Hatebreeder]

And you check that your userFuncs do in fact use GetData exactly once (which, most likely, they already do).

That is the only stability difference, and it's obviously not a very scary one.

If you're worried you'll accidentally type KT_GetData() again or something, stay with TT.

From next version, I intend to make KT2 spit errors about anything else that's wrong anyway (ie. the period not being divisible by 0.00125).

Nothing to stop you trying and seeing for yourself.

So, I can't pass on Data from one function to a timer, in which I pass on the same Data to a timer from the previous timer? (Obviously, no one uses GetData() two times in a timer... That would be stupid But meh, thanks for pointing that out xD)
About the Debug.... It's about time

 

[Cohadar]

Personally I think it would do you good to make some spells.
It would give you some time off this thread. (no offense intended)