Optimizations - Programmer vs. Compiler?
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."
Programmer: Hey, compiler. How do you like optimizing?
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?
A programmer is a machine for converting coffee into code.
Optimize. Using cryptic, short variable names also shaves valuable microseconds off compile time and run time.
I just checked the U.S. Patent office and sure enough, just minutes after your post, Microsoft patented "if (!ptr)" as a shorthand for "if (ptr==NULL)".
Prepare to be sued.
"What the hell is an aluminum falcon?"
You mean that we should not strain after a redundant temporary object gnat and swallow a network socket camel?
If you are caught thinking out of the box again, you will get no dessert!
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Grrr, you named the algorithm that must not be named! Cursed be the name of the fool who thought it would be a good algorithm for introductory students - I've lost count of the number of people convinced that this satan-spawned algorithm is faster than an insertion sort (it's not) and that there's no reason for them to learn to use the qsort() function. N.B., not to implement a quick sort, but to simply call a standard library routine.
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.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Ialwaysstripallthewhitespaceoutofmyprograms.
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.
And write C++ for C++ programmers:
;
try
{
if (1 / (int)ptr)
cout << "ptr is not null";
}
catch (...)
{
cout << "ptr is null";
}
When I wrote my ray-tracer for the final project of my graphics class, I used gcc -o3 and it optimized my code into Pov-ray, which was sweet. I was done with the project in like ten minutes.
Plus I got extra credit for implementing phong shading. I didn't even try to do phong shading.
And believe me it is a pain in the a$$. Our company did the verification for the code in the microprocessor that controls the locks to the bathroom door on a 777, if the crapper tank is full then the door locks to make sure there isn't an overflow and thus frozen turd/urine meteors that fall from the sky. Every byte of the code MUST be excercised including all error conditions.
So how many dumps does it take to fill up the crapper tank? I'd hate to be the last QA engineer in line to use the crapper. Also what happens when that last engineer fills up the crapper, does the bathroom door look thus trapping him inside?
I've always had a problem with that whole !strcmp(x,y) thing.
;)
So I made a macro called STRCMP which can be used in a manner which reads better logically.
Reinvent the wheel only at either a lower cost, greater effectiveness, or your own personal enrichment and satisfaction.
Fricking Genius! Name a function the exact same name as another function except make it all uppercase and make the behavior the exact opposite! If wonder if this would work for... scanf. I can #define PRINTF for scanf and that will be so much clearer! Or #define MALLOC to free. Or #define TRUE to false.
HAL! Open the bathroom door!
I'm sorry Dave, you shouldn't have had that last burrito.
Oh you are so right. And as a corrolary never do if (x == y), because with both sides being variables one day you'll write (x = y), and (y = x) wont save you.
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.
"if (!(x-NULL))" is not only foolproof, but much easier to understand!
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."