Re: 6502 illegal opcodes questions

["mdj" <mdj.mdj@gmail.com>]

Michael J. Mahon wrote:

> The big "open door" opportunity is multiprocessor parallelism, but
> we have invested so little in learning to apply parallelism that it
> remains esoteric.  (But AppleCrate makes it easy to experiment with! ;-)

Parallelism is the big door, but I think the approaches that need to be
explored cover a wider gamut than multiprocess parallelism, which as
you point of has considerable latency issues.

> The popular "thread" model, in which all of memory is conceptually
> shared by all threads, is a disaster for real multiprocessors, since
> they will *always* have latency and bandwidth issues to move data
> between them, and a "single, coherent memory image" is both slow
> and wasteful.

It is however an extremely efficient form of multiprocessing for
applications with modest horizontal scaling potential.

There's essentially 3 basic models for parallelism that must be
exploited:

Multithread - in which one processor core can execute multiple threads
simultaneously
Uniform Memory Multiprocessor - in which many processsor cores share
the same physical memory subsystem. Note that this is further divided
into multiple cores in the same package, plus other cores in different
packages, which have very different latency properties.
Non Uniform Memory Multiprocessor - In this case the latency can vary
wildly depending on the system configuration.

Modern multiprocessor servers employ all three approaches, both on the
same system board, plus via high speed interconnects that join multiple
system boards together. OS's must weight the 'distance' to another CPU
when considering a potential execution unit for a process.

What's slow and wasteful depends a great deal on the task at hand.
Multithreading used to be just as expensive as multiprocessing. But
consider a current generation CPU designed for low power, high
concurrency, the UltraSPARC T1.

These units have execution cores cable of running 4 concurrent threads.
In the highest end configuration, there are 8 of these execution cores
per physical processor. The cores have a 3.2GB/s interconnect. Each
physical processor has 4 independant memory controllers, so you have
non-uniform memory access on the one die.

Peak power consumption for this part is 79W at 1Ghz. Considering you
can in theory run 32 threads simulaneously, that's pretty impressive.
How well you can exploit it depends on your application. An 'old
school' web server for instance, can only get 8 way parallelism on this
chip. A new school web server written in Java, can get 32 way, assuming
at any given time there is at least 32 concurrent requests for the same
dynamic page, or 32 static requests.

It's getting to the stage where the power consumed by driving I/O over
a pin on an IC package is significant, so expect to see systems like
this grow in popularity.

Interesting, you can download a VHDL description of this part from Sun,
and synthesise it on one of the higer end FPGA's. Oh how I wish I had
access to hardware like that!

A top of the range Sun server uses parts that have 4 execution threads
per core, four cores per board, each with it's own memory
controller+memory, and up to 18 boards per system (coupled together by
an 9GB/s crossbar switch). Exploiting all the resources in this system
and doing it efficiently is *hard*, as it employs every different style
of parallelism I mentioned before within the same 'machine'.

And I haven't even considered computing clusters!

The way it's panning out is that real multiprocessors are a disaster
for parallelism. The problem is that essentially any task that can be
parallelised needs to process the same data that it does in serial
form. Because of this, you can utilise the same buses, I/O subsystems,
and take advantage of 'nearness' to allow some pretty incredible IPC
speeds.

Multithreading approaches are very important on these systems. In fact,
multithreading is important even on systems with single execution
units. The gap between I/O throughput and processing throughput means
you get a certain degree of 'parallelism' even though you can only run
one thread at a time. Free performance improvement if you employ
parallel design techniques.

Of course, there are certain heavily compute-bound applications where
the degree of IPC is very low, and massive parallelism is possible
regardless of the interconnect used, as IPC constitutes a relatively
small part of the workload. For the rest of the cases though where lots
of data is being consumed, systems that allow low-overhead IPC through
multithreading are the way to go.

Matt