[TUHS] PDP-11 legacy, C, and modern architectures
Perry E. Metzger
perry at piermont.com
Sat Jun 30 02:09:42 AEST 2018
On Fri, 29 Jun 2018 16:32:59 +0100 tfb at tfeb.org wrote:
> On 28 Jun 2018, at 18:09, Larry McVoy <lm at mcvoy.com> wrote:
> > I'm not sure how people keep missing the original point. Which
> > was: the market won't choose a bunch of wimpy cpus when it can
> > get faster ones. It wasn't about the physics (which I'm not
> > arguing with), it was about a choice between lots of wimpy cpus
> > and a smaller number of fast cpus. The market wants the latter,
> > as Ted said, Sun bet heavily on the former and is no more.
> [I said I wouldn't reply more: I'm weak.]
> I think we have been talking at cross-purposes, which is probably
> my fault. I think you've been using 'wimpy' to mean 'intentionally
> slower than they could be' while I have been using it to mean 'of
> very tiny computational power compared to the power of the whole
> system'. Your usage is probably more correct in terms of the way
> the term has been used historically.
> But I think my usage tells you something important: that the
> performance of individual cores will, inevitably, become
> increasingly tiny compared to the performance of the system they
> are in, and will almost certainly become asymptotically constant
> (ie however much money you spend on an individual core it will not
> be very much faster than the one you can buy off-the-shelf).
You've touched the point with a needle. This is exactly what I was
getting at. It's not a question of whether you want a better single
CPU or not, they don't exist, and one CPU is a tiny fraction of the
power in a modern distributed or parallel system.
> So, if you want to keep seeing performance improvements (especially
> if you want to keep seeing exponential improvements for any
> significant time), then you have no choice but to start thinking
> about parallelism.
> The place I work now is an example of this. Our machines have the
> fastest cores we could get. But we need nearly half a million of
> them to do the work we want to do (this is across three systems).
And that's been the case for a long time now. Supercomputers are all
giant arrays of CPUs, there hasn't been a world-beating single core
supercomputer in decades.
> I certainly don't want to argue that choosing intentionally slower
> cores than you can get is a good idea in general (although there
> are cases where it may be, including, perhaps, some HPC workloads).
And anything where power usage is key. If you're doing something that
computationally requires top-end single core performance you run the
4GHz core. Otherwise, you save a boatload of power and also
_cooling_ by going a touch slower. Dynamic power rises as the square
of the clock rate so you get quite a lot out of backing off just a
But it doesn't matter much even if you want to run flat out, because
no single processor can do what you want any more. There's a serious
limit to how much money you can throw at the vendors to give you a
faster core, and it tops out (per core) at a lot less than you're
paying your top engineers per day.
> However let me add something about the Sun T-series machines, which
> were 'wimpy cores' in the 'intentionally slower' sense. When these
> started appearing I worked in a canonical Sun customer at the time:
> a big retail bank. And the reason we did not buy lots of them was
> nothing to do with how fast they were (which was more than fast
> enough), it was because Sun's software was inadequate.
Your memory of this is the same as mine. I was also consulting to quite
similar customers at the time (most of my career has been consulting
to large investment banks. Haven't done much on the retail side though
that's changed in recent years.)
> (As an addentum: what eventually happened / is happening I think is
> that applications are getting recertified on Linux/x86 sitting on
> top of ESX, *which can move VMs live between hosts*, thus solving
> the problem.)
At the investment banks, the appetite for new Sun hardware when cheap
Linux on Intel was available was just not there. As you noted, too
many eggs in one basket was one problem, but another was the
combination of better control on an open source OS and just plain
cheaper and (by then sometimes even nicer) hardware.
Sun seemed to get fat in the .com bubble when people were throwing
money at their stuff like crazy, and never quite adjusted to the fact
that the world was changing and people wanted lots of cheap boxes more
than they wanted a few expensive ones.
Perry E. Metzger perry at piermont.com
More information about the TUHS