[Beowulf] Opinions of Hyper-threading?

[Bruno Coutinho]

2008/2/27, Mark Hahn <hahn at mcmaster.ca>:
>
> > alternatives?  Well, at the instruction level, we have the VLIW --
> > prepacked workloads known not to intefer with each other. What about at
> the
>
> there's a good reason VLIW never made much of a splash - even EPIC is
> pretty much past-tense.  the reason is that static schedules don't work
> well with things like caches or even early-out ALU's.  they are fine
> when your ops are consistent/deterministic in execution time - heck,
> we should consider VLIW to be a sort of mixed-grill SIMD or vector
> approach.


Another alternative to multicore and multithreading is replicating parts of
the core.
In multithreading you replicate nothing, in multicore you replicate
everyting, but you can replicate only smallest or most used core components.
Sun did it in Niagera 2: each core has two integer execution units.

as far as I can tell, current GPUs are an example of how far this can be
> taken, and at what cost.  you get a set of very in-order core-like units
> whose memory model is massively constrained by the need to remain in
> lock-step.
> very good for data-parallel workloads like graphics, but not as easy to
> apply to more complicated data access patterns or conditional flows.
>
> (since I'm ranting about GPUs, I'm really surprised those guys haven't
> dived deeply into the processor-in-memory model.  I guess it says
> something
> significant about how differently specialized cpu vs dram fabs are.
> especially when you consider that GPU boards use custom for-GPU-only
> dram.)
>

As far I know GPUs access large amounts of data (most of it is textures) in
regular streams with relatively low frequency (once each frame). Most time
they only need very high throughput.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20080227/de2880be/attachment.html>