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.
De hardware was er al in sommige ARM apparaten, maar het maakte geen deel uit van de ARM instructieset. In het geval van TI's implementatie kreeg je het ook alleen in de High Security varianten van de chips en was er geen openbare documentatie tot jaren later. Ik weet niet waar je het vandaan haalt dat dat jarenlang veel sneller was op ARM SoCs; de AES instructieset voor x86 stamt uit 2008, de eerste hardware implementatie volgde in 2010.

Hexagon/Spectra hebben daarnaast niets te maken met ARM. Dat zijn DSPs die los staan van de CPU core. Waarom zou Intel (of AMD) dat in godsnaam in hun processoren bakken? Qualcomm doet dat, omdat in hun primaire doelmarkt 99,9% van de producten ook een image sensor bevat. Een DSP/ISP is dan een logische toevoeging.

Zeggen dat ze achter lopen omdat ze geen DSP mee leveren is zoiets als zeggen dat Qualcomm achter loopt op Google omdat ze geen hardware oplossing specifiek voor NN/ML hebben terwijl Google dat wel heeft met hun TPU's.

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

Ik weet niet waar je het vandaan haalt dat dat jarenlang veel sneller was op ARM SoCs
Waarschijnlijk een pamfletje van VIA uit 2009 of zo, is nu wat lastig om terug te vinden.
Hexagon/Spectra hebben daarnaast niets te maken met ARM
--> Zeg ik nergens slimpie ;) Feit is dat ARM SoC's de afgelopen 10 jaar veel meer hw-accelerators hadden als x86-chips; Intel (maar ook Apple die nu ook in een keer een "ai-unit" hebben, ook een DSP'tje) is nu met een inhaalrace bezig.
Dat is de aanpak van ARM: Hardwarematig oplossen wat Intel softwarematig doet.
:Y)

Hoe is Intel dan met een inhaalrace bezig? Ze hebben nog steeds niets van dit alles hoor. Zijn ze ook niet mee bezig.

Dat laatste is ook onzin. Welke "hw-accelerators" mist een desktop-/servercpu dan die je in SoCs specifiek bedoeld voor mobiele apparaten wel vind, waar Intel of AMD commercieel iets mee kan?
Even Intel vacatures lezen en u ziet dat het volstaat met SoC vacatures.

Geheugencontroller (AMD) en GPU waren het eerste wat Intel moest inhalen qua integratie. DSP (als AI accelerator verkocht) en ISP was reeds genoemd, dan nog hw-video en audio codecs, Core 2 duo had moeite en 90% CPU load bij video (h.264 was het niet?) wat een Raspberry beter kan. Daar komt dan nog bij Ethernet, radio (LTE en WiFi, Bluetooth), SPI / I2C, USB, PCIe, een vorm van trusted module en nog wat van die blokdiagram-kreten.
En helemaal niets van dat alles heeft ook maar het geringste met ARM te maken :)

Sommige van die dingen vind je inderdaad terug in SoC's die ARM cores hebben, maar het heeft allemaal niets met ARM te maken. Zowel de instructieset als de holdings niet. Voor bijvoorbeeld AES bestaan ook aparte blokken, maar dan vind je ze ook niet terug in de instructieset die bij dat product horen. Een iGPU (waartoe traditioneel ook video en-/decoders toe behoren) zit ook niet in de ARM danwel x86 instructieset.

Je trekt de hele discussie uit z'n verband, dit heeft allemaal niets te maken met ARM vs x86. Als je het zo wil bekijken ga ik de GPU ontwerpen wel eens uit elkaar trekken, want daar hebben ARM SoC's toch ettelijke jaren heel veel in moeten halen.
En helemaal niets van dat alles heeft ook maar het geringste met ARM te maken
U claimt dus dat het ARM-ecosysteem niets met ARM heeft te maken, en u snapt zelf ook dat dit onzin is.

Het hele ARM-ecosysteem waarbij standaard IP-blokken onafhankelijk van de leverancier gemixt en gematcht kunnen worden, is uniek voor ARM: Voor Power, X86, Itanium en bijv. SPARC heeft dit nooit (op die schaal) bestaan.

Daarom kan ik geen DSP blokje in licentie nemen bij CEVA en aan een x86-CPU vastplakken, en daarom kan dat wel bij ARM.
Als ik me niet vergis is een X86 chip ook RISC op de backend met een slimme decoder ervoor die de CISC naar RISC translatie doet.

Dus waarom RISC inherent trager zou zijn lijkt me een beetje uit de lucht gegrepen.

En ja, als je SSE en AVX ( maar ja dat is weer niet elke processor en dan heb je ook nog AVX, AVX 512 etc en dan ook nog shitload aan differentiatie in de verschillende processor types van Intel waarbij de een weer meer AVX registers ondersteund dan de ander en de processor zichzelf ook nog throttled vanwege de hitte die AVX genereerd ) gebruikt zal je dezelfde trucjes moeten toepassen op je ARM port.

Lijkt me niet onoverkomelijk, maar ja dan moet het financieel wel uitkunnen. En als je dan direct al zegt, veel bedrijven zullen er niets aan hebben dan wordt het zo'n self fulfilling prophecy.
Zoals ik mezelf hierboven al corrigeer, zijn RISC en CISC niet echt meer correct voor moderne CPU's (geldt voor beide richtingen; ARM is niet strikt RISC en een moderne x86 functioneert vaak zat als RISC). Dat is mijn fout.

Het probleem zit hem vooral in heel specifieke instructies die je in ARM niet zult vinden. Zoals ik in mijn reactie hierboven al aan geef, zal ik vanavond even naar wat benchmarks zoeken, er is vast wel ergens een goed voorbeeld te vinden. Dat geldt voor zowel de "basis" instructiesets als de uitbreidingen. Er zitten dingen in SSE of AVX die je in Neon niet vindt terwijl dat andersom minder voor komt.
RISC vs CISC is een tegenstelling uit de jaren 90 en niet meer relevant voor de moderne tijd.

ARM en POWER chips zijn tegenwoordig zo complex dat 'reduced instruction set' de naam niet meer dekt. En Intel/AMD-chips zijn sinds Pentium Pro (1995!) intern ook een RISC-processor die zogenaamde "micro-ops" uitvoert. Daarvoor is een decoder gebouwd die de CISC-stijl instructieset vertaalt naar de RISC-instructies. Dus de tegenstelling die probeert op te voeren hier is al meer dan 20 jaar niet meer relevant.

Zie ook dit Ars Technica-artikel uit 1999(!):
The majority of today's processors can’t rightfully be called completely RISC or completely CISC. The two textbook architectures have evolved towards each other to such an extent that there’s no longer a clear distinction between their respective approaches to increasing performance and efficiency.

[Reactie gewijzigd door DCK op 13 juni 2018 17:26]

Ik heb mezelf daar al op gecorrigeerd :)

Ik doe dit te vaak hier op T.net, dingen te veel vereenvoudigen in m'n reacties :P
Bovendien: als RISC vs CISC werkelijk zo'n belangrijke factor was, dan draaide alles nu op POWER en SPARC, die bestaan al decennia lang in de servermarkt, en Intel heeft zich toch met x86 aardig in die markt binnengevochten.

Het lastige van Qualcomm is vooral dat ze op mobile een enorm voordeel hebben aan hun ingebouwde LTE-modems, niemand anders die zonder een stevig bedrag te betalen 4G-connected chips kan bakken. De aanval van Intel is daardoor ook rap afgeslagen, en andere concurrenten als Samsung, Mediatek en nVidia worden daardoor eenvoudig op afstand gehouden (zo erg dat het voor Samsung zelfs zinniger is om in de VS Qualcomm chips te gebruiken voor hun telefoons). Maar in het datacenter geven die LTE-patenten je geen enkele voorsprong, en moet je bovendien heel ander soort architecturen gaan ontwikkelen - meer I/O, virtualisatie, high-speed interconnects, meer cache, etc. Daar helpen de mobile-optimised ARM-designs ook niet echt.

Er is op zich geen specifieke reden waarom je met de ARM instructieset geen goede serverchips zou kunnen maken, maar simpelweg wat mobile-optimized cores bij elkaar verbinden ben je er nog niet, het heeft Intel ook vele jaren (en een mislukt project met HP genaamd Itanium) gekost zichzelf de high-end sector in te vechten. Als Qualcomm een shortcut zou willen richting high-end cpu design zouden ze de SPARC designs van (mede-TSMC-klant) Oracle kunnen kopen, en kijken of je die monsters als ARM chip kan omtoolen. Zo is AMD ook ooit begonnen met een x86 front end op een bestaand RISC-design te knutselen, daar is niks mis mee.
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.
Skylake is op een 14nm CPU server proces, ThunderX2 is een 16nm FinFet smartphone proces vergelijkbaar met Intels 20nm.

Verschil zit vooral in proces, minder in architectuur.

Met wat mazzel zijn het gelijkwaardige Intel 10nm en TSMC 7nm HPC tegelijk klaar voor servers, dan wordt t pas echt interessant.
Beetje raar verhaal, ik wacht zelf al een paar jaar op een simpel NAS boardje met een ARM processor. Elke keer is het "dat komt dit jaar" en nu is het er nog niet.

En dat X86 verhaal vindt ik ook een beetje maf, hercompileren moet zo kunnen. Zie Raspbian.
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.
Kijk eens naar wat ze wťl supporten. Die software is sowieso portable. ARM is een geldkwestie voor ORacle; waarom zou je de moeite doen? Een paar lousy centen op de CPU besparen maakt niet uit als je Oracle licenties moet afrekenen.

Nee, het grote probleem is dat grote DB's vooral I/O bandbreedte moeten hebben, en RAM cache. Dat kun je niet in software fixen.
Ik zeg niet dat Oracle slechte hardware ondersteuning heeft, of dat het zinvol is om voor databases ARM te gebruiken. Maar doordat ze bijvoorbeeld de cliŽnt niet op ARM hebben kan je dus ook niet en applicatie draaien die die cliŽnt nodig heeft, en dat dit bijdraagt om ťťn van de redenen dat bedrijven niet makkelijk zouden kunnen overstappen naar ARM.
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.
Raspbian is toch een stuk toegankelijker dan out-of-the-box Debian. Zeker in educatieve omgeving kan ik wel inkomen dat het een goed startpunt is voor Linux.

Daarnaast is het misschien ook handig voor projecten om raspbian eerst in een virtuele omgeving te draaien alvorens op een live systeem.
Op de desktop is Ubuntu de vriendelijke spin-off van Debian. Mint, desnoods.
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.
Zijn er eigenlijk cijfers of de energie besparing?

Als het bv max 35w is voor een xeon en 30 voor arm dan is dat misschien handig in een data center met duizenden chips maar voor thuisgebruik maakt een paar procent minder stroom verbruik weinig uit. Zeker als je eerst ook nog nieuwe hardware moet aanschaffen.
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.
Nee maar wat ik probeer te zeggen, is dat als die grote bedrijven dat overnemen dan zal de rest wel volgen aangezien zij voor het grootste deel alles op Linux draaien.
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.
Dat dacht ik vroeger ook, tot ik DEC systemen van 20 jaar oud tegen kwam die nog gewoon werken en die er nog steeds soms staan na 30/35 jaar.

Geen modern systeem wat dat nog doet.
Maar worden die systemen nog ondersteund tegen een normaal bedrag? En als het vervangen moet worden, is de kennis dan nog aanwezig wat er op detailniveau gebeurt? Kan een kostenpost worden weet ik uit ervaring.

Vervangen of onderhouden moet toch altijd een afweging blijven.
Klopt, maar helaas is dat de realiteit. Het meest beangstigende is dat het bij instanties is waar je je van kan afvragen of het echt geen tijd is om te vervangen omdat gewoonweg de veiligheid van medeburgers in het gedrang is. Maar ook bij financiŽle dienstverleners kwamen ze voor, weet nog dat bij een grote bank tot 10 jaar geleden nog PDP11 systemen draaiden voor de airco/luchtzuivering.
Had een soortgelijke ervaring bij een bedrijf dat actief zoekt naar computers met een 286 processor. Omdat deze wel gewoon gebruikt kunnen worden in hun omgeving waar het continue -23 graden Celcius is en modernere apparatuur (door condens vorming) zo vlug kapot gaat dat het voor hen zo goed als waardeloos is.

Zolang het blijft werken, is er voor hen geen reden om over te stappen.
Is trouwens een gouden markt, spare parts voor oude Digital en Wang systemen, en natuurlijk oude ISA kaarten en bijbehorende 286 systemen.
Uiteindelijke zullen er inderdaad kant en klare oplossingen komen. Maar ik denk toch dat het nog tegen gaat vallen. Microsoft zit overal goed ingeburgerd, dus ik denk dat het pas echt gaat gebeuren als Windows Server op ARM draait, en dat gaat echt nog wel even duren. Uiteraard zijn er ook bedrijven waar Linux meer gangbaar is en daar zal het ook wel sneller gaan. Maar ik werk bijvoorbeeld bij een ( vind ik zelf :P ) grote organisatie ( 13.000 man ) en ik mag hier niet eens een Linux webserver gebruiken. Allemaal IIS, de rest komt het domein niet eens in...
Ach MS heeft in het verleden Alpha en Mips ondersteund en Windows 10 kan ook op ARM draaien dus ik denk dat ze al wel een port klaar hebben.
Het ligt er inderdaad aan waar je werkt. Bij mijn laatste baan had ik Windows op mijn laptop, maar het meeste werk werd gedaan op Linux/UNIX en daarnaast had ik lokaal nog wel een virtuele Linux machine draaien. Het was alleen wel zo dat alle commerciŽle software eigenlijk alleen bestond voor Linux op x86.

Voor non-x86 hardware werden nog wel AIX, HP-UX en Solaris ingezet, maar deze servers werden steeds meer door Linux op x86 vervangen. Als je niet vastzit aan Oracle of DB2 en commerciŽle ETL tools, dan lijkt me de overgang naar ARM of POWER niet al te moeilijk. Maar dat is veel gemakkelijker voor nieuwe bedrijven die niet al te veel bagage uit het verleden hebben.
Die dingen zijn voor geen meter te beheren, veel te afhankelijk van rondklikken in een GUI. Powershell is veel te complex
Dat botst nogal wat je hier zegt, vind je ook niet? Als je gewoon zorgt dat je Powershell kan, hoef je ook niet te klikken. Ze zijn verder heel prima te beheren hoor, ik hou van klikken. :)
We hebben 1 Windows server VM op kantoor draaien als ondersteuning voor de desktops van de niet-IT'ers (IT draait allemaal Linux of Mac) en dat is het.
IT wat Mac draait, dat hoor je pas weinig haha! :P Waarom is dat dan als ik vragen mag? Wat is de meerwaarde?
Dat klikken wordt snel vervelend als ze alles verstoppen op plekken waar je het niet meer terug kunt vinden. En hoe wil jij 2 of meer servers consistent met elkaar houden door rond te klikken? Klikken = mensenwerk, en mensen zijn niet consistent. Laat ze 5 keer hetzelfde doen en ze doen het 5 keer net even anders. Om het nog maar niet eens te hebben over de overhead van rondklikken als je 10 webservers hebt die allemaal dezelfde aanpassing nodig hebben.
Dat is allemaal persoonlijk. Ik kan juist wel alles vinden, op Linux veel minder. Verder heb je een super handige zoek functie in Server 2016 / Windows 10. Verder beheer ik geen heel server park, maar doe ik sporadisch werk op een server. Maar met Powershell kun je gewoon doen wat jij opnoemt, dus blijft het persoonlijke aspect voor jou over.
Maar liever nog een Mac dan een Windows bak: zelfs de ssh client (iets wat ik dagelijks gebruik) is daar third party en GUI :r, putty suckt.
Hoeveel procent van de Windows gebruikers gebruikt de SSH cliŽnt denk jij? Zal het 1% zijn, of zal het er nog onder duiken? Heeft het dan zin om mee te leveren, ik denk het niet. Ik vind het niet erg om te downloaden, ik gebruik toch Xterm. :) Maar dat is persoonlijk voorkeur uiteraard.
Wat is de meerwaarde van Windows voor een IT;er (of voor een server for that matter)?
Dat ik ermee "werk" sinds ik 6 was bijvoorbeeld. Het zit er gewoon ingebrand en het werkt voor mij en die andere 12.999 mensen. Dus ach, het ligt in ieder geval niet aan mij. :)

edit: Ik klik veel te vroeg op reageer, ik ga nog meer plaatsen, please hold. :P
Edit 2: done!

[Reactie gewijzigd door dehardstyler op 13 juni 2018 18:23]

Probeer dan eens SmarTTY in plaats van Putty, dan zul je zien dat zaken in een mixed Windows/Linux omgeving een flink stuk prettiger werken.
Ik zou eerder willen beweren dat Windows beter te beheren is dan de gemiddelde linux server/client. De enige echt goeie manier voor linux is "redeploy" of externe tools.

En wie zit er nu nog echt aan een GUI... En als powershell al te complex is, wat moet je dan met config management tools voor linux? Dat is helemaal bijna programmeren, ieuw!
Als je aan de terminal op je linux server komt heb je eigenlijk al verloren. Alles had al gescript moeten zijn en dan is het verschil tussen bash of powershell echt niet groot, afgezien van de leesbaarheid dan, daar is powershell duidelijk beter in.

En wat denk je dat de woorden "externe tools" betekenen, natuurlijk ansible en dergelijke zijn fantastische tools. Maar ze hebben zeker hun beperkingen, en vaak is een redeploy en een ansible playbook de beste manier om een nieuwe config uit te rollen. Het hele "het is altijd idempotent" nou... dacht het niet. En Chef en Puppet hebben agents nodig, ook net jammer.

De correcte oplossing voor veel van deze dingen is stiekem toch app containerization, maar goed.
Volgens mij snap jij heel het principe van containers niet. Beheren? Nee!

Als er iets veranderd moet worden bouw je of je image opnieuw en start je de container opnieuw met nieuw image. Of je past de environment aan en restart je de container.

Kijk eens naar 12factor applications.

Als je meer isolatie wil met gebruik van containers kijk eens naar gVisor.

Kom op zeg. Diskspace een issue? Wil je soms alles op nvme draaien

[Reactie gewijzigd door cybermans op 13 juni 2018 18:22]

Dat is leuk voor een webapplicatie die alleen requests moet verwerken, maar bij ons vond een ander team het nodig om Jenkins in een container te dumpen. Want dat was zo makkelijk om op te zetten. Ofzo. Leuk joh, alle configuratie en buildbestanden in een filesystem waar je niet bij kunt. Een image opnieuw bouwen kun je wel vergeten want dan ben je alles kwijt.

Het is heel hip tegenwoordig om containers de oplossing voor al je IT problemen te noemen, maar eigenlijk zijn ze maar heel beperkt nuttig.
Je mist het probleem totaal.

Bedrijven hebben jaren gewerkt aan software. Dat porten naar een ander platform levert ontzettend veel risico op en dus werk om het te kwalificeren en garanderen dat het bij de klant niet omvalt. Dat weegt niet op tegen een iets minder efficiŽnte hardware gebruiken wat zich al lang in combinatie heeft bewezen.

En dat gaat nou eenmaal iets verder dan jouw hobby projectje.
Behalve wanneer het om disruptive innovation gaat, dan kun je je het als niet-vastgeroest bedrijf niet permitteren om niet voor de oplossing te gaan met de beste prestaties/euro. En dat is dus niet altijd Windows of Linux op x86.

Voor machine learning is een IBM POWER9 oplossing bijvoorbeeld veel beter geschikt dan een Intel Xeon oplossing. En zo zal ARM ook zijn voordelen hebben voor sommige toepassingen en nadelen voor andere.
Raspbian is een distributie van Linux. Er zijn al sinds jaar en dag apparaten met een ARM chip die een of andere versie van de Linux kernel draaien. Als je dus een OS hebt wat geen ondersteuning heeft voor ARM ben je dus al snel heel veel ontwikkeltijd kwijt (als het al mogelijk is zonder een complete rewrite te doen).
Beetje raar verhaal, ik wacht zelf al een paar jaar op een simpel NAS boardje met een ARM processor. Elke keer is het "dat komt dit jaar" en nu is het er nog niet.
Dat is toch heel simpel. Dat simpele NAS bordje met ARM processor moet voor jou goedkoop zijn, dat betekend dat het voor de maker weinig oplevert en als de vraag niet enorm is, dan is het al helemaal niet interessant. Nu blijkt dat de vraag niet enorm is, dus wordt het niet gemaakt...
Betaalbaar en leverbaar is wat anders dan goedkoop.
Ik denk dat het probleem is dat ze de source code niet hebben.
Als de server een of ander standaard (ingekocht) pakket draait, dan is dat mogelijk alleen voor x86 beschikbaar als binary, en is er geen alternatief op andere platformen.

GUI is doorgaans geen probleem, de meeste servers hebben niet eens een monitor, en de GUI wordt alleen door systeembeheer gebruikt.

Technisch is het allemaal geen probleem, de problemen van migratie naar andere platformen gaan doorgaans meer over beleid, politiek en, niet te vergeten, geld.
ik wacht zelf al een paar jaar op een simpel NAS boardje met een ARM processor.
Trek een willekeurige low-end NAS open en je vind waarschijnlijk een simpel bordje met ARM-based CPU.... al jaren.
Met net iets te weinig weinig kracht of geheugen.
Debian is geen eerlijke vergelijking.

Van die repos is alles open source beschikbaar (m.u.v. non-free), dat maakt het omzetten van alle bende ook een heel stuk makkelijker.

In de server en enterprise wereld is bar weinig open source. En zet je echt niet zo maar alles over, en moet je ook zeker niet afhankelijk willen zijn van verscheidene 3rde partijen. Het upgraden van een OS is hier soms al moeilijk zat, laat staan je hele hardware inboedel overhoop halen.
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". :)
Maar dat is niet waar het meerendeel van alle servers in de wereld op draait. De grote boeren draaien voor het grootste deel a) Linux en daar bovenop b) hun eigen applicaties of c) nog meer Open Source. Denk aan Amazon, Google, Microsoft, Apple, Cloudfront etcetera.

Juist partijen die third party applicaties zonder source draaien zijn vaak wat meer niche en dan draait het ook niet op 10.000en servers. Hoeveel Exchange servers heeft een bedrijf echt nodig? Of SAP? Tientallen? Voor een groot bedrijf? Zet dat af ten opzichte van wat de grote cloudboeren hebben draaien en het is niet meer dan een druppel op een gloeiende plaat.
Klopt, maar jij zegt wat anders. "Tenzij je op commerciŽle extern gebouwde software vertrouwt? Maar ook dat is toch vrij makkelijk te hercompileren naar ARM?"

Dat botst enorm. "commerciŽle extern gebouwde software" is helemaal niet vrij makkelijk te hercompileren. Je bent 100% afhankelijk van de bouwer. Stellen dat dat makkelijk is, zal per geval zeer verschillende uitkomsten opleveren. De ene werkt zo met je mee en de andere wil dat helemaal niet, want levert niks op.
Het is vrij makkelijk te hercompileren door de bouwer, zelf kun je dat uiteraard niet doen. Maar als je een klant bent die echt op grote schaal servers uitrolt dan mag je best wel eens wat vragen aan je leverancier. Het gaat voor Qualcomm niet om de hoeveelheid bedrijven maar om de hoeveelheid servers. En die verdeling ligt vrij scheef aangezien relatief weinig bedrijven maar gespecialiseerd zijn in taken waarbij duizenden servers nodig zijn. Een normaal bedrijf heeft maar een handjevol servers. En die gaan ook steeds vaker dingen juist in de cloud zetten bij een van die grote partijen. Maakt het jou uit of je Exchange op ARM draait of op x86 bij Microsoft? Alleen als de rekening anders is.
Zo makkelijk is dat altijd niet, vooral in de enterprise wereld hebben developers er een handje van om troep te 'exploiten'. Hoezo API's volgen als ik via deze hack het makkelijker kan. Zoek maar eens op hoe ziek veel uitzonderingen hiervoor in de Win32 API zitten, de Wine developers schrijven er soms wel leuke blogjes over.

Software wat halfbrak draait poort je niet zo maar naar een geheel ander platform. Zeker geen kwestie van even op de knop drukken om te hercompileren.

Daar komt de optimalisatie nog bij op. Veel software weet perfect gebruik te maken van de X86 instructies, maar bij het ontwikkeling is geen rekening gehouden met bv KISS, zo maar even wat instructies 'dumb downen' doe je lang niet altijd zo maar.

[Reactie gewijzigd door batjes op 13 juni 2018 19:33]

Je mist d) Een boel closed source enterprise software is gewoon beschikbaar op o.a. Linux.

Sommige bedrijven leunen op tientallen, honderden applicaties en bijbehorende zut. Prorail zit dacht ik al over de 150 client applicaties heen (als ik het me goed herinner) en zo'n bizar grote partij is dat niet.

Vergis je er niet in hoeveel enterprise software er beschikbaar is op Linux, hoeveel frontend Windows client applicaties waarbij de hele backend er van op Linux draait.
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 stond juist in het artikel ook expliciet genoemd dat voornamelijk kleine bedrijfjes er moeite mee zouden hebben. Maar kleine bedrijfjes gebruiken helemaal geen Citrix of SAP, dat is veel te duur.

Overigens is "volgens mij al geport" een flinke understatement. LAMP is al cross-architecture zolang ik me kan herinneren. Alle gangbare open source Linux software kun je op een veelvoud aan platformen draaien. Niet alleen de LAMP stack, maar iedere moderne programmeeromgeving, webserver, database, etc.
Ubuntu bv heeft officiŽle ondersteuning voor meerdere architecturen, niet alleen ARM maar ook power en s390x: https://www.ubuntu.com/download/server
Er mag gezegd worden dat het echt niet op gaat voor alle databases/stores hoor. Denk Oracle, ElasticSearch, daar gaat het niet verder dan "You can compile for linux on ARm without support." Dat is natuurlijk niet goed genoeg. Het gaat vaak fout als men ook nog support wil. (Dat geldt voor MySQL, PostgreSQL, MariaDb, Percona, MongoDB; bijna allemaal dus.)
Gewoon een kwestie van Debian Stable installeren. ARM support voor alle core packages.

Percona is de vreemde eend in de bijt hier, dat is meer een bedrijfsproduct dan een FLOSS package.
Debian Stable "support" is wel heel anders dan zeg de business Oracle MySQL support of zelfs de Postgre support contracts (3rd-party).

Daarij is Percona nou juist de enige die hun fork volledig open source heeft.
Denk dat wat ze in dit geval kleine bedrijfjes noemen, groter zijn dan we denken. Echt niet de bedrijven van 10-50 man.
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.
Is dat op de dag van vandaag nog steeds het geval? De ARM instructieset wordt steeds meer en meer uitgebreid
Nog steeds valide, en Arm is nog steeds een single word instructie taal volgens mij. Enige uitbreiding op de set is nu 64 bit en Neon.

[Reactie gewijzigd door Wim-Bart op 13 juni 2018 18:44]

Lol nee. ARM heeft de meest CISC-y extensie ooit, Jazelle DBX (Direct Bytecode Execution). Een complete set extra instructies speciaal voor Java.
Dat is een extension volgens mij en niet iedere Arm SOC heeft het, maar zeker ervan ben ik niet. Was het helemaal vergeten dat ze dat inderdaad hebben. Een smet op de architectuur naar mijn inzien.
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]

Waarom zou je dan overstappen? Klinkt alsof je testkandidaat van Qualcomm wordt.
En ons staal wordt in Amerika 2 x zo duur...Terwijl het staal superieur is aan Amerikaans staal.

Lees ook:
Dutch Steel van hoge kwaliteit
Tata Steel levert aan zijn klanten in de Verenigde Staten al meer dan een halve eeuw zeer geavanceerde staalsoorten, die ze in de VS niet kunnen maken. Het staal uit IJmuiden is een begrip in de VS en wordt vanwege zijn kwaliteit ‘Dutch Steel’ genoemd. Het staal van Tata Steel stelt Amerikaanse bedrijven in staat om winstgevende producten te maken van een hoge kwaliteit. Met zijn staal ondersteunt Tata Steel in de VS belangrijke florerende bedrijfstakken, die onder meer blikverpakkingen, batterijen, graaf-, hijs- en mijnbouwvoertuigen en auto’s produceren.

[Reactie gewijzigd door Tourmaline op 13 juni 2018 18:36]

Ja en? En wij stellen importheffingen in op amerikaanse bedrijven. Geen gewenste situatie, maar de VS pakken we blijkbaar gelijk aan.

Kijk nu naar china. Hoe pakken wij de oneerlijke handelswijze van china aan? Hoe pakken wij de chinese staatssteun aan chinese bedrijven aan terwijl daardoor door oneerlijke concurrentie met onze europese bedrijven ontstaat en europese bedrijven daardoor zelfs failliet gaan. Westerse bedrijven krijgen geen of moelijk voet aan de grond in china, terwijl china in onze open economie vrij spel heeft. Is dat eerlijk? Ik vind van niet en we laten het toe dat er misbruik van onze economie wordt gemaakt. Wat dat betreft heeft Trump gelijk, handelsverdragen moet eerlijk een gelijkwaardig zijn. Of Trumps manier de juiste is is een ander verhaal, maar misbruik toelaten vind ik ook niet wenselijk. Als EU moeten we eens daadkrachtig optreden, iets wat Trump wel doet, ongeacht of je het eens met Trump bent, hij doet tenminste iets en dat kan ik wel waarderen van Trump. Maarja, Trump erkennen dat ie iets goeds doet is natuurlijk not done, want Trump. :r
EU moet krachtiger optreden tegen zowel China alsook Amerika. Maar beiden weten het zeer zwakke punt van Europa:

Geen samenhang. Elk land kijkt op dit moment alleen naar zijn eigen belang en dat spelen beide landen slim uit.

Als alle neuzen dezelfde kant opstaan is Europa net zo machtig als China en Amerika.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) 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