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.
Maar dan gaat het dus om x86 vs ARM? Want dat is inderdaad geen discussie die met RISC vs CISC of specifieke instructiesets te maken heeft, dat is een discussie vanuit portabiliteit (aangegeven door M.D.J.) en context: x86 wordt al tientallen jaren ontwikkeld voor high-performance, ARM voor embedded. Ik vind het dan nog steeds een boeiende vraag of er workloads zijn die beter schalen op x86 vs ARM.
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]

Dit is een benchmark van de ThunderX2 vergeleken met een Xeon processor: https://www.anandtech.com...erx2-arm-server-reality/7.

De Xeon wint wel op de meeste vlakken in single threads performance, maar heeft daarentegen wel weer 256 Threads.
Voor servers gaat het vaak om de performance per Watt, en niet zo zeer om de ruwe performance. Op ruwe performance gaan de ARMs het nooit winnen, de x86 blinkt uit in verwerken van compiler-achtige taken en manipuleren van strings.

Maar voor een enkele 100+ Watt vretende Xeon (met energieslurpende secondary functies die op het moederbord ook nog aardig wat wegstoken) kun je ook vijf ARM octacores met wat minder specs wegzetten. Gezamenlijk verzetten die mogelijk meer werk dan die ene x86, en tegen minder stroom en oppervlaktegebruik. De workload moet zich natuurlijk wel lenen voor distributie over meer systemen.

Elke Joule die de server uitstoot moet door de airco weer afgevoerd worden, en dat geeft een vermenigvuldigingsfactor op het energiegebruik. Als je 100W op de CPU bespaart, spaart je totaal bijvoorbeeld 150W als de airco nog eens 50W nodig had om die 100W af te voeren.

De "prestatie" van een server platform gaat niet zozeer om gigaflops, maar evengoed om kilowatts en kubieke meters. De helft minder ruimte of minder vermogen is net zo interessant als "twee keer zo snel".
Daar heb je gelijk in en dat is ook waar ik de kansen voor ARM zie. Er wordt te veel geluld over "even snel", terwijl dat helemaal niet nodig is. Vooral voor bijvoorbeeld simpele webservers zonder gekke poespas (bijvoorbeeld proxies en load balancers) is ARM juist uitermate geschikt. Vooral ook omdat je in veel gevallen core counts binnen hetzelfde budget kunt realiseren waar je voorheen alleen van kon dromen.

In HPC is dat echter vaak een veel lastiger verhaal. Het is dan veel genuanceerder en sterk afhankelijk van je doel.
De grootste kost van servers blijft nog altijd de server zelf, de licenties, personeelskost etc.

Elektriciteit zelf valt relatief gezien wel mee. Een 100watt cpu 1u op volle toeren latwn renderen en koelen kost in onze streken ongeveer 6 eurocent aan energie en in china amper 2cent per uur voor 4cores.

Render farms verkopen hun server kracht aan makkelijk een paar dollar per uur tussen de 2 en 6 dollar equivalent voor een 4-core 1u bezig te houden. Hun meerwaarde is natuurlijk dat ze 400 cores tegelijk inzetten en dat je 2 tot 6 dollar betaald om uw projectje no-time te renderen ipv een uur te wachten.

Dus op de totale omzet weegt de pure energiekost maar 0,2 tot 1% door.

Het klopt dat meer performanxe per watt goedkoper is maar je mag dat ook weer niet overdrijven. Ik kan me best inbeelden dat ze meeste bedrijven geen zin hebben in een grote overstap als hun bedrijfswinst niet significant stijgt terwijl de helemaal niet zeker zijn dat ARM wel zal doorbreken, wie weet moeten ze na 10jaar weer naar x86 overschakelen omdat intel’s chips nu toch veel geavanceerder zijn.
AES is het allerslechtste voorbeeld dat u kon kiezen ;) Sinds 2009 hebben ARM SoC's (maar ook VIA) hardwarematige versnelling voor AES, oa OMAP 3 had dat al. Historisch gezien was AES op een ARM SoC jarenlang vele malen sneller dan op een softwarematige x86 CPU.

Dat is de aanpak van ARM: Hardwarematig oplossen wat Intel softwarematig doet. De Hexagon DSP / Spectra ISP van Qualcomm (voor AI inference) is een mooi voorbeeld van hoe x86 nog steeds achterloopt qua performance.
Bedrijven willen het risico niet nemen, hebben software waarbij ze per core betalen, of niet de kennis in huis om over te stappen op ARM. En zo geweldig presteren de huidige ARM servers ook nog niet, ze kunnen maar met moeite een gemiddelde Xeon bijhouden.
En zo geweldig presteren de huidige ARM servers ook nog niet, ze kunnen maar met moeite een gemiddelde Xeon bijhouden.
Heb je het verbruik van beide bekeken? Dat is echt wel een "dingetje" namelijk. Verder is het best een rare vergelijking, want waarom kan de ARM server de Xeon niet bijhouden volgens jou? Wat was bijvoorbeeld de taak die op beide uitgevoerd werd?
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.
Ik denk dat de reden dat ARM het vaak aflegt tegen x86 het gebrek aan optimalisatie zal zijn. Hier is bijvoorbeeld een blog van hoe middels optimalisatie software 3x sneller is gaan performen ten opzichte van gewoon de code naar ARM te compileren.
En dat X86 verhaal vindt ik ook een beetje maf, hercompileren moet zo kunnen. Zie Raspbian.
Als jij dat dan "effe" doet, dan kan de rest het gebruiken. :P
Zo makkelijk zal het wel niet zijn.
Ik zeg niet dat ik het effe doe, ik zeg alleen maar dat er een complete distributie ( Debian ) naar ARM is gecompileerd incluis support software.

Voor closed source snap ik het wel, maar open source zou toch redelijk te porteren moeten zijn.
Nou, het is natuurlijk niet alleen een recompile van je code :)
Je moet je (gehele/halve) code herschrijven naar het gebruik van en de optimalisatie op ARM. In het geval van enterprise software ben je dus effectief afhankelijk van je tientallen vendoren of zij dat doen.

Kijk als simpel voorbeeld alleen al naar Oracle, die zelfs geen ARM-client heeft (dus als je software de standaard Oracle client nodig heeft kan het al niet):
http://www.oracle.com/tec...tion/downloads/index.html
Om Oracle als voorbeeld te nemen....... Maar ik snap je punt. :)
Binnen bijna iedere enterprise omgeving staat meestal wel ergens Oracle ter ondersteuning van bedrijfskritische processen. Dus zo een slecht voorbeeld was het niet.
Dan trok ik de verkeerde conclusie. Ik dacht dat je daar op mikte met "moet zo kunnen". In de praktijk valt het in ieder geval keer op keer tegen.
RPi != Enterprise server.

Het heeft overigens toch wel lang geduurd alvorens een x86 versie beschikbaar was van raspbian. Het is wel iets meer dan een gewone recompile.
WUT!? Why the hell zou je een x86 versie van Raspbian willen? Raspbian is juist geboren al een ARM versie van Debian voor de RPi. Op x86 kan je dan net zo goed Debian installeren.
Wat heeft "een simpel NAS boardje met een ARM processor" te maken met de Centriq serverprocessor, welke een concurrent is voor de Intel Xeon?
Omdat ikzelf thuis een simpel Xeon boardje heb draaien met LXC, KVM en ZFS. Als ik een simpel ARM boardje kon krijgen met deze features dan had ik die genomen. Helemaal vanwege de energiebesparing. Ik denk dan ook dat er een groot aantal software developers dat ook wel zou draaien, als ik zie hoeveel blogs er zijn over HP Microservers e.d. En dan heb je dus marktaandeel en mindshare en dan is het vanzelf interessant om software te porteren.
Het probleem is dat de meeste projecten die bedrijven doen iets of wat complexer zijn dan jouw Raspberry Pi hobby projectje.

Wisselen van platform kan best, maar het gevolg is dat zo'n beetje alles opnieuw moet worden getest en gekwalificeerd. De kans dat er iets omvalt is enorm, de voordelen van een nieuw platform moeten dan ontzettend de moeite zijn om een omvangrijke stap als deze in te zetten.
Lekker denigrerend ook weer, "mijn hobby projectje".

De Rpi geeft aan dat als je het blijkbaar bouwt, dan komen de mensen vanzelf als het populair is. En het geeft ook aan dat het porteren van software redelijk te doen is. En dan ook nog grotendeels door vrijwilligers.

Als ARM de voordelen biedt die ze schetsen, hoge server dichtheid met veel kernen dan zullen providers dat echt wel oppikken en dan zal de software vanwege het schaalvoordeel echt wel geporteerd worden.
Als ARM de voordelen biedt die ze schetsen, hoge server dichtheid met veel kernen dan zullen providers dat echt wel oppikken en dan zal de software vanwege het schaalvoordeel echt wel geporteerd worden.
En dat is dus precies het probleem, uit de tekst:
De grote bedrijven zouden hun software nog kunnen aanpassen aan de Qualcomm-chips, maar voor kleine bedrijven zou dat moeilijk zijn.
Facebook en Google kunnen hier nog wel mee aan de gang inderdaad. Maar kleine partijen die nu x86 draaien, gaan echt niet alles opnieuw maken.
Het is X86 wat de markt bepaald. Anders kunnen we her niet maken. Geen enkel bedrijf zal Arm omhelzen met het risico dat de stekker uit de ontwikkeling wordt getrokken of software leveranciers die ontwikkeling stoppen omdat marktaandeel te laag is.

Een bedrijf is altijd risicomijdend met betrekking tot ICT. En argumenten met Google en Facebook doen het ook wordt weggelachen door de mensen die de centen hebben in een bedrijf.
Een bedrijf is altijd risicomijdend met betrekking tot ICT.

Ja en nee. Als 't werkt blijft men er vaak vanaf. Maar niet aanpassen gaat ook een risico worden op een gegeven moment.
Wat een raar verhaal. Als er Linux op draait dan is het bruikbaar als server. Tenzij je op commerciŽle extern gebouwde software vertrouwt? Maar ook dat is toch vrij makkelijk te hercompileren naar ARM?
commerciŽle extern gebouwde software
+
Maar ook dat is toch vrij makkelijk te hercompileren naar ARM?
Hoe kom je tot deze conclusie? Juist "commerciŽle extern gebouwde software" is vaak closed source. Als de bouwer dan geen interesse heeft in "hercompileren naar ARM", dan is het juist niet "vrij makkelijk". :)
Inderdaad, sowieso zijn van alle 'Linux' applicaties meestal de source-code beschikbaar. LAMP (Linux, Apache, MySQL, PHP) stack is volgens mij al geport. Ik denk dat je bijvoorbeeld meer aan closed-source meuk moet denken als Citrix, hele microsoft stack (Exchange, MS SQL Server), SAP, en dat soort dingen.
Er wordt in het artikel ook gesproken over kleine bedrijven. Zeker in deze wereld is een Windows server met GUI nog behoorlijk aanwezig.
Voor kleinere bedrijven is een serverpark migreren toch nog een behoorlijke kostenpost. Hierbij moet je niet alleen denken aan de aanschaf van de hardware, maar ook aan de expertise en daarbij de voorkeuren van de (extern) systeembeheerders.
Dan komt daarbij ook nog de software die je gebruikt. Opnieuw compileren zou in principe voor veel software moeten kunnen maar commerciŽle bedrijven komen niet gratis met een consultant over de vloer voor een herinstallatie van een softwarepakket omdat jij besluit je serverpark om te gooien. Systeembeheerder zelf missen die specifieke kennis vaak. Als ze het wel zelf proberen om te gooien en het gaat fout, valt dit weer vaak niet onder onderhoudscontracten en krijgen ze alsnog een flinke rekening voor herstelwerkzaamheden door een extern bedrijf.
Ik denk dat veel kleinere bedrijven meer de insteek hebben en houden: "Don't fix what aint broken."
Ik denk ook dat de meeste bedrijven eerder denken om richting cloud (azure /amzn/google) te gaan dan alles compleet overhoop gooien. Applicaties worden ook steeds meer aangeboden als webbased applicatie voor een leverancier dus je ziet dat de applicatiebackend servers steeds meer verdwijnen.
En ik denk dat een hoop bedrijven best over zouden kunnen stappen. Als ik bij ons kijk: al onze zelfgeschreven software is niet gecompileerd. Dat zijn geÔnterpreteerde talen of jvm (afhankelijk van de afdeling). De servers zelf zouden we best met Ubuntu ARM kunnen installeren ipv de x64 versie die er nu op staat. Daar zit alle andere software al bij. Wij hebben ook geen onderhoudscontracten bij andere bedrijven (we hebben zelf personeel om de servers te beheren). Ik zie eigenlijk geen obstakels bij ons om ARM te gebruiken.

Waarom we het toch niet doen? Een compleet gebrek aan reden om het wel te doen. De Intel chips in onze servers werken prima. Zuiniger met stroom is geen argument, we hebben een stroomlimiet in het datacenter en zolang we daar niet overheen gaan zitten we goed. De oude hardware gaat ook niet van de een op andere dag weg, dus dan zit je met 2 platformen naast elkaar (en goed werkende servers vervangen gaan we toch niet doen). Intel is misschien niet zo'n leuk bedrijf (wegwezen met die in de bios ingebouwde spyware), maar ik heb niet het idee dat Qualcomm het beter zou doen. Waar ik eerder in geÔnteresseerd zou zijn, zijn chips van compleet Europese makelij, maar de ene of de andere Amerikaanse megacorporatie is mij om het even.

Er is genoeg te fixen, dus "don't fix what ain't broken" gaat niet perse op, maar Qualcomm is geen fix op het Intel probleem.
Ik hoop dat ze blijven innoveren en dat we in de toekomst verbeterde versies van deze chips tegemoet kunnen zien. Nu is het voornamelijk ThunderX2 dat de klok slaat en ongeveer gelijk presteert met Intel Xeon en AMD Epyc tegen lagere prijzen.
Gelijk presteren is geheel afhankelijk van de software. X86 is een CISC architectuur, Arm daar in tegen is een RISC architectuur (De R in Arm).

Zo zijn bepaalde taken in Arm super snel en andere weer tergend langzaam. Daarom kunnen de twee architecturen moeilijk vergeleken worden en zijn alleen basale instructie patronen die gelijkwaardig zijn te vergelijken.
De grote bedrijven zouden hun software nog kunnen aanpassen aan de Qualcomm-chips, maar voor kleine bedrijven zou dat moeilijk zijn.
Hadden ze toch wat meer moeite moeten steken in het beschikbaar stellen van de benodigde tools, en het samenwerken met compilerbouwers.

Als je met 1 klik je sourcecode voor x86 en x64 kunt bouwen, en het kost je uren gekloot en gerommel en uitzoekwerk om dezelfde code voor ARM te bouwen, dan snap ik wel dat dat niet gebeurt. Ik heb geen idee of het veel gerommel is, maar als het net zo makkelijk als x86 was, dan had Qualcomm niet zo snel dit probleem gehad.

Dan is er nog het testwerk. Waar test je op? Waar koop je een server met Qualcomm cpu? Niet een Raspberry Pi noemen, dat is geen server. Maar geen flauw idee dus, ik heb ze nog nooit gezien. Kun je zelf een bak bouwen met Qualcomm cpu? Waar zijn de moederborden? Wat voor hardware kun je erop aansluiten? Ik heb daar nog nooit wat over gezien of gelezen. Het lijkt wel een paper launch ofzo.

[Reactie gewijzigd door _Thanatos_ op 13 juni 2018 16:08]

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