By: Maynard Handley (name99.delete@this.name99.org),
Room: Moderated Discussions
Michael S (already5chosen.delete@this.yahoo.com) on September 25, 2017 1:29 am wrote:
> Maynard Handley (name99.delete@this.name99.org) on September 24, 2017 11:32 pm wrote:
> >
> > Even you David? Isn’t it obvious that he means Cell as a metonym for that class of
> > processors? Stripped down, simplified, optimized for throughput. No-one would use literal
> > Cell these days; we know too much about sub-optimal ideas that it implemented.
>
> If you ignore all details then everything looks like everything else.
>
> Clock rate (4/1/1), the width of SIMD units (128b/512b/2048b), per lane predication (?/yes/yes), i$
> (no/yes/yes), direct access to DRAM (no/yes/yes), texture hardware (no/yes/yes) are main things that
> make the difference between Cell SPE, LRB and typical GPU. If you removed very high clock rate, made
> SIMD wider and provided direct access to DRAM then the result can't be called Cell-like any more.
>
The problem is that there isn't really (yet?) a well-defined term to express the concept he clearly has in mind. You could say tiled-processors (like Tilera) but that confuses the hardware with the tiles of a particular software stack running on top of them (ie TBDR). The best term is probably laned processors, but this is not yet a very widespread term.
But the evolution is, IMHO, obvious. We start with SIMD as an attempt to get more data throughput given a limited instruction throughput; but this has obvious problems with respect to load/store and branches. We move on to SIMT where you have more flexibility in things like the load store, but there's still a single PC shared across all threads, with the hassles that implies for branching. Finally we end up at laned processors, where the processor consists of some number (let's say 16 or 32) independent execution lanes (each one essentially a non-speculative one-wide in-order CPU, with independent PC, SP, and link register).
So how is this different from a traditional many-core processor? Some obvious points present themselves:
- there's an assumption of substantial overlap in instruction and data usage, and this should be exploited by using a common cache. It's not clear to me what the optimal designs for these are, but they are likely highly unorthodox. For instructions you want something that can maybe feed 64-byte lines to a large number (perhaps all) of the lane CPUs simultaneously (very wide read fan-out) then maybe a small (1KB?) L0-I in front of each lane. For data maybe you want an aggressively banked L1?
Point is for both I and D (and their TLBs) the goal is not independent per-lane caches but an attempt to exploit the fact of coherence in both I and D across all lanes.
- there is probably value in providing some more caches with lower latency and explicitly define properties, eg a read only D1 cache, and a per-lane read-write (but no guarantees of coherency or anything else) cache.
- it may (or may not?) make sense to provide a common pool of "registers" that all lanes can dip into. Doing this is obviously more complicated than just say 32 per-lane registers, but does allow the use of, say, just half or a quarter of the lanes, along with many more registers. Obviously this was a design point that was utilized in GPUs, but it's not clear to me that it's a point worth retaining.
At this point you have something that's probably a reasonable starting point for GPU tasks, but it didn't start with the GPU heritage, rather from a stripped down standard CPU heritage. Add some primitives to allow lanes to sync in various ways (necessary regardless of the target workload), and a few more primitives to handle specifically GPU issues (texture addressing, maybe format conversion) and you have something that's a fine basis for a GPU, but is also a fine basis for any sort of embarrassingly parallel workload.
Is this a Cell? Not even close. But, like I said, the appropriate term (lane-processor) is not very well known, and Cell is about as good a metonym as you can hope for. I mean the only other choice really is to say Larrabee and that carries an even large baggage of unhelpful and irrelevant connotations. Cell does suggest connotations of something CPU-like, and an unusual memory structure, though clearly it does not suggest exactly the model I described above.
> Maynard Handley (name99.delete@this.name99.org) on September 24, 2017 11:32 pm wrote:
> >
> > Even you David? Isn’t it obvious that he means Cell as a metonym for that class of
> > processors? Stripped down, simplified, optimized for throughput. No-one would use literal
> > Cell these days; we know too much about sub-optimal ideas that it implemented.
>
> If you ignore all details then everything looks like everything else.
>
> Clock rate (4/1/1), the width of SIMD units (128b/512b/2048b), per lane predication (?/yes/yes), i$
> (no/yes/yes), direct access to DRAM (no/yes/yes), texture hardware (no/yes/yes) are main things that
> make the difference between Cell SPE, LRB and typical GPU. If you removed very high clock rate, made
> SIMD wider and provided direct access to DRAM then the result can't be called Cell-like any more.
>
The problem is that there isn't really (yet?) a well-defined term to express the concept he clearly has in mind. You could say tiled-processors (like Tilera) but that confuses the hardware with the tiles of a particular software stack running on top of them (ie TBDR). The best term is probably laned processors, but this is not yet a very widespread term.
But the evolution is, IMHO, obvious. We start with SIMD as an attempt to get more data throughput given a limited instruction throughput; but this has obvious problems with respect to load/store and branches. We move on to SIMT where you have more flexibility in things like the load store, but there's still a single PC shared across all threads, with the hassles that implies for branching. Finally we end up at laned processors, where the processor consists of some number (let's say 16 or 32) independent execution lanes (each one essentially a non-speculative one-wide in-order CPU, with independent PC, SP, and link register).
So how is this different from a traditional many-core processor? Some obvious points present themselves:
- there's an assumption of substantial overlap in instruction and data usage, and this should be exploited by using a common cache. It's not clear to me what the optimal designs for these are, but they are likely highly unorthodox. For instructions you want something that can maybe feed 64-byte lines to a large number (perhaps all) of the lane CPUs simultaneously (very wide read fan-out) then maybe a small (1KB?) L0-I in front of each lane. For data maybe you want an aggressively banked L1?
Point is for both I and D (and their TLBs) the goal is not independent per-lane caches but an attempt to exploit the fact of coherence in both I and D across all lanes.
- there is probably value in providing some more caches with lower latency and explicitly define properties, eg a read only D1 cache, and a per-lane read-write (but no guarantees of coherency or anything else) cache.
- it may (or may not?) make sense to provide a common pool of "registers" that all lanes can dip into. Doing this is obviously more complicated than just say 32 per-lane registers, but does allow the use of, say, just half or a quarter of the lanes, along with many more registers. Obviously this was a design point that was utilized in GPUs, but it's not clear to me that it's a point worth retaining.
At this point you have something that's probably a reasonable starting point for GPU tasks, but it didn't start with the GPU heritage, rather from a stripped down standard CPU heritage. Add some primitives to allow lanes to sync in various ways (necessary regardless of the target workload), and a few more primitives to handle specifically GPU issues (texture addressing, maybe format conversion) and you have something that's a fine basis for a GPU, but is also a fine basis for any sort of embarrassingly parallel workload.
Is this a Cell? Not even close. But, like I said, the appropriate term (lane-processor) is not very well known, and Cell is about as good a metonym as you can hope for. I mean the only other choice really is to say Larrabee and that carries an even large baggage of unhelpful and irrelevant connotations. Cell does suggest connotations of something CPU-like, and an unusual memory structure, though clearly it does not suggest exactly the model I described above.