Die Single core GEEKBENCH is niet zaligmakend:
Klopt, naar aanleiding van de vorige 'discussie' die ik hier op T had, ben ik hier maar eens meer over gaan lezen. Voor wie Geekbench beter wil snappen, is het volgende interview aan te bevelen:
https://www.xda-developer...ign-a-benchmark-and-more/
https://www.xda-developer...res-honest-manufacturers/
https://www.xda-developer...h-ceo-fireside-chat-pt-3/
Wat ik zelf het opvallendste vond:
-In tegenstelling tot wat ik dacht, wordt voor Android voornamelijk 'native code' gebruikt; dus het JVM-verhaal waar ik vorige keer mee kwam is kolder. Waarvoor mijn excuses, ik ben een mens dus maak fouten

Het is overigens wel correct dat voor Android / Apple verschillende compilers en programmeertalen worden gebruikt (Apple gebruikt ObjC / LLVM als ik het goed begrijp), dus die invloed heb je wel in je benchmarks - die verondersteld worden om alleen hardware te benchmarken !?
-Verschillen tussen verschillende versies van Geekbench, dus een 'nieuwere' Geekbench kan ervoor zorgen dat
dezelfde SoC op papier in een keer veel minder presteert?! Maar veel reacties waren, dat het klopte met het onderbuikgevoel van degenen die reageerden, dus men liet het zo.
-De enorme verschillen tussen Android 6.0.0 en 6.0.1, door gebruik van een betere (nieuwere geloof ik) scheduler in Linux gingen de scores in een keer heel hard omhoog. Dus
dezelfde hardware was op papier in een keer veel sneller. Fijn, Geekbench benchmarkt voor een belangrijk deel de scheduler! En bij veel big.Little-implementaties was de scheduler vrij waardeloos, dus de multicore resultaten ook... En omdat de Linux-scheduler niet goed genoeg was, had Apple er gelijk in maar 2 cores te gebruiken, kennelijk was de iOS scheduler net zo waardeloos, maar Apple maakte wel de juiste keuze door niet teveel en vooral niet verschillende typen cores in de SoC te douwen waar de scheduler niet fatsoenlijk mee kon omgaan. Een leuke historie met als resultaat Con Kolivas vertrek bij Linux en
Brain Fuck Scheduler schiet me te binnen; het maken van een fatsoenlijke scheduler is een van de moeilijkste taken van het maken van een OS.
-Geekbench is 'closed source', maar bedrijven kunnen een licentie kopen op de broncode. Dus Apple, Intel, Samsung, Mediatek en Qualcomm zitten lekker te optimaliseren voor deze benchmark, ga daar maar van uit! Soms hebben ze zelfs sjoemelsoftware die thermal throttling uitschakels als Geekbench draait.
-De nonsens vergelijking tussen ARM / x86: ARM SoC's hadden vaak al een crypto-unit, maar Intel nog niet. Dus leek de ARM SoC sneller; maar dat vond men niet rechtvaardig. Dus als ik het goed begreep, moest de ARM-CPU toen weer AES gaan uitrekenen; voor de betere vergelijking. Dus als Kareltje allerlei slimme accelerators in een systeem bouwt voor veel voorkomende taken, en Jantje is dom en laat dat allemaal door de CPU doen waarvan hij wel een snellere heeft, dan moet Jantje natuurlijk wel de benchmark winnen want anders was het niet eerlijk. Ook al leiden de accelerators van Kareltje tot een betere gebruikservaring en minder sttroomverbruik. Met zo'n flut-instelling neem ik een belangrijk stukje van de benchmark toch al een stuk minder serieus.