La pubblicazione dell’ articolo sulle CPU AMD Bulldozer redatto in occasione della presentazione ufficiale delle stesse ha sollevato non poche perplessità e qualche polemica. Le nuove soluzioni dell’azienda di Sunnyvale sembrano avere delle potenzialità eccezionali sulla carta che restano però inespresse nell’utilizzo quotidiano. Solo in casi particolari i processori FX-Series mostrano i muscoli e riescono a battere i prodotti della famiglia Sandy Bridge della rivale Intel.
Per verificare in dettaglio tutti i possibili scenari di utilizzo, configurare sistemi di test e validare i risultati ottenuti da nuovi set di benchmark è necessario molto tempo. Il reviewer kit di Bulldozer ci è stato consegnato solo sei giorni prima dell’annuncio ufficiale e questo ha reso impossibile effettuare verifiche al di fuori di quelle standard.
Una delle domande più interessanti che ci siamo posti e, come noi anche molti altri, di fronte a questa nuova architettura è quella dell’efficienza del singolo modulo e/o del singolo core. Vista l’organizzazione ideata da AMD, che prevede una forte condivisione delle risorse fra i due core che fanno parte dello stesso modulo (tutti i dettagli sull’architettura Bulldozer li trovate nel nostro precedente articolo ), vogliamo tentare di capire qual è il modo migliore di assegnare ad essa i thread. È meglio assegnare due thread a due core di due moduli differenti oppure a due core dello stesso modulo?
A questo discorso si aggancia perfettamente quello dello scheduler di diversi sistemi operativi, come Windows 8 (seppure nella sua versione preliminare) o Linux. Una diversa politica di scheduling dei thread può dunque essere più efficiente nei confronti di Bulldozer?
Infine, frequenze di funzionamento superiori, per questa CPU, sono in grado di offrire un’effettiva scalabilità delle prestazioni?
AMD afferma che l’attuale versione del sistema operativo Microsoft, Windows 7, non riesce a sfruttare bene le CPU della serie FX in quanto non è a conoscenza delle loro potenzialità. Questo significa che ci sono delle possibilità latenti, specie nella condivisione delle risorse e nella gestione della tecnologia Turbo Core.
Un chiaro esempio è quello che si presenta con uno scenario nel quale il thread 1b necessita dei dati che arrivano dal thread 1a che però è stato assegnato ad un core presente in un modulo differente. Pur senza entrare nuovamente nei dettagli, vogliamo ricordare brevemente l’architettura di Bulldozer: a differenza delle CPU tradizionali, questa prevede un blocco, indicato come modulo , composto da due core che condividono parte delle risorse (le ALU e le cache L1 dati sono indipendenti mentre la FPU, la cache L1 istruzioni e la cache L2 sono condivise). In aggiunta lo scheduler ha assegnato una seconda iterazione del thread 1a ad un core presente in un differente modulo impedendo dunque l’attivazione della modalità Max Turbo.
Assegnazione dei thread non ottimale
Per poter trarre il massimo vantaggio prestazionale dalle CPU Bulldozer sarebbe auspicabile avere una situazione in cui il thread 1a ed il thread 1b fossero assegnati sì a due core differenti ma dello stesso modulo: così facendo i due thread possono accedere a percorsi di scambio dei dati più brevi ed i core non utilizzati possono essere parcheggiati per ottenere una maggiore efficienza della tecnologia Turbo Core. D’altro canto, però, crediamo che vada presa in considerazione anche la possibilità che i due thread si trovino a concorrere per l’utilizzo delle risorse condivise.
Assegnazione ottimale dei thread
Windows 8 , almeno stando alle dichiarazioni della stessa AMD, sembra avere una maggiore sinergia con la piattaforma FX in quanto capace di allineare meglio i thread verso i core della CPU e parcheggiare quelli non utilizzati per migliorare l’efficienza energetica e fare un uso più efficiente del Turbo Core.
Per verificare l’effettivo comportamento dello scheduler di Windows 7 nei confronti delle CPU Bulldozer, abbiamo avviato una sessione di benchmark con Cinebench single-threaded. Ecco cosa accade con i due sistemi operativi di casa Microsoft:
Lo scheduling di un singolo thread su Windows 7
Windows 7 sposta continuamente il thread da un core all’altro, impedendo una corretta attivazione della modalità Turbo Core e causando continui context switching. In aggiunta, quando avviene un passaggio da un core all’altro, il nuovo core deve porsi alla stessa frequenza di funzionamento di quello abbandonato.
Questo comportamento influenza non solo le prestazioni con applicazioni single-threaded ma anche quello di software che sfruttano due o più thread. A meno che non ci si trovi di fronte ad un software capace di caricare tutti i core della CPU, Windows 7 farà sempre girare i thread sui diversi core andando a creare su Bulldozer situazioni più efficienti (quelle in cui non vi è condivisione delle risorse) e meno efficienti (quando due thread si trovano a dover condividere le risorse della CPU).
Lo scheduling di un singolo thread su Windows 8
La politica di gestione dei thread operata da Windows 8 è invece nettamente diversa. Come vedete dallo screenshot del monitor delle risorse, con il nuovo sistema operativo il thread viene assegnato ad un unico core e a quello rimane assegnato per tutta la sua durata. Questo significa che la CPU Bulldozer può permettersi di parcheggiare gli altri core non usati ed ottenere il massimo spunto da parte del Turbo Core. Per eseguire i test sulle CPU abbiamo rispettato le seguenti regole:
- Sulla scheda sono stati installati solo i componenti necessari: CPU, Memoria, Scheda video e Hard disk.
- L’hard disk è stato formattato, sono stati poi installati il sistema operativo, i drivers per le periferiche e, quando necessario, sono state installate patch e aggiornamenti.
- Ogni test è stato ripetuto per tre volte e, se i risultati di qualche test si mostrano troppo lontani dalla media (elevata varianza), il test stesso è stato di nuovo ripetuto, scartando il risultato non corretto.
- Alla fine di ogni sessione di prova l’hard disk è stato formattato.
In merito ai sistemi di prova, ci siamo serviti di differenti piattaforme a seconda del tipo di CPU. Ciò è stato necessario per ottenere un sistema funzionante per ogni tipo di Socket che le CPU utilizzate per la nostra comparazione. Ovviamente si è cercato di realizzare i sistemi con componenti simili, quando possibile uguali.
Sistemi di prova
I test eseguiti sono descritti qui di seguito:
Benchmark sintetici
- Fritz Chess Benchmark : questo è un tool che misura la potenza del processore di sistema utilizzando il motore per la creazione di giochi di scacchi “Fritz 9 engine”. Il risultato del test è espresso in nodi per secondo medi. Il software è fortemente ottimizzato per girare in ambienti multicore ed è capace di attivare fino ad 8 thread contemporaneamente.
- ScienceMark 2.0 : grazie a ScienceMark è possibile misurare le prestazioni del sistema in ambiente di calcolo spinto. Inoltre il software misura le prestazioni della memoria di sistema e della cache integrata nella CPU.
- SiSoft SANDRA 2010 : questa suite di benchmark sintetici ci offre un quadro specifico delle prestazioni di ogni componente disponibile all’interno della piattaforma di test come memorie, CPU, disco fisso e così via.
Grafica 3D
- 3DMark06 (versione 1.1.0 Professional) : ci permette di valutare le prestazioni grafiche 3D offerte dal sistema. Nel suo computo sono inclusi, in particolare, la CPU, la memoria di sistema ed il controller grafico.
- World In Conflict (RTS): si tratta di uno strategico in tempo reale, che unisce a questo tipo di giochi una visuale simile a quella degli sparatutto in prima persona e che fa degli effetti particellari e della fisica le sue armi migliori.
- Crysis: uno dei più indicativi titoli 3D DirectX 10 per effetti grafici e per l´utilizzo della fisica.
Utilizzo generico
- PovRay (versione 3.6) : il tool Persistence of Vision Raytracer (PovRay) permette di creare grafica tridimensionale di elevata qualità. Al suo interno troviamo una scena standard creata proprio per effettuare benchmark sulla CPU che sfrutta la maggior parte delle feature disponibili con questo software. Per rendere ripetibili i nostri test utilizziamo sempre le impostazioni di default del file.ini .
- Cinebench (versione 10 e versione 11) : suite di test multi-piattaforma basato sul software di animazione CINEMA 4D ampiamente utilizzato da studi e case di produzione per la creazione di contenuti 3D. Grazie ad esso possiamo valutare le performance del sottosistema CPU seppure l’influenza di chipset, memorie e scheda grafica installate nel sistema non può essere trascurata. Il software esegue un test di rendering capace di sollecitare uno o tutti i core del processore disponibili.
- 7-Zip (versione 9.15 beta) : con questo noto software di compressione dati eseguiamo due diversi benchmark. Il primo viene realizzato utilizzando il tool integrato che restituisce una indicazione sui MIPS (million instructions per second) che il sistema è in grado di offrire (potete confrontare i risultati ottenuti con quelli ufficiali e con quelli del vostro sistema). Il secondo invece prende in considerazione una situazione reale nella quale viene richiesto al sistema di comprimere in formato 7z una cartella da 5,36GB contenente 4.379 file di diversa dimensione e tipologia (immagini, testo, html, video, foto, applicazioni) e 536 sottocartelle e poi di decomprimere la stessa. L’operazione di compressione ha una forte dipendenza dalla memoria cache della CPU e dalla memoria RAM installata nel sistema. Quella di estrazione dipende molto, invece, dalla capacità della CPU di gestire le operazioni su interi. In tutti i casi, il software sfrutta abbastanza bene tutte le risorse (core) di CPU a disposizione.
- Auto Gordian Knot (versione 2.55) : software utile per effettuare backup di DVD o comunque operazioni di transcodifica video nei formati DivX ed XviD. Per le nostre prove utilizziamo il codec XviD che il tool installa di default ed eseguiamo il ripping di un completo DVD (Codice Swordfish) che per l’occasione abbiamo memorizzato su un disco fisso e lo “comprimiamo” in modo da farlo entrare su due CD.
- Handbrake (versione 0.9.4) : un software di transcodifica video open-source multipiattaforma e multithreaded con il quale effettuiamo una conversione video di un intero DVD (Codice Swordfish) in formato adatto per i dispositivi Apple iPod, iPhone e iPad.
- DaCapo (versione 9.12) : questa suite di benchmark permette di valutare il comportamento del sistema quando si utilizzano tool di sviluppo per Java. Esso include tutta una serie di applicazioni reali open source fra cui Tomcat, FOP, Eclipse, Batik, Xalan e altri. Nel nostro caso riportiamo il tempo complessivo necessario all’esecuzione di tutti i test.
Per valutare la scalabilità della nuova CPU AMD abbiamo eseguito alcuni test specifici impostando la frequenza del processore ad un valore prefissato (4,5GHz nella fattispecie) e confrontando quanto ottenuto con il valore di riferimento preso a 3,6GHz (con modalità Turbo disattivata), con un valore teorico che parte da quest’ultimo migliorato del 25 per cento (la stessa distanza che esiste fra la frequenza di 3,6GHz e quella di 4,5GHz) e con il valore ottenuto in condizioni di funzionamento standard (ovvero con Turbo attivato).
Scalabilità con benchmark single-threaded – Moldyn (inferiore è meglio)
Scalabilità con benchmark single-threaded – Primordia (inferiore è meglio)
Scalabilità con benchmark single-threaded – Povray 3.6 (inferiore è meglio)
Quando si utilizzano benchmark, e dunque applicazioni, non ottimizzate per girare in ambienti multi-core, la scalabilità è praticamente perfetta. I numeri restituiti alla frequenza di 4,5GHz sono allineati a quelli che ci si aspetta in teoria grazie alla sola modifica della frequenza di funzionamento. In questo caso, però, la tecnologia Turbo Core sortisce un ottimo effetto, riducendo notevolmente i tempi di esecuzione e di conseguenza l’importanza dei risultati ottenuti in overclock.
Scalabilità con benchmark multi-threaded – Cinebench R10
Scalabilità con benchmark multi-threaded – Cinebench 11
Scalabilità con benchmark multi-threaded – Povray 3.7 (inferiore è meglio)
Scalabilità con benchmark multi-threaded – 7-zip
Ottimi risultati anche quelli che vengono fuori da benchmark multi-threaded con i quali la CPU in esame mostra di essere in grado di scalare molto bene. Tanto viene aumentata la frequenza di funzionamento e tanto migliorano le performance. In questi casi l’applicazione del Turbo Core riesce a garantire solo incrementi marginali garantendo così ai risultati ottenuti in modalità overclock di assumere una notevole importanza.
Scalabilità con benchmark multi-threaded – XMPEG (inferiore è meglio)
Scalabilità con benchmark multi-threaded – AutoGK (inferiore è meglio)
Scalabilità con benchmark multi-threaded – Handbrake (inferiore è meglio)
Fatti salvi i risultati ottenuti con HandBrake, con altre applicazioni di transcodifica video continuiamo a registrare un deciso miglioramento dovuto all’overclock della CPU FX-8150; stavolta la tecnologia Turbo Core si comporta abbastanza bene garantendo miglioramenti prestazionali mediamente importanti. Con HandBrake, invece, le maggiori frequenze di funzionamento non riescono che a garantire solo lievi miglioramenti dei tempi, non di certo all’altezza di quanto ci si potrebbe aspettare.
Scalabilità con benchmark multi-threaded – Truecrypt – Twofish
Scalabilità con benchmark multi-threaded – Truecrypt – AES
Ottima la situazione con le applicazioni di cifratura. In questi casi i risultati ottenuti in modalità overclock assumono importanza notevole vista la quasi totale assenza di intervento da parte del Turbo Core. Lo scheduler dei thread di Windows 8 differisce da quello dei suoi predecessori: esso tenta di assegnare i thread a singoli core in modo da massimizzare l’efficienza sia in termini di prestazioni che di risparmio energetico. Vediamo come tutto ciò si traduce sulle prestazioni della piattaforma Bulldozer.
Tipico benchmark single-threaded (tempo in s, inferiore è meglio)
Guardando ai valori ottenuti con un tipico benchmark single-threaded, notiamo un discreto miglioramento dei tempi di esecuzione quando si utilizza Windows 8 con una CPU FX-8150 (e solo da parte di questa).
Povray 3.6, single-threaded benchmark (tempo in s, inferiore è meglio)
Con Povray nella versione 3.6, l’utilizzo di Windows 8 mostra risultati abbastanza criptici. L’unica CPU a beneficiare della gestione effettuata dal nuovo sistema operativo Microsoft è il Core i3-2100 (dual-core con Hyper Threading). La piattaforma AMD Bulldozer, invece, mostra un leggero ritardo.
Cinebench, valore del test single-threaded
Tutte le CPU in esame sembrano invece beneficiare delle politiche di scheduling di Windows 8 quando sottoposte al benchmark single CPU di Cinebench 10. In particolare il Phenom II X4 980 ottiene un vantaggio davvero interessante (evidentemente garantito proprio dal fatto che viene evitato il continuo passaggio del thread da un core all’altro). Il miglioramento dovuto alla piattaforma Bulldozer rientra nello stesso range di quello delle CPU rivali Intel Core i5 e Core i7.
Cinebench, valore del test multi-threaded
La conferma del fatto che il decadimento delle prestazioni dovuto allo scheduler di Windows 7 sia proprio da ricercare nel continuo passaggio di mano arriva dal benchmark multi CPU di Cinebench 10. È facile notare in questo caso come non vi siano praticamente differenze fra l’uno e l’altro sistema operativo, fatto salvo il caso della CPU Phenom II X4.
Fritz Chess, multi-threaded
Anche Fritz Chess, re dei benchmark capaci di mettere in difficoltà sistemi multi CPU, mostra che non ci sono vantaggi derivanti dall’utilizzo di Windows 8. Quando tutti i core della CPU sono occupati non c’è differenza fra lo scheduler di Windows 7 e quello di Windows 8, dunque non rileviamo differenze prestazionali.
7-zip benchmark, multi-threaded
Al contrario il benchmark integrato in 7-zip dimostra una certa sensibilità verso il sistema operativo: con Windows 8 la piattaforma Bulldozer riesce ad ottenere un vantaggio del 10 per cento circa. Lo stesso vantaggio è però appannaggio anche delle altre piattaforme, tranne quella basata su CPU Core i3.
Guardando all’interno dei risultati abbiamo notato come ad appiattire la situazione ci pensi il test di estrazione che va ad occupare tutti i core delle CPU in esame; quello di compressione, invece, è molto più thread aware e dunque soggetto, in Windows 7, al continuo passaggio da un core all’altro. I risultati del Core i3-2100 danno conferma di quanto appena esposto essendo dotato di soli due core fisici che restano praticamente sempre occupati sia nelle operazioni di estrazione che di compressione.
Truecrypt, algoritmo Twofish
Nel caso di algoritmi di cifratura, la CPU FX-8150 era già in grado di battere senza grossi problemi le soluzioni della rivale Intel. L’utilizzo di Windows 8 risulta essere, però, controproducente per la nuova piattaforma AMD: mentre tutte le altre ottengono un vantaggio o comunque restano sugli stessi valori, Bulldozer mostra un peggioramento.
Handbrake, transcodifica video (tempo in s, inferiore è meglio)
Nulla da segnalare nel caso di transcodifica video con il software Handbrake. I risultati ottenuti sono molto simili in entrambe le situazioni.
x264
Qualche miglioramento marginale lo otteniamo con il benchmark x264: in questo caso le CPU Intel subiscono una riduzione delle prestazioni mentre la nuova piattaforma AMD mostra numeri leggermente migliori.
Tecnica di parcheggio dei core in Windows 8
Linux prevede una diversa e probabilmente più efficiente gestione del multi-tasking. Per capire se in questo caso le nuove CPU AMD siano capaci di una maggiore efficienza, abbiamo installato la distribuzione OpenSUSE 11.1 a 64-bit ed eseguito una serie di test estrapolati dalla suite Phoronix .
Non è possibile purtroppo comparare i risultati ottenuti con quelli che arrivano dai sistemi operativi Windows in quanto sono differenti sia i benchmark che le modalità di prova: possiamo però sempre mettere a confronto i numeri mostrati da differenti CPU.
x264
Le prestazioni ottenute dalla piattaforma AMD FX-8150 sono da “player di mezzo”, comprese fra quelle della CPU Core i5-2500k e della CPU Core i7-2700k.
7-zip
Lo stesso risultato l’otteniamo anche con 7-zip ma in questo caso i numeri dell’FX-8150 si avvicinano più a quelli di un Core i7-2600k che non a quelli del modello top di gamma della serie Core i5.
gzip (tempo di compressione in s, inferiore è meglio)
Nel caso di compressione con il software gzip, la piattaforma AMD Bulldozer deve vedersela addirittura con una CPU dual-core, modello Core i3-2100, che riesce ad avere la meglio (seppure di pochi decimi di secondo).
Apache building (tempo di compilazione in s, inferiore è meglio)
Anche nelle operazioni di building di un software come Apache, la nuova CPU AMD Bulldozer FX-8150 non riesce a stare al passo coi tempi delle rivali Intel Core i5-2500k e Core i7-2600k.
BZIP 2 (tempo di compressione in s, inferiore è meglio)
Quando il parallelismo delle applicazioni aumenta a dismisura come nel caso del tool di compressione BZIP 2, Bulldozer mostra i muscoli e tempi molto vicini a quelli di una CPU Intel Core i7-2600k. Sinora abbiamo fatto i conti solo con politiche automatiche di scheduling dei thread. A differenza di altre architetture, le CPU Bulldozer possono essere organizzate, come già detto, in più modi. È possibile valutare le prestazioni nel caso in cui thread indipendenti vengano assegnati a core appartenenti a moduli differenti oppure nel caso in cui essi vengano assegnati in modo da occupare prima i core dello stesso modulo.
Windows offre una comoda utility a riga di comando che permette di bypassare lo scheduler automatico. È sufficiente impostare, a tal proposito, il parametro ‘AFFINITY’ del comando ‘start’ per far sì che il sistema operativo assegni in maniera statica i thread ai core desiderati.
Quello che possiamo fare in maniera fissa è assegnare, ad esempio, quattro thread a quattro core separati di moduli differenti (ad esempio ai Core 0, 2, 4, 6) oppure a quattro core di due soli moduli (ad esempio Core 0, 1, 2, 3). Per eseguire questa operazione è sufficiente assegnare la giusta maschera (in formato esadecimale) al parametro AFFINITY.
Assegnazione dei thread ad un core per ogni modulo
- Maschera binaria: 10101010
- Maschera esadecimale: AA
Assegnazione dei thread a due core per ogni modulo
- Maschera binaria: 11110000
- Maschera esadecimale: F0
Per eseguire le prove abbiamo utilizzato il benchmark di 7-zip prendendo in esame i risultati ottenuti nelle operazioni di estrazione che dipendono fortemente dalle prestazioni della CPU. 7-zip, inoltre, può essere eseguito a linea di comando da dove è possibile impostare anche il numero di thread grazie al parametro -mmt.
Esecuzione di 7zip con un diverso valore di AFFINITY
Di seguito i risultati che abbiamo ottenuto.
7-zip, estrazione, MIPS
L’utilizzo di una maschera fissa da noi prestabilita comporta comunque un vantaggio rispetto allo scheduling automatico di Windows 7 ad ulteriore riprova che questo sistema operativo continua a far passare i thread da un core all’altro. Se però attiviamo la maschera AA, il vantaggio risulta essere davvero netto (+13 per cento rispetto alla situazione con scheduling automatico), segno che l’utilizzo di un solo core per modulo è più efficiente rispetto a quello di due moduli su quattro.
7-zip, MIPS complessivi
Chiaramente guardando ai MIPS complessivi di 7-zip la situazione si appiattisce un po’ per via di operazioni che non sono così influenzate dalla potenza della CPU (quelle di compressione). Comunque sia il vantaggio di una maschera fissa che faccia attivare, con 4 thread, sempre e solamente un solo core per modulo, permette a Bulldozer di ottenere un discreto vantaggio sulla situazione standard.
Anche se i pochi test effettuati non possono essere considerati esaustivi di una situazione più generica e complessa, abbiamo comunque dimostrazione del fatto che le congetture di AMD a volte potrebbero essere non del tutto corrette: uno scheduling come indicato dal produttore, che appare più vicino alla tipologia di maschera F0, produrrebbe sì delle migliorie ma non quanto uno scheduling con una maschera di altro tipo. Da questi nuovi ed ulteriori test non sono emerse prove a discolpa di AMD. È vero che in taluni casi le nuove CPU Bulldozer si comportano meglio ma o gli incrementi sono marginali oppure il miglioramento vale anche per le soluzioni rivali e/o di precedente generazione.
Scendendo nel dettaglio abbiamo avuto conferme sul fatto che Windows 8 sia in grado di una migliore gestione dello scheduling dei thread (vi ricordiamo che abbiamo utilizzato una versione preliminare del sistema operativo Microsoft per cui potrebbe essere presto per trarre delle conclusioni). I vantaggi ottenuti dalla CPU AMD FX-8150 sono però appannaggio anche delle altre soluzioni: almeno in linea generale, dove guadagna Bulldozer guadagnano anche Sandy Bridge e Phenom II.
Alle stesse conclusioni possiamo giungere analizzando i risultati ottenuti con Linux. La CPU AMD FX-8150 va a posizionarsi nei casi migliori fra Core i5-2500k e Core i7-2600k. Con talune applicazioni che non sfruttano al meglio la potenza degli ambienti multi-core i numeri scendono al di sotto di quelli della diretta rivale Core i5-2500k seppure il bilancio complessivo, nei confronti di quest’ultima, sia a vantaggio del modello Bulldozer.
Stupisce vedere il fatto che con una diversa politica di gestione dei thread le cose sarebbero potute andar meglio per la nuova serie di processori AMD FX. Ma allora perché non realizzare un driver software o lavorare fianco a fianco con i produttori di schede madri per trovare una qualche possibilità da attuare attraverso il bios?
Infine la scalabilità offerta dalla CPU FX-8150 è decisamente buona con tutte le applicazioni provate. Se non tenessimo in conto la modalità Turbo Core potremmo affermare che ogni MHz di incremento corrisponde ad una tacca di miglioramento prestazionale. Includendo nel conto anche la tecnologia turbo, il quadro dei risultati ottenuti non muta di molto: con applicazioni multi-threaded i vantaggi offerti dalla CPU overcloccata restano quasi gli stessi mentre con applicazioni non ottimizzate per ambienti multi core il miglioramento si riduce a circa la metà.
Se AMD avesse potuto lavorare sulle frequenze delle nuove CPU siamo certi che il quadro prestazionale generale sarebbe di sicuro volto a proprio favore probabilmente anche nei confronti dei concorrenti più agguerriti.
Tirando le somme di tutto il discorso, pensiamo che AMD avrebbe potuto mettere in campo più di una ottimizzazione per trovarsi fra le mani un prodotto decisamente più potente e magari capace di dare seriamente del filo da torcere alle soluzioni avversarie. Questo avrebbe permesso all’azienda di ampliare anche il range di prezzi nel quale muoversi: per proporre, magari, più modelli capaci di accontentare gli utenti esigenti in fatto di prestazioni come quelli attenti al portafogli.
A cura di Dino Fratelli
Ti potrebbe interessare
8 nov 2011