Abbiamo intervistato Tamás Miklos, Lead Developer di FinalWire, l’azienda produttrice di AIDA64, grazie alla gentile intercessione di József Barna, Amministratore Delegato di Bee Online International, società che distribuisce AIDA64 in Italia. Le domande che abbiamo posto a Tamás sono state centrate non solo sugli aspetti riguardanti lo sviluppo dell’ultima versione della nota suite di benchmark e monitoraggio di sistema, ma anche sulle difficoltà e i pareri personali nati nel dover portare avanti un software in grado di valutare le architetture moderne nelle loro diverse implementazioni, nonché sulle eventuali evoluzioni future del software.
Oltre ad indagare sulle difficoltà incontrate e sugli approcci utilizzati per lo sviluppo di AIDA64, non abbiamo mancato di “stuzzicare“ Tamás chiedendogli pareri personali sulle tecnologie che sono di moda in questi ultimi anni.
AIDA64 Extreme Edition, la versione di AIDA64 dedicata ad overclocker ed utenti enthusiast!
Benché nelle risposte date Tamás abbia cercato di mantenere una linea politically correct nei confronti delle varie aziende e dei loro prodotti, egli non ha fatto mancare una serie di stoccate e di sentenze negative quando ne sentiva il bisogno.
In linea di massima siamo stati più che soddisfatti delle risposte ricevute e per quel che ci riguarda ne condividiamo il contenuto. Le uniche due parziali obiezioni che ci sentiamo di porre riguardano il futuro di ARM e il dover ritornare all’approccio del direct programming in determinati software, come i videogiochi.
Nel primo caso ci sembra ancora presto per porre una sentenza definitiva sull’architettura, sia perché ARM offre ormai performance sufficienti alla maggior parte delle persone per l’utilizzo base di un PC, sia perché le industrie dei semiconduttori sono sempre più vicine al dover prendere in seria considerazione la creazione di una roadmap concreta che porti oltre al silicio (la cui resa è sempre più vicina ai suoi limiti fisici), il che potrebbe rimescolare le carte in gioco, se non addirittura cambiare in toto il mercato.
Nel secondo caso, per quanto sia vero che la programmazione diretta offra indubbi vantaggi per l’ottimizzazione del software, questa si rivela possibile solo in ambienti le cui specifiche hardware sono fisse o quantomeno ben definite, come accade nelle console. Pertanto per lo sviluppo su PC si deve ancora oggi scegliere, per quanto concerne almeno la grafica, l’utilizzo di OpenGL o di Direct3D. Il primo offre un minor overhead di CPU rispetto a Direct3D ma impone la compilazione degli shader in bytecode da parte del driver video prima della distribuzione, il che introduce spesso e volentieri una serie di ottimizzazioni a favore di una architettura invece che dell'altra e il cui risultato si ripercuote su ogni configurazione hardware. Il secondo offre sì un overhead di CPU maggiore (che si nota soprattutto quando si tenta di fare un alto numero di chiamate), ma i cui shader sono compilati in bytecode dalle stesse DirectX, producendo un codice neutrale la cui ottimizzazione è lasciata all’esplicito intervento dello sviluppatore.
Ma non dilunghiamoci oltre e passiamo invece all'intervista che troverete sia in lingua originale (inglese) che tradotta in italiano. Buona lettura!
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.
B&C: Hi Tamás, first of all, thank you for this interview. Can you explain to our readers what your position and roles are at FinalWire?
Tamás Miklós: I am the managing director of FinalWire, and I’m also responsible for leading the development of our flagship product, AIDA64.
B&C: Hyper Threading/Logical Core versus Native Core versus Clustered Multi Threading (CMT): what kind of problems have you encountered with the last AIDA64 revision? What do you think about them? Which is the most programmer-friendly or the best performer?
TM: From a hardware diagnostic software perspective, it’s not a problem to handle either of them. But when it comes to processor benchmarks, coping with such differences could be a real challenge. We are in a fortunate position of having a number of veteran benchmark experts in our team, and for them, it’s quite normal to handle very different processor architectures, ranging from in-order single-threaded simple CPUs to multi-socket + multi-core + multi-threaded beasts like Intel Westmere-EX servers. As for best performance, as always, it depends on the actual workload, the type of application you are running. We do not really feel comfortable about judging either solution: we are trying to stay neutral, and squeeze out every possible bit of performance from AMD, Intel and VIA processors, regardless of their architecture.
B&C: Have you encountered some unexpected results during the development, testing and debugging of AIDA64 3.00 with different operating systems (Windows XP, Windows Vista, Windows 7, etc)?
TM: In AIDA64 v3.00, we have introduced multi-threaded cache and memory bandwidth benchmarks, with automatic calibration scheme. On several older systems, we had to face difficulties during the development of this module, especially the calibration part. We had to make a lot of exceptions and use special code paths on such systems, which made the development process very long, spanning over 18 months. But in the end, the whole module got very sophisticated, and thanks to the long testing hours, the final revision provides the expected results, in line with the theoretical performance of the measured systems. The only exception is using Intel Haswell processors under Windows XP, where AVX extensions cannot be activated. With Haswell you can only utilize the full potential of the cache and memory subsystem if you have AVX enabled, which requires Windows 7 SP1 or later.
B&C: In the developing of AIDA64 did you utilize preexisting tools or libraries set or did you create ones of your own? If you used a preexistent one, can you tell us what is the most useful to take advantage of the modern CPU features?
TM: With AIDA64 we try to develop everything in-house to make sure that every little piece, every module in the software is properly done, and up to our quality standards. Very rarely do we have to make exceptions. For example, our CPU ZLib data compression benchmark is based on the ZLib library, and the FPU VP8 benchmark is based on Google’s WebM codec. Of those external libraries we are most impressed by the WebM codec, which is being constantly developed and improved by Google’s experts, and now even have a worthy successor in VP9.
B&C: The actual software applications have very little optimization in order to take advantage of the modern CPUs. Do you think that it's necessary some new sets of library or a new programming language to help the software developers obtaining that? Is the HSA (Heterogeneous System Architecture) platform a good solution to solve this problem?
TM: Libraries are definitely not the way to go. HSA is an interesting concept, but it has a number of drawbacks which are rarely advertised. The major issue is latency: it is simply impossible to issue a short compute task and get the results without a considerable overhead caused by the OpenCL framework and the video driver. Then there’s the issue of the whole OpenCL approach: all video and CPU drivers have to include an OpenCL compiler, which is very convenient for developers, but it also means that expected performance and latencies can greatly vary between driver updates and between manufacturers. Things that work with the current video driver will not necessarily work with the next video driver release. With direct architecture programming – the way AIDA64 CPU and FPU benchmarks work – there are no drivers and latencies to worry about, so you can use extreme optimizations and utilize the latest technologies at their full potential.
With video games, as John Carmack suggested in an interview, we would have to go back to direct programming to eliminate the huge latencies caused by video drivers and DirectX. The original Doom was a perfect example of how you can utilize the full potential of the hardware to ensure maximum video experience – you simply cannot do that today, since it’s not possible to program the GPU directly. But, in my opinion, this will not change unless a major change happens in video rendering, or one of the big video companies comes up with a feasible direct programming solution, and stops revamping the whole GPU architecture at every second or third GPU generation update.
B&C: In your experience, what are the most problematic features to optimize in the modern CPUs?
TM: The biggest challenge would have to be multi-threading. You need to optimize very different workloads and tasks, and unfortunately not all of them can be easily broken up into 4 or more threads. Then there’s the issue of using vector extensions: if you cannot use AVX or FMA instructions in your code, and the compiler doesn’t automatically do the optimizations for you, then it’s very tough to make your software excel on modern CPUs. If your code still uses only SSE or SSE2 optimizations, or does not rely on such optimizations at all, then your software will not perform much better on a brand new Intel Haswell CPU than on a 3-year-old Lynnfield.
B&C: Do you think that hardware makers provide adequate documentation for their own products? E.g., we can see that nVidia site for developers is almost abandoned.
TM: Since the recession began, and especially since the iPad was unveiled, the PC market has been in a sad and constant decline. With GPUs moving into the CPU package, consoles becoming ever more popular, and Intel capturing more and more video adapter market share from AMD and nVIDIA, those companies are quickly losing ground. They try desperately to protect their existing intellectual property by limiting access to documentation, and – although this is just a hunch – they also seem to spend less money on their online presence and maintaining their relationship with the development community. If those companies want to survive, they have to put more efforts into supporting developers.
B&C: We have seen that the cache and DRAM benchmark results in AIDA 64 3.00 are much better than the results you got with AIDA64 2.85 or older versions. Does the much higher memory bandwidth you can measure with AIDA64 translate into performance gains in real-world applications (like Maya, Photoshop, etc)?
TM: It depends on the type of application in question. The classic, legacy AIDA64 cache and memory benchmarks used only a single thread, so the performance they reflected were typical of old single-threaded applications and many 3D games. These days, in the middle of the multi-core CPU era, we can see more and more applications and games optimized for multi-threading. The performance measured by the new multi-threaded benchmarks in AIDA64 could be easily utilized by such applications – while with single-threaded programs you simply cannot use up the whole memory bandwidth.
B&C: Do you think that AIDA64 could be a good tool to test CPUs for specific scopes (farming, cloud, hpc, etc)?
TM: We offer a diverse set of CPU benchmarks, so they cover many usage scenarios, although obviously not all possible usage models. Farming, cloud and HPC markets are quite special, so for such usage models AIDA64 may not offer useful benchmark methods. What we have in AIDA64 is a set of benchmarks that are useful for measuring mainstream desktop and mobile PCs, and 1 or 2 socket servers and workstations. We develop AIDA64 as an easy-to-use software that both average PC users and enthusiasts can use to start benchmarks with a few clicks only and get the results in a few seconds. Specialized industry tools used to measure HPC and high-end server performance are usually much more complicated to set up and use, they run for a longer period of time, and they are simply too difficult and quirky for average PC users.
B&C: Do you think that in the future we'll see an integrated benchmark for GPGPU in AIDA64 (opencl, c++amp, cuda, d3dcompute, etc)?
TM: The AIDA64 OpenCL GPGPU benchmarks are already under development. We haven't specified a release date yet, simply because with those benchmarks we keep running into new issues, virtually every day. OpenCL compilers and video drivers, and even the underlying GPU hardware aren’t as mature and bulletproof as one would expect from such big companies as AMD, Intel or nVIDIA. The current set of AIDA64 GPGPU benchmarks are already capable of revealing such dirty secrets that the manufacturers would prefer to keep concealed. Overheating and throttling video cards, very slow and buggy OpenCL compilers are just a few examples :)
B&C: A question about the built-in AIDA64 stress test. When I use it my rig reaches 150 watts, but when I use Prime95 or OCCT my rig reaches 190 watts. What kind of stress test does AIDA64 perform?
TM: AIDA64 System Stability Test has a set of subtests, and you should carefully enable them, depending on the type of test you wish to run. If you’re looking for hardware errors, then you should enable all of them – which is what most users do. But if you want to put the most thermal stress on your system, then having only the FPU subtest enabled is the way to go. Thanks to SSE, SSE2, AVX and FMA optimizations, the FPU subtest alone will put the most demanding workload on the processor. You can also enable the GPU subtest as well, if you’ve got a discrete video adapter or an AMD APU. In the upcoming releases of AIDA64 we will completely revamp the System Stability Test to make it easier to use, and to put even more stress on the system.
B&C: Today ARM is everywhere, we even start to have notebooks with ARM chips. Will we see AIDA64 for Android or Windows RT in the future? Do you think that the results of the two different platforms (x86 and ARM) are comparable when using the same benchmarking software (3D Mark, for example)?
TM: Currently, we have no plans for an ARM port, since we believe Windows RT is already dead and buried. With Haswell Intel continues closing the gap in power efficiency, and they will keep delivering better and better products this year (Silvermont) and especially next year (Broadwell). If you look back on the past 30 years, Intel and x86 have beaten almost everything out there, including DEC Alpha, MIPS, Motorola m68k, and put many companies – like Cyrix, Harris, NEC, SiS, TI, Transmeta, UMC – out of the CPU business. Thanks to the 64-bit extensions developed by AMD, x86 has even killed IA-64 and Itanium, although Intel will never admit it. Many people hate Intel for x86, and try to make it look like an outdated, previous-century technology, but there’s still a lot of potential in it, and millions of guys stick to x86 for backwards compatibility. ARM may just become the next Alpha, or live next to Intel and x86 – we’ll see in the coming years.
B&C: Based on your experiences, can you give some advice to operating systems developers, to developers in general and to hardware manufactures on how they can do better software?
TM: For every company there’s always some sort of constraint, either time, money or human resources. So when you develop software or hardware, it can never be perfect, since there’s always a specific deadline or limitation you have to live with. If you have the luxury of being able to roll out your product only “when it’s done”, then you have a chance to make something great. But lately we’ve seen too many compromises, bad products, buggy products, and judging by that trend, the future looks quite dim. For all those companies, I’d recommend spending more time on researching various alternatives, validating the technologies, and most importantly listening to consumer feedback before releasing their new products.
B&C: Thank you Tamás, it has been a pleasure talking with you.
TM: Thank you, it’s my pleasure.