• Advertisement
Sign in to follow this  

What is a tight loop?

This topic is 1658 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was reading http://msdn.microsoft.com/en-us/library/ky8kkddw(v=vs.110).aspx in the "Reducing Transitions" section it mentioned about Tight Loops.

 

What exactly is a tight loop?

 

Am I correct to assume RenderLoop in SharpDX for example is a tight loop or is a tight loop something that executes repeated over and over but is quite small?

Share this post


Link to post
Share on other sites
Advertisement

A tight loop is a loop that loops many times and the loop body has few instructions. 

Share this post


Link to post
Share on other sites

A tight loop is a loop that loops many times and the loop body has few instructions. 

 

Thanks for the quick reply

 

Well that's what I thought but then I came across http://stackoverflow.com/questions/2212973/what-is-a-tight-loop on the accepted answer

 

 

(computing) Such a loop which heavily uses I/O or processing resources, failing to adequately share them with other programs running in the operating system.

 

It made me think of RenderLoop() in C# (SharpDX), wouldn't this make RenderLoop a tight loop?

 

See atm the situation im in is, I am using C# for everything in my graphics apps except math / physics calculations which is from a C++ library with C++/CLI marshalling, one way or another Update() calls these math / physics functions, if Update() is part of a tight loop (based on what I said above) wouldn't this mean I am doing it wrong as I am calling the interop methods within a tight loop, I mean eventually everything is called in Update() / Render() anyway as they are part of the RenderLoop so I wouldn't even know how to work around this

 

I hope I made sense here, I cant help but feeling I am doing things wrong or completely misunderstanding the SO answer, I would post code but its nothing more than me calling C++ methods in RenderLoop() in C#

 

Thanks in advance

Share this post


Link to post
Share on other sites

Tight loops are to do with performance, they don't necessarily have few instructions inside of it, they are however time critical to the application so you want to eliminate operations from them that can be dealt with elsewhere.

Share this post


Link to post
Share on other sites

if you're worried about performance, measure it.

 

measure the execution speed of your code comparing the code that calls the unmanaged methods with code that call managed methods that do the same calculations.

 

if you're so worried about performance that you care about tight loops, you should really consider if you want to pay the marshaling cost.

Share this post


Link to post
Share on other sites


wouldn't this mean I am doing it wrong?

Does it work?

 

For a game, nobody really cares if your system is sub-optimal. Nobody cares about the implementation details. Nobody cares that you chose one algorithm over another.  All that people care about is it looks good on their screen and plays well in their mind.

 

If they say "It looks like a game, and it is fun" they don't care which pathfinding algorithm you used, or if your particle systems rely on SOA or AOS layouts.  All they care about is that the end result looks good and feels good to them.

 

 

If it works for you and your app, then it is just fine.

 

Computers are really, really, really fast.  For the PC you've got about a half-billion cycles per frame. Feel free to use them.

Share this post


Link to post
Share on other sites

I feel I may have given the impression my concern was performance this isn't at all the case, it was truly more of a "am I doing it right?", I could probably get away with having Thread.Sleep(##) everywhere and still not notice speed differences. What really concerned me was calling native methods in C# but within a 'tight' loop, when I usually see rules, practices and principles I take notice of them, like not using macros in C++ for example. I probably should have made it obvious that my concern wasn't performance.

 

@ frob, I agree 100% with what you said, sadly this isn't a game or even game related and without going into too much detail this all will be looked at, I don't mind breaking some traditions, I just don't want to get in a habit of doing things bad now or wrong, like C++ macro's, where later I have to change, ofc it is understandable that this may inevitably happen at times.

 

Thanks for the responses regardless :)

Share this post


Link to post
Share on other sites



SiCrane, on 09 Aug 2013 - 09:26 AM, said:
A tight loop is a loop that loops many times and the loop body has few instructions. 
 
Thanks for the quick reply
 
Well that's what I thought but then I came across
 
Quote
 
(computing) Such a loop which heavily uses I/O or processing resources, failing to adequately share them with other programs running in the operating system.
 

 

as usual, the gamedev world, and the rest of the world are on different pages. 

 

in the gamdev world the first definition is correct, and speaks to the small size (tightness) and hence the speed of the loop. rasterization would be a typical place to find a tight loop, although one could be found anywhere fast iterations are required or occur naturally.

 

to the rest of the world, the second definition is the understood meaning, and speaks to the fact that the loop can be a resource hog while running.

 

the difference stems from two very different world views: games should be fast, vs software doesn't have to run fast and therefore should timeshare resources. 

 

many times the difference in world views between game development and other software development, movie making, storytelling, the manufacturing industry, business theory, etc are large. it tends to lead to a lot of confusion re: terminology, as well as some mis-application of inappropriate methodologies from outside the gamedev industry to game development.

Share this post


Link to post
Share on other sites


the difference stems from two very different world views: games should be fast, vs software doesn't have to run fast and therefore should timeshare resources.

I'm not sure I have heard that definition since preemptive multitasking became the norm...

 

A small loop that performs an I/O operation strikes me as the exact opposite of a "tight" loop. Pretty much by definition, your loop will spend most of your time blocked on I/O, which frees up the CPU for everyone else.

Share this post


Link to post
Share on other sites

I would say that the term 'tight loop' is rather colloquial really, there probably isn't a single widely recognised definition so I wouldn't worry too much about "the right thing" when it comes to such an informal concept.

 

For me a tight loop conjures up the idea that it's a high-frequency loop with a lot of looping to do, it might therefore consume a lot of CPU resource and take a while to complete. In a real-time application like a game that would usually make them time-critical (needs to be as fast as possible or it will end up being too slow otherwise) which tends lead to them being small.

 

Sometimes a tight loop is actually undesirable yet it would be the natural consequence of a naive implementation. For example, say you're processing messages off an event-queue; messages don't come through all the time. You could sit there spinning away in a (tight) loop checking for messages, but that will waste a lot of compute time; instead better to slacken off that loop with a sleep or wait.

Edited by dmatter

Share this post


Link to post
Share on other sites

Does it work?

For a game, nobody really cares if your system is sub-optimal. Nobody cares about the implementation details. Nobody cares that you chose one algorithm over another. All that people care about is it looks good on their screen and plays well in their mind.

If they say "It looks like a game, and it is fun" they don't care which pathfinding algorithm you used, or if your particle systems rely on SOA or AOS layouts. All they care about is that the end result looks good and feels good to them.


If it works for you and your app, then it is just fine.

Computers are really, really, really fast. For the PC you've got about a half-billion cycles per frame. Feel free to use them.

This negative attitude is detrimental to the goal of producing good technology especially when one asks for the "right way" to accomplish a task.

People do and should care about efficiency and correctness even if the component is invisible to the user. It transfers good practices to parts that are visible.

There are numerous examples of systems that "work" but have performance quirks because someone didn't care or thought the part would be invisible.

it is best to use technology correctly and efficiently because it only feels limitless in the moment. A fast but callously developed app on one device will be sluggish on another or even on the same device when other resource-hungry apps are active....

Seriously, please care.

Share this post


Link to post
Share on other sites

The tightest loop I saw (on x86) repeatedly executed the SBB instruction.

 

Wait for it...

 

IT WAS ALWAYS BORROWING!

 

(Sorry, I'll get my coat).

Edited by Paradigm Shifter

Share this post


Link to post
Share on other sites

This negative attitude is detrimental to the goal of producing good technology especially when one asks for the "right way" to accomplish a task.

The "right way" is typically highly subjective. Place 10 engineers in a room, and you'll get 10 different answers.
 

I was reading http://msdn.microsoft.com/en-us/library/ky8kkddw(v=vs.110).aspx in the "Reducing Transitions" section it mentioned about Tight Loops.

 
It this particular context, the author specifies what they mean: a loop that regularly calls across the managed/unmanaged boundary.
 
It is up to you to adequately define what "regularly" means in the context of your application. Call across that boundary a few hundred times per frame? No problem. A few million? It might start showing up in your profile trace (but you'll only know once you start profiling).

Share this post


Link to post
Share on other sites

This negative attitude...


It's a pragmatic attitude, not necessarily a negative one.

1. If the software we make doesn't make money, we eventually stop getting paid. Perfection in software does not necessarily lead to profitable software. Hence, we don't focus on perfection.

2. Any complex algorithm will have countless alternatives, some of which are more optimal than others. It takes time to investigate each alternative. We don't have infinite time to do this.


Remove the time and budget constraints, and I'm pretty sure everyone here would love to develop perfect software. I'm not advocating being lazy or writing code that doesn't even function correctly; That has the effect of burdening everyone else on your team with your broken code. That's not cool. Edited by Nypyren

Share this post


Link to post
Share on other sites

I recently found an example of a few bugs in my engine leading to endlessly allocating/freeing memory inside of a loop inside of my renderer (and in a few other places as well).

 

discovering and fixing them (in one case, by half-assedly moving it to a "pool", such that it would instead just continuously grab and return things to a linked list, rather than doing a full allocation/free cycle), at the time, led to a pretty much immediate 10-15 fps jump in the framerate.

 

 

this was then followed by spending around a week optimizing my stuff for "usable-framerates on a laptop with crappy 'Intel GMA' graphics hardware...".

if/when I get to fully re-integrating this with the version on my main PC, should lead to a bit of a speedup.

 

 

but, yeah, there is some possible disagreement over "how tight is a tight loop".

the general property is "the loop spins enough times for the performance of things inside the loop to be relevant".

 

but, this can vary though between a loop that spins maybe a few thousand or million times, and so a fairly major operation (500 or 1000 clock-cycles) may be relevant (such as in some parts of the rendering or game-logic), to one which spins maybe 100M or more times per second (such as in the core of a video codec), where the cost of an extraneous "if()" or the organization of a few arithmetic expressions may actually make a significant impact.

 

or such...

Edited by cr88192

Share this post


Link to post
Share on other sites

I typically think of a loop as being 'tight' based on the percentage of time spent on the loop overhead. A 'tight loop', in my mind, is a candidate for unrolling.

Share this post


Link to post
Share on other sites

I typically think of a loop as being 'tight' based on the percentage of time spent on the loop overhead. A 'tight loop', in my mind, is a candidate for unrolling.

 

yes.

 

as a video codec example:

it is very expensive to try to process pixels or coefficient values one-at-a-time, so often parts of the loops will be manually unrolled, such that rather than working on a single-pixel per loop iteration, we are working maybe on 4, 8, or 16 pixels at once. then the arithmetic may need some fiddling to avoid extra unnecessary calculations, if's avoided wherever possible, maybe SIMD operations are considered (but, OTOH, one then has to battle with memory often not being organized in a way ideally suited to the use of the SSE intrinsics), ...

 

actually, tight loops are also one of those cases where memory-access patterns and cache may start to become more obvious as well, like for example, taking 2 or 3 passes over some raw pixel data may end up costing considerably more than doing it in a single pass, if for no other reason than that for each pass the data goes out of cache and then has to be pulled in again for the next pass (sometimes even if potentially the single-pass version involves a little more complex arithmetic, ...), ...

 

so, sometimes one can end up with some fairly awful and hairy-looking loops as a result.

luckily, this sort of thing is relatively uncommon.

 

 

then, when dealing with writing an interpreter, or generating compiler output, a rather different set of tradeoffs may be involved (one learns to be wary of any sort of conditionals or difficult-to-predict jumps or branches...).

 

...

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement