How much do we care about high-load scenarios?
Eric S. Raymond
esr at thyrsus.com
Wed Sep 14 20:41:47 UTC 2016
Eric S. Raymond <esr at thyrsus.com>:
> John D. Bell <JDB at systemsartisans.com>:
> > *If* I were the architect on this project (thankfully I'm not!) I
> > would get the code simplified and streamlined in single-thread mode
> > as far as possible, and then design and code a
> > POSIX-threading-conformant "improvement".
> That is exactly the contingency plan I have unless Higher Authority (Mark
> and LF) tells me we need to do something else and do it now.
I should amplify that a little.
I will not willingly take the complexity hit of multithreading *anything*
until I see benchmark numbers demonstrating a bottleneck that can be
effectively addressed in no other way. It's not good enough to just handwave
and say "high load, we gotta optimize" - without measurements optimization
is premature and you know what *that* means.
I can certainly do concurrent programming when I have to (there's a thread-pool
scheduler in the cvs-fast-export front end that I'm quite proud of - less than
30 lines of code to manage concurrent Bison parsers and the thing runs like
a bat out of hell) but I have an ingrained reluctance to do it that I've
been explaining off-list to Hal.
Human beings simply aren't very good at the kind of reasoning
concurrent programming requires. Even most programmers handle it
poorly. Thus, while adding threading might be a fun stunt for someone
at the mastery level of Hal or Gary or myself, it's a burden we should
think twice about laying on our successors.
All this comes under one of the least obvious but most important jobs
of a system architect - *defending simplicity*.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel