AMD lancia l'Athlon 64 più economico

Il chipmaker ha lanciato il suo processore Athlon 64 meno costoso, il primo a portare il prezzo di questi chip al di sotto dei 180 dollari

Sunnyvale (USA) - Lanciato in sordina all'inizio della settimana, il nuovo Athlon 64 2800+ è il modello più economico della famiglia di CPU a 64 bit di AMD.

Il nuovo processore, che va ad affiancare i modelli 3000+, 3200+ e 3400+, gira ad una frequenza di clock di 1,8 GHz, contiene 512 KB di memoria cache di secondo livello e costa 178 dollari per ordini di 1.000 unità.

Con l'introduzione di questo modello entry-level, AMD spera di spingere i propri giovani AMD64 sui PC desktop di fascia mainstream, la stessa dove oggi tengono ancora banco gli Athlon XP. Questi ultimi sono destinati a prendere progressivamente il posto dei Duron e lasciare la fetta più grossa del mercato ai cugini a 64 bit.
AMD sostiene che, nelle applicazioni a 32 bit, un Athlon 64 è in grado di fornire fra il 10% e il 15% di prestazioni in più rispetto ad un Athlon XP di pari frequenza: questo incremento è in buona parte dovuto alla nuova e più efficiente architettura e all'integrazione di un controller di memoria.

Per promuovere sul mercato i suoi nuovi processori, lo scorso anno AMD ha preferito lanciare dapprima il modello 3200+, costoso ma capace di ben figurare nei benchmark, e solo in seguito i due modelli più economici 3000+ e 2800+.

Di recente AMD ha lanciato l'Athlon 64 FX-53, una nuova versione "pompata" dell'Athlon 64 indirizzata in modo particolare agli appassionati di videogiochi e agli utenti più esigenti.
TAG: hw
20 Commenti alla Notizia AMD lancia l'Athlon 64 più economico
Ordina
  • ad esempio in ambito scientifico
    http://www.democritos.it/activities/IT-MC/talks/ta...

    inoltre
    "High performance servers, database management systems, CAD workstations, and even common desktops will benefit from a 64-bit design"

    "The k8 also expands the amount of available CPU registers, thus offering faster computational performance than current CPU designs do."

    "Processor intensive software functions, such as graphics transform and lighting, circuit simulation, and scientific processing will directly benefit from the x86-64 architecture. Combined with native support for 16- and 32-bit software, the AMD K8 will prove to be a very competitive platform."

    http://sysopt.earthweb.com/articles/k8/index.html
    non+autenticato

  • Quando arrivarono le prime CPU a 64 bit si e' partiti subito coi benchmark, quelli fatti in modo serio hanno dato risultati deludenti, la CPU a 64bit ha senso sui server dove e' necessario trattare enormi database.
    A livello di velocita' sui desktop o si hanno dimensioni enormi di cache di 2° e 3° livello o le prestazioni sono anche inferiori.

    Da qualche giorno a questa parte i benchmark "seri" sono spariti. Li fanno poche riviste e non vengono qusi mai presi in considerazione. In pubblicita' e presentazioni si fa quasi sempre riferimento a quelli ufficiali dei produttori del chip, come quando si chiede all'oste se il vino e' buono.
    Da un 5-10% in meno di prestazioni dei vecchi benchmark ora si parla di percentuali altissime di guadagno.

    Io credo al complotto. Credo che i 64bit introdotti in un mercato dove non servono a nessuno (quello desktop) sia l'ennesima espressione di obsolescenza programmata e invito per gli utenti a rinnovare l'hardware.
    non+autenticato

  • - Scritto da: Anonimo
    > Io credo al complotto. Credo che i 64bit
    > introdotti in un mercato dove non servono a
    > nessuno (quello desktop) sia l'ennesima
    > espressione di obsolescenza programmata e
    > invito per gli utenti a rinnovare
    > l'hardware.

    I 64 bit servono praticamente solo ad indirizzare più di 4 gigabyte di memoria. Oggi per i desktop servono a pochi (nessuno?), ma sicuramente non è più una dimensione fantascientifica.

  • - Scritto da: sigsegv

    > I 64 bit servono praticamente solo ad
    > indirizzare più di 4 gigabyte di
    > memoria. Oggi per i desktop servono a pochi
    > (nessuno?), ma sicuramente non è
    > più una dimensione fantascientifica.

    Quando le DIMM da 4Gb saranno diffuse e costeranno come lo sono state le simm da 4Mb nel 96-97 allora sara' il momento di comprare CPU a 64 bit che costeranno un'80ina di euro.
    Prima di allora non serviranno a nessuno.

    non+autenticato

  • - Scritto da: Anonimo
    >
    > - Scritto da: sigsegv
    >
    > > I 64 bit servono praticamente solo ad
    > > indirizzare più di 4 gigabyte di
    > > memoria. Oggi per i desktop servono a
    > pochi
    > > (nessuno?), ma sicuramente non è
    > > più una dimensione
    > fantascientifica.
    >
    > Quando le DIMM da 4Gb saranno diffuse e
    > costeranno come lo sono state le simm da 4Mb
    > nel 96-97 allora sara' il momento di
    > comprare CPU a 64 bit che costeranno
    > un'80ina di euro.
    > Prima di allora non serviranno a nessuno.
    >


    Concordo con voi sul fatto che i 64 bit ora come ora non possano servire più di tanto (oddio, alcuni famosi videogame di adesso hanno mostrato le prime ottimizzazioni in questo senso, vedi Far Cry)... ma la cosa più ovvia che mi balza nella mente è che se non volete aggiornarvi, semplicemente non fatelo... qualcuno ve lo impone? Queste sono solo seghe mentali.. chi lo vuole se lo prende.. io personalmente credo che per questo Natale faro parte della schiera dei 64 bit, fate vobis.
    non+autenticato
  • apparte che fintantoché non si vedono dei bench sarebbe inutile parlare, cmq le cpu di AMD sono ottime nel 32, e questo indipendentemente dalla loro potenza nel 64bits.

    per il resto, a molti la potenza serve, ad altri fa comodo ma non è indispensabile, d'altra parte non è un mistero che ogni componente sw, anche il più complesso, potrebbe costare anche 1? al pezzo con una produzione in vasta scala.. il punto è che per ridurre i costi bisogna aumentare le tirature,e questo si può fare solo aumentando la domanda.
  • In questo sistema quanto è grande la tabelle delle pagine e in quanti livelli è suddivisa? 3?
    non+autenticato
  • Penso sia necessario standardizzare una ratifica universalmente accettata di benchmark a 64bits, così da valutare le prestanze di queste cpu.

    la x86-64, avendo puntatori e alcune istruzioni più lunghi, probabilmente comporterà un'incremento della dimensione del codice. Non so di quanto, voci mi hanno suggerito intorno al 15%, e se fosse così non sarebbe poi così significativo.

    Comunque, questo significa che i 512kbyte di cache su utilizzo 32bits valgono di più rispetto agli stessi su 64bits, o detto più chiaramente, l'arch. a 64 bits richiederebbe più cache.


    se poi questa cache in più richiesta in realtà è nell'ordine del 15%, penso non ci siano grossi "degradi" prestazionali, almeno fino a quando si sta sui 512kbites e oltre.

    il core Paris, che invece ne avrà 256, mi pare che avrà le istruzioni a 64bits disabilitate, quindi il problema non si pone ( forse AMD le vuole disabilitare per nascondere il fatto che quella cpu sui 64bits potrebbe risultare in alcune appz più lenta rispetto all'uso su 32??)


    avve che comunque adora le xp (per l'overclock sono sempre ottime, specie le M)

  • - Scritto da: avvelenato
    > Penso sia necessario standardizzare una
    > ratifica universalmente accettata di
    > benchmark a 64bits, così da valutare
    > le prestanze di queste cpu.
    CUT

    Scusa la domanda un po' ingenua, ma non sono
    così afferrato nello specifico campo
    (sarà anche l'ora che non mi aiuta).

    Intendi dire che con Bench per 64bit
    risulterebbe più lento?


  • - Scritto da: carbonio
    >
    > - Scritto da: avvelenato
    > > Penso sia necessario standardizzare una
    > > ratifica universalmente accettata di
    > > benchmark a 64bits, così da
    > valutare
    > > le prestanze di queste cpu.
    > CUT
    >
    > Scusa la domanda un po' ingenua, ma non sono
    > così afferrato nello specifico campo
    > (sarà anche l'ora che non mi aiuta).
    >
    > Intendi dire che con Bench per 64bit
    > risulterebbe più lento?
    >

    non proprio.

    intendo dire che, se in una CPU x86-64 con 1mega di cache, l'incremento prestazionale di un programma progettato e compilato per 64bits può essere più efficiente (ipoteticamente) del 45% rispetto alla stessa versione a 32bits, una cpu simile in clock ma con 512mega di cache, potrebbe avere un incremento del 35% nel passaggio dai 32 ai 64...

    cioé in pratica la cache viene usata di più in modalità a 64 bits, di quanto non lo so bene e comunque dipende da programma a programma, però potrebbe anche essere che un quantitativo di cache appena sufficiente per la modalità a 32bits (ad esempio il Paris ne ha 256) magari (ma è solo un ipotesi!) a 64bits non avrebbe sufficiente spazio, e avrebbe bisogno di accedere alla RAM più frequentemente (e le RAM comportano alcune latenze d'accesso), con il risultato di peggiorare le prestazioni, anziché migliorarle.


    aspetto che qualche tecnico più esperto di me confermi!
  • intanto ti ringrazio del chiarimento
    (anche se per capirlo bene è meglio che me lo
    rilegga domani;))

  • - Scritto da: avvelenato

    > aspetto che qualche tecnico più
    > esperto di me confermi!

    Quello che hai detto e' valido per una cpu in cui
    tra modalita a 32bit e modalita a 64bit cambia
    solo la lunghezza in bit dei registri e la dimensione
    dei dati immediati e degli offset nelle istruzioni
    che diventano per default a 64bit
    (con conseguenza che a parita di algoritmo viene
    richiesto molto piu spazio per memorizzare
    il codice da eseguire e viene richiesto piu spazio
    per memorizzare i dati in cache).

    Gli x86-64 hanno parecchi assi nella manica
    introdotti nel modo a 64bit che aiutano ad
    alzare ulteriormente le prestazioni.

    In modo 64bit l''indirizzamento di default e' a 64bit
    ma la dimensione di default dei dati e' 32bit
    (in modo tale che le combinazioni dati & indirizzamento
    piu utilizzate siano anche quelle piu compatte).

    Vengono raddoppiati *in numero* tutti
    i registri prevedibilmente piu utilizzati
    (quindi ci sono piu dati elaborati a massima velocita
    senza toccare le cache).

    Inoltre (e paradossalmente) a causa del formato delle
    istruzioni x86-64 uno stesso programma (a livello di sorgente)
    in forma binaria e' in media piu compatto
    ripetto a delle cpu RISC a 64bit (ed enormemente piu
    compatto rispetto agli Itanium), questo permette di sfruttare
    meglio la cache L1 e di stressare meno
    il resto del sistema per caricare istruzioni
    (la complicazione "aggiuntiva" a livello di decoder
    che ci deve essere comunque per eseguire
    anche il codice a x86 32bit in compenso permette
    di avere "gratis" istruzioni "compatte" nel formato a 64bit).
    non+autenticato
  • - Scritto da: Anonimo
    >
    > - Scritto da: avvelenato
    >
    > > aspetto che qualche tecnico più
    > > esperto di me confermi!
    >
    > Quello che hai detto e' valido per una cpu
    > in cui
    > tra modalita a 32bit e modalita a 64bit
    > cambia
    > solo la lunghezza in bit dei registri e la
    > dimensione
    > dei dati immediati e degli offset nelle
    > istruzioni
    > che diventano per default a 64bit
    > (con conseguenza che a parita di algoritmo
    > viene
    > richiesto molto piu spazio per memorizzare
    > il codice da eseguire e viene richiesto piu
    > spazio
    > per memorizzare i dati in cache).
    >
    > Gli x86-64 hanno parecchi assi nella manica
    > introdotti nel modo a 64bit che aiutano ad
    > alzare ulteriormente le prestazioni.
    >
    > In modo 64bit l''indirizzamento di default
    > e' a 64bit
    > ma la dimensione di default dei dati e' 32bit
    > (in modo tale che le combinazioni dati &
    > indirizzamento
    > piu utilizzate siano anche quelle piu
    > compatte).
    >
    > Vengono raddoppiati *in numero* tutti
    > i registri prevedibilmente piu utilizzati
    > (quindi ci sono piu dati elaborati a massima
    > velocita
    > senza toccare le cache).
    >
    > Inoltre (e paradossalmente) a causa del
    > formato delle
    > istruzioni x86-64 uno stesso programma (a
    > livello di sorgente)
    > in forma binaria e' in media piu compatto
    > ripetto a delle cpu RISC a 64bit (ed
    > enormemente piu
    > compatto rispetto agli Itanium), questo
    > permette di sfruttare
    > meglio la cache L1 e di stressare meno
    > il resto del sistema per caricare istruzioni
    > (la complicazione "aggiuntiva" a livello di
    > decoder
    > che ci deve essere comunque per eseguire
    > anche il codice a x86 32bit in compenso
    > permette
    > di avere "gratis" istruzioni "compatte" nel
    > formato a 64bit).

    beh è risaputo che le risc hanno dei programmoni giganteschi laddove con quattro istruzioni cisc risolvi tutto.Sorride ovviamente il mio confronto è tra architettura x86-32bits e x86-64

    ps: ma mi dicevano che per gli x86 è oramai poco sensato usare il termine cisc, ma è tanto scorretto usarlo? in fondo, anche nel caso in cui integrino un alpha+traduttore (non so quale famiglia usi quest'architettura), all'esterno rimane sempre una cpu-cisc, concettualmente, o no?

  • - Scritto da: avvelenato
    > ps: ma mi dicevano che per gli x86 è
    > oramai poco sensato usare il termine cisc,
    > ma è tanto scorretto usarlo? in
    > fondo, anche nel caso in cui integrino un
    > alpha+traduttore (non so quale famiglia usi
    > quest'architettura), all'esterno rimane
    > sempre una cpu-cisc, concettualmente, o no?

    Non credo proprio sia scorretto definirli CISC.
    CISC = Complex Instruction Set Computer
    e viste le oltre 200 istruzioni di un pentium senza contare quelle per mmx, sse, sse2 ecc.... la vedo dura a chiamarli RISC.
    RISC = Reduced Instruction Set Computer
    Il solo fatto che abbiano incluso alcune caratteristiche tipiche dei RISC non li fa diventare a tutti gli effetti CISC.

    E' vero che un programma per un RISC occupa più istruzioni, ma non è per questo meno veloce di un corrispondente CISC, il fatto è che i RISC hanno un architettura più semplice e questo rende possibile un uso più efficiente della pipeline

    un link
    http://www.lithium.it/articolo.asp?code=20&pag=6
    non+autenticato

  • - Scritto da: Anonimo
    >
    > Non credo proprio sia scorretto definirli
    > CISC.
    > CISC = Complex Instruction Set Computer
    > e viste le oltre 200 istruzioni di un
    > pentium senza contare quelle per mmx, sse,
    > sse2 ecc.... la vedo dura a chiamarli RISC.
    > RISC = Reduced Instruction Set Computer
    > Il solo fatto che abbiano incluso alcune
    > caratteristiche tipiche dei RISC non li fa
    > diventare a tutti gli effetti CISC.
                                                   ^^^^^
    RISC intendevo
    non+autenticato
  • - Scritto da: Anonimo
    >
    > E' vero che un programma per un RISC occupa
    > più istruzioni, ma non è per
    > questo meno veloce di un corrispondente
    > CISC, il fatto è che i RISC hanno un
    > architettura più semplice e questo
    > rende possibile un uso più efficiente
    > della pipeline
    >
    > un link
    > www.lithium.it/articolo.asp?code=20&pag=6

    sì sì lo sapevo, (cmq grazie x il link, anche se già lo conoscevo), era solo per chiarirsi, a volte ne nascono diatribe infinite su cosa è cisc e cosa non lo è... due palle! per me l'acronimo si spiega benissimo, e se non è complesso un set di 200istruzioni, allora ce ne vogliono duemila per poterlo definire complesso?A bocca aperta

  • - Scritto da: avvelenato

    > Comunque, questo significa che i 512kbyte di
    > cache su utilizzo 32bits valgono di
    > più rispetto agli stessi su 64bits, o
    > detto più chiaramente, l'arch. a 64
    > bits richiederebbe più cache.

    La cache di secondo livello e' solo dati, non istruzioni. Quindi le differenze sono molto piu' piccole del 15%.
    non+autenticato

  • - Scritto da: Anonimo
    >
    > - Scritto da: avvelenato
    >
    > > Comunque, questo significa che i
    > 512kbyte di
    > > cache su utilizzo 32bits valgono di
    > > più rispetto agli stessi su
    > 64bits, o
    > > detto più chiaramente, l'arch. a
    > 64
    > > bits richiederebbe più cache.
    >
    > La cache di secondo livello e' solo dati,
    > non istruzioni. Quindi le differenze sono
    > molto piu' piccole del 15%.

    ciò mi rassicura.