CASTalk.com

Guest · Posted: Mon Dec 26, 2005 9:15 am Post subject: TLP-oriented design and HPC

Would a TLP-oriented design be able to attract HPC customers away
from common ILP-oriented designs?

Obviously a design like Sun's Niagara (T1000 and T2000) would
not be appropriate; however, by avoiding the overhead of OoO
execution, heavily ported register files, complex multiple result
forwarding, etc. it should be possible to increase the proportion
of the die area used for functional units (thereby increasing the
potential throughput per chip) and decrease power consumption
(thereby further increasing potential compute density). It seems
that some of the problems that benefit from Tera-style
multithreading would be suitable to a system composed of chips
with many small and simple cores. However, it is not clear
whether (even with a shared on-chip level of caching)
communication overhead would overcome the benefits from more
FPUs. The success of Blue Gene hints that smaller, simpler cores
can be useful for HPC; however, Blue Gene uses paired value FPUs
to substantially increase per-core compute potential. (It might
be interesting to compare performance for various HPC workloads
between an in-order ILP-oriented design like current IPF systems
and an in-order TLP-oriented design like Piranha [an 8-core
scalar Alpha design].)

(While the HPC market is not especially large; it might be more
receptive to more exotic designs than the OLTP server market or
even the web/mail server market, allowing an initial product to
more easily break even. Obviously Sun feels its brand and good
benchmark results can sell a peculiar design to enough server
customers to make a profit without needing to appeal to the HPC
market.)

If HPC customers are appropriately viewed as a significant part
of the target market for a TLP-oriented design (say 20% of
sales), what would be the characteristics of such a design in
order to provide superior HPC performance per monetary unit and
per unit volume without excessively sacrificing performance for
the other 80% of the targeted market?

Limited two-wide issue might provide substantially improved
performance with minimal area increase (e.g., adding one FPR
read/write port would allow any non-dependent combination of one
GPR-using instruction [including FPR load and store] and one
FPR-using instruction; the dependency check logic could be shared
if each Icache had an additional predecode bit per aligned
instruction pair indicating if LIW-like operation is possible).
Even supporting somewhat more aggressive two-wide issue might not
cost much for a significant performance increase (30%??) (e.g.,
separating the LSU, ALU, and branch unit and providing one more
GPR read port and one more GPR write port could allow substantial
flexibility). (It might not even be especially expensive to
provide simultaneous issue of a load and a 64-bit store or
prefetch instruction [i.e., a memory operation that does not
require reading, assuming ECC is over 64-bit words]. Having a
separate stack cache might be worthwhile--not only increasing
potential issue width at modest cost but also increasing
effective associativity of the data cache.) Providing SMT would
make more general two-wide issue attractive by increasing
utilization.

Unfortunately, it becomes very easy to sacrifice area (and
therefore the number of cores) for increased per-core
performance. However, I am guessing that moderately aggressive
multiple issue (branch, ALU, load/store, load/store stack, and
FP/SIMD op; two-wide fetch) with SMT would provide greater than
50% throughput increase for less than 50% core size increase
(with a greater than 50% increase in design complexity :-\).

Using 128-bit registers for FP and integer SIMD operations,
separating them into high and low banks, and sharing the SIMD
functional units between two cores (where low bank for core A
would be the high bank for core B) could allow one SIMD operation
from either core or one 64-bit wide operation from both cores to
issue simultaneously. Widening the data cache interface might be
a little expensive, but could provide single-cycle load/store GPR
pair operations as well as load/store SIMD register (i.e., it is
not only a HPC improvement). Providing 32-byte-wide loads and
stores between 'aligned' 64-bit register quads (or 'aligned'
128-bit register pairs) and a small fully associative write
buffer/prefetch cache might be a relatively inexpensive way to
increase potential cache<->register bandwidth; even some server
code could probably use this form of increased bandwidth.

Using FP/SIMD register space to store most of a small-context
thread's processor state might allow switching among such
small-context threads to be relatively rapid (perhaps 8 cycles?)
without greatly increasing core area (only adding a few registers
to hold additional state). Even 16-cycle fully-dead-time context
switches might be acceptable for many uses.

By avoiding register renaming and implementing SMT, some
interesting register file banking possibilities exist. E.g.,
even register quads can be somewhat easily read/written and one
could guarantee that instructions from different threads would
not have bank conflicts. (Of course, SMT makes code optimization
more complex. Result latencies can be halved with two-way SMT,
but cache associativity and size can also be effectively halved.)

(An interesting note on Piranha: the Icaches were snooped and
coherence is provided as an artifact of using the same basic
design for the Icache and the Dcache. This might make have a
significant positive effect on Java engines that use JIT
compilation.)

Paul A. Clayton
just a technophile with diarrhea of the keyboard

Guest · Posted: Tue Dec 27, 2005 1:15 am Post subject: Re: TLP-oriented design and HPC

Anton Ertl wrote:
[snip]

Anton Ertl · Guest

Dysthymicdolt@aol.com writes:

David Kanter · Guest

Iain McClatchie wrote:

Eugene Miya · Guest

Just passing thru...

In article <1135582492.507874.298300@f14g2000cwb.googlegroups.com>,
<Dysthymicdolt@aol.com> wrote:

Dr. Adrian Wrigley · Guest

On Tue, 27 Dec 2005 12:24:37 -0800, Iain McClatchie wrote:

....

Iain McClatchie · Guest

Paul> Would a TLP-oriented design be able to attract HPC customers away
Paul> from common ILP-oriented designs?

As Anton says, the problem is memory bandwidth.

The solution to the memory bandwidth problem is GPU-style memories:
572-bit, 8- or 16-channel GDDR memory systems, but using 4 bits or
maybe even 1 bit per DRAM rather than 32. This can get the basic
ASIC+DRAM+buffers cluster to 16-64 GB of DRAM and 40 GB/s
peak bandwidth with existing technology. (Mmmm... subject to the
availability of 4 or 1 bit wide GDDR3 parts, which might be as trivial
as a bond-out change for the memory manufacturers.)

We have to leave behind the concept of DIMM sockets and
post-production configurable memories. The unit we buy from AMD
(and later, Intel) will be like a graphics card, except that it may
likely have "fins" with DRAM on them, like DIMMs but without the
air-blockage and impedance mismatch of the DIMM socket.

Well, the HPC version will have fins. The consumer version with 1-2
GB will just have surface-mounted DRAMs.

Beyond that, memory will have to be very nonuniform, as the PU
clusters will be linked by high-speed interconnects. The Xbox 360
folks are showing the way with their 10.8 GB/s each direction link
on the GPU. An HPC ASIC in today's technology might manage
two of those.

Thread scheduling and dispatch are going to become more GPU
like, with ganged instruction fetch. I can see datapaths which
execute 64 threads simultaneously on the same code path. An
"IF" branch on the code path causes the fetch system to fetch
and distribute both paths, and each of the 64 clusters grabs ops
fromt the appropriate stream depending on which way the local
branch went. This kind and size of datapath is shipping today.
The challenge is to figure out how to marry it to HPC codes
without disabling changes to either.

	CASTalk.com Forum Index -> Computer Architecture	All times are GMT
Page 1 of 1