Chinees bedrijf werkt aan ARM-serverchip met 64 cores

Het Chinese bedrijf Phytium Technology werkt aan een processor met 64 ARM-cores en geheugen- en cache-controllers op een enkele die. De processor is bedoeld voor enterprise-servers en cloud computing.

Phytium is in 2012 opgericht en voornemens de grootste cpu- en asic-leverancier van China te worden, blijkt uit de presentatie die het bedrijf gaf op de Hot Chips-conferentie in het Amerikaanse Cupertino. De Mars-chip van Phytium is bedoeld voor toepassingen die veel rekenkracht, geheugen en bandbreedte vergen. Daarnaast werkt het bedrijf nog aan Earth, een minder high-endprocessor waarover nog weinig bekend is en die voor schaalbare toepassingen bedoeld is.

Mars is opgebouwd uit acht 'panelen' waarbij elk paneel weer over acht cores beschikt. Een paneel beschikt over 4MB L2-cache waarmee Mars als geheel over 32MB L2 beschikt. De cores zijn gebaseerd op een 'Xiaomi'-ontwerp, dat niets met de Chinese smartphonefabrikant van doen lijkt te hebben. Het gaat in ieder geval om cores op basis van de ARMv8-architectuur die over 32KB L1 instructie- en 32KB datacache kunnen beschikken.

Verder beschikt Mars over acht controllers die Phytium CMC's noemt. Deze verzorgen de verbinding met zestien ddr3-1600-kanelen en 128MB L3-cache. Ook zijn er twee pci-e 3.0-interfaces. De chip heeft afmetingen van 25x25 millimeter, draait op 2GHz en wordt op 28nm geproduceerd. De tdp ligt op 120W. Volgens de Chinese maker ligt de hoeveelheid rekenkracht op 512gflops.

Phytium zal onder andere de concurrentie met Qualcomm, Cavium en AMD aangaan, die ook aan zuinige serverchips op basis van ARM werken. Daarnaast werkt Intel aan zuinige serverchips. Wanneer Mars en Earth uit moeten komen is echter niet bekend.

Reacties (35)

[Jaco69]

Hoe vergelijkt 512Gflops bij 120W zich met bestaande server chips?

[Dreamvoid]

Da's lastig te zeggen. Het is vrij eenvoudig om een chip met geen/weinig cache te maken met gruwelijk veel GFLOPS, maar de bruikbaarheid in bv een database server is dan vrijwel nul. Een 61-core Xeon Phi doet bv iets van 2400 Gflops op 300W, maar je moet er geen grote Oracle db op willen draaien.

Aan de andere extreem heb je bv een 15-core/30-thread Ivy-Bridge-EX chip die iets van 670 Gflops op 155W draait, maar de helft van die chip bestaat uit (stroomvretende) cache zodat je er ook iets van terug ziet in mem-intensieve applicaties.

Anyway, zonder de cache grootte en throughput van de memory controllers kan je nog vrij weinig zeggen over wat voor performance hij zou moeten hebben.

[Reactie gewijzigd door Dreamvoid op 28 juli 2024 05:43]

[narotic]

Floating point performance is over het algemeen ook niet zo belangrijk voor database toepassingen. FP is daarentegen wel belangrijk voor wetenschappelijke toepassingen, simulaties e.d.; oftewel het ouderwetse "number crunching". Mede dankzij acceleratie technieken als AVX of SIMD is geheugen voor die toepassingen tegenwoordig ook al vaak de beperkende factor, wat waarschijnlijk verklaart waarom deze Chinese chip maar liefst 32 MB L2 en 128MB L3 cache heeft.

Overigens heb je wel gelijk dat er niet voldoende informatie is om echt iets concreets over de 512 Gflop/s te zeggen. Is dit single of double precision? Theoretische piek of daadwerkelijk gemeten op bijv. Linpack? Desondanks is 512 Gflop/s grofweg van dezelfde orde als moderne high-end Xeon CPU's bij vergelijkbare TDP.

[robvanwijk]

Overigens heb je wel gelijk dat er niet voldoende informatie is om echt iets concreets over de 512 Gflop/s te zeggen. Is dit single of double precision? Theoretische piek of daadwerkelijk gemeten op bijv. Linpack? Desondanks is 512 Gflop/s grofweg van dezelfde orde als moderne high-end Xeon CPU's bij vergelijkbare TDP.

64 cores op 2GHz = 128G processor ticks / second
Met de vier fetch/decode/dispatch units genoemd op de tweede slide kom je dan inderdaad keurig aan 128G * 4 = 512G operations / second.

Dat wil trouwens nog steeds niet zeggen dat we ook echt 512 Gflops halen, want daarvoor moeten al die operations ook nog eens een keer floating point operations zijn... en op de derde slide staan slechts twee FP units... Op zich zou het kunnen hoor (wie weet zijn die FP units wel double pumped), maar ik ben bang dat ie (zelfs theoretisch al) blijft steken op 256 Gflops.

edit:

De 256 Gflops die ik hierboven bereken ziet één detail over het hoofd, zoals hardwareaddict terecht opmerkt: 256 Gflops * "FMA telt voor twee operaties" = 512 Gflops

Overigens staat er bij die claim van "512 Gflops" sowieso al "peak", dus ga er maar vanuit dat dat theoretisch en single precision is.

Nalezen van het PDFje dat in het artikel gelinkt wordt geeft ietsje meer "echte" informatie:

• 1x SPEC_CPU2006_base
  • INT: 19.2
  • FP: 17.8
• 64x SPEC_CPU2006_base
  • INT: 672
  • FP: 585

[Reactie gewijzigd door robvanwijk op 28 juli 2024 05:43]

[Squee]

Nalezen van het PDFje dat in het artikel gelinkt wordt geeft ietsje meer "echte" informatie:

• 1x SPEC_CPU2006_base
  • INT: 19.2
  • FP: 17.8
• 64x SPEC_CPU2006_base
  • INT: 672
  • FP: 585

Het is ook wel leuk om die scores een beetje in perspectief proberen te zetten. Op Spec.org is er een mooi archief te vinden van behaalde SPECcpu2006 scores uit het verleden, dus laat ik eens een poging wagen.

Een SPECint score van 19.2 komt ongeveer overeen met die van een Xeon E5502, een Nehalem-EP die op bijna dezelfde kloksnelheid (1.87GHz) loopt. En dan is de Intel score nog een klein beetje opgekrikt omdat ze auto parallelization gebruiken op de libquantum benchmark.

Een SPECfp score van 17.8 zitten ze aardig onder de score van de Xeon E5502 waarmee ik hem net vergeleek, die een score van 20.7 haalt, maar ook hier wordt weer flink autopar gebruikt (helaas zijn resultaten zonder autopar amper te vinden - wat toch de werkelijke single thread/core performance weergeeft). De Xeon E5405 is meer in de buurt van wat deze Chinese chip claimt te halen. Maar dan hebben we het wel over een hele oude Harpertown uit 2007.

Wat betreft de SPECcpu-rate scores (full chip throughput), kunnen we eerst proberen een klein rekensommetje te doen om te zien hoe "schaalbaar" hun systeem dan lijkt te zijn. Een score van 672 op INT komt neer op 10.5 per core, wat 45% lager ligt dan hun single core score. Een schaling van 35x, dus slechts 54% efficientie van de 64 cores. Wat betreft FP komt het neer op 9.1 per core, 48% lager dan hun single core score, en een schaling van bijna 33x, ongeveer 51% efficientie.
Overigens kunnen deze schalings cijfers aan veel dingen liggen; niet per se alleen maar hun cache coherency bijvoorbeeld (opzich is alles nogal onafhankelijk in 'rate'), of dat ze hun geheugen bandbreedte limiet bereiken, maar het kan ook liggen aan hoe goed het OS kan schalen en hoe intelligent het geheugen toewijst bijvoorbeeld.

Goed, laten we ook nog eens kijken naar wat vergelijkingsmateriaal voor SPECcpu2006 rate resultaten.

Als ik op zoek ga naar scores die uberhaupt in de buurt komen, dan komen we een oude bekende tegen; een AMD Opteron 6174, 4 sockets, ook wel bekend als het 48-core "Magny Cours" monster indertijd, evenaart de INT score van de enkele chip. Als ik op zoek ga naar alleen maar single-socket resultaten dan kom ik uit bij een Xeon E5-2630 v3 die met 18 cores op 2.4 GHz (Haswell!) een vergelijkbaar resultaat behaalt.

En dan FP rate, voor een enkele chip die 585 op FP rate haalt is geen vergelijkbaar resultaat te vinden. Het dichtst in de buurt komt het grotere broertje van de E5-2630 v3, namelijk de Xeon E5-2699 v3 met een 45MB L3 cache op 2.3GHz, met een score van slechts 474. Wat wel in de buurt komt als je naar 2 sockets gaat kijken is een Xeon E5-2660 v2, 2x 10 cores Ivy Bridge op 2.2 GHz.

Eindconclusie: De single thread/core performance is niet super sterk, de schaling is zeker niet ideaal, maar de totale throughput van deze chip is toch best wel flink indrukwekkend! Het feit dat ze op SPECint rate mee kunnen komen met de laatste 18 core Haswell Xeon en daarin SPECfp rate zelfs over heen gaan is wat mij betreft best een klein applausje waard. Maar goed, dat is natuurlijk wel allemaal uit gaande van dat deze scores niet zomaar uit de lucht gegrepen zijn, ze zijn namelijk nog niet officieel bij SPEC gerapporteerd

[hardwareaddict]

update: hij kan 4 instructies per clock decoden en ook executen. Lijken 2 SIMD units te zijn die dus 2 instructies per clock kunnen uitvoeren.

Dan kom ik uit op heel vet meer dan 512 gflops hoor - tenzij ze 'm op 250 Mhz ofzo gaan klokken. Maar er staat 2Ghz op de sheet.

Even domme throughput berekening uitgaande van multiply add:

64 cores * 2Ghz * 2 SIMD units * 1 double * 2 FMADD = 512 Gflops.
Ik vermoed dat dit hun berekening is.

512 BTB ==> ik gok dat is Branch Target Buffer
De oude K7 had ook 512 entries in de BTB.
Da's prehistorisch CISC dus.

Daar kun je op integer loads niet zulke enorme hoge IPC's mee halen (instructions per clock).

Maar waarom noem je iets SIMD unit als hij maar 1 double can executen per clock?

Waar 't uiteindelijk om gaat is: hoe snel execute je multiplication?

De modernere i7's die doen dat in 1 clock throughput voor AVX, dus dat ramt er enorm veel gflops per clock doorheen.

120 watt voor maar 64 cores klinkt lachwekkend veel hoor.

Maar het is allemaal getekend alsof het een dure supercomputerchip wordt met geavanceerde global cache coherency.

Dat gaat dus niet lukken simpelweg en zeker niet op 2Ghz op 28 nm. Forget it.

[Squee]

Dan kom ik uit op heel vet meer dan 512 gflops hoor - tenzij ze 'm op 250 Mhz ofzo gaan klokken. Maar er staat 2Ghz op de sheet.

Even domme throughput berekening uitgaande van multiply add:

64 cores * 2Ghz * 2 SIMD units * 1 double * 2 FMADD = 512 Gflops.
Ik vermoed dat dit hun berekening is.
(...)
Waar 't uiteindelijk om gaat is: hoe snel execute je multiplication?

Ja het lijkt me ook dat een FMA door hun als twee Flop gezien wordt, en hij schijnt dat met een latency van 6 cycles te kunnen, maar om theoretisch 512 GFLOPS sustained te kunnen behalen zal de FMA dus wel fully pipelined moeten zijn. FMUL en FADD individueel zijn 3 cycles aldus de slides.

512 BTB ==> ik gok dat is Branch Target Buffer
De oude K7 had ook 512 entries in de BTB.
Da's prehistorisch CISC dus.

Ik begrijp niet hoe je de specs van de branch predictor weet te koppelen aan CISC. Overigens heeft hij een 2048 entry Branch Target Buffer en een hele moderne TAGE branch predictor, wat een van de best presterende branch predictors van dit moment is. Ze hebben zelfs iets in de instructie decode wat loops kan detecteren in de instruction buffer zodat volgende iteraties er meteen van geissued kan worden zonder dat ze naar de I cache hoeven...

Deze jongens weten volgens mij echt wel waar ze mee bezig zijn. Maar eigenlijk verbaast het me ook niet zo heel erg als je ziet hoeveel Chineze studenten je aan de Amerikaanse technologie universiteiten ziet en hoeveel Chinezen er hier werken in Silicon Valley. Op een gegeven moment hebben ze genoeg expertise gecreeerd en keren ze terug naar China, en dit soort projecten zijn daar waarschijnlijk het resultaat van. Een interessante ontwikkeling.

[Reactie gewijzigd door Squee op 28 juli 2024 05:43]

[hardwareaddict]

Alles zal out of order moeten. Vandaar CISC.

Maar het is vrij lachwekkend om een ARM type core te gebruiken voor een highend server chip met allerlei vormen van cache coherency in de caches.

Het is intel niet gelukt om de cache coherency goed te implementeren op hun 4 socket systemen. De latency was te traag. Bij 2 sockets lukte het heel aardig.

Waarom zou deze gasten met 0 ervaring het ineens lukken met 64 cores?

Komt mij over als lachwekkende kladje bedoelt om de aandacht te trekken van militaire organisaties - want iemand anders kan 't toch niet betalen.

[Squee]

Waarom zou Out of Order gelijk aan CISC moeten zijn? Dat heeft werkelijk niets met elkaar te maken. Out of Order is juist waarschijnlijk lastiger bij CISC, vandaar dat ze alles in micro ops (in feite dus RISC operaties) op moesten splitsen om het fatsoenlijk te kunnen schedulen. Even een overzichtje;

• DEC Alpha 21264 en 21364 waren RISC en Out of Order
• MIPS/SGI R10000 en R12000 waren RISC en Out of Order
• ARM Cortex A57 is RISC en Out of Order
• SPARC T4, T5, M5, M6 zijn RISC en Out of Order
• IBM POWER7 en POWER8 zijn RISC en Out of Order

Dus ik begrijp niet zo goed wat je daar mee bedoelde?

ARM wil al langer richting de servermarkt en vandaar ook dat ARMv8 een fatsoenlijke 64 bits instructieset is. Ik zou ook niet zomaar willen claimen dat het een "klein" bedrijfje is wat hier achter zit, de details van het aantal mensen wat ze hier aan hebben werken hebben ze volgens mij niet gegeven, maar het zal me niets verbazen als er hier een flinke hoeveelheid mankracht achter zit. Ze hebben namelijk ook geen stock ARM implementatie genomen blijkbaar voor hun cores, of op zijn minst hebben ze er flink aan lopen sleutelen. Als het werkelijk een lachwekkend kladje zou zijn, dan neem ik aan dat een organisatie als Hot Chips daar wel doorheen zou prikken en het niet op hun conferentie zou laten presenteren.

Dat Intel het niet goed lukte om cache coherency te implementeren, daar kan ik ook weinig aan doen Volgens mij is dat toch wel flink verbeterd sinds ze QPI hebben overigens. SPARC M6 schaalt naar 32 sockets (384 cores) en kan theoretisch naar 96 sockets schalen, maar er is op dit moment gewoon geen vraag naar in de markt voor dat soort gigantische, en vooral ook dure, shared memory systemen.

[hardwareaddict]

Die slides slaan echter nergens op, want er staat op die slides ook dat de cache coherency gemaintained gaat worden.

Vergeet dat maar hoor.

Dat gaat mooi niet lukken in ons leven - tenzij ze een gedrocht bouwen zonder cache coherency.

Dan is 120 watt weer extreem veel budget. 2.2 watt voor quad core ARM SOC x 16 = 35.2 watt en dit is dan 120 watt.

Dus veel en veel te hoog geklokt voor enig REALISTISCHE server applicatie, want het moet dan niet 35.2 watt vreten maar liever 10 watt ofzo voor 64 cores en dat is ook wel haalbaar.

Maar cache coherency - dat gaat natuurlijk NOOIT LUKKEN met 64 cores.

[Squee]

Waarom zou cache coherency nooit gaan lukken met 64 cores? Dat vind ik nogal een claim, zeker als je bedenkt dat de komende Xeon Phi (2e generatie, Knights Landing) coherent is met 72 cores op een enkele chip. Het zal inderdaad niet gaan werken met alleen maar snooping, maar met een degelijk ontworpen protocol (een afgeleide van MOESI bijvoorbeeld) is dat echt niet zo onmogelijk als je misschien denkt. De SPARC T5-8 systemen schalen moeiteloos naar 128 processor cores bijvoorbeeld.

Maar laten we eens kijken wat ze wel zeggen in de presentatie over hun cache coherency; Ze hebben in ieder geval op elk "panel" twee coherency units zitten (DCU's, Directory Control Units), eentje bij elke L2 cache van 4 MB. Het is dus overduidelijk een directory gebaseerd coherence protocol, waarvan het bekend is dat die behoorlijk kunnen schalen. Ze hebben het ook over een "panel-based data affinity architecture" wat mij doet vermoeden dat iedere cacheline een vaste 'home node' heeft in een bepaalde directory op een van de panels. Daardoor kan je op basis van het adres altijd bepalen bij welke directory je moet vragen wat de status is, en of iemand anders een kopie heeft. Vanuitgaande dat de L1/L2 caches inclusive zijn hoeft de directory dus alleen maar de metadata door de L2 bij te houden. Aangezien de L3 bij de memory controllers off-chip zit op hun "CMC" gok ik dat die alleen als buffer dient voor DRAM en niet mee doet aan het coherency protocol.

Ik begrijp ook niet zo goed wat je bedoeld met je opmerkingen over het stroomverbruik. Ze gebruiken hun eigen ARMv8 implementatie dus dat zal wel iets anders verbruiken dan de 2.2W van een quad core ARM SoC die je aan haalt. Het grootste gedeelte van de stroom kosten zal inderdaad wel uit de cores komen verwacht ik, en ik vind 120 Watt voor een 64 core op 2GHz best netjes eigenlijk. Ik snap ook niet waarom 2 GHz te "hoog" geklokt zal zijn voor een "realistische" server applicatie? De meeste servers zullen boven de 2 GHz draaien, we hebben het hier niet over een Raspberry Pi thuisserver hobbybordje, maar een scale-up architectuur die mee wil proberen te komen met de grote jongens zoals Xeon, Itanium, SPARC en POWER in grote krachtige smp dozen.

[hardwareaddict]

Draai het eens om. Als je zelf niet in staat bent je eigen cores te ontwerpen, waarom zou je dan als klein bedrijfje ineens het wel voor elkaar krijgen de cache coherency goed te doen en wel voor 64 cores op maar liefst 2 Ghz?

Een manier dat een Chinees legeronderdeel in je wil investeren voor maar 512 gflops, waarvan we met veel voorstellingsvermogen dan maar aannemen dat het double precision is?

Ter vergelijking: de Nvidia Tesla's doen nu al 1.33+ Tflop en 1.0Tflop per chip is vrij normaal op dit moment. Zelfs de Xeon Phi haalt dat.

Die kost verder maar iiets van rond de 2500 dollar oplopend naar iets in de 3000 voor de Nvidia Tesla.

Die GPU's hebben natuurlijk geen cache coherency, dat is waarom ze dat gaan halen.

Als jij cache coherency wilt gaan implementeren op 64 cores en dan nog zielige ARM cores, dat komt vrij amateuristisch over hoor.

640 cores op 1Ghz met helemaal geen of beperkte cache coherency klinkt realistischer dan 64 cores op 2Ghz met cache coherency.

Die Gpu's draaien allemaal op 1Ghz ongeveer. Sommige Tesla's op 1.15Ghz het gros op rond de 1.0Ghz.

Het is maar dat je 't weet...

[marking]

Maar voor pure FP benchmarks kun je beter naar een gpu kijken. Met compute haal je makkelijk Tflops (amd nano 8 Tflops in artikel hiernaast).

Dreamvoid heeft wat dat betreft gelijk, zonder alle specs is het moeilijk om te weten waar je mee gaat vergelijken.

[hardwareaddict]

nah het lijkt meer een request for investment dit document. We gaan niks meer van deze chip horen.

Kijk gpu's zijn supersnel, maar er efficient FFT's voor priemgetallen op laten uitvoeren is niet zo simpel.

ARM cores zijn makkelijker te programmeren daar voor rekenlibraries. Lijkt erop dat ze dit ook willen doen met deze architectuur.

Je kunt het beter architectuur noemen dan chip - want het gaat ook over cache coherency.

Als ze dit ding echt gaan proberen te bouwen, dan wordt het een chip voor NSA-China natuurlijk.

In elk geval horen we er dan niks meer van.

Voor andere applicaties is dit NIET interessant, want het wordt een te dure chip wegens die cache coherency. Dat gaat ze niet snel lukken hoor. Vergeet dat maar.

Tegen de tijd dat 't lukt is 512 gflops double precision met een chip van 120 watt dus echt totaal lachwekkend.

Maar ingezet op een massale supercomputer van zeg een 400 megawatt - we praten over NSA China tenslotte waar stroom gratis is - dan is het een stoere architectuur.

Ik vermoed echter dat het ze niet gaat lukken.

Het is een te simpele tekening met daarop specs die razend ingewikkeld zijn om te bouwen. Voor zo iets pak je natuurlijk niet een zielige ARM maar pak dan een goede chip om dat mee te doen - maar die architectuur mogen ze niet verbouwen wegens patenten natuurlijk, dus pakken ze een ARM om een space shuttle mee te bouwen.

[latka]

Ook maar voor een deel van de wetenschap. De andere helft wil graag exacte resultaten en dat is FP performance weer helemaal niet belangrijk (of zeer minimaal en heel veel rekenwerk erbij om de foutmarge te bepalen).

[DirtyBird]

Wat heeft x86 hiermee te maken? Zowel arm als...normale (wat is de naam?) systemen zijn er toch beide in zowel x86 als x64? Ik begrijp niet waarom je voor arm zou kiezen als batterijduur geen issue is.[list]

Edit: reactie verplaatst

[Reactie gewijzigd door DirtyBird op 28 juli 2024 05:43]

[guzzo]

ARM (met meerdere versies), x86 en x64 (64bit uitbreiding op x86) zijn verschillende instructiesets. Een instructieset bepaalt welke instructies een CPU kan uitvoeren en hoe deze er in 1en en 0en uitzien.

Wat ik denk dat je bedoelt us dat er zowel 32bit als 64bit varianten van de ARM instructieset zijn. Dit is inderdaad waar (ARMversie8 meen ik). Maar dit zijn compleet andere instructiesets als de Intel x86 (32bit) en AMD x64 (64bit) (beiden gebruikt door zowel Intel als AMD).

Het aantal bits slaat o.a. op hoe groot een enkels instructie is/kan zijn. En bv hoe groot het geheugen is dat de CPU kan aanspreken. Met 64bits voor het adres kan je natuurlijk meer verschillende geheugen elementen aanspreken als met 32bits.

Tl;DR: er zijn van arm idd 32bit en 64bit varianten maar die zijn compleet anders dan x86 en x64, ondanks de hoeveelheid bits waar ze per clock mee werken.

De ARM instructieset is erop gericht eenvoudige instructies te gebruiken waardoor de CPU ook relatief simpel kan blijven en dus weinig energie per instructie gebruikt, maar soms wel meet instructies nodig heeft voor hetzelfde als x86 en x64.
Die laatste kunnen veel complexere instructies afhandelen (welke wel meer dan 1 cycle kunnen duren) en zijn zeker niet hetzelfde als ARM

[Rudie_V]

Volgens mij hebben voorgaande initiatieven van ARM server cpu's ook nooit de verwachtingen waar gemaakt, dus ik vraag me af waarom het deze fabrikant wel zou lukken.

[hardwareaddict]

volgens mijn kladblaadje kan zelfs een complete beginner nog met 120 watt budget wel 64 arm cores op een bordje krijgen - dus het gaat ze geen drol kosten dit te bouwen.

projecten als dit lukken als je niet te hoge winstmarge wilt hebben.

[Anoniem: 623473]

We zijn pas aan het allereerste begin van deze ontwikkeling dus het is echt veel te vroeg om hier nog iets zinnigs over te kunnen zeggen.
Feit is wel dat er best wat door belangrijke partijen in de ARM server chip is en wordt geïnvesteerd en dat zou wat kunnen zeggen.
Interessant is de 'squeeze' van boven (IBM OpenPower) en de onder (ARM) van de Xeon.
In feite heeft Intel deze markt geopend door de hoge prijzen die worden gevraagd.
In ieder geval vind ik deze ontwikkelingen erg positief

[DirtyBird]

Even een lekenvraag; waarom zou je een server op basis van ARM willen? ARM is dacht ik voordelig voor portabele technologie dankzij zijn zuinigheid, maar levert daarmee wel in op instructies/functionaliteiten. Het lijkt me niet dat je met je serverpark over straat wil wandelen dus het voordeel van ARM valt daarmee weg toch? Nogmaals, ik ben een leek op dit gebied dus misschien begrijp ik ARM verkeerd.

[Flipmo2K]

Je begrijpt het prima zou ik zeggen, meeste servers en (server)applicaties zijn x86. Dit zou theoretisch handig kunnen zijn voor embedded systemen die veel rekenkracht nodig hebben.

[DirtyBird]

Wat heeft x86 hiermee te maken? Zowel arm als...normale (wat is de naam?) systemen zijn er toch beide in zowel x86 als x64? Ik begrijp niet waarom je voor arm zou kiezen als batterijduur geen issue is.

[hardwareaddict]

Nee dat wil je niet Michiel4life, behalve als hij spotgoedkoop is.

120 watt tdp en maar 500 gflops SINGLE PRECISION, dat is de moeite niet waard joh.
Behalve als hij SPOTGOEDKOOP is.

Iets van 120 watt kun je geen serverchip noemen natuurlijk.

verder is 120 watt ook lachwekkend veel voor 64 arm cores.

quadcore ARM SOC is iets van 2.2 watt maximaal. 16 x 2.2 = 35.2 watt - dus welk soort gedrocht dit gaat worden weet ik niet - maar het klinkt niet erg goed als het 120 watt gaat vreten.

Zeker weer te hoog geklokt!

[GekkePrutser]

De cores zijn gebaseerd op een 'Xiaomi'-ontwerp, dat niets met de Chinese smartphonefabrikant van doen lijkt te hebben.

Ik zie alweer de headlines van morgen: "Het Chinese bedrijf Phytium Technology wordt aangeklaagd door Xiaomi"

Maar op zich een interessante ontwikkeling, zeker met het oog op het milieu. Door zo veel CPUs kan je heel mooi schalen naar load en toch zuinig zijn als het kan. Het verbaast me soms al hoe goed een raspberry pi als een servertje is, pak 64 van die dingen en je bent al een stuk verder.

[Reactie gewijzigd door GekkePrutser op 28 juli 2024 05:43]

[aadje93]

Een raspberry pi is handig voor enkele load die weinig vraagt zoals een hobby webserver, maar naar performance en kosten zijn ze totaal niet interesant. Ze vreten stroom voor hun geleverde performance, al is het verbruik voor hobby doeleinden uiteraard lekker laag. Heb er ook over gedacht een pi als varnisch cache in te zetten voor de webserver gewoon "omdat het kan"

[hardwareaddict]

120 watt noem ik niet milieubewust...

[Jvann]

Ik las wat snel de titel en las over het woord "server" heen, ik dacht dat ze het hadden over een 64 Cores ARM chip voor telefoons Lol ...

Het is alleen jammer dat het nog word gefabriceerd op, de nu toch wel wat gedateerde, 28nm structuur. Als ze wat lager gingen zitten zoals 20. 16 of 14 weet ik zeker dat de TDP er veel beter uitkwam (Logisch natuurlijk).

[hardwareaddict]

ja naarmate ik de sheets beter bestudeer lijkt het een highend chip te worden, enkel interessant voor NSA-Groot China als ze spotgoedkoop aangeboden worden aan NSA China.

Zitten ze met minder problemen daar qua security namelijk ==> zelf ontwikkelde chip versus een intel chip die ze liever in zo'n bunker niet hebben natuurlijk.

Maar die cache coherency komt lachwekkend over. Alsof een beginner dat opgepend heeft. Lijkt meer een request for investment dit pdf'je.

In any case - we gaan hier niks meer van horen.

[Squee]

Timothy Prickett Morgan van The Platform (het Enterprise tech broertje van The Register) heeft overigens ook een mooi artikel over deze chip geschreven, wat goed de Enterprise computing blik op een dergelijke processor weer geeft:
http://www.theplatform.ne...4-core-arm-big-iron-chip/

[Anoniem: 52621]

Wat ik zou willen, in mijn PC één dedicated core die alléén de besturing van de muis en keyboard doet, én één dedicated core die alléén videoafhandeling doet.
Met de tendens van steeds meer en meer cores moet dat toch makkelijk kunnen?
Want als ik érgens allergisch voor ben, is het wel dat de PC niet reageerd op invoerapparaten omdat de computer té druk ergens mee bezig is... en/of dat de output (te) traag opgebouwd word om die reden.
TWEE cores, of desnoods EEN voor al deze taken, en je krijgt tenminste weer het gevoel dat je meer controle hebt over je apparaat.

[Ryen]

Daarvoor zijn interrupts uitgevonden. Een complete core is overkill. Bovendien, wat moet die core doen? Het ingevoerde toetsje doorgeven aan het OS of de applicatie? En als die het nou net te druk heeft? Lost niets op dus.

[BikkelZ]

De Atari ST en Amigas waren daardoor zelfs nog responsief qua muiscursor als de software verder gecrasht was. Niet dat je er veel aan hand, maar de snelheid van dat soort dingen was inderdaad beter. En de MIDI timing ook.

[supersnathan94]

Nah niet dus. Dat heeft te maken met slechte threading in applicaties waardoor de GUI niet meer functioneerd door het laden van een bestand bijvoorbeeld (omdat dit in dezelfde thread gebeurt bv).

Waar ik meer problemen mee heb is dat de pc ongelooflijk traag is terwijl mn cpu op 10% draait ofzo. Dan weet je dus dat je schijf weer moeilijk loopt te doen of dat je te weinig geheugen hebt (wat in sommige gevallen niet uitbreidbaar meer is)

[hardwareaddict]

Bij deze chip zijn niet zozeer de specs het belangrijkst maar: "quantas costas?"

Als die chip duurder dan 100 dollar is dan is hij niet interessant natuurlijk.