[TUHS] PDP-11 legacy, C, and modern architectures

[Perry E. Metzger]

On Thu, 28 Jun 2018 14:42:47 -0600 Warner Losh <imp at bsdimp.com> wrote:
> > > Got a source that backs up that claim?  I was recently dancing
> > > with Netflix and they don't match your claim, nor do the other
> > > content delivery networks, they want every cycle they can get.  
> >
> > Netflix has how many machines?  
> 
> We generally say we have tens of thousands of machines deployed
> worldwide in our CDN. We don't give out specific numbers though.

Tens of thousands of machines is a lot more than one. I think the
point stands. This is the age of distributed and parallel systems.

> > Taking the other way of looking at it, from what I understand,
> > CDN boxes are about I/O and not CPU, though I could be wrong. I
> > can ask some of the Netflix people, a former report of mine is
> > one of the people behind their front end cache boxes and we keep
> > in touch.  
> 
> I can tell you it's about both. We recently started encrypting all
> traffic, which requires a crapton of CPU. Plus, we're doing
> sophisticated network flow modeling to reduce congestion, which
> takes CPU. On our 100G boxes, which we get in the low 90's
> encrypted, we have some spare CPU, but almost no space memory
> bandwidth and our PCI lanes are full of either 100G network traffic
> or 4-6 NVMe drives delivering content up at about 85-90Gbps.
> 
> Most of our other boxes are the same, with the exception of the
> 'storage' tier boxes. Those we're definitely hard disk I/O bound.

I believe all of this, but I think it is consistent with the point.
You're not trying to buy $100,000 CPUs that are faster than the
several-hundred-per-core things you can get, because no one sells
them. You're building systems that scale out by adding more CPUs
and more boxes. You might want very high end CPUs even, but the high
end isn't vastly better than the low, and there's a limit to what you
can spend per CPU because there just aren't better ones on the market.

So, all of this means that, architecturally, we're no longer in an
age where things get designed to run on one processor. Systems
have to be built to be parallel and distributed. Our kernels are
no longer one fast core and need to handle multiprocessing and all
it entails. Our software needs to run multicore if it's going to
take advantage of the expensive processors and motherboards we've
bought. Thread pools, locking, IPC, and all the rest are now a way of
life. We've got ways to avoid some of those things by using share
nothing and message passing, but even so, the fact that we've
structured our software to deal with parallelism is unavoidable.

Why am I belaboring this? Because the original point, that language
support for building distributed and parallel systems does help,
isn't wrong. There are a lot of projects out there using things like
Erlang and managing nearly miraculous feats of uptime because of it.
There are people replacing C++ with Rust because they can't reason
about concurrency well enough without language support and Rust's
linear types mean you can't write code that accidentally shares
memory between two writers by accident. The stuff does matter.

Perry
-- 
Perry E. Metzger		perry at piermont.com