31–40 of 56 posts
I don't think this has changed much at all since 1992. Now you can say that it's less than 90 years old, and nobody is very good at it yet.
And most of our profession has already given up on getting any better at it because a machine can spit out code that compiles.
80% of the cost is maintenance, and all software dies so there will always be work to do.
I never hear anyone talk about big-O notation anymore ... Nowadays it's all about optimizing the same old algorithms but on a GPU.
Also to some extent it’s just that we’ve pretty well standardized on algorithm implementations. Thinking about the relative merits of a BST vs a red-black tree vs a hash table with bucketing or open addressing or whatever just doesn’t happen as often when the standard library has one implementation and not choosing it would cost you a week of implementing testing and justifying the decision to your colleagues.
Earlier quoted context omitted.
> Sure, but you still generate the machine code, right? You still have to master the instructions and their specifics of the target CPUs. You do, but self-hosted compilers tend to have two huge benefits: 1) they tend to be easier to reason about, being written in a high-level language 2) they exercise the code, and usually even seldom-used parts of the code, to make problems more noticeable
But once you have written in assembly, you could start to write the next version in the higher level language. The first version (written in assembly) doesn't necessarily have to produce the most optimal code, just good enough and correct. Most of the improvements can be done in the self hosted compiler (in a higher level language). So this period did not have to last many years.
In the 1970s, it would have been really low on my list, likely below using a macro assembler.
I never hear anyone talk about big-O notation anymore ... Nowadays it's all about optimizing the same old algorithms but on a GPU.
2. Consider any algorithm of roughly linear complexity (this probably applies to N lg N as well): the only way to make it significantly faster now is to improve parallelism (whether making it so the CPU can exploit ILP, running multicore, or running on a GPU). In 1992, you could make things run significantly faster by just waiting until it was 1994.
Earlier quoted context omitted.
Languages were simpler (except for certain ones, like C++ which was a beast even in 1992), and incredibly complex and magical optimizers weren’t yet a thing, never mind a feature expected of a "passable" compiler. One could still write a reasonable non-optimizing Pascal or C89 compiler in a weekend more or less, and it would be both faster to write (thanks to more expressive languages) and faster at compiling (thanks…
I dunno, Chez Scheme is from 1985 and remains today one of the most magically optimizing compilers for a dynamic language in existence... kind of makes you wonder how we went so far wrong with Python.
This is true, but the implementation is constrained by the specification. Python is not just dynamic, but in many cases over-specified. If you read e.g. the Common Lisp specification, you will find that things are under-specified in places that leave a lot of low-hanging fruit for an optimizing implementation.
Scheme (particularly prior to R6RS) is so lightly specified as to allow a lot of variation in implementation strategies, even more so than Common Lisp.
I never hear anyone talk about big-O notation anymore ... Nowadays it's all about optimizing the same old algorithms but on a GPU.
I never hear anyone talk about big-O notation anymore ... Nowadays it's all about optimizing the same old algorithms but on a GPU.
1. For the most common things people will write, we have a plethora of asymptotically optimal choices that have been discovered. 2. Consider any algorithm of roughly linear complexity (this probably applies to N lg N as well): the only way to make it significantly faster now is to improve parallelism (whether making it so the CPU can exploit ILP, running multicore, or running on a GPU). In 1992, you could make things…
In the late 90s a couple of companies, including Microsoft and Apple, noticed (just a little bit sooner than anyone
else) that Moore's Law meant that they shouldn't think too hard about performance and memory usage... just build
cool stuff, and wait for the hardware to catch up. Microsoft first shipped Excel for Windows when 80386s were too
expensive to buy, but they were patient. Within a couple of years, the 80386SX came out, and anybody who could
afford a $1500 clone could run Excel.
As a programmer, thanks to plummeting memory prices, and CPU speeds doubling every year, you had a choice. You
could spend six months rewriting your inner loops in Assembler, or take six months off to play drums in a rock and
roll band, and in either case, your program would run faster. Assembler programmers don't have groupies.
So, we don't care about performance or optimization much anymore.
— Joel Spolsky, "Strategy Letter VI" (2007)