Intel introduceert Xeon E7 v4-lijn van processors

Intel heeft zijn aanbod van Xeon-processors uitgebreid met de Xeon E7 v4-lijn. Het bedrijf richt zich met het Broadwell-EX-platform met name realtime analytics-toepassingen. De processors ondersteunen meer geheugen dan hun voorgangers en beschikken over meer cache.

De v4-lijn is gebaseerd op de Broadwell-architectuur en wordt op 14nm geproduceerd. Intel heeft de nieuwe E7 v4-familie opgedeeld in een 8800- en een 4800-lijn. De nieuwe generatie ondersteunt onder andere maximaal 3TB geheugen per socket en tot aan 60MB last-level cache. Ten opzichte van de v3-lijn worden er nu tot 24 cores per socket in plaats van 18 cores ondersteund. De chips zijn socket-compatibel met de E7 v3-lijn van het Brickland-platform.

Ten opzichte van een Xeon E7-8890 v3 zou de Xeon E7-8890 v4 33 procent meer benchmarkgebruikers voor SAP's sales & distribution ERP-werklasten ondersteunen en ook zou de processor voor een toename van 30 procent bij online transactieverwerking zorgen, volgens benchmarks van Intel zelf.

De processors kunnen geplaatst worden in systemen met vier en acht sockets en volgens Intel is er in combinatie met nodecontrollers van derde partijen ondersteuning voor 64 sockets. Bij een systeem met acht sockets is er tot aan 24TB werkgeheugen mogelijk en die hoeveelheden lenen zich volgens het chipbedrijf bij uitstek voor realtime data-analyse, aangezien omvangrijke datasets zich volledig in het ram kunnen bevinden in plaats van op tragere opslagmedia.

Reacties (37)

[hooibergje]

Meer CPU cache lijkt me eigenlijk voor alle toepassingen nuttig. Meer cache leidt tot minder interactie naar het geheugen, wat leidt tot betere overall performance. Ik ben voor!

[ThomasG]

Meer CPU cache leidt niet per definitie naar betere performance. In het ergste geval leid meer cache alleen maar naar meer cache misses. Er komt veel meer bij kijken dan enkel de hoeveelheid cache. Het hangt er onder andere vanaf hoe het programma geprogrammeerd is, en hoe goed de processor is in pre-fetching. Wanneer een programma lineair door het geheugen wandelt, kan een processor dit goed detecteren en het volgende stuk geheugen alvast laden voordat het überhaupt opgevraagd wordt. Voor de programmeurs, bijvoorbeeld wanneer je door lineair door een array gaat. Wanneer het programma kriskras door het geheugen gaat (en er zijn toepassingen waarbij dat gebeurd), is het heel moeilijk voor de CPU om te pre-fetchen. En dan heb je vrij weinig aan meer cache in de CPU. De reden dat deze Xeon CPU's zoveel cache hebben, is omdat ze zoveel cores hebben. Niet omdat (enkel) meer cache tot betere performance leidt.

Daarnaast gebruikt de processor SRAM voor L1, L2 en L3 cache wat super snel is, maar relatief heel erg duur is en veel ruimte in neemt per byte. Zo zit L1 cache midden in de CPU en draait op de volledige kloksnelheid van de processor. L3 cache zit verder weg, en is meestal ruim twee keer zo snel als het RAM geheugen. L2 cache zit er tussen in. Meer cache betekend voor de meeste toepassingen niet tot betere performance, maar maakt de processor wel aanzienlijk duurder. Dat is zonde van het geld en materialen, als het vervolgens vrijwel geen prestatiewinst oplevert.

[Squee]

Het gat in toegangstijd tussen L3 en DRAM is nog wel ietsje groter dan een factor twee. L3 cache zal tegenwoordig iets van 35 a 45 core cycles kosten, terwijl DRAM eerder 50 a 60ns kost, plus de L3 toegang, wat bij een 4 GHz processor neer komt op een totaal van bijvoorbeeld 40 + 55ns * 4 Ghz = 260 cycles, wat dus 6.5x zo langzaam is als L3 toegang. En dit is voor desktop processoren, bij server processors met veel meer DRAM (en eventueel ECC) zal de toegangstijd nog hoger liggen, en de verhouding dus nog schever zijn. Aan de andere kant, de L3 cycle access time zal ook toenemen als de cache groter is in het algemeen, maar waarschijnlijk niet meer dan mijn hierboven geschetste schaal.

Ik ben overigens benieuwd waar je op doelt met "In het ergste geval leid meer cache alleen maar naar meer cache misses." Natuurlijk zijn er wel situaties te bedenken als je een grotere cache maakt met slechtere associativity (of zelfs naar direct mapped gaat), of een slechtere replacement policy, maar dat lijkt me een absurde aanname. Zolang je de toegangs tijd tot je L3 binnen de perken kan houden zal meer L3 cache altijd zijn voordeel hebben. Zeker voor workloads met een hele grote memory footprint, zoals databases.

Een leuke en interessante breakdown over geheugen toegangstijd is hier te vinden bij de Universiteit van Texas.

7-zip CPU benchmark had wat resultaten voor memory latency, geen idee hoe correct ze zijn, maar ze klinken wel aannemelijk;
Intel i7-4770 (Haswell), 3.4 GHz (Turbo Boost off), 22 nm. RAM: 32 GB (PC3-12800 cl11 cr2):
L3 cache = 8 MB, 64 B/line
L2 Cache Latency = 12 cycles
L3 Cache Latency = 36 cycles
RAM Latency = 36 cycles + 57 ns

Intel i7-6700 (Skylake), 4.0 GHz (Turbo Boost), 14 nm. RAM: 16 GB, dual DDR4-2400 CL15 (PC-19200):
L3 cache = 8 MB, 64 B/line, 16-WAY
L2 Cache Latency = 12 cycles
L3 Cache Latency = 42 cycles (core 0)
RAM Latency = 42 cycles + 51 ns

[Dreamvoid]

Natuurlijk hangt het totaal van de toepassing af, maar deze Broadwell-EX chips (net als de SPARC en POWER concurrenten) worden in de praktijk vooral gebruikt in (en ontworpen voor) grote database servers, en die schalen typisch erg goed met meer cache.

Voor HPC toepassingen is cache inderdaad minder belangrijk, daarom heb je daarvoor chips als de Xeon-Phi met nauwelijks cache en vooral veel throughput/paralellisatie.

Uiteindelijk heb je een beperkt transistorbudget (vanwege de fabbing/yield beperkingen) en maak je als chipbakker een afweging waar je de balans legt - veel cache of veel computing cores.

[Reactie gewijzigd door Dreamvoid op 24 juli 2024 22:56]

[Squee]

De 2e generatie Xeon-Phi (Knight's Landing) heeft anders wel tot 16GB on-package high speed 3D stacked MCDRAM memory wat als L4 cache gebruikt kan worden (of speciaal los geadresseerd voor snelle scratchpad space). Dit geheugen behaalt 400GB/s, een throughput die je ook wel nodig zal hebben om al die 72 (x4 threads) cores op een Knights Landing te voeden!

Wat leuke details daar over bij AnandTech
... en nog meer details van de HotChips 2015 presentatie bij The Platform

[edit]: Even ter verduidelijkijg... Eigenlijk zou je het ook wel een "L3 Cache" kunnen noemen aangezien hij alleen maar L1 en L2 heeft op de die, dus het de volgende in de hierarchie zou zijn, maar qua plaatsing zou het bij mij onder de noemer L4 cache vallen.

[Reactie gewijzigd door Squee op 24 juli 2024 22:56]

[winfriedD]

Deze reactie lijkt een beetje op het gezegde van de klok en de klepel.

Het verhaaltje over pre-fetching is niet zo relevant hier omdat als je 2 Xeons neemt met dezelfde micro-architectuur degene met meer cache beter zal presteren, aangenomen dat de cache latency niet al te veel toeneemt. Dat laatste is wel een probleem wat jij niet noemt, vaak neemt de cache latency toe als je de cache groter maakt.

L1 cache draait niet op de volledige kloksnelheid. Alleen registers zijn in 1 cycle benaderbaar. L1 cache latency is ca. 5 cycles.

Zoals Squee al opmerkte is het latency verschil tussen L3 cache en DRAM wel groter dan een factor 2.

[DohnJoe]

Meer CPU cache leidt niet per definitie naar betere performance. In het ergste geval leid meer cache alleen maar naar meer cache misses.

Ik weet wel iets van caches maar begrijp dit niet, kan je uitleggen hoe meer cache tot meer misses kan leiden?

[sspiff]

Het enige dat ik kan bedenken is koude cache misses, maar die krijg je evengoed bij kleinere caches, alleen ga je bij een grotere cache geen bestaande lijn weggooien.

[Vini-Vidi-Vici]

Jezus. 3TB aan werkgeheugen voor 1 CPU? Hoe moet ik dit zien? Want ik neem aan dat je geen RAM modules hebt van een terabyte? Of werkt dit systeem weer geheel anders?

[hylke94]

Linus Sebastian heeft gister toevallig een video geüpload over nieuwe servers. Hier kan 6TB voor vier processors in gezet worden...
https://youtu.be/n2W9ZdqHVws

[Xudonax]

DDR4 heeft al modules van 128GB uit mijn hoofd, dus dan heb je er nog "slechts" 24 nodig per CPU om aan de 3TB te komen. Ook grotere DIMMs zitten er ongetwijfeld aan te komen, zeker voor dit soort toepassingen. Voorlopig zul je dit echter niet voor normale prijzen terug gaan zien "helaas"

[Squee]

Zoals op het plaatje te zien is bij dit artikel heeft deze processor 4 geheugen kanalen met elk 3 DIMMS (type RDIMM, LRDIMM of 3DS LRDIMM). Dit komt dus neer op een totaal van 12, dus om de 3TB te halen zal je eerst nog moeten wachten tot 256GB geheugen modules op de markt komen. Meer geheugenslots ondersteunt de memory controller in deze chip dus op dit moment niet.

[Reactie gewijzigd door Squee op 24 juli 2024 22:56]

[StefanTs]

Elke CPU heeft echter z'n eigen controller. Het is dus 12 sloten per socket, niet voor het hele systeem.

[Verwijderd]

Er wordt dan ook 3 TB per socket ondersteund.

[Wannial]

Dit zijn momenteel 64 of 128gb modules, maar in de nabije toekomst breidt dit ongetwijfeld uit naar 256gb en groter. Servers hebben vaak ook 8 of meer geheugenslot per cpu

[Reactie gewijzigd door Wannial op 24 juli 2024 22:56]

[nelizmastr]

Simpel op te lossen door RAM risers te gebruiken zoals Tyan heeft laten zien op Computex. Compact en veel ruimte voor RAM. Als je 8 risers van 4 DIMM's hebt gaat het wel lukken

[Bigs]

Servers in die klasse hebben ook wel veel DIMM sloten https://youtu.be/hNoD5eK9sdA?t=16s

[groene henk]

Grotere dimms komen eraan. Ik denk dat iedereen binnenkort Diablo memory gaat ondersteunen: http://www.diablo-technologies.com/memory-channel-storage/
En dat geheugen komt wel vol. Veel bedrijven zetten Aix apps over naar Linux of met virtualizatien.

[Verwijderd]

Even googlen op hyperscale architecture.

[Dreamvoid]

Het gat tussen de doorsnee consumenten PC chip en de high-end server monsters wordt steeds groter - daar gaat de performance honger rustig door (de 32-core SPARC M7 is er al, deze 24-core Broadwell-EX nu, en de 24-core POWER9 komt later dit jaar), terwijl bij consumenten eigenlijk nauwelijks meer cpu power nodig is en de vraag allang verschoven is naar de prijs en laag stroomverbruik.

[HStyles]

Er is nog genoeg te verbeteren voor consumenten computers.. Ook cpu power. Als software makers heen "consumenten" prul niet beter optimaliseren voor multicore zal een upgrade naar een cpu met meerdere cores geen zin hebben.

[Verwijderd]

Bij wat voor applicaties loop je tegen een CPU bottleneck aan? Ik merk persoonlijk dat de disk of ram vaker de bottleneck zijn (heb geen SSD).

[itcouldbeanyone]

24tb ram. Ik herinder me nog goed dat 24mb high end was

[Squee]

Och, we verkopen al een paar jaar eentje met 32 TB ram...

En ik moet zeggen het is ook wel fijn hoor zo enorm veel geheugen in een grote machine. Ik heb een versie van bovenstaand systeem een tijdje kunnen gebruiken met 10TB er in en dat heb je ook wel nodig als je zoveel CPUs/cores/threads hebt. Je kan dan gewoon zo enorm veel (grote) applicaties tegelijkertijd draaien, dat je al die TB's ook wel makkelijk vol krijgt!

[kh65]

En dan slag je voor het gemak 24GB over...
Heb ik thuis wel in een servertje overigens, maar niet in mijn desktop.

[itcouldbeanyone]

Omdat 24gb in de gemiddelde thuis pc nog geen standaard is. Meeste wat er nu te koop is is 8gb.
Alhoewel ik zelf op 64gb zit

[mdj84nl]

640Kb was genoeg voor iedereen toch

[itcouldbeanyone]

Dat was het ook toen der tijd

[Crotchy]

Genoeg voor de Apollo missies

[BWzes03]

Momenteel draait mijn servertje thuis op een Atom C2750, een 8-Core Atom. Zou deze bump in cores ook een Atom trickle down effect krijgen? Dat er binnenkort een 12-core Atom server chip komt ?

[Dreamvoid]

Je kan nu al honderd atom cores op een chip zetten, maar de vraag zal zijn of dat zinnig is. Trek je die acht cores allemaal wel vol? En zo ja, wat is dan zinniger, zestien kleine Atom cores of vier grote Skylake-cores, bv?

[latka]

Die heet xeon-d http://ark.intel.com/m/pr...z#@product/specifications

[Icelus]

Amazon heeft recent een virtual met 2 TB RAM geïntroduceerd, maar 3 TB / core is wel een andere orde...

[Verwijderd]

Per socket, niet per core.

[daan9999]

nu eventjes sparen sigh.......

[MajorMuff]

24TB werkgeheugen

[Iavak]

Ik wacht nog even met mijn upgrade dan.