Re: Counterexamples in C programming and library documentation (was: [PATCH v3] NULL.3const: Add documentation for NULL)

[James K. Lowden]

On Tue, 2 Aug 2022 14:06:45 -0500
"G. Branden Robinson" <g.branden.robinson@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