Roberto Pulito

AMD: cercasi benchmark affidabile

Il chipmaker USA non considera attendibili le misurazioni del SYSmark 2012 e non sosterrà più il noto strumento di benchmarking

Roma - Advanced Micro Devices non si fida del metro di valutazione scelto dal consorzio BAPCo (Business Applications Performance Corporation) e ha deciso che non sosterrà più SYSmark, noto tool di benchmarking che misura le prestazioni hardware. A quanto sembra, anche Via e NVidia hanno seguito il chipmaker USA in questo improvviso boicottaggio.

Secondo AMD, l'edizione 2012 di SYSmark non sarebbe abbastanza affidabile e "trasparente". Il portavoce dell'azienda spiega che il nuovo benchmark non prende in considerazione le prestazioni della fusione tra CPU+GPU e che un questo modo le reali performance dell'architettura APU (Accelerated Processing Unit) non vengono evidenziate a dovere.

Tra le righe si legge insomma che i test benchmark di questo tipo favorirebbero soltanto gli altri fabbricanti del consorzio BAPCo, capitanato dal rivale Intel e composto da altri colossi come Dell, HP, Hitachi, Lenovo, Microsoft, Samsung, Seagate, Sony e Toshiba.
A questo punto AMD non esclude neppure di mettersi in proprio, insieme agli altri contestatori, per creare un nuovo consorzio e un nuovo benchmark "open". Uno strumento dalle caratteristiche più elastiche, che recepisca i trend del futuro e i reali carichi di lavoro di un sistema.

Roberto Pulito
Notizie collegate
  • TecnologiaAMD non crede nel fulmine IntelSecondo il chipmaker, il mondo non aveva bisogno di un ulteriore standard proprietario. L'interconnessione di Thunderbolt non rappresenterebbe un vero passo avanti
  • TecnologiaAMD: solo x86, grazieAdvanced Micro Device smentisce la collaborazione con ARM. Il chipmaker USA resterà ancora legato all'architettura x86 e porterà avanti il discorso APU anche in campo mobile
  • TecnologiaAMD, ritorno al marchio FXIl chipmaker USA decide di reintrodurre il prestigioso bollino di qualità per le CPU Bulldozer top di gamma. In arrivo entro settembre
5 Commenti alla Notizia AMD: cercasi benchmark affidabile
Ordina
  • tra le varie "ottimizzazzioni" del compilatore intel ce ne sara' una del tipo:
    if (CPU_BREND != INTEL)
    then
        (
         METTILA_IN_CULO_ALLA_CPU = true;
         ABILITA_MULTICORE = non_tutti;
         introduci_stati_di_attesa(a_manetta);
         ABILITA_ESTENSIONI_MULTIMEDIALI = false;
        )
    non+autenticato
  • Non è più un problema di compilatore nelle ultime versioni non c'entra (quasi) più quello piuttosto sono le librerie runtime che sono indispensabili per far girare i binari generati che fanno tutti i controlli, ma con poche semplici patch si sistemano.
    Sarebbe interessante far girare il sysmark su una macchina amd prima e dopo il patch e vedere come si comporta.
    mura
    1720
  • - Scritto da: mura
    > Non è più un problema di compilatore nelle ultime
    > versioni non c'entra (quasi)
    Quasi, l'ottimizzatore per sse della Microsoft passando da vs2008 a vs2010 si è "accorto" di avere 8 registri a disposizione invece di 4Occhiolino
    non+autenticato
  • - Scritto da: mura
    > Non è più un problema di compilatore nelle ultime
    > versioni non c'entra (quasi) più quello piuttosto
    > sono le librerie runtime che sono indispensabili
    > per far girare i binari generati che fanno tutti
    > i controlli, ma con poche semplici patch si
    > sistemano.
    > Sarebbe interessante far girare il sysmark su una
    > macchina amd prima e dopo il patch e vedere come
    > si
    > comporta.

    E con che compilatore credi vengano compilate le librerie?
    Un test vero sarebbe a mio avviso da fare con TUTTO compilato da GCC, una volta per INTEL e una volta per AMD, ma qui parte la pippa del "figurati se ricompiliamo da zero per avere dei test certi", "ci affidiamo a suite di test che sono standard del setore", etc etc.
    non+autenticato
  • - Scritto da: attonito
    > E con che compilatore credi vengano compilate le
    > librerie?

    Non hai capito cosa intendevo, il controllo sulla cpu viene fatto nelle librerie runtime per stabilire quale percorso e con queli istruzioni eseguire le varie routine di base delle stesse.

    Alla fine quello che fa veramente la differenza in termini di tempi di esecuzione è quanto sono ottimizzate le librerie runtime dato che anche il buon vecchio gcc, nelle sue ultime versioni, svolge un compito più che discreto ma poi ci stà la glibc (almeno sotto linux) a rovinare parte del lavoro.
    mura
    1720