HPE voorziet ProLiant-servers van Ampere Altra-soc met 128 Arm-cores

HPE kondigt servers aan die het met Altra-processors van het bedrijf Ampere voorziet. Het zijn de eerste servers van een grote fabrikant die met deze op Arm gebaseerde socs met tot aan 128 cores verschijnen.

HPE kondigt de HPE ProLiant RL300 Gen11 aan, een 1U-server in de nieuwe HPE ProLiant RL Gen11-reeks die het bedrijf met Ampere Altra-chips uitrust. De servers hebben een enkele socket voor een Ampere Altra met maximaal 80 cores of een Ampere Altra Max-soc die met tot aan 128 cores beschikbaar is.

HPE richt zich met de systemen op bedrijven die internetdiensten aanbieden, zoals mediastreaming, sociale platforms, e-commerce en verschillende as-a-servicediensten zoals software-as-a-service. Bij dit soort bedrijven is er behoefte aan een grote hoeveelheid minder krachtige cores.

De ProLiant RL Gen11-servers bieden plek aan maximaal zestien dimm's voor tot aan 4TB werkgeheugen per systeem. Er zijn tot aan drie PCIe 4.0-uitbreidingssleuven aanwezig, in aanvulling op twee OCP NIC 3.0-connectors. Verder bieden de systemen plek aan tien NVMe-ssd's met sff-formfactor.

Ampere kondigde zijn Altra-socs in 2020 aan. Deze zijn opgetrokken rond Neoverse N1-cores van Arm, die op de Armv8.2-architectuur gebaseerd zijn. Zo heeft de Altra Max tot aan 128 van dergelijke cores, met een kloksnelheid van 3GHz. De chip heeft een tdp van 250W en TSMC maakt ze op een 7nm-procedé.

HPE brengt de ProLiant RL300 Gen11 in het derde kwartaal van dit jaar op de markt.

Reacties (54)

Een leuke offtopic tip: Bij Oracle Cloud Free Tier krijg je 4 cores van een Ampere Altra 60 core CPU met 24GB RAM voor niks. Je kunt ook 4 VM's met 1 core en 6GB RAM starten en je krijgt er ook nog eens 200GB storage bij en nog veel meer.

Altijd leuk voor een Tweaker om mee te spelen!

Wat is de catch?

"gratis geld" bestaat niet voor de gemiddelde burger.

Dat je begint te bouwen op Oracle cloud.

Vendor locking dus.

op zich best slim...

Je mag ze in de trail period helemaal gratis gebruiken. Zodra die afgelopen is, moet je een creditcard koppelen om ze gratis te kunnen blijven gebruiken.

Kortom, je wordt de Oracle Cloud in getrokken.

Iedere grote cloud provider heeft zo’n aanbod. Bij Google kan je ook een gratis VM krijgen. Microsoft en AWS bieden ook gratis services aan.

[Reactie gewijzigd door DeeD2k2 op 29 juni 2022 12:07]

Maar bij b.v. AWS is het gratis voor een jaar, hier staat 'permanently free tier' wat insinueert dat je wellicht geen cc hoeft op te geven

Ook bij AWS heb je een aantal services die always free zijn.

Overigens betekend dit niet altijd dat je geen CC hoeft op te geven. Bij Google moest ik hem volgens mij wel opgeven na een jaar om de always free te kunnen blijven gebruiken.
Bij de ARM VM van Oracle is dat in ieder geval wel zo. De AMD VM heeft nooit een creditcard nodig. Sterker nog, je moet hem aan het einde van de trail opnieuw aanmaken als je je CC koppelt nadat je hem gestart hebt…

… kortom: verdiep je wel even voordat je denkt voor altijd een gratis server te hebben.

En, bedenk alvast wat je tegen de account managers gaat zeggen die je beginnen te stalken.

Oracle en gratis, waarschijnlijk komt er twee jaar later een licentiecontroleur langs. En dan volgens de kleine letters je financieel uitwonen omdat je een functie gebruikt die niet gratis is, maar wel beschikbaar.

Je zou er bijna een Minecraft server of iets dergelijks op kunnen runnen voor niks

ik verwacht (niet opgezocht) dat je misschien nog wel voor network traffic moet betalen.

Als ik de voorwaarden zo zie krijg je 10TB, staat helaas niet bij hoe snel het dan is.

Source:
https://docs.oracle.com/e...ree_Resources.htm#compute

Dat is 1Gbit/s per core. https://imgur.com/a/Fg4h1WC

En inderdaad 10TB traffic.

Ik zie dat dit alleen outbound is.

Outbound Data Transfer: 10 TB per month

Ik neem aan dat inbound hier niet in zit. Ik kan dit zo snel niet terug vinden.

Alleen Outbound wordt bijgehouden en is dus 10TB per maand, Inbound is altijd gratis: https://www.oracle.com/nl/cloud/networking/pricing/

[Reactie gewijzigd door dehardstyler op 29 juni 2022 16:23]

Dat kan wel denk ik, ik zou het zeker proberen!

In de highend server wereld, draait er voortaan meer op ARM dan op x86 x64?

Het lijkt me een kwestie van de juiste hardware voor de juiste klus. Deze hardware is goed om veel parallelle, relatief eenvoudige taken af te handelen.

Als je brute rekenkracht nodig hebt dan zul je waarschijnlijk toch weer op x64 uitkomen. De factor software speelt natuurlijk ook nog een enorme rol. De meeste software is x64, emulatie op ARM lijkt me dan weinig interessant.

"Als je brute rekenkracht nodig hebt dan zul je waarschijnlijk toch weer op x64 uitkomen"

Zeg dat nog een keer, nadat je de wrede performance van Apple's M Series CPU's gezien hebt.
ARM CPU's zijn er in veel verschillende uitvoeringen. Low-end tot High-End. En die High-End dingen zijn echt bloedje snel. Ik moet mijn MacMini met M1 sjip aan het bureau vastschroeven, anders vliegt ie weg

"De brute rekenkracht" van de M1 wordt altijd een beetje overdreven. Ja, ze zijn enorm vlot voor het verbruik, maar een goede getunede x86 processor zit daar niet ver achter.
Echter, wat je de laatste tijd ziet(niet alleen bij x86 processoren, ook b.v. bij ARM telefoons) is dat om bovenaan in de benchmarks te staan er totaal niet meer naar efficiëntie wordt gekeken. Tegenwoordig heb je daardoor ventilatoren als accessoire bij telefoons omdat ze anders te heet worden om vast te houden tijdens een spelletje, en bij een beetje gamelaptop is een 100watt voeding niet genoeg om hem draaiende te houden.
Apple doet daar niet aan mee, en ontwikkeld een snelle CPU en laat deze draaien op efficiënte clocks.

Als je b.v. een M1 vergelijkt met een 7nm Ryzen 5800U (15w TDP) https://nanoreview.net/en...e-m1-vs-amd-ryzen-7-5800U dan vallen de verschillen erg mee, en heeft de 5800U ook wel enkele voordelen zoals meer ondersteund geheugen, etc..
Vergelijk je een 5800U met een wat meer high performance Ryzen 5800h(45Watt TDP), dan zie je dat je voor 20% extra performance er misschien wel 100% in efficiëntie op achteruit gaat.

Wat betreft deze Alta's, ik denk dat je erg naar de workload moet kijken of deze een betere performance/watt hebben: https://www.phoronix.com/...altramax-benchmarks&num=3
Bij de benchmarks zie je dat EPYC Milan af en toe VEEL sneller is dan deze Alta's, maar het is ook regelmatig andersom.

Edit:
Nog een aanvulling hierop. Apple M gebruikt dan wel de ARM instructieset, maar het verdere design lijkt in niets meer op de referentiedesigns van ARM. Ze zorgen er ook voor dat enkele workloads waar hun klanten veel gebruik van maken enorm worden geaccelereerd, feitelijk door de ARM instructieset uit te breiden en extra hardware toe te voegen. Uiteindelijk gaan x86(uitgebreide instructieset - soms wat veel ballast ) en ARM(lean and mean instructieset - maar bij sommige taken traag) daardoor steeds meer op elkaar lijken. Welke instructieset uiteindelijk de performance/efficiëntie "kroon" gaat pakken hangt meer af van hoe bedrijven als ARM/Qualcomm/Apple/AMD/Intel kunnen innoveren. Er zijn nog steeds grote stappen mogelijk.

[Reactie gewijzigd door YoMarK op 29 juni 2022 13:01]

Ze zijn zeker niet traag maar de software moet er wel klaar voor zijn. Daarnaast ontwikkelt x64 zich ook. Je kan onder de streep niet zeggen dat ARM sneller is dan x64, het hangt van het scenario af.

ISA van de CPU heeft nauwelijks invloed op de overal performance. In dit geval is de CPU + chipset + geheugen + OS op elkaar afgestemd en dat levert een goede performance op. Als je de huidige X86 ziet zie je dat die vaak memory starved zijn (zeker met 8+ cores die je vol inzet: de geheugenbus is gewoon te traag). Dus krijg je dingen als 3D cache van AMD en de volgende Intels krijgen ook meer cache. Als je die M1 echter gaat tweaken tot het absolute performance niveau van een Threadripper (die veel minder memory starved is) dan zal je zien dat het stroomverbruik navenant stijgt en de M1 waarschijnlijk niet het niveau kan halen zonder een compleet redesign omdat je tegen andere limieten in je ontwerp aanloopt.

Je gaat toch geen trage consumenten cpu vergelijken met enterprise hardware?
Ooit de bandwidth van een moderne high end server ervaren ?

"Ooit de bandwidth van een moderne high end server ervaren ?"
Yep. Elke werkdag.

Gezien de ontwikkeling die Apple heeft doorgemaakt op het gebied van ARM durf ik je hier wel op tegen te spreken. Het is een kwestie van tijd totdat andere fabrikanten die ontwikkeling ook voorbij x86 hebben gebracht. Daarnaast is ARM makkelijker te produceren en eet beduidend minder energie. Ik verwacht dat er met enkele jaren geen x86 meer in servers verkocht worden.

Dat de meeste software momenteel x86 is dat zegt natuurlijk niet zo veel; software zal altijd de hardware volgen.

[Reactie gewijzigd door RockmanX op 29 juni 2022 10:01]

los van het feit dat @oef! het over x64 heeft. Is het niet alleen de hardware die telt hier. Wat ben ik nu met een M2-supercore server (ik argumenteer even met wat ik niet heb ) als mijn software daar niet op draait. Idd, niets. En dat moet dus eerst herschreven worden, en op dit moment lijkt niets erop dat de software die ik draai, beter gaat draaien op een (huidige) ARM-based server. Of dat nu van Apple is of niet. En als dat er is, dan zal kosten baten wel wijzen of wij de software dienen te herschrijven of niet, en dat is ook niet iets dat op 1 jaar gebeurt.

Over dat laatste, de toekomst zal het uitwijzen, maar er is eigenlijk niet echt iets dat wijst op het feit dat de gehele markt gaat kantelen naar ARM.

los van mijn mening.

quote: paper

While our study shows that RISC and CISC ISA traits are irrelevant to power and performance characteristics of mod-ern cores, ISAs continue to evolve to better support exposing workload-specific semantic information to the execution sub-strate. On x86, such changes include the transition to Intel64 (larger word sizes, optimized calling conventions and shared code support), wider vector extensions like AVX, integer crypto and security extensions (NX), hardware virtualization exten-sions and, more recently, architectural support for transactions in the form of HLE. Similarly, the ARM ISA has introduced shorter fixed length instructions for low power targets (Thumb), vector extensions (NEON), DSP and bytecode execution exten-sions (Jazelle DBX), Trustzone security, and hardware virtualization support.

quote: paper

Our findings confirm known conventional (or suspected) wisdom, and add value by quantification. Our results imply that microarchitectural effects dominate performance, power, and energy impacts. The overall implication of this work is that the ISA being RISC or CISC is largely irrelevant for today’s mature microprocessor design world.

bron: https://research.cs.wisc....3-isa-power-struggles.pdf
en ja, het is best een oude bron, maar het de redenering gaat nog steeds op (imho)

* aanpassing van mijn eerste zin naar een opmerking van @i-chat

[Reactie gewijzigd door Yoshi op 29 juni 2022 13:04]

Schrijf jij recht in assembly dan? Volgens mij draait alles van java, .net, tot nodejs/v8 en php allemaal op ARM based chips. Hoef je het niet eens voor te hercompilen. Go, rust en c(++) kun je targetten tot ARM. Ik kan mij enkel hele specifieke dingen in low level c met drivers en zulk in denken waar het een probleem is.

Het echte probleem zit er in dat op een of andere manier elk bedrijf lijkt te werken rondom een programma uit 1995 waarvan de maker inmiddels overleden is en enkel op x86 draait. Maar, daar komen we het vanzelf achter, plus dat valt inmiddels snel zat te emuleren

Zo simpel als crosscompilen/targeten is het niet. Dan moet je eigen code wel eerst architectuur agnostisch zijn en heel erg veel libraries en frameworks zijn dat niet.

Dat echte probleem waar je het over hebt herken ik goed. De oorzaak is doodeenvoudig, features gaan ver boven best practise in de ogen van iedereen in het bedrijf behalve de devs

[Reactie gewijzigd door youridv1 op 29 juni 2022 11:15]

Wellicht dat je in c(++) daar problemen mee hebt maar in java/javascript/python/.net/php heb je daar allemaal geen last van, dat kun je niet eens compilen voor een specifiek target. En dat zijn toch echt de meest gebruikte talen volgens github.

Ja, voor niet performance kritieke doeleinden wel ja. Neem ook wel mee in je "volgens github" dat er een heel stuk meer devs zijn voor die programmeertalen dan voor c(++). Met name door de leercurve van die taal. Niet om condescending te doen, maar zo is het feitelijk wel. Python wordt actief op niet programmeeropleidingen gegeven als data verwerk tooltje. Daar hoef je met c niet aan te beginnen en dat doet men ook niet.

C++ houdt de boel op die manier wel tegen. Operating systems, games, zwaardere applicaties zijn heel erg vaak op zijn minst deels in C geschreven, om goede redenen. Dat is nu eenmaal het probleem met low level, de hardware is relevant

Ook kun je daar in die non lowlevel programmeertalen ook gewoon last van hebben. Op het allerlaatste moment vervallen alle programmeertalen tot CPU instructies en als de onderlaag voor jouw high level taal niet bestaat voor een bepaalde architectuur, dan zit je met de gebakken peren.

[Reactie gewijzigd door youridv1 op 29 juni 2022 12:57]

Persoonlijk ben ik absoluut geen fan van python, maar het is wel de meest gebruikte taal. Er is uiteindelijk zeer weinig wat cruciaal is. Nodejs wat ongeveer 3x trager is als native c(++), kost inderdaad 3x zo veel rekenkracht en server kracht, maar de kosten daarvan wegen niet op tegen de zeer trage development kosten van c(++).

Gelukkig zijn de benchmarks voor c++ altijd ontzettend onveilige code zonder fatsoenlijke garbage collection. Langzaam zien we ook een beweging tot talen als go en rust voor optimale snelheid (go ongeveer 1.5 zo traag als c++, rust meestal sneller) zonder de problemen met legacy die c++ met zich mee draagt

C++ heeft geen garbage collection, maar dat weet je vast wel. Dus behalve heap pointers niet vrijgeven is er weinig wat de programmeur fout kan doen. De enige manier om een memory leak te creëeren is door expliciet pointers te gebruiken zonder abstractielaag of std::unique_ptr. Daar is anno 2022 geen excuus meer voor. unique zat al in c++98

Daar komt ook nog eens bij dat, wil je iets realtime doen, je wel een taal als c++ moet gebruiken vanwege het gebrek aan garbage collection overhead/interrupts. Die feature is mbt tot zelfrijdende autos tegenwoordig zeer relevant.

Ik ben wel fan van python, voor de dingen die je er mee moet doen. Snel scripten en dataverwerking kan python als geen ander. Maar liever geen grote projecten in schrijven.

[Reactie gewijzigd door youridv1 op 29 juni 2022 13:55]

Zo simpel als crosscompilen/targeten is het niet. Dan moet je eigen code wel eerst architectuur agnostisch zijn en heel erg veel libraries en frameworks zijn dat niet.

Dan ben ik benieuwd waar het over gaat.

De meeste libraries gebruiken de kernel API of een kernel-user wrapper library met API om functionaliteit te ontsluiten, als je die gebruikt boeit architectuur niet echt meer en kan je vrijwel de hele portage/debian tree binnentrekken en recompilen. Optimalisaties daargelaten.

Enige issues die ik met porten van o.a x86->arm en power heb gezien is libc/compiler en specifieke hardware offloading (aes accelerator, netwerkspul) zonder standaard API in de kernel. Ik heb even mogen spelen met zo'n Ampere vrij snel na introductie en weinig customs kunnen ontdekken, daar zit onmogelijk lange duur software porting in, andere kernel maar dat lijkt me logisch.

Dat zal ongetwijfeld anders zijn bij een OS als Windows maar dat ligt aan de intentie van de maker en is niet het probleem van architectuur.

wanneer je je reactie al begint met ... hij heeft het over x64 niet over x86? moet ik je dan nog wel serieus nemen?

x64 bestaat immers niet, je hebt wel IA64 (itanium) en je hebt volgens mij ook nog. Power^64 ... er is ARM64 én er is X86_64 (ook wel AMD64) genoemd?

dat wat jij x64 noemt heet dus gewoon x86_64 of kortaf. x86

dat is persoonlijk I guess, ik maak idd een onderscheid tussen die twee. Net zoals tussen arm32 en arm64.
Als je daarom mensen niet serieus neem, dan moet je dat maar doen.

goed lezen dan, - je verbetert iemand op het gebruik van term A die generaliserend correct is, met term B die feitelijk foutief is. dat is bijna het zelfde als versie 1.5 ineens versie 5 noemen. zonder dat die naamsweiziging vanuit de devs komt en ook in het version (git) systeem wordt overgenomen.

x64 bestaat gewoon niet als zodanig, dus als je dan betweterig gaan doen en iets zodanig bemoemt maakt de discussie gewoon zinloos, verwarrend en feitelijk onjuist.

Als jij vervolgens komt met, 'ja maar ik maak onderscheid, als je me daarom niet meer serieus neemt' dan vraag ik me af of je überhaupt wel begrijpt hoe versioning werkt, want dat was mijn punt helemaal niet, mijn punt was dat je zaken correct moet benoemen vooral als je eerst kritiek uit op anderen'

arm64 ARM noemen is correct - maar generaliserend dus soms onwenselijk,
x86_64 x64 noemen kun je misschien doen bij de lokale computercursus - maar ook dan moet je eigenlijk gewoon de correcte leken-naam: AMD64 gebruiken, echter in een tweakers.net-context hoor je gewoon de juiste termen en namen te kennen (of als dat niet is, dan hoor je anderen niet te verbeteren).

[Reactie gewijzigd door i-chat op 30 juni 2022 12:25]

1. Ik heb mijn eigen verbeterd, zelfs met een verwijzing, je mag stoppen met doorbomen
2. Ik ben niet de enige die die term zo gebruikt, dus laat die je en jij en computercurus maar gewoon vallen.

[Reactie gewijzigd door Yoshi op 30 juni 2022 13:58]

Zucht, krijgen we dat weer. Lees even https://chipsandcheese.co...or-x86-isa-doesnt-matter/ om een indruk te krijgen dat de ISA (instructie set ARM/X86) nauwelijks invloed heeft op de performance van je CPU. Het is een combinatie van core design, memory bus en tradeofs van absolute performance/performance per watt die de discussie leuk maken. Tegen de tijd dat er een M1 is die het tegen een Amd Epyc moet opnemen (met 128 PCI-e lanes, 64 cores en een sloot aan cache) zal je zien dat die vergelijkbaar presteren zolang ze ongeveer uit het zelfde tijdvlak komen. Om een indruk te krijgen van hoe een M1 scoort op het perf/watt verhaal: https://www.cpubenchmark.net/power_performance.html (ik heb de data niet helemaal doorgeploegd, maar het lijkt wel overeen te komen met de theorie)

Ik heb dat verhaal even doorgeskimmed en het hele verhaal verbaasd me een beetje,

claimen dat de ISA geen invloed heeft op performance / watt. door te claimen dat niet de ISA maar de optimalisaties ertoe doen. - mijn vraag is dan direct, kun je alle optimalisaties wel gelijkelijk implementeren. of is het bij de Simpelere ISA's wat makkelijker dan bij de Complexere ISA's. in other words waarom heeft men voor ARM gekozen in mobieltjes als ze ook gewoon x68 hadden kunnen kiezen?

techisch gezien lijkt het verhaal wel te kloppen, maar de vraag is of het ook logisch is en of het in de praktijk ook zo uitpakt.

Als je brute rekenkracht nodig hebt dan zul je waarschijnlijk toch weer op x64 uitkomen.

Of een GPU.

of een DPU / FPGA of zelfs een dedicated chip.

Als draaien op ARM voordeliger is dan andere opties zal er wel een omslag komen. Ik ken in ieder geval geen bedrijf die het graag duurder wil...
Maar het duurt natuurlijk wel even voordat er een echte omslag is. Niet alle software is geschikt voor en/of voordeliger te draaien op ARM. Servers moeten ook een aantal jaar meegaan want niemand vervangt ze binnen een jaar (meestal tussen de 3-5 jaar). En er moet natuurlijk ook voldoende aanbod zijn van betrouwbare partijen zoals HP hier. Weinig bedrijven zitten te wachten op servers zonder supportcontract van een leverancier die er over 3 jaar misschien niet eens meer is...

"Bij dit soort bedrijven is er behoefte aan een grote hoeveelheid minder krachtige cores."

Nu klinkt het alsof dit niet een serieuze server is, maar bij een demonstratie liet Ampera zien dat software welke goed parallel draait hogere performance haalt op een Ampera ARM systeem dan een high-end Intel Xeon, en met een behoorlijk lager stroomverbruik.

Dat lijkt mij op zich niet gek als je veel meer cores hebt. Alleen blijven er toch nog redelijk wat taken hangen op single thread performance. Dus real life app performance is veel interessanter.

Sowieso was een vergelijking met AMD waarschijnlijk relevanter geweest. Want volgens mij lopen die nog redelijk voor op intel qua performance per watt. (Ja meer mensen gebruiken nog oude XEONs, maar dan kun je ook wel gaan vegelijken met 5 jaar oude XEONs en dan win je altijd).

Het is perfect voor t web, toch wel erg veel is van de workload. Je kunt volledig single threaded 1 web request handelen, maar wel 128 tegelijk op losse threads. En op die specifieke threads kun je weer meerdere dingen door elkaar draaien met async/await magie van moderne talen.

Het is perfect voor t web, toch wel erg veel is van de workload. Je kunt volledig single threaded 1 web request handelen, maar wel 128 tegelijk op losse threads. En op die specifieke threads kun je weer meerdere dingen door elkaar draaien met async/await magie van moderne talen.

Absoluut, en eigenlijk iets wat niet nieuw is. Een slordige 15 jaar geleden had Sun Microsystems al de UltraSPARC T2 die 8 cores, met 8 threads per core deed (dus 64 concurrent threads per CPU). De T3 (uit 2010) deed 128 threads / CPU. Een van de use cases was inderdaad webservers.

Als het de de Altra M128-30 is. Dan is het in verbruik en performance vrijwel gelijk met de AMD Epyc 7763. Alhoewel dit een beetje afhankelijk is van het scenario.

https://www.phoronix.com/...altramax-benchmarks&num=3
https://www.phoronix.com/...altramax-benchmarks&num=4

Interessant, ARM is dus alleen sneller in bepaalde workloads ivm. de concurrentie en in een aantal gelijkend. Qua CPU prijs zit er weinig verschil tussen de M128-30 en Epyc 7763. Ik vond het verbruikstabelletje erg lastig te interpreteren, ergens tussen de 30%-35% minder stroom verbruik tijdens max belasting. Ik ben persoonlijk dan meer geïnteresseerd hoeveel stroom verbruik per performance er wordt verbruikt.

30%-35% minder stroom klinkt niet super indrukwekkend, maar dat is alleen het verbruik van de server, dat betekend ook minder warmte en dus minder stroom verbruik voor de koelinstallatie. Wat erg belangrijk is in datacenters.

Lijkt me voornamelijk interessant in hele grote setups waarbij je dedicated servers/clusters hebt per CPU oplossing waar je je optimale workload op kan draaien. Je blijft echter afhankelijk van de software, is het beschikbaar voor ARM en hoe performed het daarop...

Bij verbruik staan de cijfers er ook bij. De uiterste streepjes geven de absoluut gemeten min/max aan. Verder volgt het de standaardlayout van een box plot.
De uiterste kanten van het blokje geven dus aan waar 50% van de gemeten waarden in vallen, de laagste 25% metingen zitten er links van, de hoogste 25% erboven.
Binnen het blokje staat er nog een streepje op de mediaan.

Wat je bij de Ampere dus ziet is dat gedurende de testen het verbruik nog best vaak tussen 200-235W slingert terwijl de Intel en Epyc ingesteld zijn op bvb 250W per socket en zichzelf héél precies kunnen regelen op dat niveau.
Dit kan ook duiden op imperfecties in hun geheugen/pipeline-opzet, waardoor een deel van de CPU zit te wachten tot het weer wat kan doen. Misschien zijn Intel/AMD beter in alle rekenunits bezig te houden.

Verbruik is ook gemeten tijdens Stress-NG, waar AMD en Intel het sowieso vrij slecht doen.
Als je de benchmarks bekijkt, dan doen de Altra's het in sommige heel goed, maar in andere is AMD weer sneller met enorme marge. Intel komt er totaal niet aan te pas.
Je zou per workload/benchmark eigenlijk de performance/watt moeten berekenen, zeker omdat er soms enorme verschillen in zitten.

Tot nu toe waren DL xx0 servers met Intel processoren, en DL xx5 servers met AMD processoren.
Ik vraag mij af wat de naamgeving gaat zijn voor Ampere processoren.

RLxx0 he.

Misschien moeten de heren (sterk vermoeden dat het nooit vrouwen zijn) eens de volgende woorden opzoeken in de dikke van Dale : ironie,satire, cynisme en sarcasme

Bovenstaande post zou je kunnen omschrijven als “ironie”, lichte spot

Dank je! zal er maar een /s aan toevoegen...