<br><br><div><span class="gmail_quote">2008/2/27, Mark Hahn <<a href="mailto:hahn@mcmaster.ca">hahn@mcmaster.ca</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> alternatives?  Well, at the instruction level, we have the VLIW --<br> > prepacked workloads known not to intefer with each other. What about at the<br> <br> there's a good reason VLIW never made much of a splash - even EPIC is<br>
 pretty much past-tense.  the reason is that static schedules don't work<br> well with things like caches or even early-out ALU's.  they are fine<br> when your ops are consistent/deterministic in execution time - heck,<br>
 we should consider VLIW to be a sort of mixed-grill SIMD or vector approach.</blockquote><div><br>Another alternative to multicore and multithreading is replicating parts of the core.<br>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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> as far as I can tell, current GPUs are an example of how far this can be<br> taken, and at what cost.  you get a set of very in-order core-like units<br>
 whose memory model is massively constrained by the need to remain in lock-step.<br> very good for data-parallel workloads like graphics, but not as easy to<br> apply to more complicated data access patterns or conditional flows.<br>
 <br> (since I'm ranting about GPUs, I'm really surprised those guys haven't<br> dived deeply into the processor-in-memory model.  I guess it says something<br> significant about how differently specialized cpu vs dram fabs are.<br>
 especially when you consider that GPU boards use custom for-GPU-only dram.)<br></blockquote></div><br>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.<br>
<br>