Ormai è un proliferare di benchmark che assegnano punteggi nei modi più disparati. Cerchiamo di capire quanto (e quando) questi sono attendibili.
I benchmark sono degli strumenti di test per valutare le prestazioni di un software o dispositivo. Questi test possono essere effettuati secondo i criteri più disparati, e quelli più in voga tra il grande pubblico sono i benchmark per testare l’equipaggiamento hardware, e tipicamente consistono nell’eseguire un set di operazioni misurando quanto tempo il dispositivo ha impiegato ad eseguirle, assegnando infine un numero tanto più alto quanto minore è stato il tempo impiegato a eseguire le varie operazioni, per cercare di dare un’indicazione di quanto la componente hardware è “prestante”.
Misurare la velocità di un sistema di elaborazione però è un’operazione molto più complessa che misurare la velocità di un’automobile. La velocità necessaria a completare un determinato compito dipende infatti non solo dall’hardware ma anche dal modo in cui è stato programmato l’algoritmo da eseguire, dal sistema, e tutto l’ambiente di runtime coinvolto.
Ciò significa che per valutare effettivamente ad esempio le prestazioni di una CPU o una GPU, il software di test dovrebbe essere ottimizzato nel miglior modo possibile per sfruttare appieno la specifica architettura, ma nessuno garantisce che sia effettivamente così, perché i vari software di benchmark commercialmente più diffusi, il più delle volte non sono open (lasciando oscuri anche i criteri di assegnazione del punteggio), né sottoposti a una rigorosa peer validation, né tanto meno hanno versioni specifiche per ognuna delle miriade di architetture esistenti, limitandosi al massimo solo alle famiglie di architetture principali per esigenze di compatibilità senza ulteriori distinzioni specifiche (con ad esempio una singola versione per testare tutti i processori x86, una singola versione per testare tutti gli arm64 e così via) , e i confronti diretti del punteggio cominciano a perdere senso quando lo stesso software viene eseguito su architetture diverse e sistemi diversi.
Se ad esempio un algoritmo fa abbondante uso di istruzioni specifiche di un’architettura, che sull’altra architettura, che ha un diverso tipo di customizzazioni e istruzioni proprietarie, sono meno ottimizzate o emulate in più cicli di clock, avremo come risultato che la prima prenderà un punteggio molto più alto, quando magari la seconda architettura utilizzata opportunamente è il doppio più potente ma non avendo il software di benchmark a disposizione codice ottimizzato opportunamente per sfruttarne le sue peculiarità si troverà enormemente svantaggiata. O magari un benchmark potrebbe testare la velocità del processore in un’operazione di codifica per cui il processore ha uno specifico sistema d’accelerazione hardware, assegnando così un punteggio spropositatamente alto, quando invece è lento quando deve eseguire operazioni generiche e di qualsiasi altro tipo per cui non dispone di ottimizzazioni specifiche.
Per tale motivo se è lecito ad esempio confrontare i punteggi benchmark di un Intel i7 8700K con un Intel i3 8100 (basati su stessa architettura con stesso set di istruzioni) e dire che l’i7 8700K è in media il 20% più veloce in operazioni single core e il 145% più veloce in operazioni multicore, esaminando i punteggi dei rispettivi benchmark sullo stesso sistema per uno scenario d’elaborazione tipico valutato dal test, tutto ciò comincia già a diventare più controverso quando lo stesso processore si confronta ad esempio con un AMD Ryzen 7 2700x dove l’architettura presenta delle differenze per cui a seconda di come è scritto e\o compilato il codice di test, il benchmark potrebbe svantaggiare o avvantaggiare una delle due CPU, per assumere proporzioni ridicole quando ad esempio si confrontano i punteggi Geekbench tra diverse architetture e diverse piattaforme software dove oltre ad esserci pesanti differenze architetturali, i risultati possono essere totalmente falsati anche dai diversi ambienti di runtime che includono anche sistemi di sandboxing e virtualizzazioni.
Qualcomm Snapdragon 845
In particolare in ambito mobile oltre ad esserci un insieme molto più eterogeneo di architetture, alcune architetture sono costituite da una moltitudine di diverse unità di elaborazione specifiche (ISP, DSP, unità dedicate alla crittografia, unità neurali ecc.) integrate nello stesso SoC, piuttosto che da un singolo processore tuttofare con abbinata GPU, a rendere particolarmente complessa l’operazione di assegnazione di un generico punteggio per tentare di avere una valutazione oggettiva delle performance.
Tutto questo senza neanche considerare il fatto i produttori possono usare sistemi per cercare di manipolare i risultati spingendo le unità di elaborazione a funzionare a frequenze più alte di quelle usate negli scenari di funzionamento normale.
Perciò fate attenzione a valutare i vari punteggi di benchmark e relative classifiche, “cum grano salis”.
