By: Per Hesselgren (grabb1948.delete@this.passagen.se), February 5, 2013 12:13 am
Room: Moderated Discussions
Paul A. Clayton (paaronclayton.delete@this.gmail.com) on February 2, 2013 11:10 am wrote:
> Patrick Chase (patrickjchase.delete@this.gmail.com) on February 1, 2013 10:11 pm wrote:
> > David suggested posting this to the forum. I think he has a few remarks of his own to add on this topic...
> >
> > I think that the statement that x86 takes 5-15% more area than RISC is a bit simplistic,
> > because the penalty is highly variable depending on what performance level you're
> > targeting and what sort of microarchitecture you have to use to get there.
>
> x86 also has a steeper learning curve as one needs to learn the tricks to handle various odds
> and ends. Intel and AMD already have institutional knowledge about implementation (including
> validation tools), but a third party is less likely to find implementing a variant or an original
> design worthwhile (even if Intel provided the appropriate licensing). It has also been argued
> that a "necessity is the mother of invention" factor drove x86 implementers to innovate.
>
> A clean RISC like Alpha (or--from what I have read--AArch64) would be much more friendly to fast bring-up
> of a decent microarchitecture. (Classic ARM seems to be somewhere in the middle--not as complex as x86 but
> not as simple as Alpha--, but even with Thumb2+classic ARM it might be closer to Alpha than to x86.)
>
> [snip]
> > My own take is that for ARM-based microservers to survive they need to stay down in the "many weak cores"
> > regime and focus on massively parallel workloads that can tolerate the latency penalty. If they try to
> > move up into higher performance brackets then they'll be playing directly into Intel's hand.
>
> I agree that trying to compete with Intel x86 at the high performance end will be excessively difficult,
> but I think the ARM brigade may have a flexibility advantage. Even though Intel has been demonstrating some
> willingness to try new things and develop concurrent multiple microarchitectures, Intel seems to be too conservative
> to try radical designs. It is not clear that ARM will take advantage of its greater tolerance of diversity
> (while learning to provide a coherent interface to software) to introduce some weird and wonderful architectural
> features. ARM has been very quiet about transactional memory and multithreading; features along the lines
> of Intel's TSX and MIPS' MT-ASE could be significant in the server market.
>
> Even if ARM does not innovate much architecturally, I think the implementers may feel
> much more free to try different accelerators and microarchitectural tweaks. With
> an Architecture license, non-ARM implementers could even add new instructions.
One of the few ARM server benchmarks
http://armservers.com/2012/06/18/apache-benchmarks-for-calxedas-5-watt-web-server/#more-206
Why just Apache?
> Patrick Chase (patrickjchase.delete@this.gmail.com) on February 1, 2013 10:11 pm wrote:
> > David suggested posting this to the forum. I think he has a few remarks of his own to add on this topic...
> >
> > I think that the statement that x86 takes 5-15% more area than RISC is a bit simplistic,
> > because the penalty is highly variable depending on what performance level you're
> > targeting and what sort of microarchitecture you have to use to get there.
>
> x86 also has a steeper learning curve as one needs to learn the tricks to handle various odds
> and ends. Intel and AMD already have institutional knowledge about implementation (including
> validation tools), but a third party is less likely to find implementing a variant or an original
> design worthwhile (even if Intel provided the appropriate licensing). It has also been argued
> that a "necessity is the mother of invention" factor drove x86 implementers to innovate.
>
> A clean RISC like Alpha (or--from what I have read--AArch64) would be much more friendly to fast bring-up
> of a decent microarchitecture. (Classic ARM seems to be somewhere in the middle--not as complex as x86 but
> not as simple as Alpha--, but even with Thumb2+classic ARM it might be closer to Alpha than to x86.)
>
> [snip]
> > My own take is that for ARM-based microservers to survive they need to stay down in the "many weak cores"
> > regime and focus on massively parallel workloads that can tolerate the latency penalty. If they try to
> > move up into higher performance brackets then they'll be playing directly into Intel's hand.
>
> I agree that trying to compete with Intel x86 at the high performance end will be excessively difficult,
> but I think the ARM brigade may have a flexibility advantage. Even though Intel has been demonstrating some
> willingness to try new things and develop concurrent multiple microarchitectures, Intel seems to be too conservative
> to try radical designs. It is not clear that ARM will take advantage of its greater tolerance of diversity
> (while learning to provide a coherent interface to software) to introduce some weird and wonderful architectural
> features. ARM has been very quiet about transactional memory and multithreading; features along the lines
> of Intel's TSX and MIPS' MT-ASE could be significant in the server market.
>
> Even if ARM does not innovate much architecturally, I think the implementers may feel
> much more free to try different accelerators and microarchitectural tweaks. With
> an Architecture license, non-ARM implementers could even add new instructions.
One of the few ARM server benchmarks
http://armservers.com/2012/06/18/apache-benchmarks-for-calxedas-5-watt-web-server/#more-206
Why just Apache?
