Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Qualcomm: slechts paar bedrijven kunnen van x86 op Arm overstappen voor servers

Qualcomm stapt niet uit de markt voor datacenterchips, maar verkleint de divisie voor serverprocessors en brengt deze onder bij zijn bedrijfsonderdeel voor mobiele chips. Volgens Qualcomm zijn maar een paar klanten in staat om de Arm-serverchips in te zetten.

Qualcomm-voorzitter Cristiano Amon ontkent tegenover Reuters een gerucht van meer dan een maand geleden, dat het bedrijf zou overwegen de divisie voor serverchips te sluiten of verkopen. Wel reorganiseert het bedrijf de divisie en wordt deze onderdeel van Qualcomms CDMA Technologies-onderdeel, dat mobiele chips ontwerpt.

De divisie voor serverchips gaat zich richten op grote bedrijven die actief zijn op het gebied van cloudcomputing. Behalve op grote Amerikaanse ondernemingen wil Qualcomm zich via een joint venture richten op Chinese techgiganten als Alibaba, Tencent en Baidu.

"Het is ons erg duidelijk dat de kansen voor Arm liggen bij enkele spelers, die niet het obstakel van x86-software te overwinnen hebben", zegt Amon. Veel serversoftware is voor x86 geschreven, mede door de leidende positie die Intel met zijn Xeons heeft weten op te bouwen. De grote bedrijven zouden hun software nog kunnen aanpassen aan de Qualcomm-chips, maar voor kleine bedrijven zou dat moeilijk zijn.

Qualcomm had hoge verwachtingen van zijn Centriq-chips voor servers, die onder andere een betere prestatie-per-watt dan de Intel Xeons zouden bieden. De markt voor Arm-serverchips is echter niet zo gegroeid als gehoopt, en Qualcomm is bezig zijn kosten te verlagen en zich te concentreren op zijn kernactiviteiten om de winstgevendheid te vergroten.

Door Olaf van Miltenburg

Nieuwscoördinator

13-06-2018 • 14:21

108 Linkedin Google+

Reacties (108)

Wijzig sortering
Dat "ARM is even snel" en "even hercompileren" blijft grappig.

ARM kán even snel of zelfs sneller dan x86 zijn. Het hangt echter geheel van de toepassing af en er zijn genoeg dingen waar hun RISC aanpak simpelweg onderdoet voor een CISC aanpak. Het is precies hetzelfde verhaal als met PPC tegenover x86.

De complexiteit van de gemiddelde hedendaagse x86-64 CPU kost voor simpele dingen performance vergeleken met een ARM CPU, maar tegelijkertijd is het ook die complexiteit die er voor zorgt complexe taken vaak sneller uitgevoerd kunnen worden doordat er een pipeline is die sneller is dan een berg aan "simpele" instructies.

x86 is ook niet het enige waar ARM tegen op moet boksen. Een moderne CPU ondersteunt een hele berg aan instructiesets. Zelfs iets simpels als AES performance kan al relevant zijn. Ik weet niet hoe Centriq het daar doet qua performance, maar AES wordt veel gebruikt. Laat staan de vector instructiesets (SSE/AVX).

Edit: RISC en CISC is tegenwoordig niet meer correct. Zie mijn eigen toelichting hier.

Daarnaast is mijn punt met deze reactie helemaal niet dat ARM inherent trager dan x86 is (of iets in die trant). Mijn punt is dat er te eenvoudig over wordt gedacht, want naast x86 hebben CPU's nog andere instructiesets die er ook toe doen.

Je kunt geen appels met peren vergelijken. Er zijn toepassingen waar ARM weldegelijk een betere oplossing is, maar omgekeerd geldt hetzelfde: er zijn toepassingen waar ARM niet toereikend is.

[Reactie gewijzigd door Werelds op 13 juni 2018 16:25]

Dat "ARM is even snel" en "even hercompileren" blijft grappig.

ARM kán even snel of zelfs sneller dan x86 zijn. Het hangt echter geheel van de toepassing af en er zijn genoeg dingen waar hun RISC aanpak simpelweg onderdoet voor een CISC aanpak. Het is precies hetzelfde verhaal als met PPC tegenover x86.

De complexiteit van de gemiddelde hedendaagse x86-64 CPU kost voor simpele dingen performance vergeleken met een ARM CPU, maar tegelijkertijd is het ook die complexiteit die er voor zorgt complexe taken vaak sneller uitgevoerd kunnen worden doordat er een pipeline is die sneller is dan een berg aan "simpele" instructies.

x86 is ook niet het enige waar ARM tegen op moet boksen. Een moderne CPU ondersteunt een hele berg aan instructiesets. Zelfs iets simpels als AES performance kan al relevant zijn. Ik weet niet hoe Centriq het daar doet qua performance, maar AES wordt veel gebruikt. Laat staan de vector instructiesets (SSE/AVX).
Kan je dat ook onderbouwen met benchmarks? Ik ken geen toepassingen waar RISC definitief onderdoet voor CISC. RISC zou in theorie meer instructies kunnen genereren voor dezelfde code tov CISC, maar omdat RISC simpeler is zou deze ook meer instructies per cycle kunnen verwerken waardoor dit verschil kan verdwijnen. (1)

Het laatste stuk van je verhaal, over de specifieke instructiesets klopt, maar uit ervaring weet ik dat bijvoorbeeld GCC erg gepushed moet worden om die specifieke instructiesets ook te gebruiken. Dus voor een gemiddeld softwarepakket welke niet extreem geoptimaliseerd is gaat ook dit niet op. Daarnaast heeft ARM zijn eigen vector instructies: ARM neon(2). Er bestaan ook wel degelijk ARM processoren die AES supporten, Trustzone is een modern voorbeeld (3).

1: https://cs.stanford.edu/p...o/projects/risc/risccisc/
2: https://developer.arm.com/technologies/neon
3: https://www.arm.com/products/system-ip/trustzone-security-ip

[Reactie gewijzigd door KillerZero86 op 13 juni 2018 15:09]

Enige specifieke benchmark kan ik je zo 1-2-3 niet geven (zou ik vanavond eens moeten zoeken), maar zoals ik al aan geef hangt dat heel sterk van de workload af. Het verschil zit niet eens zo zeer in het aantal instructies of aantal cycles per instructie, maar vooral om de micro-optimalisaties. Het kan best zijn dat je op een x86 CPU iets wat exact dezelfde instructies zou moeten zijn (zeg, 1 cycle per instructie, 1000 instructies) door een andere pipeline vliegt en binnen 600 cycles klaar is.

Ik had wellicht ook aanhalingstekens moeten gebruiken, want RISC en CISC zijn niet echt van toepassing meer tegenwoordig. Een Intel/AMD x86 CPU zal vaak exact hetzelfde doen in exact even veel cycles als een ARM CPU, waardoor je vervolgens alleen nog maar van de kloksnelheid en/of aantal cores/threads afhankelijk bent. In die zin kunnen moderne CPUs gewoon als een RISC functioneren.

Wat overige instructie sets betreft, ik zeg nergens dat er geen ARM CPUs zijn die AES niet ingebakken hebben. Sterker nog, ik weet dat Centriq het heeft, ik weet alleen niet hoe rap het is omdat nooit naar benchmarks heb gezocht. In veel gevallen is het met GCC slechts een enkele flag; om bijvoorbeeld iets als AES-NI moet je iets meer werk doen om het goed te doen (code moet het gebruiken), maar ook dat valt reuze mee. Ik zal eens kijken of ik iets kan vinden qua benchmarks, kan me niet voorstellen dat er niet ergens een AES voorbeeld is, waarmee je meteen een benchmark én compiler optimalisaties hebt.
Een groot verschil waar ik in praktijk veel verschil tussen x86 en ARM zag was de "coherency".

De x86 zit overal met zijn controllers tussen, als de harddisk een stuk RAM vult met data dan weet de CPU daar van, of heeft zelfs al een kopie van die data in de cache gekregen. De administratie daarvan is mega gecompliceerd, en een van de redenen dat tegenwoordig alles in de CPU geintegreerd zit. Het is ook de grootste bottleneck.

Op de ARM is de aanpak doorgaans simpeler, en de CPU weet van niks. De software (kernel) moet het zelf bijhouden, en dan handmatig cache-lijnen in de CPU L2 cache bijwerken.

In de Linux kernel zie je het bij drivers terug komen, na een DMA actie (bijvoorbeeld harddisk naar RAM) meld je tegen de kernel dat de betreffende range in RAM door een apparaat is overschreven en de bijbehorende cache lijnen nu ongeldig zijn ("cache invalidate"). Op de x86 zijn die methodes doorgaans leeg, de hardware heeft 't al geregeld, en op de ARM zit er een flink stuk code achter om de cache status bij te werken. Dat verschilt overigens per chip, op sommige interfaces kan 't wel in hardware, maar zit er soms een flinke penalty achter. En dan kun je kiezen tussen bijvoorbeeld 600MB/s naar DDR schrijven, of met 1200 MB/s naar cache en 200MB/s naar DDR. Dus als je de cache "mist" stort je performance helemaal in. Ook dat is per chip en apparaat verschillend, ik vermoed dat de "server" ARMs hier veel meer in huis hebben dan de ARMs die je in een tablet aantreft bijvoorbeeld.
M'n vrienden van CloudFlare hebben een mooie die ook meteen laat zien waar ik ARM wél zie winnen: https://blog.cloudflare.com/arm-takes-wing/

Voor hen is ARM voor veel toepassingen geschikter doordat ze binnen hetzelfde power budget meer cores kwijt kunnen. Als je echter naar bijvoorbeeld de 1T crypto benchmark resultaten kijkt, blijft Falkor (de Centriq core) ver achter bij Intel, zelfs als je corrigeert voor kloksnelheid. Dat komt dan wel door twee instructies die in een extensie zitten, maar niettemin is dat wel specifiek een x86 extensie. Het gunstigste geval van ECDSA zit op zo'n 80% performance voor signing.

Kijk je naar de benchmark daarna (AES en GCM) dan zie je dat verschil nog groter worden. De core count is daar niet genoeg om de inhaalslag compleet te maken. Aan de ene kant is het knap wat Qualcomm klaar speelt binnen dat power budget, maar anderzijds is het indrukwekkend hoe verdomd rap Intel daar is. Dat zijn 12 cores die het winnen van 46 cores. Ik denk niet dat HT hier veel kan doen, dus de effectieve thread count zal wel ergens tussen de 12 en 24 liggen, maar zal geen 24 zijn. Het verbruik zal daar ook geen 120W (QC) en 170W (Intel) zijn, beiden zullen lager liggen.

Hoewel dingen als AES, SSE/AVX enzovoort technisch gezien extensies zijn, maken ze wel deel uit van x86. Dat hele extensie verhaal bestaat simpelweg omdat x86 geen versies heeft zoals ARM dat wel heeft (soort van :P). En vooral zoiets als AES is inmiddels zo ingeburgerd dat er echt geen x86 CPU meer uit komt waar dat niet in zit :)

Nogmaals, mijn punt is niet dat ARM trager of sneller is dan x86. Het is dat het van de situatie af hangt en wat je doel is - eenieder die stelt dat "A sneller is dan B" zonder context zit gewoon fout. Als je bijvoorbeeld vooral AES performance nodig hebt in pieken, zul je met Intel waarschijnlijk alsnog dicht op de QC oplossing zitten qua verbruik over lange duur. Onder langdurige belasting zal Intel het afleggen op dat gebied, maar dan moet je de afweging maken qua performance - in CF's geval maakt het niet uit als het net even iets langer duurt, hun workload is heel erg breed dus meer cores winnen het dan. Als je afhankelijk bent van AVX is het bijna een no-brainer. En zo kun je nog wel even doorgaan om beide tegenover elkaar te zetten. Er is simpelweg geen eenduidige winnaar. Wat mij betreft in ieder geval niet ;)

[Reactie gewijzigd door Werelds op 14 juni 2018 12:20]

Op veel vlakken legt de Cavium Thunder X2 het bijvoorbeeld af tegen een Xeon:
https://www.anandtech.com...nderx2-arm-server-reality

En op vlakken waar power consumptie belangrijk is heeft Intel ook 70W Xeons en eventueel Xeon-Ds.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True