OSNews

Couldn't have said it better. The funny part is that for those of us who've been developing software for a while, developing 'fast' software comes naturally. It's hard to load a modern CPU unless you're doing something really intense (or more likely, stupid.)

The way I see it, netbooks are XP machines from 2003/2004, with a CPU on par with a Prescott, 1Gb RAM, comparable video (until now), etc. They always have been relatively powerful machines.

The software performance challenge isn't really issued to experienced/professional software developers. It's issued to people who've never written native code before, and need to learn how to do so properly.

Agree! As one of these student who have to learn C# and Java, I can't say that the way we are trained is a no go. Nobody care about speed (and I am in a video game oriented program, everybody know that performances are useless in video games. Other student think I am some kind of freak every time they see me using inline assembly in pure C part of my applications. They don't even know that operator like |, <<, >> (the C one, not C++), % or ^ exist. Their apps are made mostly of heavy while loop and function driven if and else if for every possible case, it is just terribly unoptimized code.

Last time I worked with a "normal" student (not those like me who take performances seriously), I rewrote a parsing algorithm in 159 line of C++ instead of ...



...

3500 lines of code made mostly of loops!!!!

It sounded like sarcasm to me. In any case, I agree. One of the prime reasons I dropped CS as a field of study was simply that the teachers I'd come into contact with were basically useless. I can, and do, learn more on my own than I ever learned from those so-called experts and professors... too bad that most CS "professors" aren't actually professional developers along with it. I've always felt that the only ones who are qualified to teach something are those who have actually done it for a while, not those well-versed in the theory but with a lack of practical knowledge.

D'oh, thanks. I accidentally turned my sarcasm-o-meter off ;-)

Yet another example of the brilliant saying, "Those that can — do: those that can't — teach."

CS is about programming as much as math is about counting.

That I agree with wholeheartedly. I am by no means an awesome programmer but having gone through the rigor of a 4 year CS course at a prestigious university, I must say I have done most of my learning at work.

I still am learning tons every day.

It was a joke, it is oblivious that it is essential. Video games are almost the only thing able to load a Desktop PC (compiling and encoding are two other).

um... you obviously forgot about flash movies :p

While I agree with what you're saying about the people who use high-level languages and stupidly complex algorithms, you get no points for using inline assembly. With modern, competent compilers (e.g. gcc, msvc, sun studio, etc), the compiler will likely choose a good code sequence to balance size and speed. Especially if you give it some feedback in the form of profile-guided optimization. Inline asm sometimes inhibits the compiler's optimizer and generally is a waste of time if you're good enough to write clear, straightforward-to-optimize C code without too many pointers flying about (to avoid aliasing deoptimizations).

The real trick lies in writing straightforward, maintainable code for the bulk of your program so that the compiler will do a good job, and then tweaking the C code (or using processor intrinsics where there's a not-normally-generated instruction that will help you out) to get the instruction output you want from the compiler. Chances are good that you'll get it with a modern compiler, even if you don't resort to stupid tricks with the >>, XOR, or AND operators or manually strength-reducing divisions.

Spagatti code is impossible to maintain, every know that. Those 4 digit algorithm appear when people code with a debugger "oh, this case don't work, let add few line to fix that" and do that over and over again 10 thousand time. When you plan what you are doing, you end up with smaller, easier to maintain code and not just a bunch of hack almost not working.

Smaller LoC often mean more preparation and cleaner "where I am going" path.

Testing every possibility is sometime smaller, but exceptionally slower than using more complex algorithm, you are right. But coding with only a goal at the end and debugging until you come close to it is not the right way to go and produce 3500 LoC algo when they should be less than 200 if you take the time to do a trace before writing it instead of during the coding process.