> It used to be said that a compiler would never beat a programmer at assembly.
Probably still couldn't. But with gigs of ram, terabytes of hard drive space, and gazillions of flops of cpu time available, no one cares. No one can wait for Mel to optimize blackjack, your boss wants the new build 5-15 minutes after you've written the code, and that shouldn't take more than an hour itself.
It's not that the compiler got better than programmers... it just because cheaper. Hell, how many Mels are there out there anyway? Surely the number of people that clever and devoted to the bare metal of a CPU has never exceeded a few thousand people out of the entire population of Earth. Rarity makes them expensive, but it also means that shitty software shop in St. Louis or Tampa could never have such a person.
And since technology drives the economy, everything would crash if we had to rely on the availability of super-programmers.
Optimizing compilers are slightly better than they were long ago... but this isn't because they're all that impressive. We've just had thousands of monkeys pounding away over decades, hammering out one little optimization or another, and the storage to allow compilers to grow big enough to have a library of those to rely on.
It depends greatly on the programmer, and how much time you allot them. GCC will produce vastly better code than any human programmer, given a specification in C and a time bound of 1 second. Give them ten minutes? An hour? A week?
At the extreme a sufficiently adept assembly programmer (which probably still exist) will still beat the compiler, given enough time, though that can be helped by the ability to reference the code the compiler is generating.
Not any human programmer, at least not for some tasks. The handcoded x86 SIMD code in x264 (the software video encoder used by everyone who cares about video quality per bitrate) beats the output of any compiler trying to compile the pure-C fallback function. Same for a bunch of other code you use (indirectly) like memcpy or strlen.
But the optimized handcoded routines take weeks to develop while a compiler would be done in less than a second. For almost all code, a programmer's time would be better spent on something else.
You seem to have misread what I said, and are making basically the same point I did. I said that given only a single second in which to work (and given a problem specification in the form of a correct C program) then literally any human programmer will lose out to GCC. That seems unequivocally the case, and you seem to agree.
I also said that there still exist programmers who, given enough time, can probably beat the compiler. Certainly there are tasks where this is easier, but no one is getting it done in one second.
Probably still couldn't. But with gigs of ram, terabytes of hard drive space, and gazillions of flops of cpu time available, no one cares. No one can wait for Mel to optimize blackjack, your boss wants the new build 5-15 minutes after you've written the code, and that shouldn't take more than an hour itself.
It's not that the compiler got better than programmers... it just because cheaper. Hell, how many Mels are there out there anyway? Surely the number of people that clever and devoted to the bare metal of a CPU has never exceeded a few thousand people out of the entire population of Earth. Rarity makes them expensive, but it also means that shitty software shop in St. Louis or Tampa could never have such a person.
And since technology drives the economy, everything would crash if we had to rely on the availability of super-programmers.
Optimizing compilers are slightly better than they were long ago... but this isn't because they're all that impressive. We've just had thousands of monkeys pounding away over decades, hammering out one little optimization or another, and the storage to allow compilers to grow big enough to have a library of those to rely on.