System Key Timers 2

[emjlr3]

its my understanding that the inefficiency lies within the timer expiration (such that, the more times the timer expires, the less efficient) - this is completely non-dependant on the number of timers

however - if you have 1 spell with a timer stack, and 1 spell with a timer per instance, each running 5 at a time, sthe first spell will be more efficient because there are less timer expirations, now because there are less timers

as for Cohadars theory (unproven?) I didn't really see you benchmark that, aside from the last test which only mentioned KT1 and KT2 (aside from "After 4-5 different spells, the number of spells becomes completely irrelevant to these systems. " - which made no sense to me)

lets consider an AoS for a second, max of 12 players

assume 1 hero/player, 5 spells/hero - if we were to assume that at any given time, 25% of these heroes could have 2 spells active with effects - that would give is 12*.25*2 = 6

granted each spell could require more then one timer for its effects (if done on the timer/instance basis) - but lets assume that is not the case

therefore, at any given time there are 6 spell instances active - most often then not ppl do not allow multiple of heroes, thus a timer stack would be uneeded (since only 1 instance would ever be active - unless for some goofy reason the effects last longer then the spell cd)

I think its safe to assume that, unless you know your map is using mutiples of heroes, or there is the possibility for 3+ instances of your spells at a given time, the easiest way, and most efficient, is just generic timer attachment

 

[Jesus4Lyf]

Fineeeee. Here's the results.

>its my understanding that the inefficiency lies within the timer expiration (such that, the more times the timer expires, the less efficient) - this is completely non-dependant on the number of timers

Not as much as thought.

>"After 4-5 different spells, the number of spells becomes completely irrelevant to these systems. " - which made no sense to me

Yeah, well. Check the results. KT2 climbs a bit, the other systems cap out. Keep in mind the margins of error I've suggested. They clearly seem to flat-line. By the way, I cut out the results before 5 different spells, because they're both irrelevant and unreliable.

>assume 1 hero/player, 5 spells/hero - if we were to assume that at any given time, 25% of these heroes could have 2 spells active with effects - that would give is 12*.25*2 = 6

Here's where you get silly debates. In an AoS map, there are often big battles where every player suddenly casts all their spells. Let's say half are triggered, and only 75% of players are in the battle. That makes 12*0.75*2=18.

Alternatively, let's say one spell is sharl, and one spell is AoE and targets 5 units. That's going to be about 20 timed effects by itself.

I think nothing is safe to assume. In fact, I think this is rather badly over-simplifying the problem. I say as for efficiency, it only matters when you have many instances running, and in which case KT2 is the fastest (see results). But who even cares about that, it's got an awesome interface. You don't have to declare a local timer, and get a timer, and attach to a timer, and start a timer... You just call "Add". And you know there's some magic under the bonnet that will kill the lag that could be caused more than other systems.

>the easiest way, and most efficient, is just generic timer attachment

So I disagree that it's the easiest, and I disagree that it's the most efficient. RAWRRRR I DISAGREE. :nuts:

No, it really does come down to personal preference. As far as my personal opinion goes, KT2 is the most efficient and has the best interface in my eyes.
Remember, my tests were taken against TU Red, but in reality you'd probably use something "much" slower anyway for timer attachment.

"Timer utils red was a big disappointment, I expected it to be faster considering how unsafe it is." - Cohadar.

KT2 does not carry those issues either.

 

[Jesus4Lyf]

Bump.

My latest tests are currently showing (and may change, but here's the raw news):

• Next version is looking at a 23% efficiency gain without any modifications to the user interface.
• KT2 will be faster than Rapid Timers by 4%.
• It's clocking at 39,400 executions per second on my bench testing computer.

The latest version still currently has two bugs, which I'm working on. Hoping to release within the next two days, but we will see.

Couldn't help it. Had to share my excitement.

Edit:
Proof of concept/prototype version release.
Need to do more research on boolexprs and see what leaks and how to stop it.
This is not a stable, official release, so don't chuck it into a real map. This is just for the curious and those who can help me with boolexprs. Documentation hasn't been updated, although updates will be minor.
The only known problem is that boolexprs may leak, pending further research.
-- Code removed, stable Version 1.5 released. --
Check it out, Cohadar! Gonna use this, too?
It actually runs faster than Rapid Timers. Clocked it at about 2.5% faster for 100 instances.

Edit:
Actually, you probably can't. Backwards compatability. This does add one more restriction - GetData can only be called once, and must be called exactly once...

Edit:
Released Version 1.5. Here's the new stats for 100 instances. If you're wondering about TT in comparison, consider it (at the time of this release) to be the same speed as Version 1.3 of KT2. This is one sitting of bench tests:

Rapid Timers - 37,800 executions per second.
Version 1.3 of KT2 - 31,700 executions per second.
Version 1.5 of KT2 - 38,600 executions per second.

So KT2 is, with this release, 22% faster than TT and the previous release of KT2, and 2% faster than Rapid Timers, which was actually previously faster than KT2.

This is, hence, at the time of this post, the fastest timer system in existance. And if you consider only multi-period timer systems, this is the fastest by a -lot-.

Furthermore, this comes with no penalty to the user interface, but there is a slight chance of incompatability for people who have been using the system already... From now on, code attached to KT2 must call KT_GetData exactly once, even if you don't attach data (in which case just include "call KT_GetData" somewhere in your code. (All KT2 code I've seen so far already does this.) This is the total price of the 22% efficiency gain.

Over and out!

 

[Tyrande_ma3x]

Was gonna ask this some time ago but forgot - is this system resistant to leaks? And if yes, does it have some limit or is it the same as ABC?

 

[Romek]

> Was gonna ask this some time ago but forgot - is this system resistant to leaks? And if yes, does it have some limit or is it the same as ABC?
These systems (TT, KT) don't use H2I, hashing or anything of the sort. So leaks won't effect the system itself. Naturally, they'll slow things down anyway.

 

[Tyrande_ma3x]

Never really understood how TT/KT worked... Basically, don't they store data in an integer array? If yes then, well, wasn't there a limitation to vJass arrays (500,000) and if it goes over wouldn't the system break?

 

[Romek]

> If yes then, well, wasn't there a limitation to vJass arrays (500,000) and if it goes over wouldn't the system break?
That's if you have 50,000 instances.
I think TT doesn't use oversized arrays, as 8191 instances is very high anyway.

And these systems work in exactly the same way as a static timer per spell does.

 

[Tyrande_ma3x]

Right, thanks for clarifying.

As for KT, good job on improving the speed. I never thought that this could be faster than H2I() and substraction...

 

[Romek]

> I never thought that this could be faster than H2I() and substraction...
I don't really think the speeds are comparable.
TT and KT don't support low frequencies at all. The method just completely fails.
H2I + Subtraction on the other hand, can be used for any timer with any interval. Though you always use more than one timer in that case.

 

[Cohadar]

TT and KT don't support low frequencies at all.

orly?

function TT_StartEx takes code userFunc, integer data, real period returns nothing

 

[Romek]

I mean the single-timer side of it, the part he was asking about.
Usually, when I say TT, I mean the old TT stuff only. The single-timer part.

ABCT works like any other timer system.

 

[Jesus4Lyf]

Yeah, KT2 and TT (old) are designed for low periods (high frequency). But instead of saying the method completely fails, you should say that the first procurement is at an unreliable time. That's the only thing that fails. This is because you're attaching to a timer that may be already running, and hence may already be half way through a period, meaning what you attach will fire when the rest of that period expires (in other words, earlier than a full period)! (Remember it's attaching multiple things to one timer.) Thereafter it will fire perfectly fine. I think that's a good explanation.

If that is an issue, use some other system for when it's an issue. If it's not an issue, KT2 will end up being the fastest and probably easiest to use system. It acomplishes both.

And when you say faster than raw H2I attaching, it's not only faster, but significantly faster (about 23% at 100 instances on one period, but I expect it'd be at least 15% at 10 instances, pending bench tests).

The only reason not to compare the speeds is what Romek said, which is also explained in detail above. I say, make your own decisions, or read the documentation on the second post of this thread for more details (even though the bench tests on it are now out of date for KT2).

PS. There is no longer a significant efficiency gain in using struct/stack loops. In fact, I believe KT2 is faster for spells and timed effects until they go over 2 instances. And this would include most hero abilities and such. Yes, faster than static struct/stack (including KT1). Of course, there's situations where struct/stack has a purpose... Like when you know you're going to have 50 instances, such as a simple physics engine. The efficiency gain for that would be about 50%.

 

[Romek]

Yeah, KT2 and TT (old) are designed for low periods (high frequency). But instead of saying the method completely fails, you should say that the first procurement is at an unreliable time. That's the only thing that fails. This is because you're attaching to a timer that may be already running, and hence may already be half way through a period, meaning what you attach will fire when the rest of that period expires (in other words, earlier than a full period)! (Remember it's attaching multiple things to one timer.) Thereafter it will fire perfectly fine. I think that's a good explanation.

Really, trying to redeem this system for low frequencies is pointless.
This method simply does not work for low frequencies. Simple as that.
TT (old) and KT are only for periods lower than 1 second. Otherwise you'll get horrible results.

If you want to use low frequencies, use either TT_Ex or some other attachment system such as TimerUtils.

 

[Jesus4Lyf]

Lower than 1 second is a much better figure than the 0.1 seconds some keep repeating (although I've said 0.1 in the documentation). I do use this system for period of 1.0 seconds for AI.

I have no need to redeem it for higher periods. I'd rather let people know why it's not redeemable for periods greater than that.

Vexorian insists it doesn't work at all. Vexorian also suggests I could've attached two conditions instead of using the boolexpr And native, and he thinks that I did that for a speed advantage. He also says that using KT2 in ways the documentation explicitly says not to is valid grounds for saying it doesn't work, which is the equivalent of me using TU Red for attaching to a timer made using CreateTimer() instead of NewTimer(). :thdown:

Read the 4 "cons" listed at the top of the system, follow them, and I assure you all these arguments are utterly irrelevant.

And here they are, for the latest version at the time of this post:

• The code passed into KT2 must call KT_GetData exactly once.
• Periods are only be taken to an accuracy of 0.00125 seconds, not 0.007 for example.
• Period must be below 10.24 seconds.
• The first procurement of an instance is at a random time between 0.0 seconds and the period. (Be aware of it if using periods larger than 0.100 seconds.)

Use TU or ABCT for things where any of these points would be troublesome. That is it.

Cheers.

 

[wraithseeker]

Ehh? Is it just me or the way you name the functions to call exactly the same as TT? Only the name was changed to KT aka Key Timers.

 

[Jesus4Lyf]

XD You're a year late for that discussion.

>Ehh? Is it just me or the way you name the functions to call exactly the same as TT?

Yep. Well, similar. You specify a period in KT2.

>Only the name was changed to KT aka Key Timers.

Lol, KT2 is much faster than TT at the time of this post, and allows the bonus of period specification. (The code is quite different, internally!)

I'm glad you think KT2's interface is as nice as TT's. I aspire to having them be practically the "same" to the user, except for the advantages of KT2.

 

[Cohadar]

Lol, KT2 is much faster than TT at the time of this post

O really? How much exactly?

 

[Jesus4Lyf]

For you, Cohadar...

Another sitting of bench tests.
Margins of error are about 300.
Results are as follows for 100 instances.

KT2 Version 1.5 - 38,600 executions per second.
TT Version 4.0 - 31,500 executions per second.
TU Red - 30,600 executions per second.

So for 100 instances...
KT2 clocked at 22.5% faster than TT.
KT2 clocked at 26% faster than TU Red.

Results are as follows for 5 instances (about the lowest amount I find my tests are reliable for).

KT Version 1.5 - 30,300 executions per second.
TT Version 4.0 - 28,700 executions per second.
TU Red - 30,300 executions per second.

So for 5 instances...
KT and TU Red tied, clocked at 5.5% faster than TT.

So I can't get KT2 to clock slower than TU Red anymore at all, and it's definitely faster than TT (obviously the new TT StartEx stuff is gonna be slower than TU Red, and not worth bench testing).



Dunno if you wanna grab that implementation of mine for TT. It won't be fully backwards compatible. And I suppose it's slightly subject to user obedience (calling GetData exactly once).

>O really? How much exactly?

Dunno.
Lol.

PS. My bench testing method is still the same as the method used in my write-up on the second post of this thread, in case anyone is wondering how these are done. If anyone knows a different method, I'd love to hear some results.

 

[Cohadar]

I don't see how that improvement is even theoretically possible.
Your little boolexpr thingy does not add any speed boost.

So I can only presume you tested some "special cases"

 

[Jesus4Lyf]

I don't see how that improvement is even theoretically possible.

May I frame that?

"I don't see how that improvement is even theoretically possible." - Cohadar. :thup:

Ok, well, I guess I better explain. Even though I talked about how I did it in the TT thread. o.o

The And boolexpr thing doesn't add efficiency (as you said, and it seems Vex was misguided enough to assume it did). However, it makes it possible to add efficiency...

I have attached all code to one trigger per period, instead of one trigger per piece of code attached. This means only one TriggerEvaluate per procurement of a period. :nuts: Kind of a O(1) complexity loop (kind of).

So nothing shifty with my bench testing. KT2 is that fast. Faster than Rapid Timers even, because I coded it in a more efficient fashion - less overhead.

Read code for more details.