Optimizations - Programmer vs. Compiler? 1422
Saravana Kannan asks: "I have been coding in C for a while (10 yrs or so) and tend to use short code snippets. As a simple example, take 'if (!ptr)' instead of 'if (ptr==NULL)'. The reason someone might use the former code snippet is because they believe it would result in smaller machine code if the compiler does not do optimizations or is not smart enough to optimize the particular code snippet. IMHO the latter code snippet is clearer than the former, and I would use it in my code if I know for sure that the compiler will optimize it and produce machine code equivalent to the former code snippet. The previous example was easy. What about code that is more complex? Now that compilers have matured over years and have had many improvements, I ask the Slashdot crowd, what they believe the compiler can be trusted to optimize and what must be hand optimized?"
"How would your answer differ (in terms of the level of trust on the compiler) if I'm talking about compilers for Desktops vs. Embedded systems? Compilers for which of the following platforms do you think is more optimized at present - Desktops (because is more commonly used) or Embedded systems (because of need for maximum optimization)? Would be better if you could stick to free (as in beer) and Open Source compilers. Give examples of code optimizations that you think the compiler can/can't be trusted to do."
Ask the compiler... (Score:5, Funny)
Compiler: Optimizing? Optimizing? Don't talk to me about optimizing. Here I am, brain the size of a planet, and they've got me optimizing inane snippets of code. Just when you think code couldn't possibly get any worse, it suddenly does. Oh look, a null pointer. I suppose you'll want to see the assembly now. Do you want me to go into an infinite loop or throw an exception right where I'm standing?
Programmer: Yeah, just show me the stack trace, won't you compiler?
You should always... (Score:5, Funny)
From the "Patenting Fire" department (Score:4, Funny)
Prepare to be sued.
Re:You should always... (Score:5, Funny)
Re:You should always... (Score:5, Funny)
Re:You should always... (Score:3, Funny)
------------
[...][...]
------------
Re:Clear Code (Score:4, Funny)
If you are caught thinking out of the box again, you will get no dessert!
The algorithm that must not be named! (Score:5, Funny)
The most frustrating thing is that, if you must use the algorithm that must not be named, the bidirectional form of the algorithm is much faster (in practice) than the unidirectional form yet really no more complex to code than the latter if you have any potential as a software developer.
Re:You should always... (Score:5, Funny)
Whitespace causes slow programs (Score:1, Funny)
Re:Time to post the famous Knuth quote... (Score:1, Funny)
We should forget about small efficiencies, about 97% of the time.
Actually, you can get it up to 98% of the time if you are careful.
Re:Write C for C programmers (Score:2, Funny)
try
{
if (1 / (int)ptr)
cout << "ptr is not null";
}
catch (...)
{
cout << "ptr is null";
}
Re:You should always... (Score:1, Funny)
Re:Ask the compiler... (Score:5, Funny)
Optimization rules... (Score:5, Funny)
Plus I got extra credit for implementing phong shading. I didn't even try to do phong shading.
Re:Clear Code - Boeing (Score:4, Funny)
Re:Clear Code - Boeing (Score:4, Funny)
Re:Write C for C programmers (Score:3, Funny)
So I made a macro called STRCMP which can be used in a manner which reads better logically.
Re:You should always... (Score:1, Funny)
Re:Write C for C programmers (Score:1, Funny)
Re:The algorithm that must not be named! (Score:4, Funny)
The many-worlds version of bogosort is the fastest possible sorting algorithm though. Its O(C). For those that don't know, the many-worlds version just does one random permutation, with a new universe being created for each possible outcome of the permutation. You then destroy all the universes were the dataset isn't sorted.
Re:Clear Code - Boeing (Score:5, Funny)
HAL! Open the bathroom door!
I'm sorry Dave, you shouldn't have had that last burrito.
Re:Ask the compiler... (Score:3, Funny)
Re:Optimization rules... (Score:4, Funny)
Never do (x == y) (Score:2, Funny)
The recommended way for (x == y) is
if ( log(x) == log(y)) All the real good programmers that read magazine articles are doing this.
And anyway, real numbers are more precise than integers. So in the case of x and y being integers its more precise using the log of the value.
Never mind that gcc since 2.96 can issue warnings (or error with -Werror) and that languages like Java don't even allow assignments inside if(...), it's still good to practice this sound magazine article advice.
In fact never program. Because one day you'll enter a typo, and you might have a bug, and so you should never program.
Never do (x==NULL), do (!(x-NULL)) (Score:2, Funny)
Re:Clear Code - Boeing (Score:2, Funny)
So how many dumps does it take to fill up the crapper tank?
Man, due to budget cuts, I'd hate to be the one guy whose job that is.
"Hang in there, you only have 17 craps to go. Here, have another burrito."
Re:Ask the compiler... (Score:3, Funny)
Re:The algorithm that must not be named! (Score:3, Funny)
The programmer will be alive in the universes which bogosort worked well.