By: rwessel (robertwessel.delete@this.yahoo.com), January 30, 2013 4:00 pm
Room: Moderated Discussions
Paul A. Clayton (paaronclayton.delete@this.gmail.com) on January 30, 2013 2:29 pm wrote:
> Doug S (foo.delete@this.bar.bar) on January 30, 2013 12:38 pm wrote:
> [snip]
> > Another alternative for SoC vendors would be soldering the memory to the board. That would increase memory
> > performance, with the tradeoff being inability to upgrade/repair
> > and having to maintain several SKUs (you wouldn't
> > need dozens, you'd just offer 3-5 power of two upgrades
> > from very small to very large) Possibly the CPU could
> > be soldered as well, though that would multiply the SKUs by the number of speed/core variations.
>
> ISTR reading someone from Facebook mentioning that CPUs have a faster upgrade cycle than DRAM (or the
> motherboard or I/O chips) and that systems should be designed to exploit different upgrade rates. FRU
> (or specifically Field Upgradeable Unit) issues might be as significant an issue as SKU diversity.
>
> Having memory and CPU share a board could have energy-efficiency benefits as well as performance
> (and perhaps reliability) benefits. (A local cluster of such nodes with a shared address
> space--but not cache coherent--could be interesting for some "cloud" workloads.)
Yes, Paul, we know you like non-coherent memory... ;-)
But sure, you could build such a thing, but wouldn’t most applications be better off on a larger Xeon (perhaps MP) box where you could allocate shared memory between the threads/processes/images/whatever trivially? And have it be coherent?
The problem is, that if you're doing something funky, and of only limited applicability, the economics will kill you. The whole point of ARM microservers is that the will (hopefully) be *cheap*.
> Doug S (foo.delete@this.bar.bar) on January 30, 2013 12:38 pm wrote:
> [snip]
> > Another alternative for SoC vendors would be soldering the memory to the board. That would increase memory
> > performance, with the tradeoff being inability to upgrade/repair
> > and having to maintain several SKUs (you wouldn't
> > need dozens, you'd just offer 3-5 power of two upgrades
> > from very small to very large) Possibly the CPU could
> > be soldered as well, though that would multiply the SKUs by the number of speed/core variations.
>
> ISTR reading someone from Facebook mentioning that CPUs have a faster upgrade cycle than DRAM (or the
> motherboard or I/O chips) and that systems should be designed to exploit different upgrade rates. FRU
> (or specifically Field Upgradeable Unit) issues might be as significant an issue as SKU diversity.
>
> Having memory and CPU share a board could have energy-efficiency benefits as well as performance
> (and perhaps reliability) benefits. (A local cluster of such nodes with a shared address
> space--but not cache coherent--could be interesting for some "cloud" workloads.)
Yes, Paul, we know you like non-coherent memory... ;-)
But sure, you could build such a thing, but wouldn’t most applications be better off on a larger Xeon (perhaps MP) box where you could allocate shared memory between the threads/processes/images/whatever trivially? And have it be coherent?
The problem is, that if you're doing something funky, and of only limited applicability, the economics will kill you. The whole point of ARM microservers is that the will (hopefully) be *cheap*.