'Antutu-benchmark bevoordeelt Intel-soc's ten opzichte van ARM-processors'

De Antutu-benchmark, die gebruikt is om een forse snelheidswinst voor Intel Clover Trail+-processors te claimen ten opzichte van ARM-soc's, zou oneerlijke optimalisaties bevatten voor Intel-cpu's. De gebruikte compilers spelen daarbij een belangrijke rol.

Exophase, een gebruiker op het Anandtech-forum, heeft de code van de Antutu-benchmark bekeken. Deze benchmarktool wordt veel gebruikt om de prestaties van mobiele socs te meten. Opvallend was dat de Intel Clover Trail+-processors bij de introductie begin dit jaar in benchmarks opvallend veel sneller zouden zijn dan de laatste ARM-socs die in smartphones en tablets zijn te vinden. Daarbij werd versie 3.3 van Antutu gebruikt.

Volgens Exophase is de x86-versie van de Antutu 3.3-benchmark gecompileerd met Intels C++ Compiler, terwijl de ARM-versie met GCC is gecompileerd. Terwijl de Intel-compiler gebruikmaakt van auto vectorizing, werden bij de ARM-compiler geen optimalisaties doorgevoerd via zogeheten Neon-instructies, terwijl deze extensies in de praktijk volop gebruikt worden om applicaties op ARM-socs te versnellen. De x86-versie zou bovendien een testloop die 32 maal gedraaid zou moeten worden, in Antutu slechts eenmaal hebben gedraaid. Deze 'optimalisatie' zou zeer onlangs aan Intels C++ Compiler zijn toegevoegd.

Hoewel Intel zelf de twijfelachtige snelheidswinsten ten opzichte van ARM-socs op basis van de Antutu-benchmark niet met de pers zou hebben gedeeld, zijn er diverse publicaties geweest die deze benchmarktool voor metingen hebben ingezet en daar conclusies aan verbonden. Inmiddels is er een nieuwe versie van Antutu uitgebracht. Daarin zouden de prestaties van Intel Clover Trail+-socs met 20 tot 50 procent zijn afgenomen ten opzichte van recente ARM-socs.

Reacties (41)

[Tmaster]

10 jaar geleden gebeurde precies hetzelfde met 3DMark tussen de rivalen ATI en Nvidia
Die 3DMark bleek toch niet zo heel betrouwbaar te zijn:

http://www.geek.com/games...test-3dmark-build-552713/

Er staat gewoon veel op het spel en bedrijven doen er blijkbaar alles aan om wereldwijd boven aan de lijsten te komen staan bij de diverse hardware en test/review sites.

Mensen vergelijken nu eenmaal veel en zo'n hogere scoren kan nu net de doorslag geven die tot een verkoop leidt.

Intel wil wel eens meer van dit soort 'gein' uit halen:
http://tech.slashdot.org/...ating-in-3dmark-benchmark

http://techreport.com/rev...ark-vantage-optimizations

[Reactie gewijzigd door Tmaster op 23 juli 2024 10:43]

[Verwijderd]

Het wordt mij hier niet duidelijk in hoeverre Intel hier uberhaupt iets mee te maken heeft.
Intel levert de x86, en de Intel compiler, maar ik heb nergens gelezen dat er een of andere link is tussen Intel en de makers van AnTuTu, behalve dan het feit dat deze makers blijkbaar een Intel x86 SoC gebruiken, en hun software met de Intel compiler bouwen, en daarbij bepaalde compiler-switches gebruiken die een stuk voordeliger uitpakken dan wat ze op ARM en gcc gebruiken.

Suggereren dat Intel hier iets mee te maken heeft, gaat wel veel verder dan dat (zoals gezegd, Intel heeft niet eens misbruik willen maken van de situatie door de AnTuTu getallen ter promotie te gebruiken).

Het 3DMark-verhaal is compleet anders, daar schrijft Intel zelf de drivers voor hun GPU, en die hebben blijkbaar een optimalisatieprofiel voor 3DMark Vantage (veel drivers hebben dergelijke profielen voor veel games, maar Futuremark staat dit bij hun benchmark niet toe).

[Reactie gewijzigd door Verwijderd op 23 juli 2024 10:43]

[Nactive]

Het gebruik maken van de Intel compiler is niet helemaal valspelen imo. Het is de bedoeling toch om de beste compiler voor die soc te gebruiken.

Natuurlijk als je de NEON niet activeert bij de GCC compiler ben je wel aan het valsspelen ...

Ik vind persoonlijk dat je Intel compiler vs ARM compiler (als die toch een compiler hebben) moet vergelijken. Al word in de praktijk zeer veel GCC gebruikt, dus dat geeft dan weer een realistischer beeld imo.

Benchmarks zijn dan ook nooit helemaal het beeld van de praktijk ...

[Reactie gewijzigd door Nactive op 23 juli 2024 10:43]

[Verwijderd]

Natuurlijk als je de NEON niet activeert bij de GCC compiler ben je wel aan het valsspelen ...

Dat heeft misschien ook deels te maken met de legacy.
Niet alle Android-toestellen met ARM-CPU hebben NEON, bijvoorbeeld.
Misschien dat daardoor oorspronkelijk ervoor gekozen is om geen NEON te gebruiken, zodat alle Android-toestellen dezelfde code draaien, en er 1:1 vergeleken kan worden.

Als je dan nu overstapt op het gebruik van NEON, zijn de resultaten dus niet meer vergelijkbaar met oudere versies van de benchmark (en draait de nieuwe versie uberhaupt niet meer op alle toestellen).

Bij Intel ligt het anders. Er zijn geen SoCs die geen SSE-extensies hebben, dus is er geen reden om het niet te gebruiken.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 10:43]

[Blokker_1999]

Het gebruik maken van de Intel compiler is niet helemaal valspelen imo. Het is de bedoeling toch om de beste compiler voor die soc te gebruiken.

Niet helemaal, in geval van benchmarks wil je net zoveel mogelijk gelijk houden. Wanneer je 1 compiler hebt voor al je target platformen, gebruik dan ook die ene compiler zodat je daar al geen verschil meer hebt.

[RSpliet]

Dit ligt er natuurlijk geheel aan wat je benchmarkt. Over het algemeen moet je inderdaad zo veel mogelijk variabelen gelijk laten. Echter verschillen x86 en ARMv7 zo veel van elkaar dat zelfs GCC-ARM en GCC-X86 niet eerlijk te vergelijken zijn.
De minst onjuiste procedure hier is denk ik om voor beide platforms alle beschikbare compilers te testen, en hier de beste uit te pikken om je binary mee te compilen. Zo vergelijk je bij volgende benchmarks de hardware in de veronderstelling dat je daar het maximale uit haalt (beste compiler). Ik denk dat je in dit geval inderdaad voor x86 bij Intels compiler uitkomt, en op GCC of ARMCC voor ARM.

Dit probleem is echter voor een groot deel veroorzaakt niet omdat verschillende compilers zijn gebruikt, maar omdat ze niet voor hetzelfde doel (hoogste performance) zijn geconfigureerd door de devs van AnTuTu.
Het verhaal dat Intel een loop niet 32 maal, maar slechts 1 maal uitvoerde kan het gevolg zijn van diepgaande optimalisatie, waarbij software heeft kunnen besluiten dan 32 iteraties niets zou veranderen aan de uiteindelijke uitkomst van de loop. Ik zou graag de loop eens bekijken om te zien of dit inderdaad het geval is.

[Squee]

Echter verschillen x86 en ARMv7 zo veel van elkaar dat zelfs GCC-ARM en GCC-X86 niet eerlijk te vergelijken zijn.
De minst onjuiste procedure hier is denk ik om voor beide platforms alle beschikbare compilers te testen, en hier de beste uit te pikken om je binary mee te compilen. Zo vergelijk je bij volgende benchmarks de hardware in de veronderstelling dat je daar het maximale uit haalt (beste compiler). Ik denk dat je in dit geval inderdaad voor x86 bij Intels compiler uitkomt, en op GCC of ARMCC voor ARM.

Het hangt er ook van af of je de compiler voor een platform ziet als onderdeel van het platform. Want de applicaties die uiteindelijk voor een platform geschreven worden moeten ook ergens mee gecompileerd worden. Als je dan een compiler hebt die beter voor jouw platform kan optimaliseren, dan maakt dat jouw platform wel 'beter', omdat de mogelijkheden van de hardware beter uitgebuit kunnen worden. Als je het onafhankelijk van de compiler wilt vergelijken en die niet van het platform wil laten afhangen, dan zou je misschien eerst naar LLVM moeten compileren en alleen op dat representatie niveau je optimalisaties uitvoeren.

Dit probleem is echter voor een groot deel veroorzaakt niet omdat verschillende compilers zijn gebruikt, maar omdat ze niet voor hetzelfde doel (hoogste performance) zijn geconfigureerd door de devs van AnTuTu.
Het verhaal dat Intel een loop niet 32 maal, maar slechts 1 maal uitvoerde kan het gevolg zijn van diepgaande optimalisatie, waarbij software heeft kunnen besluiten dan 32 iteraties niets zou veranderen aan de uiteindelijke uitkomst van de loop. Ik zou graag de loop eens bekijken om te zien of dit inderdaad het geval is.

Eigenlijk concludeerde ik daar uit dat de benchmark code gewoon slecht geschreven is. Als de bedoeling is in een benchmark dat een bepaald stuk 32x uitgevoerd wordt, dan zal je er ook zeker van moeten zijn dat dit gebeurd en dit moeten verifieeren door bijv. de assembly output van je compiler te inspecteren. Dit is ook enorm tricky aan het schrijven van benchmarks, ik ben daar zelf ook meerdere malen tegen aan gelopen. Het is een soort gevecht met de compiler; aan de ene kant wil je dat hij zo optimaal mogelijke code genereert voor het platform wat je wil testen, maar aan de andere kant moet je ook oppassen dat je nog wel weet wat je meet als een compiler veel aanpassingen in je code gaat maken. Zo kwam ik er ook een keer achter dat een FPU benchmark die ik voor x86 en SPARC geschreven had uiteindelijk 8 FPU operaties deed op de x86 en maar 6 op de SPARC omdat de Sun Compiler een stuk slimmer bleek te zijn dan ik dacht (Een loop iterator werd megegeven als het void* argument aan een pthread en dat had de Sun Compiler door waardoor hij de loop flink kon unrollen en daarna 2 van de 8 instructies er uit kon optimaliseren)

Benchmarks blijven altijd tricky. Zoals een collega van mij het al eens verwoorde; "Benchmarks zijn vooral goed in het meten hoe goed systemen benchmarks kunnen meten"

[.oisyn]

Daar heb je niets aan, zelfs met 1 compiler heb je sowieso te maken met 2 verschillende backends. Daarnaast is het nogal onzinnig om een compiler voor een platform te gebruiken puur omdat je voor een ander platform dezelfde compiler gebruikt, terwijl de rest van de wereld in de regel een compleet andere compiler gebruikt voor dat ene platform. Waar het uiteindelijk om gaat is dat je een enigszins representatieve benchmark hebt, en dus gebruik je de compiler die de rest ook gebruikt, met dezelfde optimalisatieinstellingen.

[Finraziel]

Het hangt er vanaf wat je wil testen. Mij lijkt het dat je vooral wil benaderen hoe de SoC in de praktijk zal presteren met verschillende apps. Als de intel compiler dan veel betere resultaten levert dan zullen devs die compiler ook sneller gebruiken en zou het geforceerd gebruiken van de gcc compiler voor de benchmark juist zorgen voor niet representatieve resultaten.

[catfish]

het lijkt mij het beste om voor beide platformen gewoon de beste compiler te gebruiken
nieuwe cpu's hebben immers vaak optimalisaties die enkel met een betere compiler worden gebruikt

je mag er toch van uit gaan dat programma's die veel resources vragen altijd met de beste compiler worden gemaakt (dat hoop ik dan toch)

[Wulfklaue]

Persoonlijk heb ik geen weet, van applicaties waar men enige optimalisaties toepast, dat men NEON niet gebruikt. Zowat iedere ontwikkelaar weet dat de snelheidswinsten vrij enorm oplopen.

Daarom is deze vergelijking zo krom als wat. Maar natuurlijk hield Intel hun mond dicht hierover, laat een ander maar de foute informatie verspreiden. Het is toch niet in hun nadeel.

Nu, moest men GCC gebruiken met NEON code, en intel C++ Compiler, geen SSE, ik denk dat je enorm snel een PR bericht zou krijgen hoe Intel klaagt dat dit niet representatief was. En hun media invloed is veel hoger, waardoor als zij klagen, veel meer mensen hun aandacht getrokken word, dan nu, als ARM klaagt over deze foute weergave.

Om eerlijk te zijn, dit doet me terugdenken aan de Intel vs AMD tijdperk ( toen ze nog met elkaar deftig concurreerde ), en hoe daar enorm veel gespeeld is ( vooral van Intel hun kant uit, AMD was ook niet onschuldig ), met de benchmarks, en misleidende informatie...

Het probleem met zo een zaken is, eenmaal dat zo een nummer oorlog begint, dat je als klant geen niets meer hebt om je op te focussen.

Update:

In praktijk gaat het zelf een stapje verder. Het feit dat de ICC in de laatste versie een optimalisatie heeft ( waarbij code vervangen word door hun 'optimalisatie' ), dat enkel maar nuttig voor deze specifieke benchmark, lijkt aan te geven, dat Intel duidelijk eropuit was om de resultaten te beïnvloeden.

[Reactie gewijzigd door Wulfklaue op 23 juli 2024 10:43]

[Janbraam]

Nog erger vind ik dat Intel een bedrijf is wat staat voor geslotenheid en winst.

Met winst bedoel ik dat zij eerder kiezen voor korte termijn oplossingen dan de lange termijn. Naar mijn idee is imago nl. belangrijk op de lange termijn, zo kan het voordelen hebben om niet geld vragen voor hun technologie en gewoon samenwerken.

Met geslotenheid bedoel ik dat zij (nogal) weinig doen aan documentatie bij hun drivers. Voor een bedrijf van deze grootte een vreemde zaak IMO.

Daarnaast spelen andere factoren, zoals de gigantische winsten die zij halen, daarmee kunnen zij invloed (en dus macht) uitoefenen om hun producten beter uit de verf te laten komen dan bijv. AMD of ARM. Interessante info: http://www.agner.org/optimize/blog/read.php?i=49#49

[TheekAzzaBreek]

Als je puur de prestaties van de hardware wil testen zou je altijd dezelfde compiler moeten gebruiken, anders test je deels de compiler, niet de hardware.

Als het gaat om de prestaties van applicaties is het natuurlijk een ander verhaal.

[Dirk_P_Broer]

Maar als die Intel-compiler, gebruikt bij het compileren van de benchmarktool, Intel processoren wèl gebruik laat maken van alle recente instructiesets, en CPUs van anderen daar geen gebruik van laat maken test je ook de hardware niet goed...

[Verwijderd]

Dat ligt niet aan Intel, maar aan de mensen die deze optie gebruiken voor het compileren van een benchmark. Je kunt de Intel-compiler namelijk ook gewoon 1 fixed codepath laten compileren, dat ie op alle processors draait, ipv via de dispatcher het meest optimale pad laten bepalen...
Wat uiteraard alleen voor Intel-CPUs is geimplementeerd, aangezien het de *Intel* compiler is. Intel weet niet welk pad het meest optimaal is voor andere CPUs, en moet daar ook de vingers niet aan willen branden. MEnsen die denken dat het zo simple is als checken of een CPU wel of niet feature X ondersteunt, moeten maar eens studeren op microarchitecturen, en dit eens lezen bv: http://scalibq.wordpress....ode-of-amd-fanboy-idiocy/
Ook voor Intel-CPUs gaat het niet altijd op dat bv een MMX-routine sneller is dan een vanilla x86-routine. Code die op bv een Core2 Duo sneller is, kan op een Pentium 4 trager zijn.

[arnoud_h]

Je wilt toch het hele eco-systeem testen, en niet alleen de CPU/SoC?

Daarom vind ik het ook zo vreemd dat Windows benchmarks op een MacBook Pro worden losgelaten.

Natuurlijk grappig dat de MacBook Pro een tijd lang de snelste Windows notebook was, maar voor de gebruiker van Mac OS X totaal zinloze informatie.

[Dreamvoid]

Maar wel degelijk interessant als je veel Windows op je MBP gaat draaien.

[Brazos]

Als je puur de prestaties wilt testen kun je synthetische benchmarks beter helemaal achterwege gaan laten en gaan testen met alledaagse taken. Want dat is waar het uiteindelijk om draait, niet theoretische snelheden, maar de snelheden in de praktijk.

[Reactie gewijzigd door Brazos op 23 juli 2024 10:43]

[Verwijderd]

Dat is het voordeel als iedereen in de code kan meekijken, zulke dingen komen dan naar voren. Aangezien Intel met de resultaten van de benchmark niets heeft gedaan verwacht ik dat zij zelf ook wisten dat deze resultaten niet representatief waren.

[kidde]

Dat is het voordeel als iedereen in de code kan meekijken,

Maar de broncode is gesloten (proprietary software), dus dat gaat juist NIET. Het is niet bekend wat de broncode van AnTuTu is, en ABI vertelt niet bepaald welke compilers / opties ze gebruikt hebben.

Hier is het probleem: De benchmark zegt "Reken pi uit in 20.000.000' decimalen en verder niets.
GCC voor ARM: Laat het uitrekenen op 20.000.000 decimalen.
ICC voor Intel: Zoekt uit of het resultaat gelezen wordt, maar het resultaat wordt nergens gebruikt, dus maakt de "OPTIMALISATIE" dat de gehele berekening over geslagen wordt.
De gegenereerde assembly heeft ABI kennelijk niet bekeken, dus ze trokken niet de juiste conclusie dat een ARM processor die iets berekent minder zuinig is dan een Intel processor die niks berekent. Doh!

Wat blijkt verder, ICC gebruikt veel meer 'funroll-all-loops (iets met Gentoo en Ricers, zoek maar na als je wil lachen)' dan GCC, hetgeen doorgaans grotere maar snellere code oplevert. En al het genoemde gevalletje met het niet gebruiken van vector-optimalisaties, omdat inderdaad oudere Tegra-meuk dit niet ondersteunt. Natuurlijk dikke nonsens als je de benchmark gaat draaien op een telefoon waar helemaal geen Tegra op zit.

Conclusie is dus vooral dat "gesloten" benchmarks onbetrouwbaar zijn, weet jij veel wat AnTuTu allemaal heeft lopen sjouwen - het is in gesloten software niet tot heel lastig te controleren. Verder dat het nuttig is goed te kijken naar wat er nu eigenlijk vergeleken wordt.

[Verwijderd]

"Conclusie is dus vooral dat "gesloten" benchmarks onbetrouwbaar zijn"

Dat is nogal een boute uitspraak. Ze zijn misschien te wantrouwen maar ze zonder meer als onbetrouwbaar bestempelen gaat me wat ver.

Voor een goeie vergelijking moet je ook meerdere benchmarks naast elkaar leggen zoals dat vaak bij testen gebeurt. Soc X gaat nu eenmaal anders met bepaalde code om dan Soc Y.

De door jouw omschreven "OPTIMALISATIE" problematiek is wat mij betreft simpelweg een implementatie fout. Opzet of niet.

[Verwijderd]

Klopt, de source is inderdaad niet open. Omdat in het artikel staat dat Exophase de code van de Antutu-benchmark heeft bekeken ging ik uit van de broncode. Op het forum van AnandTech staat wat hij precies heeft gedaan:

http://forums.anandtech.com/showthread.php?t=2330027

[Nas T]

Daarom dus (altijd) wachten op reallife benchmarks. Dan zijn dit soort dingen bijnan iet aan de order en sneller duidelijk.

[Avathar]

@nas T, ook bij real life benchmarks hangt het er van af hoe de software intern in elkaar zit.

[PuzzleSolver]

Klopt, ik herinner me ook nog iets met videokaarten die optimalisaties in de drivers aanzetten waardoor er minder mooi maar wel sneller gerendered werd.

Een goede benchmark zou optimalisaties voor elk platform moeten hebben om zo'n SOC volledig te benutten, maar dat is in de praktijk nogal lastig. Zeker in het geval van vector functies en andere processor specifieke extenties.

[Damic]

>> farcry.exe en fartcry.exe ineens andere resultaten

[_Thanatos_]

Maar dat is tenminste software die je ook echt zou kunnen gebruiken, dus ligt het alsnog dichter bij de werkelijkheid dan een synthetische benchmark.

[Vizzie]

Natuurlijk, maar real life benchmarks geven wel een beter beeld van hoe je device in de praktijk gaat werken.

Dat iets sneller zou kunnen werken als dat iets anders gecompileerd werd is voor ons interessant, maar heeft niet zoveel te maken met de praktijk tenzij je zelf de code opnieuw kunt gaan compileren. Dit kan in veel gevallen niet.

[RGAT]

Na de update een verschil tot 50% is wel heel fors...

[triflip]

Geen enkele benchmark dmv software is 100% eerlijk. De enige manier om producten te vergelijken is een real time test.

[RSpliet]

Real time? Wat zijn dan je timing constraints?

Ik neem aan dat je "real world" bedoelt, ofwel timen van een set aan handelingen binnen diverse applicaties. Los van dat dit ook niet eenvoudig is (aangezien een deel van de latency kan worden verhuld in de boot-tijd) test je hiermee vaak andere gebruiks-situaties. Statische benchmarks meten de maximale performance haalbaar van de hardware (met huidige compilers), terwijl real-world benchmarks meten hoe hardware zich gedraagt in diverse praktijksettings. Deze praktijk heeft als parameters dus niet alleen de compiler en de hardware, maar ook de versie van alle gebruikte applicaties.

[triflip]

Statische benchmarks meten tot zover de maker van de benchmark wilt dat er gemeten word. Bijna elke statische benchmark heeft wel een lichte voorkeur naar een bepaald merk omdat de maker van de benchmerk het meeste met dat merk gewerkt heeft en dus beter ervoor kan programeren.

Maar ook bij deze statische benchmark het je met 3 facters te maken, de compiler, de hardware en de gebruikte versie van de gebruikte app! De X86 versie zal je niet draaiend krijgen op een ARM sock en visa versa. Er word dus niet eens met exact dezelfde applicatie getest. En de maker ervan wilde duidelijk dat Intel als de betere naar voren kwam, nadat dit opviel heeft hij het maar snel aangepast. Dit is niet zomaar een foutje bedankt geweest.

[Rudie_V]

De Antutu-benchmark bevooroordeelt intel soc's niet, maar benadeelt arm-socs door niet alle aanwezig instructies(neon) te gebruiken. Een benchmark mag best optimalisaties gebruiken om te laten zien hoe snel een soc is, want dat is toch wat we willen weten en in echte applicaties kunnen die optimalisaties ook gebruikt worden. Want wat zegt een benchmark als het niet laat zien hoe snel het kan? De scores die arm soc's halen is dus nietszeggend als in de praktijk optimalisaties gebruikt worden en het dus sneller is dan de benchmark zou doen vermoeden.

[Brazos]

Zo kun je het inderdaad ook zien, het glas is halfvol of het is half leeg. De titel impliceert nu dat Antutu intel willens en wetens bevoordeelt heeft, echter wordt dat niet nadrukkelijk bewezen. Als dit is gebeurt zonder invloed van Intel, en zonder de intentie van Antutu om intel te bevoordelen, lijkt de titel "Antutu benchmarkt benadeelt ARM socs....." beter op zijn plaats.

[haarbal]

Tsja, wie is verbaasd? met sysmark deden ze ongeveer hetzelfde, waarna amd, nvidia en via babco verlaten hebben.

[Mrjraider]

Om deze oneerlijkheid te verhelpen kan AnTuTu worden aangepast om ook de NEON instructies te doen bij ARM. Benchmarks gebruik ik al heel lang niet omdat ze voor mij weinig toegevoegde waarde hebben.

[HummerHealey]

Benchmarks zeggen toch weinig. Je kan beter naar praktijk performance kijken van veel gebruikte apps.

[mutley69]

Als we naar 't EU onderzoek kijken rond Intel vs. AMD dan zijn de gehanteerde methodes bijzonder "onzuiver". Het gevolg - AMD = bijna failliet.
En het verhaal herhaalt zich!