<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-15">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 01/30/2018 03:49 PM, D. Hugh Redelmeier via talk wrote:<br>
<blockquote type="cite"
cite="mid:alpine.LFD.2.21.1801301421390.25877@redeye.mimosa.com">
<pre wrap="">[I speak as if I'm an expert, but I'm not. Beware.]
| From: Alvin Starr via talk <a class="moz-txt-link-rfc2396E" href="mailto:talk@gtalug.org"><talk@gtalug.org></a>
| To: <a class="moz-txt-link-abbreviated" href="mailto:talk@gtalug.org">talk@gtalug.org</a>
|
| A number of groups have tried to develop extremely parallel processors but all
| seem to have gained little traction.
|
| There was the XPU 128, the Epiphany(<a class="moz-txt-link-freetext" href="http://www.adapteva.com/">http://www.adapteva.com/</a>) and more
| recently the Xenon Phi and AMD Epyc.
GPUs are extremely parallel by CPU standards. And they certainly are
getting traction.
This shows that you may have to grow up in a niche before you can
expand into a big competitive market.
- GPUs were useful as GPUs and evolved through many generations
- only then did folks try to use them for more-general-purpose
computing
Downside: GPUs didn't have a bunch of things that we take for granted
in CPUs. Those are gradually being added.</pre>
</blockquote>
A little over 30 years ago I was with a company where we developed
what may have been one of the first GPU like systems.<br>
We used a number of fixed point DSP's to build a parallel graphics
display system.<br>
At the time the conventional wisdom was that you could not use
parallelism in graphics rendering.<br>
A few years after I left the company I was told that they had sold a
number these systems based on a floating point DSP design we were
working on to a company to replace their very expensive array
processors used in MRI systems.<br>
<blockquote type="cite"
cite="mid:alpine.LFD.2.21.1801301421390.25877@redeye.mimosa.com">
<pre wrap="">
Another example: ARM is just now (more than 30 years on) targeting
datacentres. Interestingly, big iron has previously mostly been
replaced by co-ordinated hordes of x86 micros.
| At one point I remember reading a article about sun developing an asynchronous
| CPU which would be interesting.
Yeah, and many tried Gallium Arsenide too. That didn't work out,
probably due to the mature expertise in CMOS. I guess you could say
it was also due to energy efficiency being more important that speed
(as things get faster, they get hotter, and even power-sipping CMOS
reached the limit of cooling).
The techniques of designing and debugging asynchronous circuits are
not as well-developped as those for syncronous designs. That being
said, clock distribution in a modern CPU is apparently a large
problem.</pre>
</blockquote>
A little bit of searching to try and bolster my fading memory found
that there have been a few asynchronous CPUs developed over the
years.<br>
For example the Caltech miniMIPS processor, The AMULET1,2,3 and
strangely enough the ILLIAC-II.<br>
Another solution is Globally Asynchronous Locally Synchronous
processes which can get around the problems of synchronizing devices
across very large die sizes.<br>
But it looks like research died out in the early 2000's. <br>
<br>
<blockquote type="cite"
cite="mid:alpine.LFD.2.21.1801301421390.25877@redeye.mimosa.com">
<pre wrap="">
| All these processors run into the same set of problems.
| 1) x86 silicon is amazingly cheap.
Actually, this points to an opening.
Historically, Intel has been a node or so ahead of all other silicon
fabs. This meant that their processors were a year or two ahead of
everyone else on the curve of Moore's law.
That meant that even when RISC was ahead of x86, the advantage was
precarious. Eventually, the vendors threw in the towel: lots of risk
with large engineering costs and relatively low payoffs. Some went to
the promise of Itanium (SGI, HP (who had eaten Apollo and Compaq (who
had eaten DEC)). Power motors on but has shrunk (loosing game
machines, automotive (I think), desktops and laptops (Apple), and
workstations). SPARC is barely walking dead except for contractual
obligations.
But now, with Moore's Law fading for a few years, maybe smaller
efficiency gains start to count. RISC might be worth reviving. But
the number of transistors on a die mean that the saving by making a
processor core smaller doesn't count for a lot. Unless you multiply it by
a considerable constant: many processors on the same die.
The Sun T series looked very interesting to me when it came out. It
looked to me as if the market didn't take note. Perhaps too many had
already written Sun off -- at least to the extent of using their
hardware for new purposes. Also Sun's cost structure for marketing
and sales was probably a big drag.
| 2) supporting multiple CPUs cause more software support for each
| new CPU architecture.
That hurt RISC, but the vendors knew that they were limited to
organizations that used UNIX and could recompile all their
applications. The vendors did try to broaden this but, among others,
Microsoft really screwed them. Microsoft promised ports to pretty
much all RISCs but failed to deliver with credible support on any.
Even AMD's 64-bit architecture was screwed by Microsoft. Reasonable
64-bit Windows was promised to AMD for when they shipped (i.e. before
Intel shipped) but 64-bit Windows didn't show up within the useful
lifetime of the first AMD 64-bit chips.</pre>
</blockquote>
We were working with DEC around this time and got a peek into the
inability of microsoft to build a 64bit OS.<br>
Fortunately Linux was quickly ported to the Alpha.<br>
We build up and ran a number of Alpha based systems for lots of
years.<br>
<br>
<blockquote type="cite"
cite="mid:alpine.LFD.2.21.1801301421390.25877@redeye.mimosa.com">
<pre wrap="">
| 3) very little software is capable of truly taking advantage of many
| parallel threads without really funky compilers and software design tools.
A lot of software, by cycles consumed, can use parallelism.
The Sun T series was likely very useful for running Web front-ends,
something that is embarrassingly parallel.</pre>
</blockquote>
Most web applications tend to be single threaded but overall they
can gain gross parallelism by replication.<br>
Just like checkout counters at a big box store.<br>
<blockquote type="cite"
cite="mid:alpine.LFD.2.21.1801301421390.25877@redeye.mimosa.com">
<pre wrap="">
Data mining folks seem to have used map/reduce and the like to allow
parallel processing.
GPUs grew up working on problems that are naturally parallel.
What isn't easy to do in parallel is a program written in our normal
programming languages: C / C++ / JAVA / FORTRAN. Each has had
parallelism bolted on in a way that is not natural to use.</pre>
</blockquote>
People in general don't deal well with parallelism.<br>
Back to my checkout counter metaphor.<br>
Imagine if you can a checkout person trying to handle 2 shopping
carts at the same time.<br>
<br>
Programming languages have tried over the years to build various
constructs to handle concurrency.<br>
Semaphores, Monitors, Locks, Token passing but none of them have
seemed to catch on outside restricted applications.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:alpine.LFD.2.21.1801301421390.25877@redeye.mimosa.com">
<pre wrap="">
| 4) having designed a fancy CPU most companies try very hard to keep their
| proprietary knowledge all within their own control where the x86 instruction
| set must be just about open source now days.
No. There are a very few license to produce x86 processors. Intel,
AMD, IBM, and a very few others that were inherited from dead
companies. For example, I think Cyrix (remember them?) counted on
using IBM's license through using IBM's fab (IBM no longer has a fab).
I don't remember how NCR and Via got licenses. AMD's license is the
clearest and Intel tried to revoke it -- what a fight!
RISC-V looks interesting.</pre>
</blockquote>
I was sure that I had seen a number of low end SoC type products but
it is easy to believe that X86 is tied up or it just may be that the
instruction set is clonealbe but the cost of getting a product out
far outweighs the money that could be gained by selling a me too
product.<br>
I noticed the RISC-V a little while ago and thought it was an
interesting idea.<br>
<br>
<blockquote type="cite"
cite="mid:alpine.LFD.2.21.1801301421390.25877@redeye.mimosa.com">
<pre wrap="">
| 5) getting motherboard manufacturers to take a chance on a new CPU is not
| an easy thing.
It's not clear whether this matters much. It matters for workstations
but that isn't really a contested space any longer. Even though you
and I care.</pre>
</blockquote>
If your not buying HP,Lenovo or some other main line manufacturer
then your looking at systems build on motherborads from the likes of
Tyan,Supermicro, Asus and Gigabyte.<br>
If they don't pick up a CPU then your looking at highly custom small
run products from niche manufacturers.<br>
<blockquote type="cite"
cite="mid:alpine.LFD.2.21.1801301421390.25877@redeye.mimosa.com">
<pre wrap="">
| Even people with deep pockets like DEC with their Alpha CPU and IBM with their
| Power CPUs have not been able to make a significant inroad into the commodity
| server world.
In retrospect, we all know what they should have done. But would that
have worked? Similar example: Nokia and BlackBerry were in similar
holes and tried different ways out but neither worked.
Power was widely adoped (see above).
The Alpha was elegant. DEC tried to build big expensive systems.
This disappointed many TLUGers (as we were then known) because that's
not we'd dream of buying. Their engineering choices were the opposite
of: push out a million cheap systems to drive forward on the learning
curves. HP was one of the sources of the Itanium design and so when
they got Compaq which had gotten DEC, it was natural to switch to
Itanium.
(Several TLUGers had Alpha system. The cheapest were pathetically
worse than PCs of the time (DEC crippled them so as not to compete
with their more expensive boxes). The larger ones were aquired after they
were obsolescent. Lennart may still have some.)</pre>
</blockquote>
The Alpha boards were a bit high end and by the time they got in the
price range that TLUGers were willing to afford they were obsolete
but it was still possible to buy high end boards if you were willing
to spend some real cash.<br>
<blockquote type="cite"
cite="mid:alpine.LFD.2.21.1801301421390.25877@redeye.mimosa.com">
<pre wrap="">
Itanium died for different reasons.
- apparently too ambitious about what compilers could do (static
scheduling). I'd quibble with this.
- Intel never manufactured Itanium on the latest node. So it always
lost some speed compared with x86. Why did they do this? I think
that it was that Innovators Dilemma stuff. The x86 fight with AMD
was existential and Itanium wasn't as important to them.
- customers took a wait and see attitude. As did Microsoft.</pre>
</blockquote>
I would argue that Intel has not designed a successful new processor
since the 8086.<br>
From the 8086 to here has just been incremental changes with a few
failed projects along the way.<br>
The current x86_64 was ripped off from AMD while Intel tried to
push the Itanium.<br>
<br>
<blockquote type="cite"
cite="mid:alpine.LFD.2.21.1801301421390.25877@redeye.mimosa.com">
<pre wrap="">
| Mips has had some luck with low to mid range systems for routers and storage
| systems but their server business is long gone with the death of SGI.
No, SGI switched horses. Itanium and, later, x86.</pre>
</blockquote>
I was thinking more about Mips being used for controller designs and
less as Mips as a company supplying SGI.<br>
Once SGI dropped them they were dead as a workstaion/server CPU.<br>
<blockquote type="cite"
cite="mid:alpine.LFD.2.21.1801301421390.25877@redeye.mimosa.com">
<pre wrap="">
MIPS just seemed lucky to fall into the controller business, but it
seems lost now. Replaced by ARM.
| Sun/Oracle has had some luck with the Sparc but not all that much outside
| their own use and I am just speculating but I would bet that Sun/Oracle sells
| more x86 systems than Sparc systems.
Fun fact: Some older Scientific Atlanta / Cisco Set Top Boxes for
cable use SPARC. Some XEROX copiers did too.
| ARM seems to be having some luck but I believe that luck is because of their
| popularity in the small computer systems world sliding into supporting larger
| systems and not by being designed for servers from the get go.
Right. Since power matters so much in the datacentre, lots of
companies are trying to build suitable ARM systems. Progress is
surprisingly slow. AMD is even one of these ARM-for-datacentre
companies.</pre>
</blockquote>
Part of the argument for ARM in the data center is that you can run
small services on small processors that use little power.<br>
The other choice is to run a big processor and then slice it up with
some kind of virtualization or containerizing.<br>
<br>
<blockquote type="cite"
cite="mid:alpine.LFD.2.21.1801301421390.25877@redeye.mimosa.com">
<pre wrap="">
| I am a bit of a processor geek and have put lots of effort in the past into
| elegant processors that just seem to go nowhere.
| I would love to see some technologies other than the current von Neumann
| somewhat parallel SMP but I have a sad feeling that that will be a long time
| coming.
Interesting hopefuls include:
- GPUs
- FPGAs stuck on motherboards (eg. Intel can fit (Xilinx?) FPGAs in a
processor socket of a multi-socket server motherboard.
- neural net accelerators.
- The Mill (dark horse)
<a class="moz-txt-link-rfc2396E" href="https://en.wikipedia.org/wiki/Mill_architecture"><https://en.wikipedia.org/wiki/Mill_architecture></a>
- quantum computers
- wafer-scale integration
| With the latest screw-up from Intel and the huge exploit surface that is the
| Intel ME someone may be able to get some traction by coming up with a
| processor that is designed and verified for security.
You only have to be as secure as "best practices" within your
industry. Otherwise Windows would have died a generation ago.
There are security-verified processors for the military. Expensive
and obsolete by our standards.</pre>
</blockquote>
There was an interesting ACM article recently about adding a few
transistors after the chip layout phase and before manufacture to
introduce security holes that are opened by specific execution
patterns.<br>
<blockquote type="cite"
cite="mid:alpine.LFD.2.21.1801301421390.25877@redeye.mimosa.com">
<pre wrap="">
Not enough customers are willing to pay even the first price for security:
simplicity. That's before we even get to the inconvenience issues.
Security does not come naturally. Todays Globe and Mail reported:
<a class="moz-txt-link-rfc2396E" href="https://www.theglobeandmail.com/news/world/fitness-devices-can-provide-locations-of-soldiers/article37764423/"><https://www.theglobeandmail.com/news/world/fitness-devices-can-provide-locations-of-soldiers/article37764423/></a>
<a class="moz-txt-link-rfc2396E" href="https://www.theverge.com/2018/1/28/16942626/strava-fitness-tracker-heat-map-military-base-internet-of-things-geolocation"><https://www.theverge.com/2018/1/28/16942626/strava-fitness-tracker-heat-map-military-base-internet-of-things-geolocation></a></pre>
</blockquote>
Ya. I loved that little problem. Its side channel data leakage like
some of the videos posted here.<br>
Just think of what is getting let out to the world when you ask
Alexa to turn up your Nest thermostat?<br>
<blockquote type="cite"
cite="mid:alpine.LFD.2.21.1801301421390.25877@redeye.mimosa.com"><br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">---
Talk Mailing List
<a class="moz-txt-link-abbreviated" href="mailto:talk@gtalug.org">talk@gtalug.org</a>
<a class="moz-txt-link-freetext" href="https://gtalug.org/mailman/listinfo/talk">https://gtalug.org/mailman/listinfo/talk</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Alvin Starr || land: (905)513-7688
Netvel Inc. || Cell: (416)806-0133
<a class="moz-txt-link-abbreviated" href="mailto:alvin@netvel.net">alvin@netvel.net</a> ||
</pre>
</body>
</html>