Weber's Thoughts on Cell

Ever since its official introduction, we've been going around asking everyone we ran into about their thoughts on IBM/Sony/Toshiba's Cell microprocessor, and Fred Weber was no different.  Surprisingly enough, Weber's response to the Cell question was quite similar to Justin Rattner's take on Cell.  Weber saw two problems with Cell:
  1. Cell is too far ahead of its time in terms of manufacturing, and
  2. Cell is a bit too heterogeneous in its programming model, referring to Cell's approach as both asymmetric and heterogeneous (we'll explain this in a bit).
As we concluded in our Cell investigation, the approach to microprocessor design of having one general purpose core surrounded by several smaller cores is not one that is unique to Cell.  Intel has now publicly stated that this heterogeneous multi-core approach is, at a high level, something that they will be pursuing in the next decade.  The problem is that to be produced on a 90nm process, the individual cores that make up Cell has to be significantly reduced in complexity, which Weber saw as an unreasonable sacrifice at the current stage. 

The next problem that Weber touched on was the Cell approach to a heterogeneous multi-core microprocessor.  To Fred Weber, a heterogeneous multi-core microprocessor is one that has a collection of cores, each one of which can execute the same code, but some can do so better than others - the decision of which to use being determined by the compiler.  Weber referred to his version of heterogeneous multi-core as symmetric in this sense.  Cell does not have this symmetric luxury; instead, all of their cores are not equally capable and thus, in Weber's opinion, Cell requires that the software needs to know too much about its architecture to perform well.  The move to a more general purpose, symmetric yet heterogeneous array of cores would require that each core on Cell must get bigger and more complex, which directly relates back to Weber (and our) first problem with Cell that it is too far ahead of its time from a manufacturing standpoint. 

Index The K8 is here to stay
Comments Locked

35 Comments

View All Comments

  • Filibuster - Thursday, March 31, 2005 - link

    ...but...its HYPER!

    #11 it can also decrease performance by 10-50% depending on the application. Clearly it matters what you're doing with your PC.

    http://www.digit-life.com/articles/pentium4xeonhyp...

    I think Fred is talking about the inconsistant gains/losses. Its not the best way to spend transistors.
  • fitten - Thursday, March 31, 2005 - link

    #13, HT is kind of like hardware allowing context switching at instruction speed levels. Tyipcally, a thread that stalls on IO (like a hard drive) or something gets swapped out and another thread runs until the IO request completes. However, if a thread just can't use a cache well (streaming data, for example) all of those stalls due to memory loads just cause the CPU to sit and wait. These stalls are on the order of 10s of clock cycles. Other IO is on the order of 1000s of clock cycles (or more). A context switch is on the order of 100s of clock cycles. Obviously, you don't want to swap threads just because of a L2 cache miss. However, HT allows two thread contexts to be loaded so that when one thread stalls on a L2 cache miss, for example, the other thread can execute instructions with no delay. It's like shuffling cards. Basically, it allows the CPU to execute two contexts on the granularity of a clock cycle or two rather than on 100s of clock cycles.

    So, as an example, the worst case for a thread is that every piece of data it wants will generate an L2 cache miss. On a non-HT processor, this means that this thread will not be swapped out until its scheduling quantum is met. But, during that time, the CPU will in effect be idle for probably 90% of the time due to all the cache misses. Since the thread won't be swapped out, your CPU will effectively be used for only 10% of the time during that quantum, then the next thread is allowed to run. With HT, both threads are loaded and those 90% of the cycles that the "bad" thread would waste can actually be used by the other thread.
  • xtknight - Thursday, March 31, 2005 - link

    #11-not sure what you mean by "processing efficiency". all HT does is virtually separate the processor into two threads. maybe I'm missing something, but I can't figure out why everyone associates HT with performance gain.
  • PeteRoy - Thursday, March 31, 2005 - link

    The future of processors is Software that make use of them.
  • hectorsm - Thursday, March 31, 2005 - link

    Does anyone know why Fred thinks that HT is a misuse of resources?

    Doesn't HT increase processing efficiency by 10-30%?

    Sounds to me like he got it backward.
  • xsilver - Thursday, March 31, 2005 - link

    Could it be that possibly the reason for the slowdown in clock increases is not due to AMD/Intel R&D but rather software companies that are not keeping up.... As far back as I can remember many programs were able to utilize the new speed increases effectivly whereas now, a budget "3000" cpu is already kinda overkill for many office apps....
    gaming is the only arena where the software is pushing the hardware (maybe video editing too but that market is much smaller?)

    there needs to be more innovation on the software front to utilize the added hardware benefits... is a positive reinforncement routine....
    If there was that push, I have no doubt that the speed increases would happen at a much better rate
  • Calin - Thursday, March 31, 2005 - link

    An architecture with several cores, with one more powerful than the others, requests the programmer to tell to each thread what kind of performance it needs. While this could be accepted by console developers (that work very close to the hardware layers), you can say bye bye to easy porting to that platform.
    while the performance increase can be substantial, the trade off is very specific code even at the highest level
  • Jeff7181 - Thursday, March 31, 2005 - link

    Comment WAS mad on HT...

    "Fred’s response to this question was thankfully straight forward; he isn’t a fan of Intel’s Hyper Threading in the sense that the entire pipeline is shared between multiple threads, in Fred’s words 'it’s a misuse of resources.'"
  • Zebo - Thursday, March 31, 2005 - link

    Wish some comment was made on HT, intel only real saving grace for last couple years. Guess with DC it becomes a non-issue though at that point.


    Hehe nice to see CPU world going full circle... AMD copied Intel like nobodies biz now it's the other way around. Props to AMD for innovating dispite thier punny size.. they definity should be rewarded by sales. I know I made the right choice with A64, the latency he mentions you can feel all the time, hard to "benchmark" it other than system just feels snappy compared to any other CPU I've used to including a P4C oC'ed to 3.4, A-XP OCed to 2.7, and IBM chips from apple at 2.5.
  • bupkus - Thursday, March 31, 2005 - link

    Reduced processor complexity is a step neither manufacturer is willing to take.
    OR
    Neither manufacturer appears willing to reduce processor complexity.

Log in

Don't have an account? Sign up now