anon (anon.delete@this.anon.com) on September 25, 2013 8:02 am wrote:
> Kevin G (kevin.delete@this.cubitdesigns.com) on September 25, 2013 7:18 am wrote:
> > Simon Farnsworth (simon.delete@this.farnz.org.uk) on September 25, 2013 5:32 am wrote:
> > > anon (anon.delete@this.anon.com) on September 25, 2013 4:22 am wrote:
> > > > Simon Farnsworth (simon.delete@this.farnz.org.uk) on September 25, 2013 4:06 am wrote:
> > > > > Here's some uninformed speculation for you: Intel's biggest design advantage over their
> > > > > ARM competition is their skill in memory controllers. Iris Pro 5200 shows that one trick
> > > > > Intel can pull off is eDRAM designed for high performance; if Intel can sustain that performance,
> > > > > but offer low power consumption, you get the following speculation:
> > > > >
> > > > > Intel will offer a future phone/tablet chip with eDRAM on package replacing external memory completely (2
> > > > > GiB, 4 GiB, 16 GiB, whatever is appropriate to the market at the time). This chip will be expensive for
> > > > > the performance level it provides, but will always win power consumption measurements (and thus battery
> > > > > life benchmarks), by a large margin for applications that make heavy use of GPU and CPU, and a small margin
> > > > > for applications whose power consumption is dominated by other system components such as the screen.
> > > > >
> > > > > By being lower power consumption while having comparable performance to competing chips, it gives
> > > > > Intel-based phones and tablets a power consumption advantage. This, in turn, gets Intel design
> > > > > wins in high-end Android devices, as they can either design a nicer case with a smaller battery,
> > > > > or use the same battery size as a competing design, but with a longer battery life.
> > > > >
> > > > > All speculation, and it turns on Intel being able to offer
> > > > > low power, high performance eDRAM to make the sale.
> > > >
> > > > IBM has a lot of experience with eDRAM memory now, and
> > > > they share a lot of process tech with other foundries.
> > > >
> > > > Intel *may* get there first if they have a density edge, but if the technique
> > > > gives an advantage, I don't think others will be too far behind.
> > > >
> > >
> > > In my speculative world, you need both eDRAM process technology (and I'd be surprised too if Intel
> > > was ahead of anyone there, given IBM's long experience with it) and decent memory controller design
> > > experience to exploit eDRAM. IBM has that experience, as does Intel; I'm not sure how much experience
> > > the ARM vendors have with designing high performance, high efficiency memory controllers (my experience
> > > of ARM-based SoCs is that the memory subsystem is the biggest let-down in system performance).
> >
> > For eDRAM to be beneficial in the desired capacities (say 4 GB for smart phones), it would need to
> > be delivered across multiple dies. Intel and IBM both have experience with traditional MCM's but
> > they will need to move to TSV, interposers and/or other exotic packing techniques to meet the small
> > area requirements. Neither Intel or IBM have shipped products using these yet to my knowledge.
>
> No, but it seems on the verge of happening.
>
> http://www.eetimes.com/document.asp?doc_id=1262885
>
> Of course, it's been talked about for a decade or more, but IBM says they actually have a roadmap
> now. Huge capacity and low power seems to coincide with what IBM wants from last level caches
> on high end machines, which may make it suitable for mobile too, if the cost is right.
>
> >
> > As for ARM-based SoC designers having experience with high performance
> > memory controllers, Apple has at least proven competition in this area.
>
> And ARM Holdings. Nvidia is no stranger to high performance memory controllers,
> and neither is AMD. Memory controllers are not the problem.
>

It's worth noting just WHY IBM cares about eDRAM, and why they are willing to spend so much for it.
Let's recall that hyper threading sounded like a great idea when it was first proposed, and the first commercialized, around 15 years ago. But the results were continually disappointing. Why?

The basic problem is that the bulk of dead time in execution is waiting for loads that miss in the LLC. We want our hyperthread to do something useful during that time. BUT unfortunately our hyperthread lands up using some fraction of the LLC for its own purposes. And so we have that, yes, the other hyperthread CAN work when main thread is waiting on DRAM --- but in the process it shrinks the effective size of LLC, and this effect can be worse than the win of using dead time. All this holds regardless of other issues like whether or not you do a crappy job of the buffers you provide to your threads, how you schedule them etc.

Exactly how this balances out depends on the workload and the LLC size. As we know, for most workloads, and once the mechanical details (buffers, scheduling) don't suck, for Intel sized LLCs (so about 1.5MB to 2MB/core) a hyperthread is worth about 25% of a core. Better than zero, but not great.

IBM, selling big iron POWER boxes to people who run lots of threads want to do better than this --- they'd like their hyperthreading to work so that every slot of every CPU is constantly active. They solve this by throwing a MASSIVE LLC cache at the problem, like 80MB (10MB/core) on the theory that "god damn it, now maybe you threads will stop fighting and play nice together". I don't know if they've ever given numbers, but this would give 2.5MB/thread (IBM can run up 4 threads/core) which beats Intel's 1.5..2MB/core, which in turn suggests that for most code you ARE going to hit the goal here --- the actual CPU has basically every slot occupied every cycle.
I don't think IBM have ever released numbers, but they thought it worthwhile to up the thread count from 2 to 4, so presumably the scheme works to some extent.

OK, point of all this is that IBM is trying to solve a very particular problem with their eDRAM. A problem that in no way maps onto mobile. I don't know if we have any evidence that a larger than 2MB or so LLC per core (or thread, if you were to hyperthread) is worth the cost (especially in energy).

The Intel reason for eDRAM (fast communication between GPU and CPU, large working space for GPU) is closer to mobile. It is quite possible that Apple already do this on the A7 --- there is a large block of what looks like 4MB of cache next to the GPUs, but off the CPUs, and to me its most likely job is to act like Crystalwell. Of course a larger version of that would be nice, but what Apple has seems to do the job.

Point is --- both of these are a FAR cry from 2GB of working RAM for the system. I think the gap between what's needed and what can be done is too far for that to be bridged. More relevant is something like a better Crystalwell, but even that may not be interesting until it can either be done on-die or CHEAPLY with TSVs.