Geekbench waarschuwt: Intel-optimalisatietool maakt scores onvergelijkbaar

De Geekbench Browser toont een waarschuwing bij benchmarkresultaten van cpu's die de nieuwe Binary Optimization Tool van Intel ondersteunen. Volgens Geekbench is het niet mogelijk om te achterhalen of die technologie is gebruikt.

Intel kondigde eerder deze week de Intel Binary Optimization Technology aan, die de manier waarop code wordt uitgevoerd aanpast. Daardoor gaat software sneller werken op ondersteunde cpu's. De technologie kan ook worden gebruikt in de Geekbench 6-benchmarksoftware. Volgens moederbedrijf Primate Labs stijgen de gemiddelde Geekbench 6-scores door het gebruik van iBOT met 8 procent, met uitschieters van 40 procent.

Primate Labs schrijft dat de tool de benchmark verandert en dat het onduidelijk is voor zowel het bedrijf als gebruikers hoe dat precies gebeurt. Daarom zijn resultaten met iBOT ingeschakeld niet vergelijkbaar met andere resultaten.

Omdat niet te achterhalen is of cpu's die compatibel zijn met de technologie er ook daadwerkelijk gebruik van maken, toont Geekbench nu een waarschuwing bij alle resultaten van cpu's die iBOT ondersteunen. Daarin staat dat het benchmarkresultaat 'mogelijk ongeldig' is vanwege binaire modificatietools. Primate Labs noemt dit een 'hopelijk tijdelijke' oplossing voor het probleem.

Op dit moment is de Binary Optimization Tool alleen te gebruiken door processors op basis van de Panther Lake- en Arrow Lake Refresh-architecturen. Primate Labs zegt dat de waarschuwingen ook zullen worden getoond als de technologie beschikbaar komt op meer cpu's.

Reacties (43)

[mrtak]

Staat er ook een waarschuwing voor SSE of SSE2?

[Werelds]

SSE en dergelijke worden door de applicatie gebruikt, indien beschikbaar. Daar heeft GB de controle over.

Dit, daarentegen, past de applicatie code *extern* aan en wordt *niet* standaard op alle systemen met deze processors gedaan. Dus nee, een waarschuwing voor SSE, AVX, enzovoort is niet nodig, want dat ligt bij de applicatie. Dit is een opt-in feature die niet te detecteren is.

Stel bijvoorbeeld dat kloksnelheden niet uit te lezen waren. Dan zou je resultaten zien die misschien wel dubbel zo snel zijn, zonder aantoonbare reden. Dat is wat dit is en doet. En wellicht nog erger, nieuwere versies zullen misschien meer optimalisaties bevatten, waardoor de resultaten nog verder gaan verschillen. Geeft een CPU nu een score van 5000 zonder iBOT, 7500 met iBOT 1.0 en over een half jaar 10000 met iBOT 1.1 - zonder dat je kunt zien wat dat verschil veroorzaakt. Zegt dus helemaal niks meer.

[!mark]

Maar als iBOT ook dat soort winsten gaat boeken in daadwerkelijke applicaties, dan is er toch niks mee dat dat zichtbaar is in benchmarks?

En ja dat is wel heel naief gesteld natuurlijk en geloof er zelf ook geen bal van, eerder dat ze juist maximaal zullen gaan optimaliseren om er in benchmarks het beste uit te komen en in de praktijk minder

[Werelds]

Maar als iBOT ook dat soort winsten gaat boeken in daadwerkelijke applicaties, dan is er toch niks mee dat dat zichtbaar is in benchmarks?

Het feit dat je niet weet of het met of zonder iBOT is sowieso wel.

En zelfs als GB zou kunnen laten zien of het met of zonder iBOT is, de resultaten van hun product zijn dan geenszins representatief voor de algemene prestaties van die CPU. Het werkt alleen wanneer iBOT een specifieke binary aan heeft gepast, waardoor dezelfde optimalisaties niet altijd toegepast worden. Als iBOT bijvoorbeeld een AVX-1 instructie stilletjes omzet naar een AVX-2 instructie omdat laatstgenoemde op die specifieke CPU sneller werkt, maar dat dus enkel doet voor applicatie A (GB bijvoorbeeld) terwijl applicaties B t/m Z er even veel profijt van zou hebben, zie je een verschil in prestaties. GB zou dan aangeven dat die CPU 50% sneller is dan wat dan ook, maar in de praktijk zie je er geen reet van omdat iBOT met de binary heeft lopen rotzooien.

Het zou ook anti-competitieve praktijken als resultaat kunnen hebben. Wederom, Intel optimaliseert Photoshop stilletjes via iBOT, maar allerlei andere vergelijkbare software krijgen die optimalisaties niet omdat...ze daar geen tijd voor hebben, Adobe ze betaalt dat te doen, er iemand binnen Intel enkel PS belangrijk vindt, enzovoort.

[napata]

Het klopt wat je zegt maar dat geldt toch ook al zo bij GPUs? Drivers bevatten vaak specifieke optimalisaties. Soms kan een driverupdate redelijk veel prestaties opleveren.

Geekbench heeft trouwens ook een GPU benchmarks. Ik vermoed dat het zowel voor hen als gebruiker ook helemaal onduidelijk is wat de driver precies uitvoert.

[Reactie gewijzigd door napata op 25 maart 2026 13:18]

[Xfade]

waarom zou dit moeten ?

[Scriptkid]

Vraag is dus maakt IBOT de browser ook sneller, want dan is het gewoon valide, elke processor architectuur heeft andere features om dingen sneller te maken. we kunnen ze niet allemaal uit gaan zetten en dan gaan vergelijkten dat is het hele idee van features en improvements.


Het wordt pas een ding als er iets gefaked wordt omdat het een benchmark is zoals we in de early 2000 hadden met videokaart benchmarks van 3dmark.

[mcDavid]

Het probleem is dat een benchmark vaak bewust inefficiënte code probeert te draaien om de CPU te stressen. Bijvoorbeeld een loop die berekeningen uitvoert maar niets met de resultaten doet.

Als je dan een optimalisatie tool gebruikt die dat detecteert en de hele loop verwijdert, dan ben je wel sneller klaar maar heb je eigenlijk helemaal geen benchmark uitgevoerd.

[Skit3000]

Klinkt dus alsof ze de benchmarktool aan moeten passen (en opnieuw moeten draaien op alle oude cpu's om een baseline te kunnen maken).

[Finraziel]

iBOT werkt nog maar voor een handvol applicaties... Dat daar vooral benchmarks of games die veel gebruikt worden als benchmark tussen zitten is op zijn minst iets om nota van te nemen.

Er zit geen browser in de lijst van ondersteunde applicaties (Geekbench is de enige niet-game), dus daar gaat het vooralsnog niet helpen.

[bun00b]

In principe als alle hardware gebruik maakt van alle mogelijke optimalisaties, is er geen probleem en zie je voor elke chip wat de maximum prestatie zowat is, toch? Een beetje zoals hoe eenzelfde chip met en zonder overclocking verschillende resultaten geeft.

Maar wat ik hier begrijp is dat in tegenstelling tot overclocking, waar het verschil in kloksnelheid zichtbaar is dus je ziet ook duidelijk waarom er een verschil in prestaties is, hier met iBOT er geen flag is om aan te geven of het is gebruikt? Dus in principe als de optimizer van Intel ergens zou kunnen meegeven dat het is gebruikt, kunnen ze in de resultaten ook mooi de vergelijking weer kunnen maken met/zonder overclock, met/zonder iBOT etc.

Het is inderdaad lastig aangezien het geen meegeleverde software is die dus "standaard" aanwezig is wanneer iemand een ondersteunde chip gebruikt, dus ze kunnen nergens die assumptie maken, en iBOT is ook zelf niet compatibel met alle software dus zelfs al heeft het een hogere benchmark score, betekent het nog niet dat de applicaties die je gebruikt ook dezelfde prestatiewinst gaan vertonen.

Het is voorlopig nog een soepje, maar de tool is ook nog maar pas uit. Ik geloof wel dat dit binnenkort wordt opgelost. Ik hoop ook dat deze soort tools naar alle chips kan komen, misschien als onderdeel van de driver?

[Wolfos]

Zolang het alleen bij een piepklein subset van software werkt is het feitelijk valsspelen wanneer benchmarks onder die subset vallen.

Wat heb je eraan als een paar oude games wat sneller draaien? Meestal ben je toch GPU-limited. Als ze nou die stotters uit Oblivion-remastered wisten te optimaliseren was het nog merkbaar, maar zelfs dat is ook maar één geval.

[Reactie gewijzigd door Wolfos op 25 maart 2026 11:41]

[bun00b]

Juist, vandaar dat het voorlopig ook eerder niche is dan iets nuttigs. En dat één van de eerste ondersteunde apps een benchmark tool is, zegt ook al veel.

Als het voor (bijna) alles werkt, zou het een goede tool zijn.

[GarBaGe]

Intel is al decennia bezig om software sneller te laten draaien op hun CPUs.
Het is niet voor niets dat op Linux de Intel compiler een stuk efficienter is dan de generieke GCC compiler.
Een groot probleem, is dat veel software slecht of matig is geschreven en niet efficient draait.
In de nieuwste ontwikkelingen aan Intels kant in de vorm BOT zie je simpelweg de volgende generatie.
Als Geekbench inefficient geschreven is en veel sneller kan werken (tot 40%) dan moeten de mensen van Geekbench aan de slag.
Naarmate Geekbench efficienter is, zal een tool zoals BOT hier minder mee kunnen doen.

[bantoo]

Nee dat moet Geekbench helemaal niet. het doel van een benchmark is niet om een zo snel mogelijk programma te schrijven. Het is om een stuk software te schrijven wat gebruikt kan worden om verschillende systemen te vergelijken. Als Intel vervolgens een stukje custom herkenning inbouwt voor Geekbench en dat anders uitvoert haalt het niet langer het doel van de benchmark. Stel je voor dat ik iets schrijf om een FPU te testen, simpele benchmark die op iedere CPU zal draaien. Als Intel daar bijvoorbeeld met BOT allemaal AVX512 calls van zou kunnen maken krijgen ze hoge getallen maar die zijn niet langer gekoppeld aan het doel van de benchmark.

[GarBaGe]

Intels software verandert wel instructies, maar het eindresultaat is hetzelfde.
Als Geekbench allemaal "nep" instructies uitvoert (noop of wait) dan zal de Intel software dit veranderen met hetzelfde resultaat, maar wel sneller.
Ik zie dit hetzelfde als John Carmack in de jaren 90 met Quake, die er achter kwam dat een Intel CPU een integer en een floating point tegelijkertijd kon uitvoeren. Hiermee kon deze specifieke processor veel efficienter worden ingezet en was het resultaat een veel soepelere game op die specifieke hardware.
Andere manier van executie, zelfde eindresultaat.
Een generieke tool als Geekbench, is voor mij heel onoverzichtelijk wat ie precies doet en test.
Ik heb veel liever software die de CPU echt aan het werk zet: compressie, renderen, dat soort taken.

[bantoo]

Dus dan boeit de benchmark je gewoon niet, okay duidelijk.

[NEO256]

Beste meneer, je praat poep.
Ja wat je stelt over software optimalisatie is correct, maar je mist het punt.

Dit is een "diesel gate" achtig probleem. De auto doet het beter, dan wat hij op papier zou moeten halen door de sjoemelen met variabelen waar je niet aan hoort te zitten.

Intel sjoemelt met de resultaten van benchmark programma's door niet transparant te zijn over de optimalisaties die binairy code in execution te veranderen zodat hij sneller draait.

Dus mijn voorspellingen zijn de volgende:

• Er komen wild veel verschillen in wat voor gains dat je gaat krijgen liggend aan de code en workload. Wat je CPU uitvoer snelheid dus onvoorspelbaar maakt.
• Er zijn nu al jaren op een rij grote security issues gevonden in branche prediction, wat probeert te voorspelen hoe je een workload het beste kunt opdelen over cores. DEZE techniek PAST DE CODE ZELF AAN voor hij wordt uitgevoerd. Als je diet niet FOUTLOOS DOET, kun je een veilige applicatie dus ineens ONVEILIG maken.
• Omdat de manier waarop Intel dit doet dus niet transparant is, gaan mensen dadelijk proberen om deze problemen heen te werken. Dit gaat bakken met tijd kosten, fouten in de hand werken en alles nog onduidelijker maken.

Ik zie alleen maar verliezers.

Dit kan een fantastische tool zijn, als Intel het had aangeboden als een soort van instructie set optimalisatie flag. Ja we ondersteunen het, zet maar aan.

Beter nog, open source de hele meuk, zodat we mee kunnen kijken of wat je doet wel is wat we willen. Zie bovenstaande voorspellingen. Als mijn TLS verbinding of cryptografische berekeningen worden geoptimaliseerd, maar niet meer veilig kunnen worden uitgevoerd, of nog erger nieuwe fouten introduceert, omdat ik deze CPU's gebruik. Wat voor hel komen we dan in terecht?

Dat er dadelijk BitCoins of andere digitale valuta zijn, waar de chain en ledger niet meer kloppen omdat de onderliggende berekeningen wel zijn gemaakt, correct zijn bevonden, omdat dezelfde validatie logica die fouten niet vindt, omdat ze "mathematisch wel correct zijn" maar bepaalde stappen hebben overgeslagen.

Het is stepulatie, maar dit soort dingen zijn gewoon killing, hier kunnen echt nare dingen gaan gebeuren. En het probleem ligt maar op een plek, transparantie:

• Staat het aan?
• Wat doet het precies?
• Wat heeft het gedaan?
• Is het resultaat altijd bit voor bit hetzelfde?
• Wanneer heeft het nut en wanneer werkt het niet?

Kunnen we het vertrouwen om ook maar iets beter te maken of moeten we Intel maar op hun woord vertrouwen?

[latka]

Ik denk dan ook dat benchmarks onzin zijn: draai je programma waar het om gaat en meet het aantal fps en of er überhaupt wel frames gerenderd worden (dus dat ibot niet doodleuk het scherm.op zwart zet). Als je game op een cpu met ibot dan ineens 20% sneller is dan zie ik geen enkel probleem om te melden dat je cpu sneller is dan die van de concurrent. Dat geekbench het tricky vind zal komen omdat geekbench zelf in de lijst van apps staat vermoed ik. Als ibot betaalde software zou zijn zou ik het argument een stuk sterker vinden.

[jpfx]

Sterker nog, in benchmarks kunnen delen code met opzet inefficiënt zijn geschreven, omdat je wilt meten hoelang een vaststaand, bekend proces duurt. Daarvoor kan je 2000 keer hetzelfde gaan doen. Niet efficiënt, maar zeer passend voor het doel. Als een processor dan na 50 keer "ziet" dat de uitkomst gelijk is, en een efficiëntie slag toepast door de bewerking niet uit te voeren maar direct het resultaat te geven, is de hele benchmark naar zijn grootje. Het resultaat van de benchmark zegt dan helemaal niets meer over hoe snel of goed de processor echt is.

[Zoijar]

Hmm maar dat doet elke processor intern. De assembly instructies zijn helemaal niet wat de CPU daadwerkelijk uitvoert, intern zitten er allemaal optimalisaties in, pipelining, prediction, pre-fetches, etc, etc. Elke assembly instructie in je binary is al een klein "programmaatje" dat door de CPU wordt uitgevoerd; het is eerder een soort van virtual machine.

[Mellow Jack]

Dat is dus niet zo. Tenminste als ik het goed begrijp kijkt intel maar de machine code en doet op dat niveau optimalisaties. Dus ja, zelfs jou zelf gemaakte binary word geoptimaliseerd. Ergens kan me dus voorstellen dat dit impact heeft op applicaties die expres inefficiënte stukjes hebben om in dit geval de ruwe performance te monitoren.

Daarentegen kan je in theorie je benchmark zo schrijven dat de impact minimaal is. Maar als je hele suite uit dit soort concepten bestaat heb je niet zo 123 iets anders verzonnen

[Zoijar]

Dat dacht ik ook, dat het hardware-based profile guided optimization was, wat je normaal op compiler niveau doet, maar nu dus post-compile op binary niveau kan doen. Dwz, je draait je binary een tijdje onder hw-pgo, dan houdt hij statistieken bij van welke cache en branch misses ed. je hebt in welke stukken code, en de volgende normale run primed hij je branch predictors en pre-fetchers op dat patroon voor meer efficientie.

Maar misschien begrijp ik het verkeerd.

[Sinester]

Dat is dus niet zo. Tenminste als ik het goed begrijp kijkt intel maar de machine code en doet op dat niveau optimalisaties. Dus ja, zelfs jou zelf gemaakte binary word geoptimaliseerd.

Volgens mij klopt dit maar half.

Ja het kijkt naar machine code en optimaliseerd dit, maar nee het gaat zeker niet werken op jouw zelf gemaakte Binary aangezien het op dit moment alleen ondersteund wordt door Applicaties die Intel aangemerkt heeft als supported

[dmantione]

Dat klopt niet, je moet een programma uit het lijstje van Intel hebben hiervoor, dus nee, het is helemaal niet generiek. Ik denk dat je dit beter kan vergelijken met de trend van een aantal jaar geleden waarbij videodrivers waar voor een aantal spellen handmatig geoptimaliseerde shaders hadden.

[Xfade]

Het gaat toch niet over hoe geekbench geschreven is, de intel bot is een applicatie voor specifieke cpu's. en geekbench kan dus niet zien dat de instellingen daar in aan of uit staan en dus de performance die Geekbench kan meten erg laat varieren.

Dat geekbench deze instellingen niet kan zien, zouden ze kunnen fixen met hulp van intel.

Het is eerder alsof je een nr1 3Dmark score upload, maar dat jou clocks hetzelfde lijken als de nummer 100 in de lijst.

[NEO256]

Ik ben het met je eens.

In een reactie hierboven beschrijf ik het met diesesl gate voorbeeld;

De auto doet het beter, dan wat hij op papier zou moeten halen door de sjoemelen met variabelen waar je niet aan hoort te zitten.

[Stiello]

Oke.. we hebben een fiets getest met trapondersteuning, maar we weten niet hoe hard hij gaat zonder die ondersteuning. Daarom verklaren wij de test onbetrouwbaar, omdat we niet weten of de trapondersteuning altijd betrouwbaar is.

Fair enough.

[wiseger]

We hebben de uitstoot van de diesel auto getest op de rollerbank. Nauwelijks uitstoot, wat een geweldige dieselmotor.

Oops, de software van de auto paste in deze omstandigheden het gedrag van de motor aan. In de echte wereld is de motor helemaal niet schoon maar behoorlijk vervuilend.

Als het gedrag van een CPU tijdens een benchmark test veranderd door optimalisatie software, dan weet je niet of de benchmark nog een realistische weergave is van het gebruik in normale omstandigheden. Dat is waar het probleem zit.

[freeco]

Mijn eerste idee was: "Wat is het probleem? Dit is een optimalisatie, geen cheat".

Maar je hebt wel een punt: de optimalisatie is specifiek gericht op een benchmarktool, niet op een realworld applicatie.

Wat mij betreft is iBOT sowieso nog te beperkt. Ik draai geen Geekbench, of de dozijn games die het nu kan optimaliseren. Terwijl het wel een interessant idee is, heeft het geen added value voor 99% van de gebruikers. Toch nog niet.

[Stiello]

Er is alleen een nuance, de software die in het diesel geval gebruikt werd was specifiek voor die test gemaakt om een betere score te halen. In theorie kan iBOT (waarschijnlijk) veel software versnellen en dus ook echt betere resultaten neerzetten. Vandaar dat ik de vergelijking met de fiets (cpu) en trapondersteuning (iBOT) maakte.

Mochten ze iBOT altijd en overal betrouwbaar kunnen inzetten veranderd dat wel de zaak. Het is een optimalisatie van de cpu taken waardoor een cpu met iBOT dus sneller is dan een zonder. Net zoals een slimme robot stofzuiger die de kortste route neemt sneller is dan een domme, ook al rijden ze even snel en zuigen ze even hard.

[NEO256]

Exact DIT!

Dat is ook het eerste waar ik aan moest denken, diesel gate.

Maar terug naar je voorbeeld Stiello:

Oke.. we hebben een fiets getest met trapondersteuning, maar we weten niet hoe hard hij gaat zonder die ondersteuning. Daarom verklaren wij de test onbetrouwbaar, omdat we niet weten of de trapondersteuning altijd betrouwbaar is.

Je MIST HET PUNT!

In jou voorbeeld zou het moeten zijn:

We hebben een fiets die heeft trapondersteuning, maar we weten niet hoe hard hij gaat zonder die ondersteuning want we kunnen niet zien of hij aan of uit staat. Daarom verklaren wij de test onbetrouwbaar, omdat we niet weten of de trapondersteuning altijd betrouwbaar is en belangrijker nog; we de resultaten niet valideren met andere fietsen die deze optimalisatie niet hebben en onder welke omstandigheden deze optimalisatie wel of niet werkt. Zelfs als de fiets, hetzelfde is in: gewicht, wiel diameter, banden type, accu vermogen, maximaal vermogen van de trap ondersteuning.

In je trap ondersteuning voorbeeld; we kunnen niet uitsluiten dat het stopt met werken zodra het te warm of koud is, als de luchdruk met 15 millibar valt binnen een uur, als we over een hobbelig pat rijden, als je 10 kg meer op het zadel zet dan waar het voor getest is.

WANT al die variabelen worden NIET gedeeld. DAT is het probleem.

We vertrouwen de benchmark niet, want deze SYNTHETISCHE benchmarks, die alleen onder de meeste ideale omstandigheden proberen zo veel mogelijk dezelfde berekeningen / opdrachten uit te voeren, zodat je een idee hebt HOE SNEL een CPU kan presteren, WANT Intel doet IETS wat ze niet 100% transparant uitleggen, aan EXECUTION code wat in sommige gevallen wel of niet positief is voor prestaties en we niet weten WAT HET NOG MEER DOET buiten sneller draaien op deze CPU.

HEL, wel kunnen NIET EENS een AB test uitvoeren op hetzelfde processor, om te valideren of execution onder omstandigheden bit voor bit hetzelfde is.

Dus in je fiets voorbeeld; we kunnen niet eens garanderen dat als je normaal instaat bent om 2 uur te fietsen met wind stil zonder ondersteuning, kan het nu 3 uur of veel minder zijn, want we kunnen niet zien of de trap ondersteuning wel aan staat EN belangrijker WAT HIJ DOET. De fabrikant zegt "we optimaliseren hoe jij fietst" dus passen iets aan over de manier hoe jij trapt, nadat jij al de trapper naar beneden gedrukt hebt, maar zeggen je niet of we dat op dit moment doen, waarom we het nu op deze manier doen, of het resultaat hetzelfde is, zoals bijvoorbeeld:

100 Newton aan rotatie in resulteerd in 15km/h in de 3e versnelling,
want dat ligt dan in dit voorbeeld aan alle onbekende omgevings variabelen en wat die optimalisatie doet.

Bonus, wat dus anders is als een instructie set, wat als volgt werkt in je trap ondersteuning voorbeeld:
"Vanaf 8 graden omgevingstemperatuur en lager moet de accu op temperatuur gehouden worden om beter te presteren, de opgebruikte energie aan verwarmen, zorgt netto voor meer kilo watt uur die je uit de accu kunt trekken, tenopzichte van niet verwarmen. Dit verschil kun je meten want: model A met 55 kwh accu, heeft die modus niet, ten opzichte van model B, ook met 55 kwh en produceert 5000 rotaties met een weerstand van 100 netwon tot de accu leeg is.
Dus als fietsen gaan testen, MET deze functie en dezelfde accu vermogen, dan doen deze EXACT hetzelfde als de accu verwarming uit staat.
Maar scoort 20% beter bij 0 graden, 30% beter bij -5 graden etc, als de accu verwarming aan staat, ten opzichte van de controle groep."

Om een kort verhaal lang te maken;
Het is belangrijk, om appels met appels te kunen vergelijken, maar Intel stopt soms suiker in de hap appel die je in je mond stopt en jij kunt als normale sterveling of zelfs als techneut niet zien wanneer deze suiker is toegevoegd en hoeveel beter die hap appel nu smaakt en opzichte van iets anders, want ze zeggen niet wanneer ze het doen, wat testen onmogelijk maakt.

[Reactie gewijzigd door NEO256 op 25 maart 2026 13:04]

[Mars Warrior]

Ik snap het probleem van Geekbench wel, want als zij bepaalde zaken op de CPU testen om vergelijkbare resultaten te krijgen over CPU's heen, dan kan deze optimalisatie de test dus als het ware "kortsluiten", waardoor je de vergelijking niet meer kunt maken.

Er wordt immers andere binaire code gedraaid op de CPU.

Als Geekbench specifieke versies voor AMD en Intel zou uitbrengen kun je die onderling ook niet mee vergelijken omdat je verschillende programma's aan het testen bent...

[dmantione]

Bedenk ook dat als je optimaliseert, je je het eerst richt op benchmarks, want dat is waar kopers naar kijken. Het risico is dat wél de benchmarks versneld worden, maar echte software veel minder. In dat geval wordt de benchmark misleidend.

[Kepslok]

Mede daarom dat goede reviewers ook vele real world benchmarks uitvoeren. Denk aan benchmarks als video encoding, compression/decompression, rendering, code compilation etc.

[Pietopdeheuvel]

Heel eerlijk, Benchmarks, Schmenschmarks. Uiteindelijk gaat het er niet om hoe snel een cpu een synthetische benchmark verwerkt, maar hoe snel de totale computer is in jouw use case. Heel leuk als een CPU bv een fantastische Multicore score heeft maar wanneer applicatie X niet in staat is om al die cores te gebruiken heb je er niets aan. Staar je niet blind op synthetische benchmarks, het is hooguit, als het dat al is, indicatief

Waar schaf je je computer voor aan, gaming, video editing, Grote tot hele grote LLM AI modellen lokaal draaien? Focus daarop, en maak een geïnformeerde keuze.

[SambalSamurai]

Een oprechte vraag van een leek:

Is er ook een nadeel voor het gebruiken van Intel Binary Optimization Technology?
In welke omstandigheden of scenarios is het raadzaam om iBOT uit te schakelen, en uit te laten staan?
Wordt de betrouwbaarheid of de integriteit van de originele software verlaagd door iBOT?

[dmantione]

In bepaalde randgevallen zouden problemen kunnen ontstaan. Bijvoorbeeld bij floating point geldt dat (a+b)+c<>a+(b+c). Afhankelijk waarvan de volgorde van de optelling wordt uitgevoerd kan een kleine afrondfout ontstaan. En je zou kunnen zeggen dat goede software daarmee om moet kunnen gaan, maar strict gesproken produceert het programma een ander resultaat. Fouten schuilen bij software altijd in een klein hoekje.

Je wilt iBOT uitschakelen in situaties waarbij een programma exact de instructies moet uitvoeren zoals ze gegeven zijn. In het merendeel van de gevallen zal het redelijk onschadelijk zijn.

[Reactie gewijzigd door dmantione op 25 maart 2026 13:11]

[latka]

Is er een lijst van zaken die ibot optimaliseert want de order of execution aanpassen is redelijk tricky. De layout van de instructies aanpassen (zoals in het tweakers artikel gedaan werd met cold/hot path ) is veel minder risicovol. Ik mag hopen dat ibot alleen veilige transformaties doorvoert.

[Omega]

Lastig, al neig ik te zeggen dat deze software in hetzelfde hoekje valt als compiler optimalisaties. Software bouwen om optioneel gebruik te maken van hardware features, of om deze te optimaliseren is voor specifieke hardware is veelvoorkomend.

In de Linux-wereld is het bijvoorbeeld niet ongewoon om binaries te draaien die specifiek voor jouw hardware zijn gebouwd en dus niet werken op andere hardware die niet dezelfde features ondersteunen. In sommige gevallen kunnen mensen hier een gigantische prestatiewinst mee behalen.

[Stijnvi]

Als ik het goed begrijp is het probleem dus dat IBOT de uitvoering van de code optimaliseert, maar dat dit niet in ieder programma even goed werkt, en het daarom dus niet representatief is? Het is dus niet een soort dieselgate waarbij dit specifiek is gedaan om te knoeien met de benchmark, maar om het in autotermen te houden is het meer een soort van functie die alleen werkt op A-wegen en niet op N-wegen, en omdat deze test op een A-weg wordt gereden is deze dus niet representatief voor de prestaties op een N-weg?