C++ [1.3 ]this attack speed formula can cause bad performace?

[roriscrave]

How i talked, this new formula of attack speed can cause bad performance (if for example have a lot of players online )?
When player have more fist skill, he hit more fast, so i changed

it

        uint32_t getAttackSpeed() const {
            return vocation->getAttackSpeed();
        }

to it:

        uint32_t getAttackSpeed() const {
            int32_t SpeedAttack;
            SpeedAttack = vocation->getAttackSpeed() - (getSkillLevel(SKILL_FIST) * 10);
                if (SpeedAttack < 200) {
                    return 200;
                } else {
                    return (uint32_t) SpeedAttack;
                }
        }

I keep thinking that he will recalculate this formula all the time:

SpeedAttack = vocation->getAttackSpeed() - (getSkillLevel(SKILL_FIST) * 10);

is there another way "smarter" to do it? or not a big problem?

 

[Infernum]

Nope, there's literally no other way to do it anyways.

 

[roriscrave]

Nope, there's literally no other way to do it anyways.

and about a performace?

 

[Infernum]

That's what I meant with "Nope", it was an answer to "can cause bad performance".

 

[roriscrave]

That's what I meant with "Nope", it was an answer to "can cause bad performance".

and something like it, what u think?
wouldn't be calculating the formula all moment

SpeedAttack = getSkillLevel(SKILL_FIST);
if (SpeedAttack >= 100)
    return 600;
elseif (SpeedAttack >= 80)
    return 700;
elseif (SpeedAttack >= 60)
    return 800;
elseif (SpeedAttack >= 40)
    return 900;
elseif (SpeedAttack >= 20)
    return 1000;
..

 

[Infernum]

You seem to have very bad perspective on performance, C++ is one of the fastest languages out there. If you truly think a simple calculation that includes 2 operators can affect performance, we'd have a gigantic problem everywhere.

Either way you want is fine, the difference would literally never be seen.

 

[roriscrave]

You seem to have very bad perspective on performance, C++ is one of the fastest languages out there. If you truly think a simple calculation that includes 2 operators can affect performance, we'd have a gigantic problem everywhere.

Either way you want is fine, the difference would literally never be seen.

It's because when I had server online I reached 120% cpu with 70 players online.
now I'm always cautious
thx for answer

 

[Infernum]

internalGetSpectators is the heaviest function in the source and is constantly being used, and will make cpu skyrocket the more players you have on the server.
You can even see what's taking up most resources in your sources by using perf.

 

[roriscrave]

internalGetSpectators is the heaviest function in the source and is constantly being used, and will make cpu skyrocket the more players you have on the server.
You can even see what's taking up most resources in your sources by using perf.

yes, recently I installed, but my server is not online yet.
when online in some weeks/months will check this

 

[Ninja]

There is nothing wrong with the formula itself but it's totally possible to throttle the scheduler with many players using low interval attacks (although it depends on whether you have classicAttackSpeed enabled or not).

 

[fabian766]

Since in my opinion the question is not answered yet then I'll try to answer it.
Your formula should compile to something like:

imul edx, edx, -10
add edx, eax
mov eax, 200
cmp edx, 200
cmovge eax, edx

Going by:

https://www.agner.org/optimize/instruction_tables.pdf

imul is about 2-4 cycles, add,mov,cmp,cmov is about 0.5-1 cycles so depending on how well it'll get pipelined you'll get 4-8 cycles cost for the arithmetic instructions do you think it is much?(in my opinion it is nothing)
You'll probably get much higher cost by fetching variables like "vocation->getAttackSpeed()" or "getSkillLevel(SKILL_FIST)" because they likely will not be in l3-l2-l1 cache so it need to get it from ram which usually is about 100ns.
More bottleneck probably will be caused by "Player::doAttacking".
About bottleneck of TFS the most heaviest functions are:
"IOLoginData::loadPlayer"
"IOLoginData::savePlayer"
"Map::getSpectatorsInternal"
"Map::getPathMatching"
but you should use "perf" to check what really bottlenecking your server.

 

[roriscrave]

There is nothing wrong with the formula itself but it's totally possible to throttle the scheduler with many players using low interval attacks (although it depends on whether you have classicAttackSpeed enabled or not).

i have classicAttackSpeed 'disabled', what u think?

classicEquipmentSlots = true
classicAttackSpeed = false

Since in my opinion the question is not answered yet then I'll try to answer it.
Your formula should compile to something like:

imul edx, edx, -10
add edx, eax
mov eax, 200
cmp edx, 200
cmovge eax, edx

Going by:

https://www.agner.org/optimize/instruction_tables.pdf

imul is about 2-4 cycles, add,mov,cmp,cmov is about 0.5-1 cycles so depending on how well it'll get pipelined you'll get 4-8 cycles cost for the arithmetic instructions do you think it is much?(in my opinion it is nothing)
You'll probably get much higher cost by fetching variables like "vocation->getAttackSpeed()" or "getSkillLevel(SKILL_FIST)" because they likely will not be in l3-l2-l1 cache so it need to get it from ram which usually is about 100ns.
More bottleneck probably will be caused by "Player::doAttacking".
About bottleneck of TFS the most heaviest functions are:
"IOLoginData::loadPlayer"
"IOLoginData::savePlayer"
"Map::getSpectatorsInternal"
"Map::getPathMatching"
but you should use "perf" to check what really bottlenecking your server.

i can change vocation->getAttackSpeed() to 1200, because all vocations have this attack speed. Could it be a little more efficient than fetching a moment?

 

[Infernum]

Yes, using a constant will be faster. But we're literally talking about billionths of a second, which you'll never see. Why are you still hellbent on improving a few billionths of a second?
There was a reason I didn't go into the assembly & number of CPU cycles it would take, because as he said it himself, it's literally irrelevant in this case unless you're using extremely high attack speed like @Ninja said.

 

[roriscrave]

Yes, using a constant will be faster. But we're literally talking about billionths of a second, which you'll never see. Why are you still hellbent on improving a few billionths of a second?
There was a reason I didn't go into the assembly & number of CPU cycles it would take, because as he said it himself, it's literally irrelevant in this case unless you're using extremely high attack speed like @Ninja said.

thx all for answer, i'll use limit = '500 ms' i think ill dont get trouble