[Beowulf] Opinions of Hyper-threading?
Many of your questions may have already been answered in earlier discussions or in the FAQ. The search results page will indicate current discussions as well as past list serves, articles, and papers.
Mark Hahn hahn at mcmaster.caWed Feb 27 16:42:50 PST 2008
- Previous message: [Beowulf] Opinions of Hyper-threading?
- Next message: [Beowulf] Opinions of Hyper-threading?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 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. 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.)
- Previous message: [Beowulf] Opinions of Hyper-threading?
- Next message: [Beowulf] Opinions of Hyper-threading?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Beowulf mailing list
