Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bloop_bleep]

Depends on what you're doing in the loop. If it's like multiple floating point multiplies taking around 25 cycles then relative to that the register increment, compare, and correctly predicted branch that take about 1 or 2 cycles would be rather quick.

[Reelya]

It's really not that, which is my point. It's the number of iterations you run per frame which matters. If you do 1 million things per frame, and you remove the iterator overhead, then it doesn't matter whether those things had 1 instruction or 10 instructions in them, the saving is the same.

EDIT: Or, you could argue about things that aren't frame-limited, so let's do that. Say there's a quick loop, and you do it a million times, and it spends 20 seconds dealing with the loop counter / tests and 1 minute dealing with the 'guts', vs a slow loop which you also do 1 million times, and it spends 20 seconds dealing with the loop and 10 minutes dealing with the guts. The saving from unrolling the loop in both cases is the same: 20 seconds sheared off the task. The same amount of time saved by doing the optimization. So, if you had a 'tight loop' and a 'slow loop' then it wouldn't necessarily make any more sense to unroll the tight loop if the slow loop had more iterations going on.

The point is that X milliseconds is still the same percentage of a frame assuming you're working to a set frame rate target, so the low hanging fruit is always the iterator with the most number of loops regardless of how 'slow' it is.

[bloop_bleep]

The absolute saving. But the relative saving is smaller. I.e. it would be lower on your optimization priority list and would be less likely to push you to match your requirement.

[bloop_bleep]

.

[Reelya]

The absolute saving. But the relative saving is smaller. I.e. it would be lower on your optimization priority list and would be less likely to push you to match your requirement.

I edited to explain why that's not true.

If you loop a slow thing 1 million times and a fast thing 500,000 times, then the slow thing is still where you want to do that optimization, because there is an absolutely larger number of loop instructions going on. So saying to optimize the fast thing because "relatively" it's sped up more is a false economy, because in absolute terms, this had less effect on how fast your entire program was.

So there's no actual tension between relative and absolute savings here: which ever optimization has the most absolute improvement on the program's speed is also the one that just happens to have the most relative improvement, when looked at holistically.

Or, in percentage terms, if you say "we can save 10% on this part's speed, but 50% on this other part, so let's do this other part" is misleading, if the first part is 10 times slower to start with, so 10% of that is actually more in real terms.

[Putnam]

"Relative saving" is never a term I've heard. You optimize what takes the most time no matter what, something that's fast-enough doesn't need to be optimized even if it could be faster. The absolute gain's the only one that matters.

[bloop_bleep]

What I meant was if you had one thing running for 1% of the time and the other thing running for 99% of the time, and you found a way to shave off 20 seconds from the thing taking 1% of the time, great. But wouldn't you be more effective and efficient if you were trying to optimize the 99% thing first? Maybe you can shave an hour off the runtime there. Whatever you do in the 1% section is multiplied by 1/100 compared to 99/100 in the 99% section. It makes more sense to put more effort in the 99% section. Loop unrolling seems like late-stage finicky micro-optimization to me. It shouldn't be the first thing you reach for.

[Naturegirl1999]

Does all the optimization stuff apply to every coding language or just some? If only some, which ones?

[MrRoboto75]

Does all the optimization stuff apply to every coding language or just some? If only some, which ones?

To a certain extent, yeah.  Your program takes up space in physical and temporary memory, and the hardware takes time to do what you tell it to.

Generally, the closer the language is towards low-level, direct hardware interaction, the more control over exactly how the computer does things, and more ways you could make it faster or more efficient.  Higher level languages trade that control for more readability on the human side of things.

[wierd]

It would apply to any programming language that uses loops, AND, which as a compiler that does not produce machine code that reinterprets the source into a more compact structure anyway.

(Some compiler options have the potential to mangle attempts at loop unrolling, for instance.)


It's functionally the difference between this:

Code: [Select]


DoThisThing=0

For DoThisThing 1 to 25
Call DoTheThing()
Next


and

Code: [Select]


Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()
Call DoTheThing()


The second one takes a significantly larger amount of memory, because it has unrolled the loop.  However, it has zero loop structure, and thus frees up 25 absolute evaluations and 25 absolute counter value changes.

If you fire off that code 100 times every second, you are talking 5000 operations saved by unrolling, in absolute terms.   However, if the data used by DoTheThing() has to come from the memory bus each and every time, and cannot be cached, because the size of the program chain has exhausted the space in the CPU, the gains are totally lost, because entire instruction cycle windows are wasted waiting for DoTheThing() to complete.  It's even worse if DoTheThing() has to fetch something from virtual memory. (which can well happen, if basically every program in the computer has had its loops unrolled, all seeking the same performance increases.)


You need to be more aware of the limitations of the system you are running on.


Getting developers to comprehend that not everyone trades out their computer every 2 years like they do (because waiting on the compiler is an arduous task, that their time is better spent doing things elsewhere), and thus the real-world environment their code will be running in is not the bleeding cutting edge they are always using (and where their code runs fabulously!), further gets them in a pissy mood when you bring it up.

The maxims I always hear are "CPU is cheap. Ram is Cheap."  Or, in other words, "You should have a 24 core threadripper, and 50gb of RAM, like I do."

[Egan_BW]

(because waiting on the compiler is an arduous task, that their time is better spent doing things elsewhere)

[Reelya]

What I meant was if you had one thing running for 1% of the time and the other thing running for 99% of the time, and you found a way to shave off 20 seconds from the thing taking 1% of the time, great. But wouldn't you be more effective and efficient if you were trying to optimize the 99% thing first? Maybe you can shave an hour off the runtime there. Whatever you do in the 1% section is multiplied by 1/100 compared to 99/100 in the 99% section. It makes more sense to put more effort in the 99% section. Loop unrolling seems like late-stage finicky micro-optimization to me. It shouldn't be the first thing you reach for.

But that's not the same as saying that you shave off the tight/fast loops vs the long/slow loops, which is what you actually said.

Anyway on the basis of what you just said, you'd focus on the slow loop first anyway, since this is likely taking a lot more time than some speedy loop somewhere else. It wouldn't matter that you're only shaving 1% off that loop, because it's slow, so 1% is more in absolute terms than say, 50% of a very small loop somewhere else.

Think about it this way, you have two loops, both run for 1 million iterations. One takes 10 milliseconds per iteration, the other takes 1 millisecond per iteration. When you run your profiler, the 10 millisecond one is going to stand out since the program is spending more time here. So in other words, your argument about prioritization implies you'd be looking at the slow loop anyway, even if you could theoretically scrape more time off the fast look through optimizing that. The strategy of profiling the program wouldn't highlight that fast loop.

[bloop_bleep]

Ok, I see. But in that case you would perhaps look at optimizing the thing inside the loop if it's lengthy enough before trying to unroll.

[Reelya]

Of course, but that's bringing unrelated points into this discussion of whether it's better to unroll fast loops or slow loops.

[Naturegirl1999]

Wouldn’t unrolling slow loops make things run even slower?

Code: [Select]

Unrolled
FillRed()
FillGreen()
FillBlue()
FillRed()
FillGreen()
FillBlue()
FillRed()
FillGreen()
FillBlue()

Rolled
FillRGB()x3
     FillRed()
     FillGreen()
     FillBlue
NextIf I’m getting this completely wrong please tell me