The use of "magic" turns the viewpoint into a strawman position. Who thinks it is "magically" fast. Some, perhaps, but enough to consider it a view held by large numbers of programmers?
My experience is that hand-tuned assembly slows down over time relative to C, because C compilers keep getting more clever in what they optimize, and are able to handle new instruction sets with different timing profiles.
The text after "Line coverage is a measure of test quality" only shows that line coverage is not a perfect measure of test quality. It could still be an approximate measure of test quality.
The author writes "Programmers that comment on Hacker News or Proggit links are not a randomly sampled cross section of the industry. They’re better."
Is there any evidence for that? Or is that a myth as well?
> Who thinks it is "magically" fast. Some, perhaps, but enough to consider it a view held by large numbers of programmers?
In my experience, yes. Counting the number of people I've met in person and the ones whose opinions I've read online, there are dozens of people who seem to believe this. Do I have stats on this? No. It's just my anecdotal evidence. As is the rest of the list.
> My experience is that hand-tuned assembly slows down over time relative to C
My point was that other native code AOT languages do just as well or better. I wasn't advocating writing assembly, I doubt I'd do as good of a job as the people who write compiler backends.
> The text after "Line coverage is a measure of test quality" only shows that line coverage is not a perfect measure of test quality. It could still be an approximate measure of test quality.
Fair point.
> Is there any evidence for that? Or is that a myth as well?
Possibly a myth I believe in myself. It's my anectodal evidence, and I'd love to be proven wrong by actual data.
> Overall these are misconceptions that some programmers have, and mostly junior programmers at that
My experience is that senior programmers are worse, because they refuse to acknowledge they might be wrong.
That by virtue of using a C compiler the code will, with no effort on my part, run faster than equivalent code written in a different language. That, if an implementation exists in C, that no other implementation can beat it.
I'm railing on against it because I've met people who believe that first paragraph, literally.
> If I say "the C compiler has millennia of work by a small army of clever people", do you think I'm saying it's "magic"?
No. But one can use the same backends as the current C compilers for other languages. The results will be the same.
> In that section you only mention C and assembly. It is not until much later mention other AOT languages.
My bad. Sometimes things are obvious to me and I incorrectly assume that other people will get what I'm saying.
"However, the C programming language did take advantage of several low-level programming features of the PDP-11, resulting in their inclusion into new processor".
I'd say no to the myth question. Reasonable people may disagree.
> C was implemented for other systems within its first year
I don't doubt it. Those systems were far, far simpler than an last-gen x86 processor.
My point isn't that "it's fancy PDP11 assembly", it's that today's hardware isn't even close to being represented by C. Or, at the very least, no more so than alternatives.
I've seen a lot of people write that they can see the assembly that would be generated when they read C. I don't think they've looked at the output of a compiler in a long while if that's the case.
C-with-intrinsics does a decent job of matching the machine's instruction set, with a fallback to be able to support machines which don't support specific instructions.
FWIW, no programming language, not even assembly, is able to handle "cache hiearchies, cache lines, memory prefetching, out-of-order execution, etc".
7 comments
[ 1.9 ms ] story [ 36.2 ms ] threadThe use of "magic" turns the viewpoint into a strawman position. Who thinks it is "magically" fast. Some, perhaps, but enough to consider it a view held by large numbers of programmers?
My experience is that hand-tuned assembly slows down over time relative to C, because C compilers keep getting more clever in what they optimize, and are able to handle new instruction sets with different timing profiles.
The text after "Line coverage is a measure of test quality" only shows that line coverage is not a perfect measure of test quality. It could still be an approximate measure of test quality.
The author writes "Programmers that comment on Hacker News or Proggit links are not a randomly sampled cross section of the industry. They’re better."
Is there any evidence for that? Or is that a myth as well?
Overall these are misconceptions that some programmers have, and mostly junior programmers at that. I was hoping for something more along the lines of https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a... (for addresses) and https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-... (for names).
In my experience, yes. Counting the number of people I've met in person and the ones whose opinions I've read online, there are dozens of people who seem to believe this. Do I have stats on this? No. It's just my anecdotal evidence. As is the rest of the list.
> My experience is that hand-tuned assembly slows down over time relative to C
My point was that other native code AOT languages do just as well or better. I wasn't advocating writing assembly, I doubt I'd do as good of a job as the people who write compiler backends.
> The text after "Line coverage is a measure of test quality" only shows that line coverage is not a perfect measure of test quality. It could still be an approximate measure of test quality.
Fair point.
> Is there any evidence for that? Or is that a myth as well?
Possibly a myth I believe in myself. It's my anectodal evidence, and I'd love to be proven wrong by actual data.
> Overall these are misconceptions that some programmers have, and mostly junior programmers at that
My experience is that senior programmers are worse, because they refuse to acknowledge they might be wrong.
If I say "the C compiler has millennia of work by a small army of clever people", do you think I'm saying it's "magic"?
You wrote "My point was that other native code AOT languages do just as well or better"
In that section you only mention C and assembly. It is not until much later mention other AOT languages.
BTW, you wrote "C maps closely to hardware. / If “hardware” means a PDP11 or a tiny embedded device, sure."
Is that not also a myth? https://en.wikipedia.org/wiki/PDP-11_architecture#Myth_of_PD...
As http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.138... points out, C was implemented for other systems within its first year. Surely any strong biases towards a PDP-11 specific hardware would have been noticed very early on.
That by virtue of using a C compiler the code will, with no effort on my part, run faster than equivalent code written in a different language. That, if an implementation exists in C, that no other implementation can beat it.
I'm railing on against it because I've met people who believe that first paragraph, literally.
> If I say "the C compiler has millennia of work by a small army of clever people", do you think I'm saying it's "magic"?
No. But one can use the same backends as the current C compilers for other languages. The results will be the same.
> In that section you only mention C and assembly. It is not until much later mention other AOT languages.
My bad. Sometimes things are obvious to me and I incorrectly assume that other people will get what I'm saying.
> Is that not also a myth? https://en.wikipedia.org/wiki/PDP-11_architecture#Myth_of_PD....
From the link you posted:
"However, the C programming language did take advantage of several low-level programming features of the PDP-11, resulting in their inclusion into new processor".
I'd say no to the myth question. Reasonable people may disagree.
> C was implemented for other systems within its first year
I don't doubt it. Those systems were far, far simpler than an last-gen x86 processor.
My point isn't that "it's fancy PDP11 assembly", it's that today's hardware isn't even close to being represented by C. Or, at the very least, no more so than alternatives.
I've seen a lot of people write that they can see the assembly that would be generated when they read C. I don't think they've looked at the output of a compiler in a long while if that's the case.
Yes, the C language took advantage of byte addressing on the PDP-11, and most computers since then support byte addressing because of C.
That's hardly the same as "C maps closely to a PDP-11", which is the claim you made that I am arguing is a myth.
The link I gave to http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.138... describes "THE MACHINE MODEL OF UNIX". Nothing about that model is closely tied to the PDP-11 hardware, that I can tell.
C-with-intrinsics does a decent job of matching the machine's instruction set, with a fallback to be able to support machines which don't support specific instructions.
FWIW, no programming language, not even assembly, is able to handle "cache hiearchies, cache lines, memory prefetching, out-of-order execution, etc".
Ha ha. "Programmer tries to make himself feel better for wasting half his days on online forums." It's related to work, I swear!