

Discussion: Aren't loops the only interesting code? - tech_junkie
http://www.futurechips.org/thoughts-for-researchers/loops-interesting-code-portions.html

======
pavpanchekha
Linkbait. "Aren't the teats the only interesting part of a cow?" Uhh, sure,
yes, you get the milk from that, I don't know if I'd define "interesting" that
way.

As for his actual argument. Depends on the application. If you run 20 lines of
code, no loops, for 2mil clients on one server, that 20 lines matters. If that
20 lines includes one line which requires a lock, maybe only that one line
matters. Maybe I analyze a graph structure (oh, the social web) and my loop is
a loop per say not not anything that can be easily optimized without knowing
the topology. The slow part of your loop can be the loop body. Or not --- it
can be the allocation/deallocation cost of data structures. Parallelism can be
fast --- or the concurrency weight can be crushing. I'm not saying that
parallelism isn't a huge win. I'm saying the question is invalid or trivial.

Point is, the generalization here isn't wrong; generalization here is wrong.

------
mechanical_fish
What code _isn't_ running in some sort of "loop"? As I have discovered when,
e.g., writing test build code, that function which "only runs once" actually
gets run several times per day, or several times per coder per day, or (when
you are debugging or testing new code) several dozen times per hour.

Because every function is potentially callable from within someone else's
loop, there is no such thing as a function that isn't part of a loop. There
are merely frequent loops and less- frequent loops; it's a question of degree.
Unless it's a function that really does never get run, in which case, yes,
nobody cares if your dead code is slow.

------
microarchitect
If you're compute bound and are trying to optimize for performance, then sure,
you only need to worry about loops.

One way to think about this is that if you need optimize something, it's only
because a particular task is taking at least a few seconds to execute. A few
seconds means a few billion instructions on a modern CPU. There aren't any
executables with billions of instructions of straight-line code so your code
surely has a loop (or a million loops).

However, as many others have pointed out, this CPU-centric view won't give any
insight into optimizing I/O bound applications.

------
kalleboo
Isn't that simplifying things a bit? Loops are hidden everywhere, just
concatenating a string is actually a loop even if there's no visible
for/where, but the best optimization for that isn't speeding up the loop, it's
removing the call completely.

~~~
schrototo
Right, and it's a simplification that doesn't even seem particularly useful.
There's a reason why we abstract things and look at them at a higher level.

------
phamilton
With unlimited resources, it's the code only executed once that becomes the
performance issue. Amdahl's law shows that you can't run faster than the
sequential sections.

------
ww520
My only advice is: run the profiler. You will often be surprised what're
causing the bottlenecks.

------
georgieporgie
_In fact, I can argue that any time we wait on a computer program to do
something useful, we are in fact waiting on a loop_

Plenty of things are bound by I/O. You might have to wait for a disk to spin
up, or a packet to get to the other side of the world and back. Indeed, the
CPU will, at some level, ultimately be running in a loop, but it's not a loop
in order to get anything done, it's just blocking.

