These are very early compilers indeed, but it makes me wonder: a HN comment today reminded me of 'Proebsting's law' that compilers double program speed every 18 years. He got this by comparing a -O0 run with a -02 run and then dividing, but the obvious problem with this is that even if a modern compiler is run with -O0 it's probably going to be in effect optimizing a lot just by all the architectural choices and default code generation. It would be interesting to see if one could take a more recent C compiler, say late '70s and compare it to a heavily optimizing GCC run, and answer the question: how much have C compilers improved over the last 30-40 years?
I am pleasantly surprised to see that current GCC seems to be able to generate code for a PDP-11 target. I think there may actually even be cycle-accurate PDP-11 simulators around, which would enable you to do the benchmarking. If you do get around to it, I'd love to hear your results!
Aren't most optimisations hardware dependant, and if so: wouldn't it make sense that the work put into these optimisations depends largely on how much the hardware is used? Is the PDP-11 still a useful target in that sense? Wouldn't the original x86 instruction set be more useful for example?
Well, if you want to compare a 1970s compiler to a modern compiler, the x86 instruction set will not be a useful target, since no 1970s compilers target it. These particular ancient compilers target the PDP-11.
The larger question of whether optimizations are hardware-dependent is interesting. In some sense, sure. But there are a lot of optimizations in modern compilers that apply equally well to the PDP-11 and to the AMD64; they're just not that different.
My homework assignment for you: write a C function of three or four lines which loops over an array of structs and does some computation for each one, including some conditional and a call to a one-line static function; compile it with -c -O0 -Wa,-adhlns=unoptimized.lst and with -c -O5 -fomit-frame-pointer -Wa,-adhlns=optimized.lst; list the optimizations you notice in the difference between unoptimized.lst, and hazard a guess at which of them are applicable on a PDP-11.
The situation with x86 specifically is a little weirder than that: http://www.emulators.com/docs/nx06_rmw.htm . It's a bit of a long read, but the summary is that on some x86s, single-instruction adds to memory are faster, and on others, load/increment/store in three instructions is faster.
Um, yes, and this kind of unstyled webpage is also the kind that makes me twitch straight to my "Make Readable" CSS-forcing bookmarklet so that I can read it in a legible size, line spacing, and line width, rather than having it trawl all the way across my widescreen monitor in 12pt serif.
It can get exhausting keeping up with all of the silly CSS/JS web trends, I realize, but there is a good reason for a lot of it.
I wonder if a popular web browser could get away with changing all its default CSS rules to resemble modern readability guidelines, without breaking a large majority of the web?
People who use CSS resets would be fine; people who use things like normalize.css might have to go get a new version; but the rest of the internet (which is implicitly relying on things like the line-height of <p>s and the padding of <body>) might just spontaneously combust.
Then again, it might be fine to apply an alternate "default theme" if and only if there are literally no non-user-agent CSS styles defined on the page (either by stylesheets or DOM-manipulating Javascript).
>Then again, it might be fine to apply an alternate "default theme" if and only if there are literally no non-user-agent CSS styles defined on the page (either by stylesheets or DOM-manipulating Javascript).
You may have to create your own "chrome" subfolder in there. (I did.) Some poking around reveals that the essays on Paul Graham's website achieve their indentation by sticking all the text in a <td width=455>. 455 pixels, then. So I tried this CSS file, having spent all of three or so minutes looking at a CSS reference:
~ $ cat heh.css
p {max-width:455px}
And installed that as <profile-dir>/chrome/userContent.css. ... This seems to have far-reaching implications. It does make all the paragraphs on this website, except for the first one, fit in what is presumably a 455px box. This also goes for Hacker News comments, and it also constricts the paragraphs on a website that pretty certainly has its own CSS. I suspect the only thing that would override this is a CSS that specifically changed the max-width property of <p> objects. (I expect a CSS expert would have been able to predict all of the above, except possibly the fact that it seems common for the first paragraph to not be in a <p> tag.) Oh, and I had to restart Firefox for the effects to be visible; and, editing that CSS file, it seems I'll have to restart Firefox again to see changes.
That was in response to (and in empathy of) jacquesm' implication that this was preferable to other styles on the web, it wasn't meant to criticize this link's WM.
And if they hadn't, people would be confused about whether something's supposed to be a pointer or an array. I think I like the current syntax much better.
yeah, I found this last night and posted it on Reddit. Thanks for the cross post. I have a github repo open for it I if anybody wants to fork. I won't merge pull requests. github.com/mortdeus/legacy-cc
