Okay I'll just reply to his incorrect assumptions.
#4 Yes it has. If anything the step up from a 1997 computer t(what was that? 200Mhz Pentiums?) to 3Ghz quad core processors with up to 12 ALU's in parallel per core, is a much, much bigger step up than going from an 87 era CPU (like say the 8080) to the Pentium (which was more or less the same processor, just clocked at a higher speed). Of course I wouldn't expect someone who relies on his compiler to do his optimizations for him to be aware of this.
#5 And it's true to. The least Mr. Hyde (is life too weird or what?) could do was provide evidence as to how he thinks one should profile a SOA driven multithreaded application, with hundreds of concurrent users, all wanting to do different things. Yes I'm aware that in your cute little Unix-like commandline tool, or pong game, you can fairly accurately profile the bottlenecks, but in any serious application, the complexity is too high to do so effectively.
#6 It's not something I believe. It's something I can prove. For the same price of one software engineers day, you can buy the most ridiculously overpowered PC you can imagine. I know you think customers pay for anything you ell them to, but In reality, nobody wants to pay extra for something that's already "good enough". If user's time is so valuable - why don't they want to pay to optimize? Or even document? Nobody is going to pay an extra 100.000 USD for a piece of software that works, to maybe get a performance boost, when they can get new hardware for 2.000 USD that will guarantee it!
#8 This one is brilliant. Doesn't mister Hyde realize that poor (much the same as great) is highly subjective? Also he seems to be of the (wrong) opinion that optimization is somehow different to finding a better algorithm. He acts like optimization is something you can have done automatically by some fairy god mother.
Let me just eliminate this myth once and for all. Unless you have an intimate understanding of how your compiler (regardless of language) translates your source code into binary code, and likewise have an intimate understanding of all your build targets (including hardware and operating system quirks) there is no way you can effectively optimize a program. Why? Because there is no way of telling which concrete optimization is going to affect performance on different targets. You just tightened up a loop so it can fit inside your cache? Cool.. Here's Brians computer with half the cache. Back to the drawing board. You just rearranged the order of a complex mathematical expression to eliminate as many expensive instructions as possible? Oh, what's that? The expression can no longer be processed in parallel on a multiple ALU CPU? Bummer.
The idea that there are some kind of magical optimizations that always work, and that programmers are just too lazy or stupid to implement them is so ignorant it can only be ascribed to higher education. You have to have at least a Masters to say something that stupid.
For the record, I never said "you should never optimize". I said "you should never optimize unless you have to". Now call me elitist but I'd wager that any well-written Python software (isn't it all) will outperform any poorly written C++ program. I'd wager that hiring someone to write well-written Python programs is several orders of magnitude easier and less expensive then hiring a C++ programmer to do the same (because let's face it, C++ is so anti-compact that even it's inventor doesn't expect anyone to ever understand it all, and the vast majority of C++ programmers are hacks anyway).
Look, I don't know how to break it to you, but not every C++ programmer is as good as you. I present to you as evidence practically every piece of software ever written. Let's take Microsoft as an example shall we? Microsoft is the major corporation in the world with the highest average IQ. Now when you think of all the hordes of morons in front-line support, that leaves a handful of super geniuses left to develop their software, and almost without exception it's all written in C++, and also almost without exception it is not marginally the least bugged, never mind best performing. I mean having SQL Server manager crash when you double click on a table name? How the hell did no-one find that one? Having Outlook do whatever the hell it does when it starts up, that hangs the entire fucking system for what fells like an eternity? Great performance? I don't think so.
Listen. Once (like 5 years ago - if that) I was just like you (I programmed in Assembly until 2002 - because I lived under the illusion that it was the fastest). All idealistic and thinking the customers deserve the best of the best. Bollocks! The customers deserve what they're willing to pay for, and if they don't care about performance, neither do I. In that respect, the customer is always right. I will write the software to specification and to the best of my abilities, and to date, that's all worked out wonderfully. But if they aren't willing to pay for the time I spend optimizing, well hey - there's no such thing as a free lunch.
#4 Yes it has. If anything the step up from a 1997 computer t(what was that? 200Mhz Pentiums?) to 3Ghz quad core processors with up to 12 ALU's in parallel per core, is a much, much bigger step up than going from an 87 era CPU (like say the 8080) to the Pentium (which was more or less the same processor, just clocked at a higher speed). Of course I wouldn't expect someone who relies on his compiler to do his optimizations for him to be aware of this.
#5 And it's true to. The least Mr. Hyde (is life too weird or what?) could do was provide evidence as to how he thinks one should profile a SOA driven multithreaded application, with hundreds of concurrent users, all wanting to do different things. Yes I'm aware that in your cute little Unix-like commandline tool, or pong game, you can fairly accurately profile the bottlenecks, but in any serious application, the complexity is too high to do so effectively.
#6 It's not something I believe. It's something I can prove. For the same price of one software engineers day, you can buy the most ridiculously overpowered PC you can imagine. I know you think customers pay for anything you ell them to, but In reality, nobody wants to pay extra for something that's already "good enough". If user's time is so valuable - why don't they want to pay to optimize? Or even document? Nobody is going to pay an extra 100.000 USD for a piece of software that works, to maybe get a performance boost, when they can get new hardware for 2.000 USD that will guarantee it!
#8 This one is brilliant. Doesn't mister Hyde realize that poor (much the same as great) is highly subjective? Also he seems to be of the (wrong) opinion that optimization is somehow different to finding a better algorithm. He acts like optimization is something you can have done automatically by some fairy god mother.
Let me just eliminate this myth once and for all. Unless you have an intimate understanding of how your compiler (regardless of language) translates your source code into binary code, and likewise have an intimate understanding of all your build targets (including hardware and operating system quirks) there is no way you can effectively optimize a program. Why? Because there is no way of telling which concrete optimization is going to affect performance on different targets. You just tightened up a loop so it can fit inside your cache? Cool.. Here's Brians computer with half the cache. Back to the drawing board. You just rearranged the order of a complex mathematical expression to eliminate as many expensive instructions as possible? Oh, what's that? The expression can no longer be processed in parallel on a multiple ALU CPU? Bummer.
The idea that there are some kind of magical optimizations that always work, and that programmers are just too lazy or stupid to implement them is so ignorant it can only be ascribed to higher education. You have to have at least a Masters to say something that stupid.
For the record, I never said "you should never optimize". I said "you should never optimize unless you have to". Now call me elitist but I'd wager that any well-written Python software (isn't it all) will outperform any poorly written C++ program. I'd wager that hiring someone to write well-written Python programs is several orders of magnitude easier and less expensive then hiring a C++ programmer to do the same (because let's face it, C++ is so anti-compact that even it's inventor doesn't expect anyone to ever understand it all, and the vast majority of C++ programmers are hacks anyway).
Look, I don't know how to break it to you, but not every C++ programmer is as good as you. I present to you as evidence practically every piece of software ever written. Let's take Microsoft as an example shall we? Microsoft is the major corporation in the world with the highest average IQ. Now when you think of all the hordes of morons in front-line support, that leaves a handful of super geniuses left to develop their software, and almost without exception it's all written in C++, and also almost without exception it is not marginally the least bugged, never mind best performing. I mean having SQL Server manager crash when you double click on a table name? How the hell did no-one find that one? Having Outlook do whatever the hell it does when it starts up, that hangs the entire fucking system for what fells like an eternity? Great performance? I don't think so.
Listen. Once (like 5 years ago - if that) I was just like you (I programmed in Assembly until 2002 - because I lived under the illusion that it was the fastest). All idealistic and thinking the customers deserve the best of the best. Bollocks! The customers deserve what they're willing to pay for, and if they don't care about performance, neither do I. In that respect, the customer is always right. I will write the software to specification and to the best of my abilities, and to date, that's all worked out wonderfully. But if they aren't willing to pay for the time I spend optimizing, well hey - there's no such thing as a free lunch.