Als onderdeel van zijn Core Ultra 200 Plus-processors maakt Intel zijn nieuwe Binary Optimization Technology beschikbaar. Daarmee gebeurt iets dat we in processorland niet eerder hebben gezien: de functie past de manier waarop code wordt uitgevoerd aan, waardoor die software sneller gaat werken. In onze review zagen we vaak prestatiewinsten van enkele procenten, maar soms ook uitschieters tot wel 16 procent prestatiewinst.
Tweakers sprak vorige week met drie Intel-medewerkers over de technische werking van iBOT, zoals Intel de techniek zelf afkort. In dit interview leer je hoe iBOT exact werkt, wat het verschil is met het al langer bestaande APO en waarom Intel deze nieuwe optimalisatietechniek ziet als een grote nieuwe pijler voor toekomstige prestatieverbeteringen.
Robert Hallock |
Michael Chynoweth |
Erin Maiorino |
Jullie bieden al sinds de 14th Gen Core de Application Optimization-tool (APO) aan om de prestaties van apps en games te verbeteren. Hoe verschilt iBOT van APO?
Hallock: "Eerst even APO: dat is een technologie die op OS-niveau werkt. Het regelt hoeveel threads een game gebruikt en welke prioriteit die krijgen. Veel games bepalen dat zelf via een zogenoemd affinity mask, maar de onderliggende aannames kloppen niet altijd. Een cpu met acht fysieke cores en acht virtuele threads wordt dan bijvoorbeeld gezien als een cpu met zestien fysieke cores.
Door die foute aanname wordt dan een hoop onnodig werk gestart dat de circuits in die cpu helemaal niet efficiënt kunnen verwerken. De overhead van al die threads beheren zorgt er vervolgens voor dat de game juist trager wordt. APO stelt ons in staat om zulke gevallen te identificeren en de cpu beter te laten reageren op de game.
Maar APO kan op architectuurniveau geen fouten in de code oplossen. Daar heb je een andere tool voor nodig. Onze Binary Optimization Tool werkt echt op het uitvoeringsniveau van de microarchitectuur."
Chynoweth: "Om nog iets toe te voegen aan wat Rob zei: ik zeg zelf altijd dat APO de hardwarebronnen optimaliseert voor de software en iBOT de software voor de hardware. En het interessante is dat er daartussenin een soort grijs gebied tussen die twee ontstaat, dat we eerlijk gezegd niet helemaal hadden voorzien toen we hiermee begonnen. In dat tussengebied ontstaan allerlei interessante interacties."
Hallock: "APO en iBOT zijn dus verschillende tools voor verschillende problemen, op verschillende lagen van de softwarestack. Zonder die tools zouden gamers in situaties terechtkomen waarin ergens tussen de 5 en 25 procent van de mogelijke prestaties vastzit achter een optimalisatiekeuze die misschien niet goed is voor de cpu die de gebruiker daadwerkelijk heeft. Die prestaties willen we met APO en iBOT teruggeven aan de gebruiker."
Hoe optimaliseert Binary Optimization Technology de software dan voor de hardware?
Hallock: "Het basisidee is dat ontwikkelaars keuzes moeten maken bij de optimalisatie van hun software. Dat gebeurt vaak op een specifieke architectuur of processorserie; alleen goed gefinancierde ontwikkelaars kunnen in hun lab naar een hoop verschillende cpu's kijken. Op welke architectuur een programma of game is geoptimaliseerd, wat soms zelfs consolehardware of een Arm-cpu kan zijn, beïnvloedt wat voor code er wordt gebruikt en welke instructies er worden gebruikt. Ook als code is geoptimaliseerd voor bijvoorbeeld een andere x86-architectuur, kunnen we die nog steeds draaien, maar dat heeft wel grote invloed op de prestaties.
Met iBOT heeft Intel nu een tool om een gecompileerde workload te 'openen'. We kunnen er niets uithalen, maar wel zaken stroomlijnen of herordenen, zodat die beter aansluit op de executionpipeline van moderne Intel-cpu's, bijvoorbeeld zodat de machinecode de cache beter vult of de branchpredictor beter benut. Met iBOT kijken we naar functies daarin die langzamer werken dan zou kunnen, om ze on-the-fly te vervangen door code die beter werkt op Intels x86-architectuur."
/i/2008078256.png?f=imagegallery)
Misschien is het goed om even te definiëren wat 'machinecode' precies is.
Hallock: "Machinecode is een instructie op een heel diep niveau. Je kijkt dan niet meer naar programmeertaal met context en logica, maar naar een soort handleiding die de cpu vertelt wat hij moet doen. Bijvoorbeeld: spring naar geheugenadres 0x00010 om daar een stukje data op te halen."
Kun je een praktisch voorbeeld geven van hoe iBOT die machinecode kan optimaliseren?
Hallock: "Laten we een hypothetisch voorbeeld nemen van een programma dat iets in cache opslaat. Je ziet links (in onderstaande afbeelding, red.) een eenvoudige 'if-then'-constructie. Als dit kleine stukje data een waarde lager dan 10 heeft, gaat de volgende regel code naar een errorhandler. En als dat niet zo is, doe je in plaats daarvan het normale werk. De 'then' is dus de uitzondering.
Het probleem is alleen dat veel algoritmen voor caching en branchprediction gewoon de volgende regel code – dat then-statement – als uitgangspunt nemen. Maar als die code slechts in 1 procent van de gevallen wordt gebruikt, of zelfs in 0,01 procent van de gevallen, dan cachet de cpu iets en springt hij toe naar iets dat bijna nooit wordt gebruikt. Dat is zonde van de waardevolle cacheruimte en kostbare processortijd."
/i/2008079256.png?f=imagearticlefull)
Hallock: "Een voorbeeld van hoe we dat kunnen herordenen met iBOT is om het then-statement in cold storage te zetten. Je kunt dat verplaatsen naar de L3-cache of zelfs het werkgeheugen, zodat standaard het echte werkpad wordt genomen in de machinecode.
Dan gebeurt dus het volgende: in plaats van eerst de errorhandler uit te voeren, waarmee je de cache vult met dingen die je waarschijnlijk niet gaat gebruiken, vul je de cache met nuttige data die je wél nodig hebt. Je gooit dan geen belangrijke cachelines meer weg voor een heel uitzonderlijk scenario.
Er zijn allerlei voorbeelden zoals dit op het gebied van caching, codehotspots en branchprediction. Maar het idee is dat wij kunnen herstructureren waar en wanneer het minst gebruikte pad in de machinecode terechtkomt, zodat de processor betere beslissingen kan nemen terwijl hij door de code heen loopt."
Als je puur de machinecode bekijkt, weet je alleen niet of een afslag in de praktijk vrijwel altijd of juist bijna nooit wordt genomen. Je moet de code dus draaien en analyseren om te weten wat er gebeurt, lijkt me.
Chynoweth: "Ja, daar komt veel bij kijken. We registreren elke genomen sprong in de code (een branch in jargon, red.) in wat we de lastbranchrecords noemen. Daar zien we welke branches worden genomen, waarvandaan en waarnaartoe, en of die branch goed was voorspeld door de branchpredictor."
Draai je een programma dan op een soort gesimuleerde processor, of op een echte chip zoals consumenten die ook in hun pc hebben zitten?
"Wij gebruiken een echte processor met een echte workload."
Hallock: "Daar raak je precies ons voordeel: wij gebruiken een echte processor met een echte workload. Iedereen doet aan code profiling, maar generieke tools daarvoor geven je geen specifieke details over wat er ín de processor gebeurt. Voor bepaalde aspecten van de microarchitectuur ben je gewoon blind.
De zelfontwikkelde tool die wij gebruiken, Intel Hwpgo, gebruikt informatie uit een performance monitoring unit in de hardware. Die geeft informatie over specifieke events en geeft daarbij bijvoorbeeld de adresinformatie en die lastbranchrecords. We kunnen daardoor precies zien waar de bottleneck zit in de processor.
Deze manier om de prestaties te monitoren hebben we ooit bedacht om ontwikkelaars te helpen debuggen, maar met iBOT hebben we er ook een geweldige toepassing voor gebruikers voor gevonden."
Chynoweth: "Wat belangrijk is, is dat je met deze hardwarematige profiling ook echt zeker weet dat je analyse klopt. Voorheen gebruikten ontwikkelaars vaak een instrumented binary met allerlei extra logging. Dat vertraagt de uitvoering echter zeker met een factor drie; ik heb zelfs wel eens een factor tien gezien. Hoe weet je dan nog of de resultaten van je profiling worden veroorzaakt door je eigen debugfeatures of door echte inefficiënties in de code?
Onze metingen hebben minder dan één procent overhead. Hwpgo is zonder twijfel een superieure manier van profileren. Het kost ook nauwelijks prestaties terwijl je het doet en je kunt het toepassen op echte binary's in een productieomgeving."
Wat voor soorten optimalisaties kunnen jullie doen met al die informatie?
Hallock: "De technologie bestaat uit verschillende modules, die je het best kunt zien als een familie van tools die elk op hun eigen manier ingrijpen op architecturale aspecten van software – denk aan branching, caching of codehotspots.
Die modules zijn opvallend generiek, want de problemen die ze aanpakken komen overal in code terug. Welke module wordt ingezet, hangt sterk af van de context: welke compiler is gebruikt, met welke compilerflags, hoe lang geleden de code is gebouwd, waarvoor die destijds bedoeld was en zelfs welke processor de ontwikkelaar destijds zelf op zijn bureau had staan.
Welke modules we precies gebruiken verschilt per workload, maar ze komen allemaal uit dezelfde gereedschapskist en hebben hetzelfde doel: architecturale knelpunten opsporen en oplossen in de code."
Lijst met door iBOT ondersteunde games
- Assassin's Creed Mirage
- Borderlands 3
- Cyberpunk 2077
- Far Cry 6
- Final Fantasy XIV: Dawntrail
- Hitman 3
- Hogwarts Legacy
- Marvel's Spider-Man Remastered
- Naraka: Bladepoint
- Remnant II
- Shadow of the Tomb Raider
- Tiny Tina's Wonderland
Het viel me op dat in het voorlopige lijstje van ondersteunde games weliswaar enkele recente titels staan, zoals Cyberpunk 2077, maar toch voornamelijk oudere games. Daar ligt dus blijkbaar het meeste potentieel. Komt dat doordat ontwikkelaars beter zijn gaan programmeren, of doordat compilers beter worden en nieuwere x86-features zijn gaan gebruiken?
Chynoweth: "Een beetje van alles eigenlijk. Voor iBOT kijken we in de eerste plaats naar games die populair zijn maar inefficiënt draaien. Ook passen we het vooral toe bij titels waarbij we niet de mogelijkheid hebben om met de ontwikkelaars samen te werken. Voor Cyberpunk 2077 hebben we eerder samen met de ontwikkelaars aan een grote patch gewerkt die ongeveer 30 procent prestatiewinst opleverde. Maar neem Shadow of the Tomb Raider, een game waaraan niet langer actief aan wordt ontwikkeld. Toch spelen nog steeds veel mensen die game en we weten dat er specifieke knelpunten zijn die betere prestaties in de weg staan. In zulke gevallen zetten we de Intel Binary Optimization Tool in om die efficiëntie te verbeteren en betere frametimes te realiseren."
Ook ligt de focus tot nu toe vrijwel exclusief op games. Ligt er ook potentie voor iBOT in productieve software?
Hallock: "In theorie komt elke categorie software in aanmerking voor binaryoptimization. Maar daarbij rijzen meteen wat fundamentelere vragen: is het echt de moeite waard? Is de prestatiewinst groot genoeg? Is dit een verstandige inzet van engineeringtijd? En hoe kijkt de community hier tegenaan – zien ze het als iets nuttigs en positiefs of juist niet? Dat zijn filosofischere overwegingen.
In de praktijk maakt het niet zo veel uit of het gaat om creatieve toepassingen, productiviteitssoftware of games: overal waar ruimte is voor optimalisatie, zouden we binaryoptimization kunnen toepassen. Dat is uiteindelijk ook ons doel. Tegelijkertijd beseffen we dat niet-gameworkloads waarschijnlijk een hogere drempel hebben, zeker met hun reputatie, zowel bij gebruikers als in de media. Daarom rollen we deze technologie bewust voorzichtig en methodisch uit en blijft deelname opt-in.
"We weten hoe snel het beeld kan ontstaan van: 'Kijk, Intel zet een feature aan en krijgt daardoor een hogere benchmarkscore.' Dat willen we koste wat kost vermijden."
We weten hoe snel het beeld kan ontstaan van: 'Kijk, Intel zet een feature aan en krijgt daardoor een hogere benchmarkscore.' Dat willen we koste wat kost vermijden. We willen laten zien dat het kan, om daarna stap voor stap toe te werken naar een bredere toepassing. Er zit nog enorm veel potentie in deze technologie, maar we kiezen bewust voor een voorzichtige aanpak, zodat de industrie de tijd heeft om te begrijpen wat we doen en het zich geleidelijk kan ontwikkelen."
Dus je wil bijvoorbeeld geen Cinebench-optimalisatie doen, omdat mensen dat als valsspelen zouden kunnen zien?
Chynoweth: "Het moet een positief effect hebben op de eindgebruiker. Cinebench is een renderbenchmark, dus laat ik rendering als voorbeeld nemen. We hebben onlangs Hwpgo toegepast samen met Chaos Group, de ontwikkelaar van de populaire renderer V-Ray. Met soortgelijke optimalisaties als we doen met iBOT hebben we daarbij gemiddeld meer dan 15 procent prestatiewinst behaald. Daar hadden klanten van V-Ray, grote filmstudio's bijvoorbeeld, direct baat bij."
Maiorino: "Dat toont ook aan dat onze engineers vertrouwen hebben opgebouwd bij partners als Chaos Group. Een compilerupdate doorvoeren is namelijk geen kleinigheid; er kan veel misgaan. Mike (Chynoweth, red.) en zijn team hebben uitstekend werk geleverd door dat vertrouwen te winnen en te laten zien dat we in nauwe samenwerking met onze partners extra prestaties willen ontgrendelen. Zo profiteert iedereen van die mooie prestatiewinst."
Je zou denken dat zware cpu-workloads, zoals rendering en videocodering, al zo extreem zijn geoptimaliseerd dat er weinig potentieel meer over is. Maar jullie zien in dat soort taken dus wel een toekomstige rol voor iBOT?
Hallock: "Als we video-encoders als voorbeeld nemen, gaat een groot deel van de optimalisatietijd in zulke projecten zitten in het sneller maken van de encoder zelf, zoals bij de scèneanalyse en het coderen. Daarbij ligt de focus vooral op de algoritmische optimalisatie van de codec die men wil implementeren.
Dat hoeft echter niet per se te betekenen dat er ook specifiek voor een bepaalde cpu-architectuur is geoptimaliseerd. Ontwikkelaars willen dat de encoder goed presteert, maar denken misschien niet aan optimalisaties die specifiek op één architectuur gericht zijn – en bij opensourceprojecten voelen ze daartoe vaak ook geen directe verplichting.
In zulke gevallen blijft er dus zeker nog ruimte over voor verbetering. Een workload kan al intensief generiek geoptimaliseerd zijn, terwijl er met architectuurspecifieke optimalisatie nog veel te halen valt."
Chynoweth: "Juist bij codecs zien wij daardoor soms onze grootste prestatiewinsten, wat dit voor ons een bijzonder interessant domein maakt."
In een eerdere presentatie zeiden jullie dat iBOT nu start met de Core Ultra 200 Plus-cpu's, maar vanaf nu een vaste pijler wordt voor prestatieverbeteringen bij toekomstige cpu-generaties.
/i/2008079264.png?f=imagegallery)
Hallock: "De eerste lakmoesproef is eigenlijk de vraag: voor welk type product is binaryoptimization zinvol? Dat zal altijd een product zijn dat niet wordt gebottleneckt door de gpu. We passen het bijvoorbeeld niet toe bij Panther Lake 12 Xe, de configuratie met een grote geïntegreerde gpu. Voor een igpu is die heel snel, maar hij zal in veel gevallen wel maximaal benut worden. Dan valt er weinig meer te behalen met binaryoptimization; zelfs als we de cpu nog sneller maken, kan de gpu niet ineens meer frames produceren.
Panther Lake 4 Xe, met een minder krachtige igpu, is juist bedoeld om te combineren met een krachtige losse videokaart. Games zullen in deze systemen dus veel minder snel gebottleneckt worden door de gpu, wat het een geschikter scenario voor iBOT maakt. Wel kijken we per processor wat zinvol is, waardoor de lijst met ondersteunde games kan verschillen tussen bijvoorbeeld Panther Lake voor laptops en de Core Ultra 200 Plus-cpu's voor desktops.
Naar de toekomst toe is de vuistregel dus: als het platform ontworpen is om te werken met een losse videokaart, zullen we iBOT toepassen, zowel bij laptops als bij desktops."
Maar zo'n grafische bottleneck speelt alleen bij games. Hoe zit dat bij optimalisaties voor pure cpu-workloads?
Hallock: "Dat klopt, voor pure cpu-toepassingen kan elk product in principe profiteren van binaryoptimization. Maar we maken ons geen illusies; mensen kopen deze cpu's vooral om te gamen en daarom is de verhouding tussen games en andere software in de supportlijst nu ongeveer 15 om 1."
Je zei al dat iBOT niet standaard aanstaat; het is vooralsnog opt-in. Wat maakt jullie terughoudend?
Hallock: "De geschiedenis barst van de voorbeelden van 'zet een feature aan en krijg meer performance'. Maar diezelfde geschiedenis laat ook zien dat dit lang niet altijd goed afliep.
"Je kunt natuurlijk zeggen: dit is geweldig voor gaming, waarom staat het dan niet gewoon standaard aan?"
We begrijpen heel goed dat binaryoptimization op het eerste gezicht op die eerdere pogingen kan lijken. Juist daarom vonden we het essentieel om deze technologie zo conservatief mogelijk te introduceren. We weten dat iBOT fundamenteel verschilt van eerdere pogingen die er misschien oppervlakkig op leken, maar inhoudelijk iets totaal anders deden. Die eerdere voorbeelden brachten risico's met zich mee voor consumenten en voor het vertrouwen van het publiek. Daarom kiezen we ervoor om iBOT voorlopig opt-in te houden, zodat mensen er rustig aan kunnen wennen en goed kunnen begrijpen wat het doet. Misschien schakelen we het op termijn standaard in, maar eerst willen we zien hoe het wordt ontvangen. We vonden dat de juiste, ethische aanpak.
Je kunt natuurlijk zeggen: dit is geweldig voor gaming, waarom staat het dan niet gewoon standaard aan? Maar wij willen het veilig spelen. Dat is volgens ons beter voor onszelf, voor het publiek en voor de industrie als geheel."
Is dat ook vanwege de mogelijkheid dat er nog bijwerkingen zijn die jullie in jullie tests niet hebben gezien, maar waar gebruikers wel tegenaan kunnen lopen? Of is het vooral een kwestie van perceptie en acceptatie?
Hallock: "Vooral dat tweede. Laat duidelijk zijn: we verzamelen geen telemetrie, dus we weten niet wie iBOT aanzet. Wat we wél doen, is heel goed letten op het sentiment: op berichtgeving van jullie, reacties op jullie site, opmerkingen op YouTube, Reddit, X, Bluesky en ga zo maar door. We volgen dat allemaal nauwgezet om te voelen wat mensen ervan vinden. Op basis daarvan kunnen we onze keuzes eventueel aanpassen of juist bevestigen. Dat moeten we nog zien.
"Ik verwacht zelf trouwens dat gebruikers het goed zullen ontvangen. Het zijn tenslotte gratis extra prestaties."
Ik verwacht zelf trouwens dat gebruikers het goed zullen ontvangen. Het zijn tenslotte gratis extra prestaties. Maar tegelijk snappen we dat dit heel anders is dan hoe cpu-optimalisatie de afgelopen vijftig jaar gebruikelijk was. Nu hebben we ineens een extra roadmap. We hadden al een hardwareroadmap die leidt tot steeds betere gamingprestaties, maar nu hebben we ook een softwareroadmap die de gamingprestaties verbetert – in hetzelfde tempo of misschien zelfs sneller.
Dat is behoorlijk bijzonder. Er is niets anders zoals dit. Maar als je een grote verandering introduceert, kun je de wereld niet van de ene op de andere dag veranderen. Zo werkt het niet. Dus we willen dit stap voor stap doen."
Tot slot, wat zou onze lezers moeten bijblijven over iBOT?
Chynoweth: "Ik zou zeggen dat iBOT in zekere zin echt een gamechanger is, omdat het gaat veranderen hoe software en hardware met elkaar omgaan. De software draait nu harmonischer samen met de hardware. En met APO wordt de hardware op zijn beurt weer voor de software geoptimaliseerd. Vooruitkijkend zoeken we zelfs al naar extra mogelijkheden in de cpu zelf.
We werken rechtstreeks samen met de cpu-ontwerpers, om te kijken welke informatie de chip in real time aan ons kan teruggeven, op nanosecondenschaal, en hoe we daarmee niet alleen de gemiddelde framerate kunnen verhogen, maar ook de consistentie van frames en andere problemen die de gebruikservaring raken kunnen aanpakken. Daar gaan we in de toekomst nog agressiever op inzetten."
"Het zijn échte extra fps en we weten dat dat voor gamers echt telt."
Maiorino: "Van mijn kant wil ik vooral benadrukken dat dit échte fps-winst is. Dit zijn geen fake frames, geen rare AI-dingen die buiten beeld plaatsvinden. Het zijn echte extra fps en we weten dat dat voor gamers echt telt."
Hallock: "Wat ik de lezers van Tweakers vooral wil meegeven, is dat we geen enkel stuk werk dat de binary hoort uit te voeren verwijderen. Alles wat in de broncode stond, gebeurt nog steeds. Er wordt niets overgeslagen. Maar we kunnen wél veel prestatiewinst behalen door ervoor te zorgen dat de code de processor compacter en efficiënter bereikt.
iBOT is dus een heel pure vorm van prestatieoptimalisatie, omdat je alles behoudt zoals het bedoeld was, maar het simpelweg beter uitvoert. Dat is waar we echt trots op zijn: dat we een workload sneller kunnen laten verlopen, terwijl we respect tonen voor het origineel, doordat we alle oorspronkelijke verzoeken daarin intact houden."
Ik kan me voorstellen dat het soms wel heel aantrekkelijk is om gewoon een stukje uit de code te schrappen, als je ziet dat iets onnodig berekend wordt of makkelijk overgeslagen had kunnen worden.
Hallock: "Ja, maar het blijft er gewoon in, want het zat nu eenmaal in het origineel. Dat is het juiste om te doen."
Redactie: Tomas Hochstenbach • Eindredactie: Marger Verschuur
:strip_exif()/i/2008078270.png?f=thumbmedium)
:strip_exif()/i/2008078268.png?f=thumbmedium)
:strip_icc():strip_exif()/i/2008078264.jpeg?f=fpa_thumb)
/i/2008059666.png?f=fpa)
/u/89002/crop5f4e07abb6d85_cropped.png?f=community){kind=small}
/u/27299/hoofd.png?f=community){kind=small}
:strip_icc():strip_exif()/u/56926/MGA_new.jpg?f=community){kind=small}
.
/u/12436/p1_normal.png?f=community){kind=small}
:strip_icc():strip_exif()/u/109773/ziltoid_fetid_70px.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/2370468/crop6901c511c81b0_cropped.jpg?f=community){kind=small}
/u/3041/crop651a776a4ad9f_cropped.png?f=community){kind=small}
/u/321057/crop69aafcef36c11_cropped.png?f=community){kind=small}
/u/9258/killbill.png?f=community){kind=small}
/u/581763/crop671d464e1d270_cropped.png?f=community){kind=small}
/u/1733216/crop61f3fcf0194a9_cropped.png?f=community){kind=small}
/u/152942/crop687206d7bca78.png?f=community){kind=small}
:strip_icc():strip_exif()/u/136442/crop6198f3130240d.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/596456/wd%2520icon.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/262645/Waldorf.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/401615/edit.jpg?f=community){kind=small}
:strip_exif()/u/53522/crop583d477015a24.gif?f=community){kind=small}
/u/336312/crop6638bf772fb60_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/287731/crop6270fa65746ea_cropped.jpg?f=community){kind=small}
/u/34200/crop6554f56fe2075_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/109168/crop5c6ad3dc9bc0f_cropped.jpeg?f=community){kind=small}