On Tue, 2 Aug 2022 14:06:45 -0500 "G. Branden Robinson" <g.branden.robin...@gmail.com> wrote:
> (the "root of all evil" thing), which also got stuffed into > Donald Knuth's mouth Knuth did say it. Please see " Structured Programming with go to Statements" mentioned in "ACM Computing Surveys Vol. 6, No. 4" at https://dl.acm.org/doi/10.1145/356635.356640 and https://dl.acm.org/doi/pdf/10.1145/356635.356640. Regarding, > https://ubiquity.acm.org/article.cfm?id=1513451 Hyde's assertion is that performance intution is easy and necessary. His advice boils down to learning about hardware and compilers. That won't get you far writing fast programs today. The highest order of performance in almost any application today is minimizing I/O, because I/O is orders of magnitude slower than anything else. Second is the knowing the language of implementation. I once wrote a slow program in Perl. It used the very clever pack/unpack functions on a file of hundreds of megabytes, one 1 KB record at a time. It ran IIRC 90 minutes. Eventually someone rewrote it for me in C, after I told them not to, and the runtime fell to 5 minutes. I doubt it was particularly good C; it's just hard to write obvious C that's slower than obvious Perl. Python programmers know this dictum well. The key to fast Python is no Python: make sure every line packs a wallop. Push all the processing down into libraries written in C, to avoid the slow-as-molasses interpreter. Similarly, Java programmers know how to rein in the garbage collector. Only after those hurdles are cleared do we arrive at standard-issue CS concerns like big-O complexity and NUMA memories. Even there, the practical solution may well be found in Rob Pike's observation, "Complex algorithms are slow for small N, and N is usually small." Hyde is right -- although he doesn't exactly say so -- that performance is an emergent property of design. Rare is the system with implementation performance problems that can be improved by finding the hot spots. More common, in my experience, are errors in the design that no amount of implementation can correct. --jkl