IF-free codes
-
yes, readability is worse :) but superfluous IFs make code slower. Actually, it will be extremely helpful, if new compilers shall be able to generate such blocks of IFs. :-D
SarK0Y wrote:
superfluous IFs make code slower.
That isn't necessarily true. Modern processors use a variety of tricks that reduce the 'cost' of unused branches. One of the problems of 'computed conditional' logic is that you incur the cost for all cases, not just the unused branch. Your overall performance actually decreases.
Software Zen:
delete this;
-
Good Time to all, Amici(Friends). Here, i'd like to discuss how to reduce conditional branches in the code. 1st of the all, i would like to share some tricks. Their description is here. :-D ----------------------- Thanks in Advance for attention of Yours.
CP wrote:
The Weird and The Wonderful forum is a place to post Coding Horrors, Worst Practices
Congratulations, your contribution was spot-on! :cool:
-
Good Time to all, Amici(Friends). Here, i'd like to discuss how to reduce conditional branches in the code. 1st of the all, i would like to share some tricks. Their description is here. :-D ----------------------- Thanks in Advance for attention of Yours.
-
If you did that to my codebase I'd probably avoid working with you as much as possible. You can always throw hardware at code performance. You can't throw hardware at code readability.
-
yes, readability is worse :) but superfluous IFs make code slower. Actually, it will be extremely helpful, if new compilers shall be able to generate such blocks of IFs. :-D
Are you aware of the 90/10 law? 90% of the time is spent in 10% of the code, and only 10% of the time in the remaining 90% of the code. If you are attempting to optimize code in the 90% of execution time, great. Otherwise leave optimizing alone. Use macros with good names to do optimizations, and it will *hopefully* make your code clearer. If you were targeting code for the ARM cpu then eliminating branches is totally pointless because.. ARM cpu has conditional branching on almost every cpu instruction, but doesn't cost extra cpu time to fetch a separate branch instruction like on many CISC cpus.
-
Good Time to all, Amici(Friends). Here, i'd like to discuss how to reduce conditional branches in the code. 1st of the all, i would like to share some tricks. Their description is here. :-D ----------------------- Thanks in Advance for attention of Yours.
-
Good Time to all, Amici(Friends). Here, i'd like to discuss how to reduce conditional branches in the code. 1st of the all, i would like to share some tricks. Their description is here. :-D ----------------------- Thanks in Advance for attention of Yours.
What? do i need to write 4 lines to avoid an If?, I have better things to do... ;P
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
Good Time to all, Amici(Friends). Here, i'd like to discuss how to reduce conditional branches in the code. 1st of the all, i would like to share some tricks. Their description is here. :-D ----------------------- Thanks in Advance for attention of Yours.
SarK0Y wrote:
Here, i'd like to discuss how to reduce conditional branches in the code. 1st of the all, i would like to share some tricks.
I would suggest that you learn what automated profiling is. Then buy or find a tool that does that. Then learn how to use it effectively.
-
The readability of the if-less code is bad. What do you have against conditional branches? I would much rather have readable code with conditional branches instead of less readable code with out them.
"I've seen more information on a frickin' sticky note!" - Dave Kreskowiak
-
If you did that to my codebase I'd probably avoid working with you as much as possible. You can always throw hardware at code performance. You can't throw hardware at code readability.
-
Monaco.Bavarian wrote:
you are a winner of obfuscated C contest
Thanks, I generally dislike reading C++ because its nature seems to be obfuscated = better. That one was so hard to read, I couldn't understand the point. From comments it looks like the point is that using if tests to branch to another location is a bad practice. Everything I've read leads to not using spagetti code. IE branching is good. I just read an article about bubble sorting and someone reading the article believing it was efficient. I was just going to leave the article thinking it was written by a beginner, leave him alone, but when a reader believes it is efficient. I couldn't just drop it. On initial tests, just 200K takes over 2.5 minutes. I calculated 20M would take 70 weeks. I built a less readable set of code that sorts 50M records in 14+ seconds. Less readable = much greater efficiency to me is a good thing. (At least when comparing weeks to seconds.) I didn't see the benefit of his code in the article.
-
Good Time to all, Amici(Friends). Here, i'd like to discuss how to reduce conditional branches in the code. 1st of the all, i would like to share some tricks. Their description is here. :-D ----------------------- Thanks in Advance for attention of Yours.
-
Monaco.Bavarian wrote:
you are a winner of obfuscated C contest
Thanks, I generally dislike reading C++ because its nature seems to be obfuscated = better. That one was so hard to read, I couldn't understand the point. From comments it looks like the point is that using if tests to branch to another location is a bad practice. Everything I've read leads to not using spagetti code. IE branching is good. I just read an article about bubble sorting and someone reading the article believing it was efficient. I was just going to leave the article thinking it was written by a beginner, leave him alone, but when a reader believes it is efficient. I couldn't just drop it. On initial tests, just 200K takes over 2.5 minutes. I calculated 20M would take 70 weeks. I built a less readable set of code that sorts 50M records in 14+ seconds. Less readable = much greater efficiency to me is a good thing. (At least when comparing weeks to seconds.) I didn't see the benefit of his code in the article.
If you use constructs like this below (or with more if else) there are much combinations to test. It would give a bad software metric if you use a test tool. We have to use test tools for our tests of space applications. But the way the guy wrote his code is more bad. A construct like below written in his if free style would be unreadable for someone else and I bet the performance would be very bad too.
if ( expression1) {
if ( expression2) {
if ( expression3) {
...
} else {
...
}
} else {
if ( expression4) {
...
} else {
...
}
}
}
else {
if ( expression5) {
if ( expression6) {
...
} else {
...
}
} else {
if ( expression7) {
...
} else {
...
}
}
} -
If you use constructs like this below (or with more if else) there are much combinations to test. It would give a bad software metric if you use a test tool. We have to use test tools for our tests of space applications. But the way the guy wrote his code is more bad. A construct like below written in his if free style would be unreadable for someone else and I bet the performance would be very bad too.
if ( expression1) {
if ( expression2) {
if ( expression3) {
...
} else {
...
}
} else {
if ( expression4) {
...
} else {
...
}
}
}
else {
if ( expression5) {
if ( expression6) {
...
} else {
...
}
} else {
if ( expression7) {
...
} else {
...
}
}
}I've never encountered a business case that needed that many branches for a single set of conditions. I have encountered "cute" programmers who thought that unnecessary complexity made sense and did things that didn't make sense to me. (Throwing unrelated logic together in one big if-else if- cluster.) I'm also wondering if branching might help both the readability and maintainability of the logic and if that supercedes efficiency if it meets the business logic? IE
if ( expression1) Condition1();
else NotCondition1();
...
void Condition1()
{
if ( expression2) Condition2();
else NotCondition2();
}
void NotCondition1()
{
if ( expression5) Condition3();
else NotCondition3();
}void Condition2()
{
if ( expression3) {
...
} else {
...
}
}
etc.I'm not all that convinced that branching to routines won't be performant as well as more readable. I just recently read about a bubble sort routine. OK, old news + inexperienced developer = time to move on. One of the respondents liked how easy it was to read and how efficient it was. Man, I can't let that misinformation go. I explained how it rated as N^2 efficiency. (IE double the number of fields will quadruple the time to compute.) 200K records sorted in over 2 minutes. (The posted program sorted 11 hardcoded values in an int[] array. Of course that would be fast.) I calculated a million numbers would sort in about 56 minutes. I ran 50 million numbers through a binary sort process in just over 14 seconds. The time consistently increased by a second for just under 3 million numbers being added. A LOT of if tests being done in recursive routine calls. Slightly slower than List's built-in Sort routine, List blows up faster with memory problems as the numbers increase. (Can't do 20 million int[] and 20 million List)
-
SarK0Y wrote:
superfluous IFs make code slower.
That isn't necessarily true. Modern processors use a variety of tricks that reduce the 'cost' of unused branches. One of the problems of 'computed conditional' logic is that you incur the cost for all cases, not just the unused branch. Your overall performance actually decreases.
Software Zen:
delete this;
Especially with moores law hitting the ceiling lately (until someone finds a trick to break through and go up another 100 floors). Can't make it go any faster -- so add more cores. Can't utilize all the cores -- so add more microcode parallelism. Soon they might end up having CPUs that can follow dozens and dozens of branch path pipelines at the same time (until it can prune unused ones). Of course, the information that can be saves during context switches may limit that technique. On a side note.. Some languages (like Smalltalk) don't actually use branching in "if"'s (well, their equivalent to an if).. what may seem a condition check/branch is really an expression returning a boolean object, and then when asked to _run_ the "ifTrue" conditional code block it either does, if it is a "true" object, or doesn't if a "false" object, without any checks/branching. And the same for the "ifFalse" (aka "else") code blocks, only reversed.
-
Good Time to all, Amici(Friends). Here, i'd like to discuss how to reduce conditional branches in the code. 1st of the all, i would like to share some tricks. Their description is here. :-D ----------------------- Thanks in Advance for attention of Yours.
The old IBM 360 JCL didn't have any if statements. In PERL, you'd normally see something like open ("fred") || die which translates to if (not open("fred")) then die If you look at the assembler, in both cases, it is exactly the same.
-
in OOP use duck typing as means to avoid using if's and case statement to invoke objects of different classes. [^]
RonDsz wrote:
duck typing
Quack, Quack!
Bob Dole
The internet is a great way to get on the net.
:doh: 2.0.82.7292 SP6a
-
Good Time to all, Amici(Friends). Here, i'd like to discuss how to reduce conditional branches in the code. 1st of the all, i would like to share some tricks. Their description is here. :-D ----------------------- Thanks in Advance for attention of Yours.
We had such discussion in the eighties when programmers wanted to be artists, writing unreadable code just to be irreplaceable. If you would be one of my programmers I would fire you immediately for this waste of money and time and delivering error-prone code. I thought those times were gone! X|
------------------------------ Author of Primary ROleplaying SysTem How do I take my coffee? Black as midnight on a moonless night. War doesn't determine who's right. War determines who's left.
-
Good Time to all, Amici(Friends). Here, i'd like to discuss how to reduce conditional branches in the code. 1st of the all, i would like to share some tricks. Their description is here. :-D ----------------------- Thanks in Advance for attention of Yours.
Without a doubt, that's the worst idea I've seen in a long time. Instead of using a nice, easy to read
if
, you've turned it into a very-expensive-to-support-and-debug piece of crap that you'd have to throw unit test after unit test at with a crap-ton of edges cases. Congratulations! Now go back and wipe that smiley face off your post before I smack it off.A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Oh my gosh! A program with no if-else statements! Please don't make me learn assembly! Oh, wait - I already did...
Yeah, there's some optimization for ya. Instead of typing a nice little two letter word like
if
, now you have to remember a ton of 3 letter "if" statements that all being with "J". ;)A guide to posting questions on CodeProject[^]
Dave Kreskowiak