Intel Ice Lake-chip met grotere L1- en L2-cache verschijnt in benchmarkdatabase

Een processor die als Ice Lake-model staat aangeduid is in de database van Geekbench verschenen. Het gaat om een zuinige dualcore, die over meer L1- en L2-cache beschikt dan huidige, vergelijkbare processors.

De Ice Lake U-processor staat bij Geekbench met vermelding van 32KB L1-instructiecache, wat normaal is voor een U-processor, maar 48KB L1-datacache per core, waar dat bij de huidige generatie 32KB is. Ook de L2-cache is hoger dan bij U-processors momenteel: 512KB in plaats van 256KB. De hoeveelheid L3-cache is nog steeds 4MB.

Verdere details over de processor zijn er nog niet. De single- en multicore-prestaties liggen op 4151 en 7945. Bij de Core i3-8130U, een recente Kaby Lake R-dualcore, zijn die prestaties respectievelijk 3693 en 7145. Die processor is wel weer opgevolgd door de iets snellere Core i3-8145U, een Whiskey Lake-processor waar nog geen Geekbenchscores van zijn.

Volgens Wikichip krijgt Ice Lake onder andere een igpu van de elfde generatie, waar Kaby Lake R en Whiskey Lake een igpu van generatie 9.5 hebben. Wat aantal execution units betreft zou het dan om een verdubbeling van 24 naar 48 gaan. Volgens planning maakt Intel Ice Lake op 10nm. Dat zou betekenen dat de processors op zijn vroegst eind 2019 verschijnen.

Reacties (31)

[Astennu]

Eindelijk weer een keer kans op ipc improvements (met die cache vergroting best aannemelijk). Maar wordt ook echt tijd en ze hebben het straks ook hard nodig vs Zen2

[Marctraider]

Als het zo simpel was... Iemand nog AMD Thunderbird vs Barton core? Dubbel zoveel L2, was totaal niks van te merken

Nee, magische performance winst door de cache te verhogen werkt in veel gevallen niet ;-)

[Reactie gewijzigd door Marctraider op 24 juli 2024 07:07]

[Astennu]

Thunderbird is een hele andere chip. Jij bedoeld thoroughbred.
En tussen thoroughbred en thunderbird Zat de eerste Athlon XP nog Palamino. (van thoroughbred had je een A en B versie. A was een 130nm versie van Palamino welke 180nm was. De B was een redesign nieuwe stepping die hogere clocks mogelijk maakte)

Barton was zeker wel een stuk sneller dan thoroughbred op gelijke clocks. De barton modellen met dezelfde + rating Bv 2500+ hadden lagere clocks dan de 2500+ thoroughbred's. In sommige compute taken waar L2 cache weinig deed kon een thoroughbred sneller zijn maar met games waren de bartons sneller.

[Reactie gewijzigd door Astennu op 24 juli 2024 07:07]

[exodude]

Thunderbird vs Barton was alleen een verdubbeling van de L2 cache. Deze Ice Lake chip heeft een 50% grotere L1D cache. Deze grotere cache KAN het mogelijk maken dat er minder vaak terug gegrepen hoeft te worden naar de L2 cache. De L2 cache wordt vergroot om de hit rate (branch prediction efficiency) hoog te houden.

Als deze core cache starved was en het zwakte punt van deze architectuur, dan kan het zeker leiden tot een hogere IPC. De vraag is alleen of dat ook het geval is. Het is ook maar net de vraag of de L2 cache in verhouding tot de L1D cache niet te groot is geworden. Dan ontstaan diminishing returns.

[Squee]

Even wat kanttekeningen hier;

Deze grotere cache KAN het mogelijk maken dat er minder vaak terug gegrepen hoeft te worden naar de L2 cache. De L2 cache wordt vergroot om de hit rate (branch prediction efficiency) hoog te houden.

De cache hit rate en branch prediction efficiency staan wel compleet los van elkaar; je branch prediction wordt niet beter van een grotere L2 cache. Wat wel zo is, is dat een hogere branch prediction accuracy een grotere L2 cache meer nuttig zou kunnen maken voor bepaalde workloads; omdat de core dan verder vooruit kan werken zonder veel te hoeven wachten op data uit het geheugen.

Als deze core cache starved was en het zwakte punt van deze architectuur, dan kan het zeker leiden tot een hogere IPC. De vraag is alleen of dat ook het geval is. Het is ook maar net de vraag of de L2 cache in verhouding tot de L1D cache niet te groot is geworden. Dan ontstaan diminishing returns.

Intel heeft zeer gedetailleerde performance modellen en simulaties van elke core die ze ontwerpen, en de architecten en performance teams zullen deze gebruiken om de optimale parameters te bepalen van het design. Het is belangrijk dat al deze dingen goed op elkaar afgesteld staan (bijvoorbeeld ook hoe aggressief de prefetchers werken, maar er zijn echt tientallen zoniet honderden belangrijke parameters in zo'n design), dus ja, als zij investeren in het implementeren van een grotere L1D cache, dan zal de core daar zeker meer uit kunnen halen. Er zullen altijd bepaalde workloads zijn die weinig lokaliteit hebben en bijna tot geen voordeel laten zien, en andere zullen het juist erg goed doen.

Je opmerking over diminishing returns vond ik een beetje vreemd; ja, er zijn diminishing returns bij grotere caches, zeker omdat ze veel power en area in beslag nemen, en performance niet lineair toeneemt met de grootte van een cache. Maar de verhouding L1D/L2 cache size is niet iets wat dat veroorzaakt. Het is vooral dat de L1D qua afmetingen beperkt is om de toegangstijd minimaal te houden. Idealiter zou je een gigantische L2 hebben en geen L3, wanneer je de L2 op een latency van 10-12 core cycles zou weten te houden. (Apple had geen L3 in meerdere designs en een heel grote L2, en Skylake-SP doet dat min of meer omdat de L3 kleiner geworden is en slechts een victim-cache is).

[SG]

Om cache hit or mis resultaat te behalen , moet er grotere hoeverlheid cache doorlopen worden.
Omdat L2 > L1 is bijft iets grotere L1 altijd heel stuk sneller dan L2 omdat die vele malen groter is.
Het is dus altijd wel trade off . Als kijkt naar transister budget aan grote L2 L3 en soms ook L4 caches.
Zie dat 48KB vs 32KB nogal subtiel is en dan is ook duidelijk dat groter te langzaam wordt want gezien de MegaBytes aan diverse cache soorten is 1MB L1 mogelijk maar ja door 1 MB zoeken of cache hit of mis hebt duurt ook veelvoud langer daarom blijven ze zo relatief klein.

Prefetcher en de data en code cache aligned en zo puur mogelijk data en instructie in cacheline zetten wat op dat moment ook alemaal nodig is. Is de optimalisatie waar men voor gaat. Data locality.

[robvanwijk]

De cache hit rate en branch prediction efficiency staan wel compleet los van elkaar; je branch prediction wordt niet beter van een grotere L2 cache.

Van de ene kant zie ik je punt, maar het klopt niet helemaal. Je hebt gelijk dat een mispredict altijd een mispredict blijft, daar verandert de grootte van de cache niets aan. Maar als de branch predictor goed gokt, dan moet het voorspelde instructie-adres (en de data die die instructies nodig hebben) natuurlijk wel in de cache zitten, anders schiet je er nog steeds weinig mee op. De kans daarop kun je verhogen door die cache groter te maken (als je erin slaagt die grotere cache net zo snel te houden), maar dat is van nog veel meer dingen afhankelijk. De belangrijkste andere factoren zijn waarschijnlijk de associativity van de cache en de manier waarop je een eviction victim kiest.

Wat wel zo is, is dat een hogere branch prediction accuracy een grotere L2 cache meer nuttig zou kunnen maken voor bepaalde workloads; omdat de core dan verder vooruit kan werken zonder veel te hoeven wachten op data uit het geheugen.

In dat geval gaat het niet alleen om de branch predictor en de grootte van de cache; als je niet wilt wachten op data uit het geheugen, dan heb je ook een goede prefetcher nodig.

Idealiter zou je een gigantische L2 hebben en geen L3 [..]

lol, idealiter zou je een gigantische L1 hebben en geen L2, L3, main memory en page file...

[Squee]

Als het zo simpel was... Iemand nog AMD Thunderbird vs Barton core? Dubbel zoveel L2, was totaal niks van te merken

Nee, magische performance winst door de cache te verhogen werkt in veel gevallen niet ;-)

Nou ja, cache afmeting zegt niet alles, dat is het vooral (net zoals GHz...). Als je een 2x zo grote cache maakt, maar hij heeft ook 2x de latency om de data er uit te kunnen lezen, dan zal je in veel gevallen op minder performance uitkomen. Cache afmeting, associativiteit, en latency zijn slechts enkele van de vele parameters die in een dergelijke situatie performance kunnen opleveren. Het aantal uitstaande requests dat een enkele core en de gehele SoC kan hebben telt ook mee, of op wat voor klok te cache loopt (zelfde als de core of een ander (lager) frequentie domein?). En dat is nog compleet de micro-architectuur/pipeline van de core buiten beschouwing gelaten, of wat voor workload je voornamelijk op je core draait!

Dus mits de core micro-architectuur (bijna) ongewijzigd blijft, zoals hier het geval lijkt te zijn, is het veel lastiger om er voorspellingen over te maken. Dus ja, je kan "veel" scenarios bedenken waar een grotere cache niet helpt, maar in dit geval verwacht ik zeker een performance winst. En dan wellicht meer van de grotere L1D dan de grotere L2.

[SG]

Intel caches hebben ooit al vroeg de sprong gemaakt naar 256bit cache bus.
Waar AMD lang op 128bit bus bleef hangen

[Countess]

niks?

https://hexus.net/tech/re...amd-barton-xp3000/?page=7

Toch echt wel iets duidelijk. Als je de matched resultaten bekijkt (tbird vs barton op gelijke clocks) dan was er toch echt wel verschil in de 3 game benchmarks.

er was misschien geen verschil in de synthetische benchmarks die toen ook nog popular ware om te runnen, maarja daar heb je nauwelijks cache misses natuurlijk dus heb je ook niks aan een grotere cache.

[Olaf van der Spek]

Eindelijk weer een keer kans op ipc improvements (met die cache vergroting best aannemelijk)

Ik zou er niet teveel van verwachten.

[Squee]

Eindelijk weer een keer kans op IPC improvements (met die cache vergroting best aannemelijk). Maar wordt ook echt tijd en ze hebben het straks ook hard nodig vs Zen2

Vooral die L1D cache vergroting is wel interessant, 48KB betekent namelijk dat het een 12-way cache zal zijn (vanwege Virtual indexing, physical tagging en de x86 4K virtual memory pagesize). Blijkbaar is Intel tot de conclusie gekomen dat ze dat op een power en area efficiente manier kunnen implementeren, of dat op zijn minst de performance voordelen daar tegen opwegen. Een cache waar zoveel op gehamerd wordt als de L1D cache met 12-ways zal namelijk best wel wat verstoken. Maar goed, het is wel Intel, dus het zou kunnen dat ze nog een slimme truc hebben weten toe te passen (way prediction, wellicht) waardoor ze dit op een efficientere manier kunnen doen.

Apple met zijn A12 chip heeft daar wel een enorm voordeel, omdat ze compleet hun eigen ecosysteem hebben qua software. De ARM architectuur specificatie heeft een modus waar de minimale pagesize 64K is, dus waarschijnlijk door daar gebruik van te maken kan Apple de L1D cache rustig 128K groot maken, zonder meer dan 4 ways te hoeven gebruiken (2 zelfs, maar een hogere associativiteit is wel beter). Omdat er alleen maar iOS (en wellicht MacOS) op hoeft te draaien wat ook van Apple is, zijn ze niet meer afhankelijk van de kleinere 4K pagesize support.

Overigens ging Skylake-SP ook al naar een andere Cache hierarchie tov van Haswell/Broadwell; met een veel grotere L2 cache (1M). Dat resulteerde ook in een IPC verbetering, maar Ice Lake brengt het op een andere wijze nu ook naar de desktop/laptop klasse.

[jabwd]

Moeten een instructie set toevoegen voor DOM manipulatie/javascript, nu dat we toch al over de grens heen zijn en de meeste al niet eens meer weten dat een website minder dan 100KB gewoon gemakkelijk kan.

npm install bloat

[Cilph]

npm install yarn
yarn add bloat

[MrMonkE]

Not enough free space to install bloat!

[dasiro]

dat zijn best wel ingrijpende veranderingen qua chipdesign om nog onder dezelfde codenaam te plaatsen, terwijl er voor zover ik snel kan zien nog geen 10nm opvolger voor is (of toch zeker niet met deze timing)

[Balance]

Geekbench scores Core i3-8145U liggen single-core rond de 4380 en multi-core rond de 8890. Wat niet heel gek is gezien de boostklok 500 MHz hoger is. Maar met deze processoren hangt het heel zwaar van koeling en beschikbaar vermogen af, wat de kloksnelheid bepaald.

Hopelijk hebben ze de GPU eens flink op de schop gegooid, deze is sinds Broadwell (2013) qua architectuur als hetzelfde. Wordt hoog tijd voor een stukje efficiëntiewinst en zaken als HDMI 2.1 (of überhaupt HDMI 2.0) en DisplayPort 1.4.

[Reactie gewijzigd door Balance op 24 juli 2024 07:07]

[jkommeren]

eindelijk wat igpu improvements!!! sinds 3 jaar?

windows is al niet te doen met een uhd 620 en 4k scherm. leuk hoor die nvidia gpu, maar je start menu draait op de uhd620! traag als stront..

heb zelf ook een surface book, zelfde probleem

[gameguy12]

volgensmij kan intel hd er wel mee overweg hoor, misschien een keer kijken voor driver updates? Anders kun je in nvidia control panel aanzetten dat alles via dee nvidia gpu gaat.

[jkommeren]

drivers geüpdate hoor. misschien let ik er teveel op, maar het is een bekende tekortkoming.

de iris was veel beter zegt men.

task manager met gpu usage zeg genoeg btw. dikke spike als je op start drukt

windows desktop manager kan niet op de nvidia draaien helaas. de rest wel inderdaad.

[Reactie gewijzigd door jkommeren op 24 juli 2024 07:07]

[Loggedinasroot]

Dit is inderdaad strontvervelend. Heb zelf een i7-6820HQ met een HD530. Op Linux is een extern 4k scherm ook niet soepel. Helemaal niet als je het laptop scherm ook aan laat staan.

Ik ga waarschijnlijk naar een AMD overstappen.

[latka]

Iris op een 8259u nuc gaat uitstekend met 3x2560x1440. Iris is gewoon HD graphics met dedicated vmem. Dat is altijd al een belangrijk verschil in snelheid tussen losse gpu en igpu geweest.

[Iblies]

620 of 530 is hetzelfde laken een pak.
Die zitten beide rond de 400 gflops.

4K Decoderen is voor diegene met een 620 een ramp. Ze hebben daar heel sneaky een keer een versie toegevoegd met HDCP 2.2 wat oa wordt gebruikt door Netflix. Je moet dus echt de refresh hebben.

Diegene met de Iris komen er nog wel redelijk vanaf, die zit al heel lang rond de 800 gflops wat een voordeel oplevert mbt de codering. Dat wordt daarmee deels gecompenseerd.

[necessaryevil]

Ben ik de enige die het bijzonder vind dat een startmenu traag gaat op een moderne computer? Ja, het ziet er ietsje anders uit dan windows 95, maar het is toch maar een paar 2D plaatjes en een beetje tekst? Wat zie ik over het hoofd?

_{Dit is geen klacht tegen microsoft ben gewoon tevreden over Windows.}

[Euronitwit]

Hoe zit het dan met:
Intel heeft grote moeite om in grote hoeveelheden en rendabel 10nm-chips te produceren.

bron artikel op Tweakers

[Fiander]

laatste regel:

Dat zou betekenen dat de processors op zijn vroegst eind 2019 verschijnen.

Word dus waarschijnlijk pas 2020 waarmee de problemen die Intel met 10nm heeft niet ontkracht worden.

[Euronitwit]

Maar dan breng je het toch nog niet uit als je niet genoeg kan maken?

[Fiander]

Hebben ze de chip dan al uitgebracht?
in het artikel hierboven staat niks meer dan dat in een benchmark programma deze processor in de database verschenen is.

Dat kan twee dingen betekenen.
1 Intel heeft deze processor getest, en per ongeluk deze data geupload.
2 ze hebben het bewust gedaan om de aandacht van iets anders af te leiden.

Dat is dus kiezen tussen : het zijn idioten/prutsers, of het zijn achterbakse ******.
ik neig op basis van wat ik zie erg naar de tweede.
wat mij meteen erg nieuwsgierig maakt naar waar de afleiding voor nodig zou zijn geweest?

Het is nu wachten op de eerste nieuwe "benchmarks" waarbij de dataset is afgestemd op 48K data, om zo aan te tonen dat de concurrentie toch echt langzamer is....

[robj28]

Denk dat dit gedaan is om pefromance impact van de meltdown en specter hardware fixes op te vangen.

[Fiander]

of om nieuwe benchmarks te kunnen maken met een dataset van 48K, en dan te claimen dat ze sneller zijn dan de concurrentie?

[ataryan]

Monolitische core is monolitisch. Cache erbij is suboptimaliseren. Intel most z'n chips ophakken en bijmekaar plakken. Betere yields, meer cores, betere prijs\prestatie. Dusss. Intel, kom maar op. No more cache.