[TUHS] Evolutionary Paths (was Gnu/Stallman (was Bugs in V6 'dcheck'))

[lm@mcvoy.com (Larry McVoy)]

First, let me say how cool it is to be replying to the guy who did yacc.
I've used it for decades, thank you for that.

I was at SGI when they did the Origin servers, the architecture (as I
remember it) was a board with 2 CPUS, some local memory, and an connection
to a hypercube style of memory.  An interesting aside is that this is
where I learned that infinitely large packets in a network are infinitely
stupid because you have to buffer a packet if the outgoing port is busy.
I used to be a fan of big packets on ethernet, that system taught me
that ethernet is just fine.  The Origin "network" had ~32 byte packets.
Buffering those was "easy".

The problem with the lots-of-cpus design is that memory latency goes up.
It was OK for local memory, it was not OK for remote memory.  Don't get
me wrong, SGI did a really great job at it, but when you compare a bunch
of networked boxes with the SMP model SGI had, SGI won on jobs that needed
shared memory, the bunch of networked boxes kicked ass on everything else.
Cross reference: google.  Intel's test harness.  And a bunch of others.
When you are benchmarking against a 10,000 node cluster and the cluster
is winning, yeah, you need to rethink what you are doing.

I've copied Greg Chesson, you guys should know him, he's ex Bell Labs,
he can correct my ramblings, I worked for him at SGI.

--lm

On Tue, Jun 03, 2014 at 11:48:25AM -0700, scj at yaccman.com wrote:
> Well, I'm sure my biases are showing, but I see the Kernel as a means for
> supplying features for a model of computation, and the programming
> language as the delivery vehicle for that model of computation.  And in my
> view, C/C++ is far more obsolete than Linux.
> 
> Hardware has left software in the dust.  It is quite feasible to produce a
> chip with 1000 or 10,000 processors on it, each with a bit of memory and a
> communication fabric.  That's what tomorrow's technology is giving us. 
> Multicore and named threads are just not going to cut it when using such a
> system.  A central supplier of any service is a bottleneck.  We've got to
> write our software to act more like an ant farm than a military hierarchy.
> 
> Otherwise said, we have to learn to think different.  Very different.  And
> the hardest part of that is letting go of the old ways of thinking. 
> Perhaps encroaching senility is help in this...
> 
> Steve