B&C: Ciao Tamás, prima di iniziare, ti vogliamo ringraziare per averci concesso questa intervista. Potresti spiegare ai nostri lettori che pesizione e che ruoli ricopri all'interno di FinalWare?
Tamás Miklós: Sono il Managing Director di FinalWare, e sono inoltre il responsabile dello sviluppo del nostro prodotto di punta, AIDA64.
B&C: Hyper Threading/Core logici contro Core fisici contro Clustered Multi Threading (CMT): che tipo di problemi avete incontrato nello sviluppo dell'ultima versione di AIDA64? Cosa ne pensi di questi? Qual è il più facile da programmare o il più performante?
TM: Dal punto di vista di un software di diagnostica, non è un problema avere a che fare con queste architetture. Ma quando si comincia a parlare di benchmark, potrebbe diventare un problema. Noi siamo in una posizione privilegiata in quanto lavorano con noi un buon numero di esperti di benchmark, e per loro è la normalità avere a che fare con un gran numero di architetture differenti, partendo da quelle In-Order single thread, fino ad arrivare a sistemi multi socket, multi core e multi threated come le soluzioni server Intel Westmere-EX. Riguardo le migliori performance, dipende dal tipo di lavoro che si vuole fare, quindi dall'applicazione che si utilizza. Non ci sentiamo nella posizione di poter giudicare ogni soluzione: tentiamo di rimanere neutrali, cercando di tirare fuori il meglio da ogni processore, sia di AMD, sia di Intel sia di VIA, sfruttandone la specifica architettura.
B&C: Avete incontrato alcuni risultati inattesi durante lo sviluppo, il testing e il debugging di AIDA64 3.00 con i differenti sistemi operativi (Windows XP, Windows Vista, Windows 7, ecc.)?
TM: Con AIDA 64 v3.00 abbiamo introdotto nei benchmark "multi-threaded cache" e "memory bandwidth" l'automatic calibration scheme. Su molti sistemi più vecchi abbiamo incontrato delle difficoltà nello sviluppo, specialmente riguardo la parte relativa la taratura. Abbiamo dovuto accettare un gran numero di casi particolari, e per questo abbiamo realizzato parti di codice specifiche per questi sistemi. Questo ha prolungato notevolmente i tempi di sviluppo, superando i 18 mesi. Comunque alla fine il tutto è diventato molto sofisticato, e grazie alle molte ore di testing la versione finale risulta perfettamente affidabile, rilasciando risultati in linea con le performance teoriche dei sistemi provati. L'unica eccezione riguarda l'utilizzo delle CPU Haswell sotto Windows XP, dove le estensioni AVX non possono essere attivate. Con Haswell, in Widnows XP, si può solamente utilizzare la sola potenza della cache del memory controller se si ha le AVX attivate, le quali richiedono Windows 7 SP1 o S.O. successivi.
B&C: Nello sviluppo di AIDA64 avete utilizzato tool o set di librerie preesistenti, oppure ne avete creati di vostri? Se ne avete usati di preesistenti, potresti dirci qual è il più utile per trarre vantaggio dalle caratteristiche delle moderne CPU?
TM: Con AIDA64 tentiamo di sviluppare ogni cosa in casa così da essere sicuri che ogni piccola componente, ogni singolo modulo del software lavori perfettamente, migliorandone la qualità. Molto raramente abbiamo fatto delle eccezioni. Per esempio, il nostro benchmark di compressione CPU ZLib è basato sulle librerie ZLib, e il benchmark FPU VP8 è basato sul codec WebM di Google. Riguardo queste librerie esterne ci ha impressionato molto il codec WebM di Google, il quale è costantemente sviluppato e migliorato dagli esperti di Google, rendendolo il degno successore/contenitore del VP9.
B&C: Oggigiorno l'ottimizzazione software è scarsa (possiamo osservarlo con i videogame). Pensi che sia necessario l'utilizzo di qualche nuova libreria per risolvere questo problema? La piattaforma HSA (Heterogeneous System Architecture) potrebbe essere una buona soluzione?
TM: Le librerie non sono decisamente la strada da seguire. L'HSA è un'idea interessante, ma ha un numero di difetti che raramente sono compresi. Il maggior difetto è la latenza: è semplicemente impossibile effettuare un semplice compute task ed averne il risultato senza un considerevole overhead causato dal framework di OpenCL e dai driver video. Poi c'è un problema riguardo l'approccio ad OpenCL in generale: tutti i driver della scheda video e della CPU devono includere un compilatore OpenCL, la qual cosa è molto utile per gli sviluppatori, ma ciò significa anche che le prestazioni e le latenze supposte possono variare notevolmente attraverso gli aggiornamenti dei driver stessi, ed anche cambiando produttore (Questo è già oggi visibile nei semplici videogame o nella gestione dei dischi cambiando scheda madre, ma lasciando invariato il chipset, ndr). Le cose che adesso funzionano con i driver video disponibili non è detto che funzioneranno con i successivi update. Con l'architettura direct programming - il metodo utilizzato da AIDA64 per i benchmark CPU e FPU - non ci sono problemi riguardo i driver o le latenze, così si possono utilizzare ottimizzazioni estreme e si possono utilizzare le ultime tecnologie al massimo del loro potenziale.
Con i videogame, come suggerito da John Carmack in un'intervista, dovremmo tornare al direct programming per eliminare le elevate latenze causate dai driver video e dalle DirectX. Il primo Doom è un perfetto esempio di come si può utilizzare pienamente il potenziale dell'hardware per assicurare la migliore esperienza visiva - cosa che non si può fare oggi, da quando non è più possibile programmare direttamente le GPU. Ma, a mio parere, questo non accadrà finché non vi sarà un profondo ripensamento del rendering video, oppure finché una delle grandi compagnie di GPU non realizzerà una soluzione di direct programming praticabile, smettendo al contempo di rinnovare completamente le proprie GPU ogni due o tre generazioni.
B&C: In base alla tua esperienza, cosa rende così complicato ottimizzare il software per le CPU odierne?
TM: La sfida più grande dovrebbe essere il multi-threading. Hai bisogno di ottimizzare un gran numero di workload e task differenti, e sfortunatamente non tutti possono essere divisi in 4 o più thread. Poi c'è un problema riguardo l'utilizzo delle estensioni vettoriali: se non usi le istruzioni AVX o FMA nel tuo codice, ed il compilatore non effettua le ottimizzazione per te automaticamente, è veramente difficile che il tuo software eccella con le moderne CPU. Se il tuo codice utilizza solo le ottimizzazioni SSE o SSE2, o non utilizza tali ottimizzazioni del tutto, beh il tuo software non funzionerà molto meglio su una nuova CPU Haswell rispetto ad una CPU Lynnfield, vecchia di 3 anni.
B&C: Pensi che i produttori di hardware forniscano un'adeguata documentazione per i propri prodotti? Ad esempio, il sito di nVIDIA per gli sviluppatori è quasi del tutto abbandonato.
TM: Da quando la recessione è iniziata, e specialmente da quando l'iPad è stato svelato, il mercato PC è in un deprimente e costante declino.Con le GPU che stanno venendo inglobate all'interno del package delle CPU, e con Intel in continua ascesa nel market share delle GPU, a scapito di AMD e nVidia, quet'ultime compagnie stanno perdendo terreno. Queste stanno cercando disperatamente di proteggere le proprie proprietà intellettuali limitando l'accesso alla documentazione, e - ma questo è solo un vago sospetto -tagliando i fondi alla propria presenza online e alla comunità degli sviluppatori. Se queste compagnie vogliono sopravvivere, devono mettere maggiori energie nel supportare gli sviluppatori.
B&C: Abbiamo visto che i risultati riguardo i benchmark su Dram e Cache con AIDA64 3.00 sono decisamente migliori rispetto a quelli conseguiti con AIDA64 2.85 o versioni precedenti. Questo aumento di performance potrebbe verificarsi anche nelle applicazioni reali (come Maya o Photoshop)?
TM: Dipende dal tipo di applicazione in oggetto. Il classico, datato benchmark sulla cache e sulla memoria di AIDA64 era solamente single thread, così le prestazioni mostrate erano assimilabili a quelle delle vecchie applicazioni single-threated e a molti videogiochi 3D. Oggigiorno, nel bel mezzo dell'era delle CPU multi-core, possiamo osservare che sempre più applicazioni e giochi sono ottimizzati per il multi-threading. Le prestazioni misurate dal nuovo benchmark multi-threated di AIDA64 può essere facilmente assimilato a queste applicazioni - mentre con i programmi single-threated, semplicemente, non si può utilizzare la bandwidth massima della memoria.
B&C: Pensi che AIDA64 potrebbe essere un buon tool per scopi specifici (farming, cloud, hpc, ecc.)?
TM: Noi proponiamo diversi set di benchmark per la CPU, così che possona coprire molti scenari di utilizzo, anche se ovviamente non possiamo coprirli tutti. I mercati relativi al Farming, al Cloud e all'HPC sono abbastanza speciali, per questo AIDA64 non offre dei set di benchmark adatti. Quello che abbiamo in AIDA64 sono un set di benchmark utili per testare i desktop e i mobile PC consumer, e i server e le workstation con 1 o 2 socket. Abbiamo sviluppato AIDA64 per essere un software di facile utilizzo di modo che sia gli utenti avanzati, sia gli utenti enthusiast potessero far partire i benchmark con pochi click, ed al contempo potessero conoscerne il responso dopo pochi secondi. I software industriali specializzati utilizzati per testare gli HPC e i server ad alte prestazioni sono solitamente molto più complicati da settare e da utilizzare, lavorano per un lungo periodo di tempo e, detto molto semplicemente, sono troppo complicati e peculiari per i normali utenti PC.
B&C: Pensi che in futuro potremo vedere un benchmark per il GPGPU in AIDA64 (opencl, c++amp, cuda, d3dcompute, ecc.)?
TM: I benchmark di AIDA64 per OpenCL GPGPU sono già in sviluppo. Non abbiamo ancora una data di rilascio precisa perché con questi benchmark incontriamo quasi quotidianamente un nuovo problema. I compilatori OpenCL e i driver video, ed anche l'hardware vero e proprio della GPU non sono così maturi e a prova di proiettile come ci si aspetterebbe da grandi compagnie come AMD, Intel o nVidia. L'attuale set di benchmark GPGPU di AIDA64 è già capace di rivelare alcune zone d'ombra che i produttori preferirebbero tenere celate. Surriscaldamento e throttling delle schede video, e compilatori OpenCL molto lenti e buggati sono solo alcuni esempi. :)
B&C: Una curiosità riguardo lo stress test integrato in AIDA64. Quando lo utilizzo la mia configurazione consuma circa 150 Watt, ma quando uso Prime95 o OCCT questa arriva fino a 190 Watt. Che tipo di test esegue AIDA64?
TM: Il System Stability Test di AIDA64 ha un set di subtest, e tu puoi abilitarli, ma con attenzione, così da effettuare il test che più ti è utile. Se vuoi testare per trovare eventuali errori hardware, puoi abilitare quelli adatti allo scopo - ed è quello che fa la maggior parte degli utenti. Ma se vuoi avviare il test più stressante per il tuo sistema, attivare il subtest FPU è il metodo migliore. Grazie alle ottimizzazioni SSE, SSE2, AVX e FMA, il subtest FPU da solo riesce a caricare massicciamente il processore. Puoi inoltre abilitare il subtest della GPU, se hai una GPU discreta o usi una APU AMD. Nelle prossime release di AIDA64 rimodelleremo completamente il System Stability Test per renderlo più semplice da usare, aggiungendo anche altri stress test per il sistema.
B&C: Oggi ARM è ovunque, e stiamo osservando la commercializzazione dei primi notebook che utilizzano SoC ARM. Vedremo AIDA64 per Android o Windows RT in futuro? Pensi inoltre che i risultati conseguiti su piattaforme differenti (x86 e ARM) possano essere confrontabili utilizzando il medesimo software (3DMark, ad esempio)?
TM: ttualmente non abbiamo un piano per un porting su ARM, da quando crediamo che Windows RT sia ormai morto e sepolto. Con Haswell Intel continua a diminuire il gap riguardo l'efficienza energetica, e dovrebbe rilasciare prodotti sempre migliori quest'anno (Silvermont), specialmente il prossimo (Broadwell). Se guardi indietro di 30 anni, Intel e le istruzioni x86 hanno messo a tacere praticamente qualunque avversario, inclusi DEC Alpha, MIPS, Motorola m68k, e moltre altre compagnie - come Cyrix, Harris, NES, SiS, TI, Transmeta, UMC - anche esterne al business delle CPU. Grazie alle estensioni 64 bit sviluppate da AMD, x86 ha anche ucciso le IA-64 e Itanium, seppure Intel non lo ammetterà mai. Molte persone odiano Intel per le x86, e tentano di farle sembrate ormai datate, una tecnologia buona per il secolo passato, ma c'è ancora un enorme potenziale in queste istruzioni, nonostante milioni di persone attacchino le x86 per la retrocompatibilità. ARM potrebbe diventare la prossima Alpha, o potrebbe convivere con Intel e le istruzioni x86 - lo sapremo solo negli anni a venire.
B&C: Sempre basandoti sulle tue esperienze passate, potresti dare qualche suggerimento agli sviluppatori di sistemi operativi, agli sviluppatori in generale, e ai produttori hardware su come realizzare software migliori?
TM: In ogni azienda c'è sempre un qualche tipo di vincolo, di tempo, di denaro o di risorse umane. Così, quando si sviluppa un software o un componente hardware, questo non potrà mai essere perfetto, dato che ci sarà sempre una specifica scadenza o limitazione di cui bisogna tenere conto. Se si ha la possibilità di presentare il proprio prodotto solamente quando sarà pronto, allora si ha la possibilità di fare qualcosa di realmente grandioso. Ma ultimamente abbiamo visto troppi compromessi, prodotti difettosi, prodotti buggati e, osservando questa tendenza, il futuro sembra ingrigirsi. Per tutte quelle aziende, io consiglierei di spendere più tempo nella ricerca di ulteriori alternative, di utilizzare delle tecnologie rodate e praticabili, e soprattutto consiglierei loro di ascoltare il feedback del cliente prima di rilasciare nuovi prodotti.
B&C: Grazie Tamás, è stato un piacere parlare con te.
TM: Grazie a voi, il piacere è stato mio.