Register    Login    Forum    Search    FAQ

Board index » Everything




Post new topic Reply to topic  [ 14 posts ]  Go to page Previous  1, 2
Author Message
 Post Posted: December 19th, 2017, 10:16 pm 
 

Joined: February 28th, 2013, 3:23 am
Posts: 2970
Location: Oklahoma, United States
My function names are usually descriptive verbs, Draw(), Update(), IsAlive(), GetPosition(), etc...( those are the only ones that come to mind atm ).
My class/struct names are usually descriptive nouns, Person, Cell, Board, Grid, etc... ( wow, I'm full of great ones <- sarcasm )
My variables are usually descriptive ... (i, j, k, x, y, z, position, velocity, acceleration, orientation, count or numElements or maxElements, isDead, etc...).

My point is, I try to make the names self documenting so I don't have to leave so many comments. If you enter a function called Calculate() or CalculateVelocity() which would you need to leave a comment for? Caclulate() would probably need a comment above the signature letting you and others know that is what the function does, calculates velocity. CalculateVelocity() wouldn't need any comments telling you or others what the function does. Inside the function it should be much the same.

Code:
Vec3 CalculateVelocity( const Vec3& CurrentPos, const Vec3& PreviousPos, float DeltaTime )
{
     // velocity is the change in position over the change in time ( deltaP / deltaT )
     const auto deltaPosition = CurrentPos - PreviousPos;
     const auto velocity = deltaPosition / DeltaTime;
     return velocity;
}

_________________
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com


Top 
 Profile  
Reply with quote  
 Post Posted: December 19th, 2017, 10:21 pm 
 

Joined: February 28th, 2013, 3:23 am
Posts: 2970
Location: Oklahoma, United States
sloppy short hand code means nothing to framerate, those var names end up as values and addresses to the CPU.

Const does provide a little speed boost, because it allows the compiler to make assumptions about what code to produce. For non-const variables, the compiler has to assume that the value has changed since the last time it came across that variable, so reacquire it from cache or memory. For const variables, it can assume that the value hasn't changed and just paste the value it got last time.

No I do not prefer non-optimized over readability...always. It sometimes helps optimizations by caching those variables instead of having to redo the calculations or making another function call. How optimized it is really depends on the compiler and how good at optimizing your code it is.

_________________
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com


Top 
 Profile  
Reply with quote  
 Post Posted: December 20th, 2017, 2:55 am 
Site Admin
User avatar

Joined: December 31st, 2011, 4:53 pm
Posts: 3538
Location: Japan
The little things you sometimes see people doing, trying to reduce the number of local variables they use, trying to write things in fewer statements, or even real dumb shit like just using short one letter variable names, these things either have zero performance impact, or impact so negligible it might as well be zero. Even stuff like fretting over indirection with pointers, virtual function calls, etc. are seldom worth the worry. Just wasting time creating a story in your head about how 'efficient' your code is and how 'close to the metal' you work.

The biggest gains are in optimization of the algorithm. Make sure you've done all you can there before moving down to lower level concerns. At the low level, cache utilization rules. It should be the first thing considered in most cases. After that, if you need speed you can try to parallelize things with vector and MT. You might be able to get boosts by tweaking branches, sometimes adding a branch can let the predictor do good work, sometimes removing one can safe you a lot of pipeline stalls.

_________________
Chili


Top 
 Profile  
Reply with quote  
 Post Posted: December 20th, 2017, 5:24 am 
 

Joined: February 28th, 2013, 3:23 am
Posts: 2970
Location: Oklahoma, United States
chili wrote:
You might be able to get boosts by tweaking branches, sometimes adding a branch can let the predictor do good work, sometimes removing one can safe you a lot of pipeline stalls.


Yeah, I remember a situation where I had thought about putting for loops in if/else if/else blocks instead of putting the branching inside the loops and the branches inside for loop in that situation was faster than loops inside branches

Code:
// This was faster for my situation
for()
{
    if()
    {
    }
    else if()
    {
    }
    else
    {
    }
}
than
if()
{
    for()
    {
    }
}
else if()
{
    for()
    {
    }
}
else
{
    for()
    {
    }
}

which really shocked me, since I figured one branch before loop was better.

_________________
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com


Top 
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
 
Post new topic Reply to topic  [ 14 posts ]  Go to page Previous  1, 2

Board index » Everything


 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
cron