The Ultimate Question of Programming, Refactoring, and Everything - by Andrey Karpov
-
Of course not, this is for other people. :-D
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
Wait a dang-blasted minute! From your perspective, I am part of the set of "other people"!
I wanna be a eunuchs developer! Pass me a bread knife!
-
Wait a dang-blasted minute! From your perspective, I am part of the set of "other people"!
I wanna be a eunuchs developer! Pass me a bread knife!
-
Oh, don't worry about me; I'll just take the mick. It's the fact that JSOP is also part of that set that you need to worry about.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Oh, don't worry about me; I'll just take the mick. It's the fact that JSOP is also part of that set that you need to worry about.
I wanna be a eunuchs developer! Pass me a bread knife!
He and I are best buds, so I am good :-D
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
-
- The Ultimate Question of Programming, Refactoring, and Everything[^] Phenomenal write-up by Andrey Karpov!
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
I skimmed through the document and thoroughly read through part 1, and I can tell you from experience, there are situations(read cryptography and other time sensitive code sequences) where a manually unrolled loop is very much the advantage. Loops take time, the more loops you have to sort through the slower your program will run. Granted in the majority of cases it doesn't matter, but I guarantee that if you write a program that has to cycle through 6000+ loops, then in the same program unroll those loops as a series of separate functions, you will notice a significant speed boost. If it can be avoided, don't use them. Another speed increase is to use a fuzzy logic switch rather than a series of if statements, again for the same reason, if statements take longer to execute. Plus it forces you to pay more attention to what you are doing. Everything I skimmed through is really situation dependant.
-
I skimmed through the document and thoroughly read through part 1, and I can tell you from experience, there are situations(read cryptography and other time sensitive code sequences) where a manually unrolled loop is very much the advantage. Loops take time, the more loops you have to sort through the slower your program will run. Granted in the majority of cases it doesn't matter, but I guarantee that if you write a program that has to cycle through 6000+ loops, then in the same program unroll those loops as a series of separate functions, you will notice a significant speed boost. If it can be avoided, don't use them. Another speed increase is to use a fuzzy logic switch rather than a series of if statements, again for the same reason, if statements take longer to execute. Plus it forces you to pay more attention to what you are doing. Everything I skimmed through is really situation dependant.
I've sent Andrey a link to this thread, and I am sure he'll appreciate your feedback. Thank you.
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
-
- The Ultimate Question of Programming, Refactoring, and Everything[^] Phenomenal write-up by Andrey Karpov!
Regards, Nish
Website: www.voidnish.com Blog: voidnish.wordpress.com
Brilliant post. Excellent.
I may not last forever but the mess I leave behind certainly will.
-
I skimmed through the document and thoroughly read through part 1, and I can tell you from experience, there are situations(read cryptography and other time sensitive code sequences) where a manually unrolled loop is very much the advantage. Loops take time, the more loops you have to sort through the slower your program will run. Granted in the majority of cases it doesn't matter, but I guarantee that if you write a program that has to cycle through 6000+ loops, then in the same program unroll those loops as a series of separate functions, you will notice a significant speed boost. If it can be avoided, don't use them. Another speed increase is to use a fuzzy logic switch rather than a series of if statements, again for the same reason, if statements take longer to execute. Plus it forces you to pay more attention to what you are doing. Everything I skimmed through is really situation dependant.
Yeah - but as he noted, unroll the loop after your profiler has said "hey - this is a slow part" - not before. In other words, don't second-guess the compiler - don't "pre-optimize" code that doesn't need it. Get the steak on the grill, the sizzle will come later. This is, in fact, one of the early-days lessons from game development and demo-coding. Back then, compilers weren't as intelligent, and sometimes you needed to "help the compiler along" by unrolling loops, or adding a bit of hand-crafted inline-assembler to make things a tad faster. But you never did this on the first iteration of the code (or at least, you shouldn't have - I am sure many coders did, just like they do today). Instead, you would compile and run the code, and profile/log the speed of various sections, and anywhere it seemed like things were taking longer that they should have, you'd drill down and find the likely culprit, then try to optimize that section (loop-unroll, etc). Otherwise - without the profiling - you might optimize something that didn't need it, or worse (and this could happen, especially back then), your optimization might actually make things slower (perhaps because your "optimized code" is re-interpreted into something much worse object-code-wise than had you let the compiler do it job normally). So he isn't saying here not to unroll loops, but rather saying "unroll a loop after you have profiled the code - then profile the code with your unrolled loop, and compare the speed difference to make sure you haven't made things worse".
-
Very cool.
the problem is that the question will be malformed
-
Yeah - but as he noted, unroll the loop after your profiler has said "hey - this is a slow part" - not before. In other words, don't second-guess the compiler - don't "pre-optimize" code that doesn't need it. Get the steak on the grill, the sizzle will come later. This is, in fact, one of the early-days lessons from game development and demo-coding. Back then, compilers weren't as intelligent, and sometimes you needed to "help the compiler along" by unrolling loops, or adding a bit of hand-crafted inline-assembler to make things a tad faster. But you never did this on the first iteration of the code (or at least, you shouldn't have - I am sure many coders did, just like they do today). Instead, you would compile and run the code, and profile/log the speed of various sections, and anywhere it seemed like things were taking longer that they should have, you'd drill down and find the likely culprit, then try to optimize that section (loop-unroll, etc). Otherwise - without the profiling - you might optimize something that didn't need it, or worse (and this could happen, especially back then), your optimization might actually make things slower (perhaps because your "optimized code" is re-interpreted into something much worse object-code-wise than had you let the compiler do it job normally). So he isn't saying here not to unroll loops, but rather saying "unroll a loop after you have profiled the code - then profile the code with your unrolled loop, and compare the speed difference to make sure you haven't made things worse".
Loops, if statements, and equating to exact values are always the slow down point. When you are dealing with a code base where speed of execution is vital, you shouldn't even be considering using any of these, not even on a first iteration. There are some, admittedly rather niche circumstances where it's just a bottleneck to use either of those. If you have ever played around with cryptography, you'd get in the habit of just plain not using loops where they are not needed, if statements, or equating to exact values are also considered bad coding practice and should be avoided. Quite a few cryptographic sequences will for example only use a loop to retrieve raw data until the end of the file is reached, everything else is a bunch of sequentially executed linear functions. There are also not many, actually I can't think of any that use if statements, or don't use fuzzy logic to avoid the bottle neck checking the condition twice as an if statement does or of trying to equate to an exact value. I find it interesting that C++, the language of choice of most cryptographers, does not support fuzzy logic. A switch that says do this when the integer value is less than 1 is much faster than a switch that says do this if the value is exactly 0 because of the extra checks involved to ensure it is an exact value. They are both integer values so from a logic standpoint it doesn't actually matter if you are using fuzzy logic or exact logic, but from a speed of execution perspective, it matters a lot. They also will always use and re-use a bunch of global variables as well, purely for the fact that creating and initializing a variable locally then releasing the memory location back to the pool takes time, again if you are running sequences 6000+ times it's going to be a big drain to a time sensitive code base. Literally the only occasions you will find local variables are for function specific counters, and they are always statically declared for that very specific reason. Playing around with crypto code also teaches you how vital it is to keep every line of code as close to atomic as possible and keep the cache full. Cryptography not only requires a good knowledge of the language you are using, but also how compilers and even the hardware operate. There is a good reason why AES takes 18 clock cycles per byte and can encipher roughly 11 megabits/s on a 200MHz CPU and up to 700 megabits/s on a high end AMD APU. It's because all possible bottlenecks have been removed. Of course, none of that actually matters if you are an a