ARM Challenging Intel in the Server Market: An Overview
by Johan De Gelas on December 16, 2014 10:00 AM ESTBroadcom Vulcan
Broadcom is late to the 64-bit Server SoC party, but the Broadcom Vulcan is one of the most ambitious designs.
Each core can have four threads in flight. Some might call it "super-threading" or even "fine grained multi-threading" as only one thread is active in each cycle. The Vulcan core, inspired by previous network processors, has four instruction pointers (registers with the next instruction address) and four sets of architectural registers similar to the Oracle (previously SUN) Tx architecture.
Although similar, the fine grained multi-threading of the Vulcan seems much more advanced than the "Barrel-processor" approach of SUN's UltraSPARC T1 which cycled continuously between the four threads in flight. The thread scheduler seems to decide with some intelligence which thread it should fetch instructions from instead of just cycling round robin between threads.
32 Bytes are fetched each cycle, good for eight instructions. The ARMv8 decoder is capable of decoding four of those ARMv8A instructions into four micro-ops. Six micro-ops can be executed per cycle: four integer and two floating point/NEON (128-bit) micro-ops.
Broadcom promises that it will offer 90% of the performance of the Haswell Core. To reach 3GHz speed, Broadcom will use TSMC's 16nm FINFET technology.
Qualcomm
Qualcomm, the company behind the hugely successful "Krait" mobile chips, has also announced that it will enter the 64-bit ARM server SoC market. However, Qualcomm has presented little else than the "end of the x86 era, cloud changes everything" presentations that only make non-technical analysts excited, so we are waiting for something more substantial.
If it was any other company, we would have ignored the product as vaporware. But this is Qualcomm, the most successful ARM SoC company of the past years. The current high-end mobile chip, the 20nm Snapdragon 810 with four A57 core at 2GHz (and four A53) shows how well Qualcomm executes. Qualcomm has an impressive track record, so although they have yet to show anything tangible in the server area they are a force to be reckoned with.
Facebook
Twitter
RSS
78 Comments
View All Comments
aryonoco - Wednesday, December 17, 2014 - link
I just wanted to thank you Johan De Gelas for this very insightful and interesting article.Hugely enjoyed reading it and your thoughts on the subject.
Good to see high quality content continue to be published at AT now that Anand has left.
JohanAnandtech - Wednesday, December 17, 2014 - link
aryonoco, Jann Thanks for letting me know. A good motivation to always push a bit harder to make sure I don't let my readers down :-).jann5s - Wednesday, December 17, 2014 - link
Thank you Johan, for writing this very interesting article!przemo_li - Wednesday, December 17, 2014 - link
Very well written walk through current and possible CPU/SOC parts.Will there be similar piece for software?
ARM (embedded) folks aren't famous for quality drivers/code.
It must change, so it will change. But for now such overview would be great!
bobbozzo - Wednesday, December 17, 2014 - link
Typo on page2:"(4 Slots x 8 DIMMs)" - change 8 to 8GB
Thanks
bobbozzo - Wednesday, December 17, 2014 - link
and page 4:"you will be able to choose between SoCs that have 100 Gbit Ethernet and 10GBit Ethernet."
should 100 be 40?
bobbozzo - Wednesday, December 17, 2014 - link
Page 12:"Most of them are the usual IPSec, TPC offloading engines"
Should that be TCP?
Also, are there still accelerators for AntiVirus engines and IDS/IPS search (there were some back in 2005).
Thanks
bobbozzo - Wednesday, December 17, 2014 - link
...I guess that's what the RegEx would be useful for.
However, not all IDS/IPS / A/V patterns use RegEx, and there are other means of acceleration.
eanazag - Wednesday, December 17, 2014 - link
Welcome back Johan.Glad to see you're still writing here. Good stuff in the article.
JKflipflop98 - Wednesday, December 17, 2014 - link
I simply don't get where this whole "microserver" thing is coming from.By the time you cluster up enough ARM processors to match the processing power of an Intel/AMD solution, you're burning just as much power and spent just as much money as you would have by using x86 in the first place. Except now you have to use some janky middleware solution because all your software is x86 and you're running on ARM cores.