SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Politics : Formerly About Advanced Micro Devices -- Ignore unavailable to you. Want to Upgrade?


To: Scumbria who wrote (59289)5/22/1999 2:06:00 PM
From: Charles R  Read Replies (2) | Respond to of 1572919
 
Scumbria,

"The multi-threading can be largely managed by the
compiler, and therefore does not require the high overhead of a multithreaded OS."

Wouldn't this overhead be increasingly irrelevant as processor ASPs drop and performance increases *assuming* a scalable OS?

"I don't see the verification of McKinley as being a big problem, in fact it will
probably be easier than any of their x86 CPUs (including Merced.)"

I should clarify/correct myself - what I meant was the challenge of tuning the compiler to a new CPU. i.e., not the function of the CPU itself but getting software to work on it. Would that change your response?

Chuck



To: Scumbria who wrote (59289)5/22/1999 5:09:00 PM
From: Gopher Broke  Read Replies (1) | Respond to of 1572919
 
I am confused as to how EPIC helps multi-threading. All it does is help the hardware to perform better by putting the onus on the compiler to rearrange the instructions for better pipelining of a single execution instance.

Multi-threading, as I understand the term, means different execution instances and I don't see how EPIC help here, except that making a single thread run faster obviously helps. I have not heard anyone suggest that the three co-packaged instructions could be associated with different threads. So servers will still be multithreading in the same way when running EPIC instructions.