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 (76)

[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.

[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]

[supersnathan94]

Daarom hebben we bij GPU vergelijkingen (zeker bij Tweakers) dan ook dat we per driverversie vergelijken. Even ter info: De GPU benchmarks worden iedere keer opnieuw gedaan met specifieke drivers om ze zo dus ook vergelijkbaar te kunnen maken. Bij reviews zul je dus mogelijk best grote verschillen zien in de grafieken als je 1 kaart over verschillende reviews vergelijkt, puur omdat de kaarten per review tegen elkaar af worden gezet en opnieuw worden gemeten met een 1-op-1 vergelijkbare setup.

Want inderdaad. De ene versie is de andere niet. Je ziet soms gigantische wisselingen van de wacht als het gaat om optimalisaties. Dus verschillende driverversies vergelijken is inderdaad niet goed.

Het probleem is dat men mogelijk een expres zo bedacht, complex probleem wegoptimaliseert en de uitkomst op een andere manier “vind”. Stel je gaat prime95 gebruiken als benchmark. Het zou prima mogelijk kunnen zijn dat een tool dan herkent dat je prime berekeningen doet en gewoon de gehele reeks op het internet opzoekt.

Keurig netjes de gehele reeks “berekent” tot op de zoveelste in een tijd dat een gemiddelde supercomputer nog gaat blozen. Dan is in 1 klap je vergelijking nutteloos.

Het probleem is niet eens zozeer dat het gebeurd, het probleem is dat het onzichtbaar en ondetecteerbaar is.

[Werelds]

Maar dat is het nu juist. Dit zou een driver moeten zijn, waarbij dat detecteerbaar is en de versie uit te lezen is. Als een driver dan iets zou doen dat de resultaten flink wijzigt kunnen zij die resultaten apart groeperen, uit hun gemiddeldes gooien, enzovoort.

Quack3.exe. Just sayin'

[!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.

[kdekker]

Ik denk dat je al moet stellen dat 1 applicatie op 1 CPU met 1 meting sowieso niet representatief genoemd kan worden.

Verder is het technisch best mogelijk om een prorgamma te hebben dat 'aha, ik draai op processor xyz' even een andere DLL te laden en daardoor van optimalisaties van die CPU te gebruiken. Daardoor gaan de prestaties van het programma er op voorruit. Het verschil is dan dat het geen individuele (iBOT) tweak is, maar de leverancier met zijn software op processor xyz betere prestaties neerzet dan anderen. Maar ook daar geldt mijn voorgaande opmerking: N=1 (of dat nu 1 gebruiker, of 1 game is) is niet representatief.

Je hebt wel een punt dat prestatiescores op GeekBench (GB betekent echt wat anders) wat meer context behoeven of 'minder waard' worden, omdat die context er niet is. Al denk ik dat bij 4% winst dat wel meevalt. En ik moet me sterk vergissen, op basis van ervaringen in het verleden (zie ook mijn reactie bij het iBOT artikel: kdekker in 'Intel Binary Optimization Technology: 'Dit wordt een gamechanger voor cpu's'') dat er over de hele linie 40% haalbaar is. Het Tweakers artikel hierboven spreekt al van 'uitschieters', dus laat dat dan eens 10% over de hele linie worden. Hoe erg is dan de ruis bij GeekBench? Ik denk dat het allemaal wel meevalt en dat de reactie van GeekBench meer een WC-eend reactie is.

[Werelds]

Ik denk dat je al moet stellen dat 1 applicatie op 1 CPU met 1 meting sowieso niet representatief genoemd kan worden.

Met iBOT krijg je dat 1 applicatie op duizenden (zoniet meer) exemplaren van hetzelfde model CPU breed variëert. Volgens de beschikbare data allemaal hetzelfde (kloksnelheden, chipset driver versies, enzovoort), maar dat ene vinkje maakt specifiek GB 8% (geen 4%) sneller. Dat is significant genoeg om ze niet mee te nemen in statistieken

Verder is het technisch best mogelijk om een prorgamma te hebben dat 'aha, ik draai op processor xyz' even een andere DLL te laden en daardoor van optimalisaties van die CPU te gebruiken. Daardoor gaan de prestaties van het programma er op voorruit. Het verschil is dan dat het geen individuele (iBOT) tweak is, maar de leverancier met zijn software op processor xyz betere prestaties neerzet dan anderen. Maar ook daar geldt mijn voorgaande opmerking: N=1 (of dat nu 1 gebruiker, of 1 game is) is niet representatief.

Verschil is dat dan van toepassing is op _alle_ gebruikers van die CPU, niet enkel op diegenen die dit vinkje vinden en aan zetten.


Los daarvan is het optimaliseren van een benchmark zoals dit overigens wel heel erg twijfelachtig...nogmaals, quack3.exe

[Rudie_V]

Ja maar je zou het ook om kunnen draaien dat GeekBench niet helemaal correct is, omdat die de benchmarks niet optimaliseert voor een core-architectuur en dus niet het hele potentieel laat zien. Hun software zou alsnog een bepaalde processor een onbedoeld voordeeltje kunnen geven.

Met iBOT wordt de uitvoer van code wel aangepast op een core-architectuur en laat het meer het ware potentieel zien. Hoe je het ook bekijkt, het blijven hoe dan ook synthetische benchmark cijfertjes in dit geval.

Ik snap ook wel dat je software niet voor elke core-architectuur kan optimaliseren en dat je benchmarkt met een generieke compilatie van je software in plaats van met bepaalde optimalisaties voor een specifieke core-architectuur.

Maar deze tool laat wel zien dat er nog winsten zijn te halen met een tool als iBOT. Misschien moet een AMD ook maar zoiets uitbrengen en kunnen we zien hoe dan de verhoudingen zijn.

[Hans1990]

Ja, geekbench vermeld welke instructie sets de host tot z'n beschikking had. Dat is geen waarschuwing, meer een verklaring.

Stel je slingert ffmpeg of handbrake CLI aan, dan zie je dat die rapporteert welk SIMD pad er is geselecteerd. Dat kan een variant van SSE of AVX zijn. Maar stel je draait deze tool in een VM maar stelt de virtual CPU als een PentiumIII in (misschien om l33t/fake neofetch screenshots te maken van een PentiumIII op 5GHz). Die architectuur instelling kan zomaar veel applicaties ontzettend traag maken, omdat ze dan geen moderne AVX codepaden meer mogen kiezen.

Echter hier is het potentiele probleem dat niet meer dezelfde instruction stream wordt gedraaid. Zo'n binary optimization tool heeft primair als doel wellicht om code te herordenen zodat de cache beter wordt gebruikt. Maar het zou ook instructies kunnen herordenenen zodat er beter rekening wordt gehouden met zaken als latency en throughput van de specifieke architectuur. Normaliter hoeft dit niet heel veel uit te maken, omdat moderne C compilers dit ook doen, hoewel ontwikkelaars wel rekening moeten houden met de grootst algemene deler (dus: Intel vs AMD, maar ook compatibel met Zen 1 t/m Zen 5). Zo'n binary optimization tool weet op welke chip het draait, en dus kan hier nog enkele % winst halen, als dat het al is...

Maar benchmarks zijn hier wat bijzonder in, omdat die bewust suboptimale code kunnen draaien om e.e.a te stresstesten. Ga bvb eens kijken welke instructies nou echt bijzonder veel sneller zijn geworden door de jaren heen: https://www.agner.org/optimize/instruction_tables.pdf

Het antwoord: beperkt! Na de GHz race wordt hier wel flink meer aan gesleutelt, maar soms minder vooruitgang dan je denkt. Bvb als ik "ADD" vergelijk tussen Zen 1 en Zen 5, dan is de throughput van 0.25 cycle (4 resultaten per kloktik) naar 0.18 (~5,5) gegaan. Echter een instructie zoals FADD (floating point add) is zelfs trager(!!) geworden. Dat verklaard dus totaal niet waarom een 9950X ruim 2x zo snel loopt als een 1800X in (sommige) single core benchmarks. Deels is dat kloksnelheid, deels betere architecturen, maar ook deels beterer SIMD engines.. want SIMD is waar moderne programma's vaak nog veel winst kunnen halen.

Soms kan een processor ook on-the-fly e.e.a optimaliseren. "MOV" instructies zijn tegenwoordig namelijk gratis. Processors gebruiken namelijk iets dat heet register renaming. Met die techniek kan 1 registernaam meerdere waardes tegelijk bevatten. Dit is ook noodzakelijk: er worden meerdere instructies tegelijk worden uitgevoerd, speculatief en ook nog out-of-order. En dat tot honderden tegelijk, terwijl x86 maar ~10 registers kent. Het is een soort soort stoelendans die nooit stopt, maar wel telkens spelers afvallen en tegelijk weer nieuwe bijkomen.. (wellicht wat vage analogie )

Maar wat als zo'n binary optimization tool deze stappen deels kan overnemen? Die kan immers veel verder vooruit en terugkijken. Het zou letterlijk hele stukken code als "zinloos" bestempelen omdat zo'n benchmark deze bewust opschrijft om de worst-case prestaties te testen (bijvoorbeeld de latency of throughput). Dan hoeft de hardware opeens een stuk minder hard te werken. Het kan ook tellen hoevaak een if-else afslag wordt genomen, en deze zo ordenen dat die beter met cache of branch predictor omgaat, enzovoort.

Echter in het uiterste geval kan je dan net zo goed Score=Infinity aanwijzen en het programma verlaten. Een benchmarkt rekent zelden iets "unieks" uit, omdat het juist fijn is als een resultaat geverifieerd kan worden om te checken of je processor niet onstabiel draait...

[Reactie gewijzigd door Hans1990 op 25 maart 2026 19:07]

[Xfade]

waarom zou dit moeten ?

[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]

[NEO256]

Om dmantione zijn voorbeeld verder ondersteunen wil ik de volgende voorbeelden aanhalen.

Ze zijn beide niet 1 op 1, maar ik hoop SambalSamurai dat je je kritsch denken hier op los kunt laten om te begrijp wat ik probeer te zeggen.

Casus A: branch prediction problemen.

Voorbeelden:

• Spectre v2: Branch Target Injection
• Branche History Injection
• Spectre-v1: Bounds Check Bypass
• Branch Privilege Injection
• Straight-Line Speculation
• Return Stack Buffer

Uitleg

Branche prediction zorgt er voor dat als je meerdere processor kernen in je computer hebt zitten, dat stukken zinnig werk, je tasks en byte executie code dusdanig worden gevoerd aan de kernen zodat ze optimaal worden uitgevoerd. Die CPU's staan niet tussen door niets te doen wachtend op een opdracht, je taak is sneller af, want alle code is sneller uitgevoerd, een core met toegang tot level 1 cache die de juiste informatie al heeft, kan de code significant sneller uitvoeren want die hoeft die cache niet in te laden of op te bouwen.

Probleem stelling

Deze voorbeelden zijn klinisch en gaan er vanuit dat elke taak, byte code en persoon die de code uitvoert te vertrouwen is. In de werkelijkheid heb je te maken met; rechten welke stukke code aangeraakt mogen worden door welke thread / taak en welke informatie er uitgewisseld moet worden.

Praktijk

Programma A kan data uit programma B uitlezen of aanpassen ondanks dat: ze soms op een ander OS draaien en er dus geen enkele koppeling zou moeten zijn tussen applicatie A en B, maar in dit geval is dat ze dus op dezelfde hardware draaien. Dezelfde bare metal server, draait ergens in de miljoenen processen ergens een stuk code, die kwaadwillig is, wat je niet zomaar kunt detecteren, want simultanious multithreading (SMT) met branch prediction wordt door zowel AMD als Intel gebruikt (zij noemen het hyper threading).

Conclusie

De materie, de logicie die wordt uitegevoerd is ZO onzettend complex, er promoveren mensen op het maken van deze logicia en het vinden van problemen in deze logica. Het is een essentieel onderdeel van performance verbeteringen, maar bewijst keer op keer dat het een enorm security risk is.

Daarom gaan er stemmen op om hyper threading / Simultaneous Multithreading anders aan te gaan pakken. Inplaats van proberen zoveel mogelijk dozen in dezelfde vrachtwagens te proppen met de kans dat pakketjes beschadigd raken en in elkaar lekken. Zijn ze onderandere aan het kijken om het gewoon uit te zetten en gewoon meer cores tegen het probleem aan te gooien. Niet iedereen gebruikt 4 of 8 cores, MAAR als je SMT uit zet en het aantal cores verdubbelt, krijg je soms selfs betere resultaten ZONDER security risks.


Casus B: AV512

In de media:

• https://shihab-shahriar.github.io//blog/2026/AVX-512-First-Impressions-on-Performance-and-Programmability/
• https://lemire.me/blog/2018/08/15/the-dangers-of-avx-512-throttling-a-3-impact/
• https://www.tomshardware.com/pc-components/cpus/ryzen-9000-cpus-drop-10-frequency-executing-avx-512-instructions-intel-cpus-typically-suffer-from-more-substantial-clock-speed-drops

Introductie

In bepaalde (cryptografische) en AI workloads is het gewenst om grote complexe berekeningen te kunnen doen met een instructie set. Intel is hier onderandere AV512 voor gemaakt, wat 512 bit registers ondersteund met acht stuks 64 bit maskers. Kortom het is op papier een win win.

Probleemstelling

Performance degradatie van Intel CPU's waar deze op werd toegepast. JA, de instructie set werkt en zorgt voor een versnelling MAAR zorgt in de oudere CPU modellen voor een enorme drop in performance van de rest van de processor wat er in de praktijk voor zorgt dat elke keer als er zo'n berekening voorbij komt, het hele systeem een x tijd gemeten in seconden op zijn knieeen gaat en maar een fractie van de uitvoer snelheid haalt

Moderne CPU's van Intel en AMD gebruiken het en werken nu voorspelbaarder, sneller en beter. Die hebben deze problemen niet meer.

Conclusie

Zelfs een goed idee, met een prima inhoudelijke technische uitvoering is niet goed genoeg getest en onbewezen in allerlei consumenten / desktop computers gestopt, waardoor mensen bedrogen uitkwamen met hoe goed hun Intel processor werkt en presteerd in de praktijk. Veel mensen hebben de AV512 uitgezet en dat loste het op, maar dit is wel zuur voor de personen die het wel serieus willen gebruiken, want elke keer als het aangeraakt wordt wordt hun computer traag tot ie klaar is met de instructie set.


Ik kan door blijven gaan, maar wat ik met deze 2 voorbeelden wil onderstrepen is;

Bedrijven komen elke keer met nieuwe technieken, foefjes, buzwords, nieuwe technologieen.

Zelfs als de techniek goed is, wil het niet zeggen of het al rijp is voor gebruik, goed is voor jou of dat het de nadelen waard zijn.


Dus om je orginele vraag te beantwoorden;

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?

Dat weten we niet, want Intel is niet transparant over hoe dit werkt, of het aan staat en wat het doet.

En daar ligt het probleem.

Ze kunnen van alles claimen, maar ik kan zo nog stapels aan voorbeelden noemen, waarop wordt beloofd, door AMD, Intel, Nvidia, etc, dat iets beter gaat werken, maar dat in de praktijk de problemen zo groot zijn dat je het beter niet had kunnen doen.

[Reactie gewijzigd door NEO256 op 25 maart 2026 14:03]

[SambalSamurai]

Steek je hand omhoog als je - net als ik - de uitleg van NEO256 in één adem hebt gelezen!

Dank voor dit zeer verhelderende antwoord NEO256.
Ineens begrijp ik waarom ik gevoelsmatig hyperthreading al jaren uit heb staan.
Helemaal niet zo gek idee dus dat Intel wedt op méér cores, zonder hyperthreading.

Ik denk dat ik persoonlijk ibot hype train over sla.
De native (non-ibot) software bevat al voldoende bugs, gaten en onvolkomenheden.
Kwaliteit boven snelheid en voor mij.

[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.

[MSalters]

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.

Nee! IEEE754 is daar duidelijk over. Goede software mag 100% vertrouwen op verschillende resultaten, en er zijn algoritmes die alleen maar werken als een CPU de regels correct implementeert.

Het gaat dan vooral over algoritmes die zo slim zijn opgezet dat afrondfouten elkaar cancellen. Als je daar 1 keer opeens anders afrond dan versterken die fouten elkaar juist.

[dmantione]

Ik begrijp je bericht niet helemaal. IEEE754 definieert in ieder geval wat het resultaat van een floating-point operatie moet zijn. Dus het resultaat van a+b is deterministisch en betrouwbaar. Als er een afrondfout in zit, dan is die onderdeel van de standaard.

Door IEE754 correct toe te passen krijg je dat a+(b+c) en (a+b)+c een ander antwoord op kunnen leveren. De meeste hogere programmeertalen garanderen de volgorde niet, compilers vinden het acceptabel om transformaties uit te voeren die wiskundig correct zijn. Een goed geschreven programma kan daarom met het verschil tussen a+(b+c) en (a+b)+c omgaan.

De realiteit is evenwel dat programma's niet perfect zijn.

[MSalters]

De meeste programmeertalen die IEEE754 claimen garanderen dus wel IEEE754 regels. En CPUs doen dat doorgaans ook.

Ja, genoeg C compilers hebben een "fastmath" setting die expliciet dit uitzet. Dat is dus omdat het zonder opties wél de norm is. En programma's vertrouwen daar dus terecht op.

Hobby taaltjes? Die hebben doorgaans geen optimizers met data flow analyse en zullen dus ook geen (opzettelijke) reordering doen.

[dmantione]

C garandeert de volgorde van evaluatie niet. Een individuele operatie is IEEE754-conform, maar de compiler is vrij in de volgorde van evaluatie. "fastmath" maakt de IEEE754 conformiteit op enkele punten wat minder streng, het heeft geen gevolgen voor de associtiviteit.

In Pascal zijn operatoren van gelijk niveau gegarandeerd links-associatief. In Pascal wordt a + b + c altijd uitgevoerd als (a + b) + c. Pascal is volgens mij één van de weinige talen die dit hard specificeert.

[MSalters]

In C is het optioneel maar een compiler die IEEE754 claimt en de macro definieert moet zich aan die regels houden. En ja, dat is inclusief volgorde.

[dmantione]

Nou, ik heb de standaard er even bij gezocht. Uit hoofdstuk 10:

A programming language standard specifies one or more rules for expression evaluation. A rule for
expression evaluation encompasses:

• The order of evaluation of operations.

Kortom, IEEE754 definieert geen volgorde, het laat het aan de programmeertaal over.

[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).

[Scriptkid]

ligt aan het antwoord, als het zelfde antwoord er uit komt is het dus sneller ,

als er geen of een fout antwoord uit komt is het dus een fail dus slechte optimalisatie,

Het gaat er in een benchmark om hoe snel jij iets kan doen als jij dat op een andere manier doet met het zelfde antwoordt dan ben jij dus sneller en verdien je die hogere score.

[MSalters]

Dat is dus al letterlijk 40 jaar bekend. En al 40 jaar weten professionele benchmark-bouwers dat je dus geen stupide dingen moet doen.

Het "probleem" is nog erger met compilers. Loop die niets doet? Het telt al jaren als een compilerbug wanneer je die onnodig laat zitten in de binary.

En ook een CPU kan tegenwoordig slimme dingen. Bij het omzetten van je x86 code naar uops zou die lege loop zomaar kunnen verdwijnen, want leeg.

[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.

[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.

[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.

[Seal64]

Maar misschien doet iBOT dat ook wel? Wie zegt dat het niet zo geoptimaliseerd is dat als er een benchmark gedraaid wordt, alle kanten eraf gelopen worden om maar een zo hoog mogelijke score weg te zetten?

[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.

[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]

[Stiello]

Duidelijk verhaal.

[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.

[Wolfos]

Niet alleen dat, de gekozen games zijn ook degenen die vaak in benchmarks gebruikt worden. Ik geloof absoluut de uitleg niet dat Shadow of the Tomb Raider nog zo vaak gespeeld word. Maar hij komt wel in benchmarksets voor.

[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.

[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.

[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.

[MSalters]

Dat is al dom sinds we branch predictors hebben, bijvoorbeeld de AMD K8 uit 2003. Die zou 1998 of 1999 van die loop branches goed voorspellen precies omdat ze identiek zijn.

[NEO256]

Daarom is het al een tijdje zo dat we niet meer heel erg op syntetische bernchmarken vertrouwen.

Het is maar een indicatie, en zelfs voor die benchmarkts hebben ze bepaalde randomisatie en andere mitigitaties erin zitten om op een betrouwebare aantoonbare manier tot een zinnig resultaat te komen.

Daarom zijn er tegenwoordig steeds meer benchmark suites die allerlei zinnig werk doen, wat zo groot is, zo afwisselend, zo veel omvattend dat je het niet kunt bevatten in een paar optimalisaties die alleen op die benchmarks werken.

En daar zit te kracht.

Het is niet alleen maar 1 benchmark programma om de tuin leiden. Als je ze "allemaal om de tuin leidt" dan is het geen vals spelen meer, dan werkt het gewoon. En hoe dichter een bencharmk zit tegen "echt gebruik", maar nog steeds consistente, voorspelbare resultaten geeft onder gemeten omstandigheden.

Dat is wat benchmarken de moeite waard maakt.

Verder heb je ook nog kruis werking. Als de syntetische scores X, Y en Z zijn voor bepaalde testen is het meestal zo dat je dat terug ziet in de "real world benchmarks" en dat die te voorspellen zijn.

Ofterwijl 1+1 is 2 en niet 4 omdat je iBOT aan had staan, wat dus nu aan het gebeuren is.
Je gaat met niet vertellen dat GeekBench het nu alleen doet, omdat ze "denken" dat het zorgt voor onduidelijke niet te valideren resultaten.

Waarschijnlijk lopen ze nu dus tegen bakken aan discrepanties aan, die ze moeten verantwoorden.
Want als GB andere cijfers geeft als verwacht, terwijl het product wel degelijk op een bepaalde manier werkt, dan zijn zij de zwarte piet.
Als blijkt dat iBOT dingen doet, die niet te voorspellen zijn of niet goed werkt, dan is het Intels probleem.

En dat wil GB proberen te voorkomen.

[Reactie gewijzigd door NEO256 op 25 maart 2026 14:40]

[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.

[bantoo]

Ja gefeliciteerd dat is al 30 jaar algemeen bekend, maar dit is niet wat hier gebeurd. BOT is APPLICATIE specifiek. Als ik zometeen een binary bouw krijg ik die perf winst dus niet.

[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.

[MSalters]

Correct maar het verschil is schaal. Je hebt maar een paar kB aan uop cache en een paar nanoseconde in je decoder pipeline. Dit kan een milliseconde de tijd nemen en de resultaten in RAM bewaren.

[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. een stuk van wat je hier stelt is niet correct.
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?

[Reactie gewijzigd door NEO256 op 25 maart 2026 14:35]

[MSalters]

De formulering van @GarBaGe is misschien ongelukkig, het voorbeeld is 100% relevant.

Elke moderne CPU kan een Int en Float operatie tegelijk uitvoeren (en vaak een handvol). Door instructies goed te schedulen houd je de Execution Units (EU) optimaal bezig. Een compiler die optimaliseert voor Zen 2 weet hoeveel EUs een Zen 2 heeft, welke EU wat kan, en hoe lang dat dan duurt.

En je Intel i7 is totaal anders. Daar komt deze technologie om de hoek kijken. Die kan dus code her-optimaliseren voor jouw CPU, ook al bestond die eerder niet.

[NEO256]

Sorry, maar jij mist ook het punt.

Er worden niet dezelfde berekeningen op een bepaalde manier in een andere volgorde uitgevoerd en/of verdeeld over processor kernen zoals wat SMT doet.

De berekening zelf, wordt op een andere manier uitgevoegd en er zijn nog geen wijdversprijde kennis van wat die iBOT nu daadwerkelijk doet. Dus in de komende dagen, weken, maanden en welicht jaren, gaan we te horen krijgen, of deze techniek in AB testen dezelfde resultaten geeft.

Ja FIJN dat je berekening sneller gaat ... maar waarom, onder welke omstandigheden.

En als ik benchmarks wil kunnen draaien, zodat ik dat kan bewijzen, dan moet ik dus weten of iBOT aan staat.

Waar ik me wel in kan vinden:

"Ik wil liever weten welke echte weredel scenario's beter worden uitgevoerd door deze techniek"

Maar daar horen voor mij de volgende dingen bij:

• Ik wil niet vertrouwen op de uitspraaak "dat het beter is", ik wil bewijz zien.
• Ik wil het uit kunnen zetten, want ik wil niet verast worden met de nadelen als in de toekomst problemen worden ondenkt.
• Intel heeft geen goed track record als het gaat over problemen aanwijzbaar veroorzaakt door hun producten en waar consumenten worden gedupeerd.

Benchmarks zijn een hoeksteen van computer vergelijkingen en iBOT is gewoon een probleem, kort en bondig. Als we niet kunnen zien of het aanstaat of niet en wat het doet, dan weten we het gewoon niet en is het net alsof je meer zuurstof aanmengt voor het de motor inloopt en dan raar staat te kijken dat in veel gevallen je motor beter presteerd, maar warmer wordt, sneller kapot gaat, niet goed werkt als de zuurstof toevoer niet op de juiste manier wordt geregeld en al en al gewoon een bak complexiteit toevoegd die in veel gevallen voor meer prestaties leiden, maar in de praktijk gewoon een issue vormen waar je niet op staat te wachten als gewone gebruiker, je wilt gewoon je PC kunnen gebruiken.

[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.

[FreezeXJ]

Dat is vrij lastig als ik de hardware nog niet heb, en vooraf probeer in te schatten of ik er een goede koop aan heb.

GeekBench voert een voorspelbare set instructies uit waarvan ik daarna kan proberen te bepalen hoe gelijk die is aan het programma dat ik wil gaan draaien. Als Intel met z'n fikken wel aan GB gaat zitten, maar niet aan mijn code, dan zijn de resultaten waardeloos. Als iBot wel een kunstje snapt van de benchmark, maar mijn software te complex is, dan is het resultaat ook nietszeggend. Ergo: het is geen benchmark meer, maar een demo-tooltje voor iBot.

[latka]

Een benchmark gebruiken om cpud onderling te vergelijken is al een beetje gokken. Dus ik zou eerder kijken naar real World resultaten.

[Reactie gewijzigd door latka op 25 maart 2026 18:29]

[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.

[smartsys]

Natuurlijk niet. Je hebt een vaste meetmethode om de snelheid of uitstoot van iets vast te stellen. Op het moment dat het testobject gaat detecteren dat het getest wordt en dan een ander gedrag dan het real-world gedrag laat zien ben je de boel bewust aan het manipuleren met het doel er "winst" uit te halen.

Even een sprongetje naar dieselgate wat Volkswagen een gazilion dollar heeft gekost. Hier hebben verschillende auto fabrikanten hun auto's de test laten detecteren en in een optimalisatie mode laten draaien. Het resultaat was dat je bijna de uitlaatgassen kon inademen zonder direct het loodje te leggen. Totdat je het keuringsstation uitreed en de uitstoot van troep een veelvoud werd.

Weer terug naar CPU's. Als een fabrikant van software bepaalde optimalisaties doorvoert alleen in benchmark software is dat met het doel om "beter" uit de test te komen. Aangezien je precies weet wat er getest wordt kun je heel gericht optimaliseren en komt jouw CPU misschien als véél sneller uit de test. Vervolgens verkoop je de "snelste" CPU aan miljoenen klanten wereldwijd en blijkt dat in de praktijk de goedkopere CPU van de concurrent toch sneller. Dan heb je dus je klanten genept en kun je waarschijnlijk hele grote rechtszaken gaan verwachten. Helemaal in landen als de USA ben je dan zo per CPU een bedrag kwijt waar je helemaal niet blij van wordt.

Lijk mij dat Intel hier heel veel risico mee loopt als het echt zo is. Als het optimaliseren met iBOT echt enorm voordeel oplevert in real-world toepassingen doordat een AI engine bijv. na analyse direct kan optimaliseren zou dat gewoon een hele slimme oplossing zijn en is het Intel gegund dat ze door slimmer te zijn ook sneller zijn.

[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.

[NEO256]

Super leuk Piet.

Alleen HOE MEET JE DAT!?

Hey Piet, ik zie allemaal goedkope dieseltjes staan op Marktplaats, echt spot goedkoop, de meeste van Volkswagen groep. Kun je me misschien uitleggen waarom deze super betrouwbare auto's zonder zichtbare schade met soms weinig km's nu geen donder mee waard zijn?

Nou Piet, dat hoeft niet want dat kan ik je vertellen.

De TESTEN die wij onderandere met de EUROPESE UNIE hebben samen gesteld, zijn verkloot door Volkswagen door dat ze hebben vals gespeeld op de testen die we hebben ontwikkeld.

Met jou logica, moeten we niet testen, je moet gewoon die auto's gaan rijden en zelf gaan bepalen of het voor jou werkt.

Maar Piet, jonge, ik kan je NU al vertallen dat de normale Nederlander het niet intereseerd, dat je buurman met COPD en de generatie achter ons, die last hebben van die fijnstof die je uitstoot en CO2 die je de lucht in dwarrelt een probleem zijn, waar een normale sterveling geen ENE REET OM GEEFT!

Wij als gemeenschap willen beter dus zoeken we naar hoe dingen werken en hoe ze synthetisch EN onder alle omstandigheden beter zijn.

WAT heb ik aan een CPU dis SOMS beter presteerd, maar soms ook niet, EN wellicht niet eens DEZELFDE BERKENINGEN heeft uitgevoerd, want ... ze slaan dingen over of doen die berekeningen op een andere manier? Want god mag weten wat Intel doet met die optimalisaties.

Je hele argument is POEP, pure stront; als we niet kunnen meten wat iets doet, onder welke omstandigheden, waarom zouden we er dan nog een nummer op plakken? Waarom iets testen?

Intel is goed, koop Intel, noem je prijs, dan krijg je een doos, waarop staat CPU, die past wellicht wel of niet op je mobo, zoek lekker ff lekker zelf uit, doet het misschien wel of niet, draait misschien wel of niet Crysis en start hopelijk op...

Is dit de wereld waar je in wilt leven!?

Ben jij zo'n AI bro, die aan ChatGPT vraagt: "wat moet ik vandaag eten" en je 2 dagen laten wakker wordt op de IC, omdat sommige zouten giftig zijn, maar dat had je niet in de prompt verwerkt.
En dat vindt je acceptabel?

Disclaimer:
Dit schrijf ik wat te persoonlijk, ik ken je niet en voor anderen, ik ken Piet niet. En dit moet je ook niet lezen als een persoonlijke aanval, mijn excuses als het wel zo overkoomt, maar ik neem mijn woorden niet terug.

Wat ik wil is dit gedachte goed hard bestrijden, dit is waar de tech wereld aan kapot gaat. "we hebben hier iets nieuws en geweldigs, helemaal vol gestopt met buzwords waar je hopelijk warm van wordt", maar we leggen niet uit hoe het werkt, wat het doe, hoe het gebruikt kan en moet worden en welke voordelen het oplevert, maar we willen wel dat je het koopt en gebruikt. En misschien jaren later komen we er pas achter wat voor gevolgen dat het heeft.

Voorbeelden:

• De Cloud, SaaS
• Subscription models
• AI

En om dit verder te verduidelijken; Ik ben niet TEGEN deze technologien. Ik gebruik het zelf soms ook, MAAR ik bestijd dat ze ten allertijden beter zijn en ik ben tegen dis informatie, die geleid wordt doo emoties over DAT HET BETER IS OMDAT HET NIET NIEUW IS wat totale bullshit is.

Een 80 jaar oude auto kun je 100% ecologisch verantwoord en groen maken. Dan hoeft ie niet te worden gesloopt en hoef je geen energie te verspillen aan iets wat al gemaakt is.

De reden waarom dat we dat niet op grote schaal doen is veelvoudig, maar daar gaat het me niet om, het gaat me er om: dat er altijd een nuance is en dat cijfrts, metingen, onderzoek en introspectief denken, kritisch denken, belangrijk is en basis moet zijn van je beslisvorming.

De reden dat ik mijn tech nieuws van Tweakers.net haal die nuances toevoegen, zelf ook meten en kritisch nadenken over welke informatie wel en niet relevant is onderstrepen dat ook.

Anders krijg je shit als wat Trump nu doet.
We stoppen met bouwen van windmolens want olie is beter.

Dat terwijl ik gisteren nog een video aan het kijken wat dat Las Vegas en heel Nevada te weinig water heeft om ze meer water gebruiken dan ze kunnen winnen uit smelt en berg rivier water, want ze gebruiken meer dan er begroot is en belangrijker nog klimaat verandering zorgt voor grotere en ergere droogte problemen.

Maar die oranje sul zegt dat ze moeten gaan boren boren boren.
Want dat voelt goed.
En DAAR ligt het probleem.

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

[Applerol Sprits]

Volgens mij mis je het punt een beetje, en had je wat teveel koffie o

[NEO256]

Ik ga vooral veel te serieus in op platte en voor mijn gevoel oppervlakkige reacties op een complex probleem waar al een simpele, niet eens zo vreemde oplossing is gevonden door Geekbench.

Maar het wordt afgedaan als een groot probleem want "Intel" en Intel is goed.

Wordt er gewoon moe van.
Mensen die het laten lijken alsof Geekbench te boosdoener is, omdat ze naar mijn mening en een aantal met me, gekeken hebben naar een nieuwe techniek, die invloed heeft op hun deel gebied / brood en boter, een beslissing nemen die de consument beter informeren en nog steeds zijn ze de boosdoener... Kom op.

[Applerol Sprits]

Onzin, het gaat er gewoon om dat resultaten van een CPU in een synthetische benchmark niet zo heel veel zeggen. Of dat nu Intel of AMD, Apple Silicon of whatever is. Je haalt er alles en nog wat bij wat er helemaal niet toe doet.

[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?