Benchmark toont mogelijke Intel Core i5-processor met hyperthreading

De Intel Core i5-processors in de aankomende Comet Lake-serie krijgen mogelijk zes cores met ondersteuning voor hyperthreading. Dit is op te maken uit een gelekte benchmark, waarin een nog naamloze cpu met zes cores en twaalf threads verscheen.

De benchmark verscheen in de database van SiSoft Sandra en toont een hexacore-cpu van Intel met twaalf threads. De huidige i7-processors van Intel bevatten acht cores, al is dat wel zonder hyperthreading. De verwachting is dat de cpu van de SiSoft-pagina een Core i5-chip is, aangezien de huidige i5-9600k ook zes cores heeft, maar dan wel zonder hyperthreading. De genoemde cpu draait op een kloksnelheid van 2GHz, wat doet vermoeden dat het hier om een vroege engineering sample gaat. Dergelijke testversies van cpu's hebben vaak lage kloksnelheden in vergelijking met de processors die uiteindelijk in de winkel verschijnen.

De nog onbekende cpu heeft per core 256KB aan L2--cache en beschikt over een totaal van 12MB aan L3-cache. De huidige Core i5-9600k heeft evenveel L2-cache, maar beschikt over 9MB aan L3-cache. De cpu is getest in een moederbord van ECS, dat een H470-chipset lijkt te bevatten. Deze chipset bestaat nog niet, maar moederborden met H370-chipsets liggen al wel in de winkel. Het lijkt bij de chip te gaan om een Comet Lake-cpu. Deze serie zal in 2020 de huidige Coffee Lake-processors vervangen, waarbij nieuwe chipsets verwacht worden.

Eerder deze maand verschenen er al benchmarks van een Intel Core i3-processor met vier cores en acht threads op SiSoft Sandra. Deze informatie ligt in lijn met die van de nu verschenen vermeende Core i5. Als deze trend zich doorzet, krijgen de Core i7-cpu's in de Comet Lake-serie mogelijk acht cores en zestien threads. Dit is weer in lijn met de huidige geruchten rondom Comet Lake. Ook gaat Intel volgend jaar volgens meerdere geruchten een i9-processor voor consumenten uitbrengen met 10 cores en 20 threads. De processors moeten op een verbeterd 14nm-procedé gemaakt worden.

Reacties (75)

[Byron010]

Mits de applicaties etc er allemaal goed gebruik van gaan maken, kan ik dit alleen maar aanmoedigen. Meer cores & meer threads is altijd fijn

[JonathanG]

Hangt af van de toepassing natuurlijk. Games willen een snellere enkele core, terwijl rendering juist meer cores wilt. Maar ik denk dat Intel beetje bang geworden is van de AMD cpu's en nu ook fatsoenlijke configuraties gaat uitbrengen. Misschien dat de price/performance nu ook iets beter word, want met de Ryzen 3000 serie liep Intel zwaar achter in die categorie.

[rjberg]

Games willen een snellere enkele core, terwijl rendering juist meer cores wilt.

Games moeten ook renderen. Maar dat terzij houdt het heel veel verband met hoe de game en de engine zijn geschreven.

De JMonkeyEngine (Een open-source Java game engine waar ik mee heb gespeeld) heeft een enkele update loop die dus single threaded is. Moet een taak om performance redenen worden gedelegeerd dan moest dat met de hand gebeuren. Physics draaien op dezelfde thread. De reden daarvoor is synchronisatie, als je dingen op meerdere cores/threads doet, moeten ze afgestemd worden op elkaar, wat erg moeilijk is. De enige manier zover ik weet om goed werk te splitsen is ervoor zorgen dat het zo min mogelijk overlapt (anders zit het ook op elkaar te wachten.)

Voorbeeldscenario van hoe gebrek aan synchronisatie fouten kan veroorzaken: In een space shooter wordt een laserkanon gericht op een doel, en dat doel werd tegelijkertijd geraakt door een raket van een ander. Dit laatste gebeurd ongeveer halverwege het renderen, dus het halve kanon is al getekend. De andere helft draait mee met de verplaatsing, en daardoor ontstaat een knik in het afgebeelde kanon. Dit is uiteraard een kleine glitch, maar in andere situaties (zoals met AI) kan dit erger uitpakken.

Te veel synchronisatie is ook niet goed, als threads op elkaar wachten verspillen ze hun tijd, waardoor je eigenlijk sons voor een groot deel singlethreaded beter af bent. Als twee ruimteschepen in een space shooter door aparte threads worden bestuurd qua physics, maar zodra ze in de buurt komen voor elk klein stapje in hun beweging op de ander moeten wachten heb je dus eigenlijk een single thread, in de zin dat maar een core nuttig werk aan het verrichten is.

Ik denk dat je hieruit kunt concluderen dat schaalbaarheid van de performance van een game haalbaar is, maar moeilijk. Werk dat voor veel indiespellen eigenlijk al te veel is, maar dan is het ook vaak niet nodig. Pas als je echt alles eruit wil persen moet je echt aan dit soort dingen werken.

Ik ben uiteraard geen expert. Mijn game programmeer ervaring is lang geleden en puur uit nieuwsgierigheid van hoe het werkte. Maar het blijft handig om dit soort dingen te illustreren.

Edit: Wel is het zo dat andere taken binnen het besturingssysteem (antivirus, updates, streaming, browser...) wel profiteren van extra cores, omdat ze niet met de game in aanraking komen. En door die apart te doen ontlast je de andere cores.

[Reactie gewijzigd door rjberg op 22 juli 2024 22:15]

[NoobishPro]

Oude kennis of niet, klinkt dit vrij logisch.

Wel wordt er tegenwoordig al op software- en firmwarebasis performance verdeeld over cores. Ook deze technologie wordt alsmaar beter. Dit voor betere temps en ontlasting van andere cores zodat de CPU beter kan blijven performen, plus voor meer rekenkracht op de "single thread". Maar dat is uiteindelijk inderdaad wel een single thread welke wordt opgesplitst en na de calculaties weer wordt samengeperst, dus zelfs in deze situatie heb jij geloof ik nog steeds gelijk. Tenslotte blijft die communicatie "wachttijd" aanwezig.

Wel kan ik mij inbeelden dat multi-cores heel goed gebruikt kunnen worden voor grote (open world) games (waarvan je er nogal veel hebt tegenwoordig) zodat je bijvoorbeeld met andere cores delen van de wereld kunt gaan renderen, terwijl de "sterkste" thread zich concentreert op waar je nu mee bezig bent?

Ik maak deze stellingen vragend, omdat ik zelf eigenlijk enkel algemeen verstand heb van hoe computers werken en zelden tot nooit te maken heb gehad met threading of game making. Wel algemeen programmeren maar helaas niet zó specifiek. Ik zoek dus nog bevestiging

[rjberg]

Wat je nu beschrijft als "software- en firmwarebasis" klopt inderdaad, veel software kan tegenwoordig op andere manieren geschreven worden om beter te schalen. Op CPU niveau hebben we al out-of-order execution, hoewel ik niet weet of zoiets over multi-threading ook gebeurd. Ook op software en engine niveau is veel bereikt, databases kunnen bijvoorbeeld meerdere queries door elkaar doen, op een manier waardoor het resultaat effectief sequentieel is, in de zin dat het alleen sneller is zonder dirty writes of iets dergelijks. Ik kan me op zich voorstellen dat game engines het toestaan om taken in kleine stukken te splitsen om vervolgens zelf die taken uit te zoeken die tegelijkertijd kunnen.

Wat multi-core gaming betreft: open wereld games zijn per definitie heel groot, en misschien wel de belangrijkste taak van een game engine is kijken welke delen van de wereld gebruikt wordt en welke niet. Sterker nog, toen ik begon met graphics (nog voordat ik goed wist wat een game engine was) beschreef wikibooks dit als waarom je een game engine nodig hebt, omdat je vanwege performance redenen niet alles naar je gpu via OpenGL kan sturen. (Of je spel is wel heel klein.) Later kwam daar ook dingen als physics en AI in een update loop bij om dus te helpen met game logica, alsmede bijhouden van data tussen de onderdelen.

Kan een open wereld game dingen doen met de niet-op-het-moment-gebruikte wereld? Soms wel, maar dat gebeurt dan meestal in een versimpelde vorm. In Skyrim respawnen de bandieten per kamp na een paar dagen, maar die komen dan alleen terwijl je weg bent, en het is niet zo dat bandieten uit een stad naar een verlaten kamp reizen om bandiet te worden. Draken vallen alleen aan als je aanwezig bent, ze gaan niet NPC's vermoorden terwijl je weg bent. Meestal vereist dit niet eens een achtergrond thread, een game houdt vaak met een klok bij wanneer je ergens als laatst geweest was, om vervolgens de tussentijd in versimpelde vorm heel snel te simuleren.

Maar zoals @P_Tingen zei, het hangt ook heel erg af van wat je maakt. Als je bijvoorbeeld in een game als developer de wereld kan splitsen in kleine onderdelen die niet continu overlappen is zoiets heel makkelijk. Denk hierbij aan een spel waarbij je een huis met kamers hebt, die niet of nauwelijks interactie hebben. Alleen het verplaatsen van een speler van kamer naar kamer kost extra. Maak je bijvoorbeeld een open wereld MMO waarbij je ook grote aantallen kanonnen met onbeperkte afstand kan afschieten dan zal op een grote server dat lastiger worden, helemaal als je ook wil dat de kanonskogels in de lucht kunnen botsen. Kan misschien wel, maar dan kun je beter een manier vinden om dit niet stapje-voor-stapje in klassieke physics vorm te doen, maar de banen van projectielen van te voren uitrekenen met paraboolformules, misschien zelfs inclusief botsingen. Op die manier ontlast je de physics op de main loop, en het is sowieso sneller. Kost wel meer werk voor een developer, omdat je niet meer op de standaard universele wijze werkt. Het is dus een balans tussen developtijd, game mechanics en realisme, en game performance en hardwarebenodigdheden.

EDIT: Overigens slaat "renderen" op het omzetten van een 3d scene of model in een 2d plaatje. Bij een open wereld game wordt maar een klein deel echt gerenderd omdat veel of te ver is, of niet te zien omdat het zich bijvoorbeeld achter je bevind.

[Reactie gewijzigd door rjberg op 22 juli 2024 22:15]

[P_Tingen]

Het hangt heel erg van de use-case af waar je voor programmeert. Bij een vorige klant heb ik samen met een collega een systeem gemaakt om een optimale werk-order samen te stellen voor een tabaksfabriek. Dit was erg complex omdat er erg veel factoren bij elkaar komen; verschillende kwaliteiten tabak, teer, nicotine, suikereisen, voorraad, afstand tot aan fabriek, leeftijd van de voorraad. Dit leverde bij een niet al te ingewikkeld tabaksrecept al miljarden combinaties op, wat veel te veel was om allemaal door te rekekenen. Bij een ingewikkelder recept (bv een met 28 verschillende soorten tabak waarbij van elke kwaliteit 15 balen op voorraad zijn) heb je dus al 28^15 combinaties. En dan zijn er nog extra mogelijkheden waarbij de ene kwaliteit vervangen kan worden door een combinatie van x anderen.

We hebben daarom een programma gemaakt dat op basis van het aantal beschikbare cores een aantal threads uitzet van processen die domweg combinaties maken van de mogelijke orders. We begonnen dan met de belangrijkste factoren voor de samenstelling, omdat je zelfs met 56 threads (tot zover konden we testen) niet alle combinaties kan berekenen. Door deze aanpak konden we zo'n dikke 50 miljoen combinaties per seconde doorrekenen. De ervaring leerde dat we na een paar seconden op die manier wel een lokaal optimum te pakken hadden. De berekening is zo versneld van 50.000 combinaties in een half uur in het oude programma tot 250 miljoen combinaties in 5 seconden in het nieuwe programma.

Het is erg mooi trouwens om zoiets te testen op een server en dan bij de cpu-performance alle 28 cores op nagenoeg 100% zien te staan stampen

[Zeerob]

Leuk, maar een versnelling van 50.000 combinaties in een half uur naar 250 miljoen in 5 seconden kan natuurlijk nooit met multi-threading bereikt worden.
Met multi-threading kan je hooguit een versnelling realiseren die gelijk is aan het aantal cores dat je hebt. Dus bij een 8-core processor, maximaal 8 keer sneller. En in de praktijk minder.

[P_Tingen]

Nee, dat klopt, maar we zagen wel dat de prestaties zo ongeveer 1:1 schaalden met het aantal cores. De multi threading lukte niet in de 4GL taal waar het origineel in geschreven was en we zijn dan ook naar C# overgestapt voor dit onderdeel.

[Zeerob]

Ja, wel leuk. Ik zag dat je 28 cores had, en dan is de versnelling natuurlijk wel de moeite.
Ik heb ook multi threading bij een aantal projecten toegepast (C++). Voegt wel aardig wat complexiteit toe. Synchronisatie, en zo. En bij dergelijke projecten wil je elk onderdeel natuurlijk ook optimaal snel laten werken. Ander belangrijk punt vond ik dat fouten veel lastiger te vinden zijn omdat een fout b.v. alleen optreedt als twee dingen toevallig precies tegelijk gebeuren. Het kan dus zijn dat een fout pas na heel veel uren draaien optreedt. Bij een single-thread applicatie zijn de meeste fouten (niet alle) heel goed reproduceerbaar.

[P_Tingen]

We gaan wel wat ver off topic, maar goed, nerds onder elkaar

Ik was gezegend met een collega die er écht verstand van had. We konden het probleem goed opsplitsen in deelprocessen (de "combinators"). Die subprocessen werden verdeeld over de cores. De enige taak van die processen was het vinden van een combinatie van ingrediënten die aan de gestelde voorwaarden voldoet (dus bv niet teveel of te weinig van bepaalde ingrediënten). Wanneer die processen een geldige combinatie gevonden hadden, gaven ze die door aan een het "classificator" process. Hiervan was er maar 1 en deze hoefde alleen maar de geldige combinaties te verzamelen en als de tijd om was (5 seconden), de gevonden combinaties te sorteren op wenselijkheid, gebaseerd op een hele rits voorwaarden. De nummer 1 in de lijst werd dan doorgegeven.

De classificator lijkt dan de bottleneck, maar die hoefde in de praktijk erg weinig werk te doen. Het meeste werk werd gedaan door de combinators.

[P_Tingen]

Hmm en heb je je ook afgevraagd of je wel voor de tabaksindustrie wilde werken?

Zeker. En daar heb ik het best wel moeilijk mee gehad. Mijn beide ouders zijn overleden aan de gevolgen van het roken waardoor ik redelijk anti-roker ben geworden. Toch ben ik er daarom niet weggegaan.

Ik ben in loondienst en ik heb in principe geen oordeel over hoe een klant van mijn werkgever zijn geld verdient, een beetje dezelfde redenatie als een strafrechtadvocaat dus. Daarbij werk ik in de IT en niet in marketing. Als ik daar had gewerkt was het anders geweest omdat je dan actief mensen probeert te laten roken. In de IT sta je zo ver van de uiteindelijke klant af dat je daar geen invloed op hebt.

En de belangrijkste reden was wel dat het uiteindelijk niet mijn keuze is of iemand wel of niet gaat roken.

Ik heb er ook zeker geen spijt van; ik heb er vakkundige collega's en vrienden leren kennen en het productieproces van het maken van tabak is - technisch gezien - erg interessant, juist omdat tabak een natuurproduct is, waardoor je dus mooie optimalisatieprocessen moet maken.

[Elazz]

Genoeg games de laatste tijd die ook zeer goed schalen op meerdere cores en zal er alleen maar beter op worden.

[JonathanG]

Meer en meer games doen dat, maar nog lang niet alle. De ontwikkelaars van een spel zijn hier ook verantwoordelijk voor en als ze het niet nodig achten dan zullen ze dat niet implementeren.
Het zijn tegenwoordig ook dan vooral simulatie games (Simcity enz.) die goed schalen met meerdere cores.

[Arm1n]

Assassins creed odyssey weet anders alle 8 cores van m'n CPU op 100% belasting te krijgen. Wat overigens voor m'n gevoel meer te maken heeft met slechte optimalisatie dan dat deze rekenkracht echt nodig is om een luttele 45 fps te krijgen (i7-3770 terwijl m'n GPU uit z'n neus zit te vreten).

[Tokkes]

Ja en nee. Sinds AC Origins is het inderdaad zo dat de game heel CPU-bound is. Zelf had ik tot een paar weken geleden een 4670k overklokt naar 4.6GHz over alle 4 cores en zonder throttling of any kind tikte de CPU 99-100% aan, om mij een 45-50 fps te geven in Origins.
Toen een 4790k in geplempt en nog voor er een overclock op ging ging het al netjes naar de 60 FPS, stabiel, en met nog wat overschot op zowel CPU als GPU vlak qua load.

Daarbij zit die verrekte DRM er ook nog voor wat tussen, helaas.

Zelf ben ik er wel voor te vinden, deze vooruitgang. In plaats van dat developers hun AA(A) games blijven afstemmen op de low-end markt om verkopen te maximaliseren, zorgt dit misschien voor meer high-end hardware adoptie ipv mensen die met een i3 verwachten BFV vloeiend te kunnen spelen "want hij is toch nieuw?!"

[Reactie gewijzigd door Tokkes op 22 juli 2024 22:15]

[mr_evil08]

Vreemd AC is minder zwaar dan BFV en ik doe met BFV op mijn museum pc probleemloos boven de 60fps. ben wel benieuwd wat dat heeft veroorzaakt, dat zou die DRM dan wel zijn.

[Tokkes]

https://steamcommunity.co...ns/0/1483235412209884660/
https://www.reddit.com/r/..._odyssey_drm_performance/

Het is wat giswerk zonder DRM-vrij exemplaar maar dat VMProtect gedoe lijkt mij niet koosjer en Denuvo is bekend om zijn performance impacts.

[Reactie gewijzigd door Tokkes op 22 juli 2024 22:15]

[Sergelwd]

Dat is bij zo'n consoleport inderdaad puur slecht port-werk

[ashwin911]

Moderne game engines maken tegenwoordig gebruik van multi-threaded rendering. De render voorbereidingsfase vindt dan plaats in verschillende jobs in meerdere threads. Zodat de CPU zoveel mogelijk GPU commands per frame stuurt en dus de GPU so min mogelijk idle momenten heeft. Dus het zijn niet alleen sims die goed schalen over meerdere cores.

[psychodude]

Simcity schaalde juist vrij slecht. Cities Skylines bedoel je mogelijk, schaalt redelijk, tot circa 8 cores. Hoewel niet zuiver evenredig per core. En ook dit laatste is nog altijd wel een probleem, dit betekend namelijk nog altijd (vaak) dat je single core performance bound bent.

Dit probleem is toe te weiden aan meerdere factoren. Uiteraard kun je de developers aanwijzen. Maar zij kunnen met alle liefde een game optimaliseren zodat deze bijvoorbeeld prima draait met 16 cores om een paar jaar geleden een volledige high end CPU te benutten. Maar dit strookt niet met de hardware van de consument (destijds). Wat was gemiddeld? De afgelopen jaren een quad core en niet heel lang geleden een duo core. Intel zit hier nog nauwelijks boven tegen een redelijke prijs. AMD steekt hier momenteel fors bovenuit.

Zullen zaken gaan veranderen? Jazeker, gebeurd nu al. Je merkt dat de consumenten de overstap naar meer cores maken. De toekomstige generatie consoles overstapt naar meer cores. En daarmee developers dus ook steeds meer games met verbeterde multicore support levert.

Daarmee moet intel dan ook wel mee, willen ze voorkomen dat ze de cpu markt, zeker op consumenten vlak, niet te veel terrein willen gaan verliezen.

[JonathanG]

Ik bedoelde inderdaad cities skylines. En het zal nooit inderdaad evenredig scalen, maar elke scaling is mooi meegenomen.
En de support voor multi core gebruik is inderdaad in opkomst, want de gemiddelde consument heeft meer cores, en gemiddeld maar 1 GPU. Ook de reden dus dat dingen zoals SLI/NVLink en Crossfire nu veel minder relevant zijn.
En ben dus benieuwd of intel goed meegaat, wat ondanks dat ze over het algemeen beter presteren (soms zelfs maar met een paar %) is de prijs to performance van AMD vele malen beter.

[Tokkes]

Dat schalen is wat moeilijk. Je kan verschillende threads (AI, Physics, UI) wel uitbesteden aan andere cores, maar je zit nog steeds met een general 'world thread' die alles een beetje met elkaar verbindt. Hoe meer er gaande is in die thread (zoals de physics EN de graphics van een ontploffing, bijvoorbeeld, en tegelijkertijd alle characterposities bijhouden en berekenen enz enz). Voor die thread ben je over het algemeen inderdaad 'cpu bound' zoals ze zeggen, en de reden waarom er nog zoveel voor Intel gekozen wordt.

[mr_evil08]

Was dat maar zo vaak blijft het bij 2,3 tot 4 threads bij games, het heeft ook behoorlijk lang geduurt voordat er een beetje fatzoenlijk multi-treaded begon te worden, maar ik ga die discussie hier niet weer starten.

Het gaat nog jaren duren dat 8 tot 16 threads standaard wordt bij software als ik kijk hoe lang het geduurt heeft bij quad core.

[Reactie gewijzigd door mr_evil08 op 22 juli 2024 22:15]

[wica]

Met alle security issues van de laatste tijd, rond CPU's en HT. Heb ik liever geen HT aanstaan op mijn CPU.

[unglaublich]

De security issues zijn vaak genoeg een probleem in de branch-predictor, en die is essentieel voor CPUs met een instructie pipeline. Je ontkomt dus toch niet aan de zwakheden.
Als je echt iets anders wilt neem je een PowerPC of ARM processor, maar dan zal de software support vaak tegenvallen (behalve Linux op ARM).

[latka]

Power en arm zijn ook vatbaar voor meltdown: https://en.m.wikipedia.or..._(security_vulnerability)

[JonathanG]

De issues vallen over het algemeen wel. Het is maar net wat je download en hoe voorzichtig je wil zijn. Maar als je echt niet wilt dat je data gejat wordt, kun je alleen je pc van het internet afgooien. Mensen met slechte bedoelingen vinden toch wel een weg om je te pakken als ze willen. Maar de kans dat die exploits bij jouw worden toegepast is klein als je legitieme software gebruikt. Als je nou meer RAM download dan zou het fout kunnen gaan, maar als je trusted software neemt (denk aan Adobe, gamelaunchers, games, word, excel enzovoort) dan valt het risico wel mee.

[JapyDooge]

Het hele idee van bijv. de rowhammer attacks en afgeleiden en ook diverse andere recente aanvallen met betrekking tot HT specifiek dat heel veel van deze zaken niet zozeer een download zijn, maar prima uitgevoerd kunnen worden in normale javascript op een website.

Dat kan dus ook een malafide banner zijn op nu.nl of welke andere vertrouwde site dan ook.

[latka]

In de browser zitten mitigations ,(minder nauwkeurige klokken)

[Jack Flushell]

Hahaha. Lekker makkelijk. "Als je maar legitieme software gebruikt valt het wel mee". Er is zo onnoemelijk voor software te krijgen en jij noemt een paar grote spelers en dan zou het goed moeten gaan? Daar moeten consumenten dan maar op vertrouwen - op die paar grote jongens en niks anders gebruiken. Zo van: in dit dorp hoeft de deur niet op slot, want niemand steelt hier, daar kun je gerust vanop aan. Ik weet niet wat ik lees, echt.

Ik mis overigens wel de info in dit artikel over HT en de exploits van de laatste tijd. Je zou verwachten dat die opgelost zijn als ze nieuwe CPU's met die techniek uitbrengen.

[JonathanG]

Ik zeg niet dat je geen beveiliging moet hebben, maar ondanks dat grote bedrijven vast wel je gegevens verzamelen, denk ik niet dat die programma's bedoelt zijn om je schade toe te brengen door middel van exploits. Als je malafide software download dan moet je weten waar je aan begint. En zoals ik al eerder aangaf, als je niet wilt dat er misbruikt word gemaakt van jouw of je gegevens moet je maar zonder internet leven. Helaas zitten we aan veel technologien vast en zal iemand met kwade bedoelingen wel een andere weg vinden om jouw van je gegevens te ontdoen.

[wiseger]

Ik zie het niet terug in de meeste apps. Het komt zelden tot nooit voor dat al mijn AMD cores op honderd procent draaien, er zijn er altijd wel een paar vrij. Ik zie dan niet in wat hypertreading toevoegd. Hypertreading klinkt meer als iets wat handig is als je weinig cores in je CPU hebt.

[nl noob]

Heeft iemand nog een idee wat momenteel het verschil is tussen de i3 i5 en i7 series van Intel?
Eerst was i3 de low-performance & low-power cpu van Intel. i5 de krachtige zonder HT en i7 bevatte altijd HT. Nu is er een tijdje geleden dus al een i3 uitgegeven met HT en komen ze nu (mogelijk) met een i5. Wat is het voordeel dan nog van een i7? Willen ze nu "low-end, mid-end en high-end cpu's" gaan uitbrengen onder die namen?

[Anonymoussaurus]

De i7 heeft nu dus geen hyperthreading meer maar de i9's weer wel .

[Zer0]

Eerst was i3 de low-performance & low-power cpu van Intel. i5 de krachtige zonder HT en i7 bevatte altijd HT.

10 jaar geleden waren er al i3 en i5 CPU's met hyperthreading....

Willen ze nu "low-end, mid-end en high-end cpu's" gaan uitbrengen onder die namen?

Volgens mij is dat altijd al de insteek geweest van de ix naamgeving.

[Roland78]

Met de volgende generatie lijkt het heel duidelijk te worden:
i3 4 cores 8 threads
i5 6 cores 12 threads
i7 8 cores 16 threads
i9 10 cores 20 threads

[Zer0]

Nope, want er zijn nu al 10e generatie i7's met minder dan 8 cores...

Laten we aub stoppen met het verzinnen van niet bestaande relaties, het i-nummer zegt helemaal niks over het aantal cores, het wel of niet aanwezig zijn van HT enzovoort, en dat is ook nooit zo geweest.
Het geeft een positionering in de markt aan, niks meer, niks minder.

[Roland78]

Dat is laptopspul. Hierboven wordt geschreven over desktopprocessors.

[Zer0]

Ja en? Er is nog steeds geen verband tussen het aantal cores en het modelnummer.
.....nietszeggende correlaties

[Roland78]

Is er inderdaad nog niet, maar vanaf de 10e generatie wel.

[Zer0]

https://en.wikipedia.org/..._does_not_imply_causation

[Roland78]

https://wccftech.com/inte...400-series-platform-leak/

[Roland78]

Wijsneus. Merk het woordje ‘lijkt’ op in mijn eerste post.

[Roland78]

https://videocardz.com/82...-s-lineup-has-been-leaked

[Anoniem: 669783]

Huidige sweet spot voor games is een quad core met hyperthreading. Voor de toekomst is zes cores of meer wel zo prettig. Ik moet nog games treffen die mijn Xeon E5-2643 tot het uiterste drijft. 'vergelijkbaar met een i7-2600'

[skelleniels]

Te zien welke game, maar tegenwoordig is Hexacore (zonder HT) toch vaak in het voordeel tov een quadcore met HT

[LeStef]

Dan moet je eens een moderne game proberen, verschil met een hedendaagse CPU zal wel enorm zijn.

[wiseger]

Dat begrijp ik niet helemaal. Zes echte cores die parralel werken t.o.v. vier cores die parralel werken maar hun taak switchen met wachtende threads. Waarom zou de processor met vier cores dan sneller zijn? Ik zou juist verwachten dat de zes cores sneller zijn want ze hebben in totaal meer rekenkracht.

[CH4OS]

Waarom zou Intel op de i5 opeens hyperthreading doen? Bij de vorige i7 is de feature juist verdwenen, in het voordeel van de i9 immers. Ik vind het een wat vreemde keuze in elk geval.

[Reactie gewijzigd door CH4OS op 22 juli 2024 22:15]

[skelleniels]

Ik denk dat die feature juist verdwenen was omdat anders de i9 met evenveel cores geen bestaansrecht had. Volgens mij zal het nu zo gaan:

Pentium: Dualcore met HT
i3: Quadcore met HT
i5: Hexacore met HT
i7: Octacore met HT
i9: Decacore met HT

Waarbij het nu zo is:

Pentium: Dualcore met HT
i3: Quadcore zonder HT
i5: Hexacore zonder HT
i7: Octacore zonder HT
i9: Octacore met HT

[latka]

Het is altijd zo geweest (en dat zal nu niet anders zijn) i7>i5>i3 (binnen een generatie).

[CH4OS]

Maar daar heb ik het toch niet over? Met de 9000 serie is het i9 > i7 > i5 > i3, waarbij het enige verschil tussen de i9 en de i7 de hyperthreading was, de i5 heeft (voor desktops) nooit hyperthreading gehad en nu komt dat opeens wel?

Ik had het wellicht geen naamgeving moeten noemen en heb daar nu een beter woord van gemaakt.

[Reactie gewijzigd door CH4OS op 22 juli 2024 22:15]

[latka]

Mijn reactie was omdat iedereen maar roept dat i7 hyperthreading heeft en nu niet meer en dat dat raar is. Ik heb Intel nooit zien roepen dat i7 altijd hyperthreading heeft, alleen dat het beter is dan i5

[Fijinees]

Een kat in het nauw die rare sprongen maakt wellicht?

[sdk1985]

Ik moet wel eerlijk zeggen dat voor gaming ik op basis van mijn ervaring met een 8700K en een 9700K liever een 8core/8thread dan een 6core/12thread cpu koop. Het hyperthreading deel kost namelijk enorm veel extra voltage. Bij mijn 8700K haal ik met hyperthreading uit gemakkelijk 5.2 Ghz. Met hyperthreading aan heb ik meer warmte, meer voltage en dan blijf ik steken op x48. De 9700K heeft 2 cores meer en heeft dit probleem niet. Die loopt harder bij minder voltage, ondanks die twee extra cores.

Verder lijkt het momenteel de vuistregel te gelden dat 8 threads genoeg is voor alle games. Daarboven zie je eigenlijk geen winst, niet van het aantal threads. Onder de 8 threads zijn er een aantal games die flink minder presteren.

[Reactie gewijzigd door sdk1985 op 22 juli 2024 22:15]

[StenMartens]

te laat ingezet op 10 en/of 7nm. ze zijn er wel mee bezig maar die machines zijn niet van vandaag op morgen geleverd, laat staan geimplementeerd in een productieomgeving. dus wat doen we in de tussentijd? laten we maar gewoon features die we al jaren hebben gehad die exclusief voor de premium producten waren implementeren in de overige producten. dan kunnen we met bestaande middelen toch nog wat toevoegen om niet volledig uit de markt gedrukt te worden.

Ik heb altijd intel chips gehad, maar ze hebben wel echt zitten slapen in de gedachte dat ze een luxepositie hadden.

[fentoment]

Te laat ingezet op 10 nm?

Ze zijn er al laaaaaaang mee bezig, ene probleem na het andere blijkbaar.
Slechte yields, niet echt super prestaties, blablabla.

Dus het was voor hun blijkbaar beter om extra geld in 14nm te steken, zodat ze toch iets hadden.

[Reactie gewijzigd door fentoment op 22 juli 2024 22:15]

[DaRk PoIsOn]

Volgens de buren houden we nog even 14nm en gaat intel daarna naar 7nm.

https://youtu.be/-eTa7x84gq0

[StenMartens]

klopt. maar zoals @fentoment al zei, dat gaat niet zonder slag of stoot. maar feit is wel dat ze het nu aan het verliezen zijn van AMD doordat ze nog altijd op 14nm bouwen.

[RoelDozer]

Intel moet wel willen ze concurreren met AMD die SMT heeft op midrange processors en Intel hyperthreading enkel op de allerbeste HEDT processors heeft. Voor alles behalve het allerzwaarste werk (Epyc en Xeon buiten beschouwing) is AMD verreweg de beste keus voor je geld.

[Nemesizz]

Hyperthreading alleen op HEDT? Nee hoor, ook entry level CPU's zoals de i3 hadden al Hyperthreading.

[RoelDozer]

Hadden inderdaad. Tegenwoordig begint het pas op de i9 9900K. Maar nu AMD overal behalve de instap CPU's al SMT aanbiedt moet Intel wel gehoor geven.

[Zer0]

i7-9800X, i7-10510U, i7-10510Y, i7-10710U etc
Er zijn diverse i7 CPU's met hyper-threading.

[RoelDozer]

Welke of HEDT zijn zoals de 9800X of zeer recent zijn uitgekomen als antwoord op AMD's SMT.

[skelleniels]

Pentium G5400 heeft ook al HT

[Hackus]

2GHz lijkt me voor laptopje. (zie trouwens nergens dat het een i5 is)

[Marnixjee]

"De benchmark verscheen in de database van SiSoft Sandra en toont een hexacore-cpu van Intel met twaalf threads. De huidige i7-processors van Intel bevatten acht cores, al is dat wel zonder hyperthreading."
dit stukje redeneren denk ik, overigens is 2Ghz inderdaad wel wat laag voor een Desktop cpu.

[JapyDooge]

"De genoemde cpu draait op een kloksnelheid van 2GHz, wat doet vermoeden dat het hier om een vroege engineering sample gaat. Dergelijke testversies van cpu's hebben vaak lage kloksnelheden in vergelijking met de processors die uiteindelijk in de winkel verschijnen."

Beetje verder lezen nog

[Hackus]

"De benchmark verscheen in de database van SiSoft Sandra en toont een hexacore-cpu van Intel met twaalf threads. De huidige i7-processors van Intel bevatten acht cores, al is dat wel zonder hyperthreading."
dit stukje redeneren denk ik, overigens is 2Ghz inderdaad wel wat laag voor een Desktop cpu.

oa i7-8565U(voor laptop) is 4C-8T, 1.8GHz, dus lijkt me eerder in die richting

[rickboy333]

Ben ik de enige die verbaasd is dat ECS group nog moederborden maakt? Ik dacht dat ze al jaren uit de moederbordhandel waren gegaan/geen consumentenborden meer maakte.

[Van der Berg]

Intel moet nu wel wegens de concurrentie met AMD. jammer dat ze niet voor echte meer cores kiezen i.p.v. HyperThreading