Link alla notizia: http://news.hwupgrade.it/12263.html

AMD prosegue lo sviluppo delle proprie soluzioni Athlon 64 con processo produttivo a 0.09 micron. Il debutto sul mercato è atteso tra fine 2004 e inizio 2005

Click sul link per visualizzare la notizia.

Ehm....test OK ma i risultati? nisba?

[quote+Ehm....test OK ma i risultati? nisba? [/quote]
E secondo te', li fanno leggere a noi??? :D

Secondo me il progresso dei processori sta fortemente rallentando. Facendo un empiricissima analisi delle recensioni dei processori AMD su HwUp:
Athlon 600Mhz giugno 1999
Athlon Tbird 1Gh giugno 2000
Athlon XP 1800+ ottobre 2001
Athlon XP 3000+ febbraio 2003
e forse a fine 2004 vedremo un processore che raddoppi le prestazioni dell'XP 1800+ del 2001.
A nasometro, si può dire che negli ultimi 3 anni si è compiuto lo stesso incremento prestazionale del precedente anno e mezzo.
Commenti?

Ps ho usato AMD per avere un model number + o - confrontabile, non vuole essere un calcolo dettagliato e preciso!

Questa notizia era apaprsa ieri su xbitlabs. Tuttvia oggi è apparsa un'altra notizia (pare da fonte nettament più attendibile) di orientamento esattamente opposto ( http://www.xbitlabs.com/news/cpu/display/20040420082153.html) , ossia AMD sta iniziando ora la produzione di CPU a 0.09 micron.

secondo me ne vedremo delle belle cn la tech a 0,09 micron!

La vedo dura per intel ...
già bastano 2500 mhz del 64 per dare testa a 4.0 ghz del precotto ...
i 0.09u partono da 2600 mhz ...

La politica di AMD di andare avanti per piccoli passi e del miglioramento continuo rispettando i tempi di maturazione delle tecnologie paga.....

chissà se avranno gli stessi problemi di temps di intel...

Ragazzi, il mio ultimo procio INTEL è stato un P166, però:
- i prescott non sono eccitanti, però in certe situazioni se la cavano meglio degli AMD anche a parità di prezzo (es. compressione MPEG2/4 etc., che guardacaso oggi ha nel processore il collo di. Il tutto anche se fortemente overcloccati; vedi prova su THG di ieri dove il PIV (EE) a 4 Ghz convertiva + rapidamente dell'Athlon FX a 2,9Ghz (ammetto che mi ha molto stupito). Dobbiamo prendere atto che non si può più dire A e meglio di B e basta ma bisogna vedere cosa devi farci.
- la politica di AMD in merito allo spremere il possibile dalle tecnologie sempre stata più aggressiva di Intel; un indicatore può essere la temperatura di funzionamento dei processori. Solo con i Prescott e gli A64 si è vista una inversione; sennò è da dieci anni che AMD spreme il possibile e Intel è più conservativa.

Ehm... intendo collo di bottiglia...

e' normale che il P4 lavori molto bene con quei software, per via dell'architettura

Oggettivamente AMD e Intel sono quasi alla pari, semplicemente adottano strategie diverse, chi con i Mhz chi con l'architettura.

Il vero sorpasso lo vedremo quando una delle due unirà entrambi i concetti.

E cmq sono scettico sui reali vantaggi dei 64bit... indirizzamento a oltre 4gb di memoria e poi?

Un Athlon 64 ora come ora è + veloce per via del controller delle memorie integrato...

Speriamo che Intel risolva tutti i problemi a 0,09 e esca con proci competitivi ... altrimenti lo sviluppo rallenterà sempre di + ed i prezzi dei processori resteranno alti.

@warduck
Io uso un programma di calcolo struttrale che si chiama sap2000 e qualunque ingegnere civile lo conosce.
Beh innanzitutto è scritto per usare numeri a 64 bit per natura delle grandezze e per la dimensione delle matrici che vengono impiegate nel calcolo.
Poi ho fatto una prova comparativa tra un p4 2.4 ed un athlon64 3200+ in modalità 32-bit. Un sistema di 31000 equazioni. p4: 46 sec; athlon64: 24 sec. Tu mi potrai obiettare che il p4 doveva essere 3.2 per essere confrontato, ma è quello che avevo. Resta una differenza abissale.

Originariamente inviato da WarDuck
E cmq sono scettico sui reali vantaggi dei 64bit... indirizzamento a oltre 4gb di memoria e poi?

Un Athlon 64 ora come ora è + veloce per via del controller delle memorie integrato...

non sono d'accordo, e ti spiegherò perché;

_____________________________________


Optimization

Use 64-bit registers for 64-bit integer arithmetic.

Rationale
Using 64-bit registers instead of their 32-bit equivalents can dramatically reduce the amount of code necessary to perform 64-bit integer arithmetic.

Example 1
This code performs 64-bit addition using 32-bit registers:
; Add ECX:EBX to EDX:EAX, and place sum in EDX:EAX.
00000000 03 C3 add eax, ebx
00000002 13 D1 adc edx, ecx

Using 64-bit registers, the previous code can be replaced by one simple instruction (assuming that RAX and RBX contain the 64-bit integer values to add):
00000000 48 03 C3 add rax, rbx

Although the preceding instruction requires one additional byte for the REX prefix, it’s still one byte shorter than the original code. More importantly, this instruction still has a latency of only one cycle, uses two fewer registers, and occupies only one decode slot.


Example 2
To perform the low-order half of the product of two 64-bit integers using 32-bit registers, a procedure
such as the following is necessary:
; In: [ESP+8]:[ESP+4] = multiplicand
; [ESP+16]:[ESP+12] = multiplier
; Out: EDX:EAX = (multiplicand * multiplier) % 2^64
; Destroys: EAX, ECX, EDX, EFlags
llmul PROC
mov edx, [esp+8] ; multiplicand_hi
mov ecx, [esp+16] ; multiplier_hi
or edx, ecx ; One operand >= 2^32?
mov edx, [esp+12] ; multiplier_lo
mov eax, [esp+4] ; multiplicand_lo
jnz twomul ; Yes, need two multiplies.
mul edx ; multiplicand_lo * multiplier_lo
ret ; Done, return to caller.
twomul:
imul edx, [esp+8] ; p3_lo = multiplicand_hi * multiplier_lo
imul ecx, eax ; p2_lo = multiplier_hi * multiplicand_lo
add ecx, edx ; p2_lo + p3_lo
mul dword ptr [esp+12] ; p1 = multiplicand_lo * multiplier_lo
add edx, ecx ; p1 + p2_lo + p3_lo = result in EDX:EAX
ret ; Done, return to caller.
llmul ENDP

Using 64-bit registers, the entire product can be produced with only one instruction:
; Multiply RAX by RBX. The 128-bit product is stored in RDX:RAX.
00000000 48 F7 EB imul rbx

_______________________________

bastava chiedere ;)

x tasso79
(...)Poi ho fatto una prova comparativa tra un p4 2.4 ed un athlon64 3200+ in modalità 32-bit.... (...)Tu mi potrai obiettare che il p4 doveva essere 3.2 per essere confrontato, ma è quello che avevo. Resta una differenza abissale.


ti sei obiettato da solo... bravo :P
e infatti la differenza abissale che resta è tra il pentium 2.4 e l'athlon64 3.2+, differenza che c'è anche senza tutti quei calcoli... :rolleyes: mi dispiace ma non dimostri nulla con quel discorso...
(non intendo essere ostile, è solo una considerazione)

quoto invece il commento di avvelenato

Credo che quello che voleva dire tasso79 è che 24/46 < 2400/3200. Ad ogni modo, era noto che i programmi che utilizzano pesantemente calcoli in virgola mobile e non sono ottimizzati per le SSE2-3 (ed alcuni, come il SAP, non lo saranno per molto tempo) vengono eseguiti molto più velocemente dalla famiglia Athlon che non da quella P4 (come è vero che il video editing in genere è più rapido sui P4). Inoltre, le differenze prestazionali tra Athlon e Athlon 64 per questi calcoli in modalità 32 bit, a parità di clock, è trascurabile, poichè in pratica le due CPU hanno in comune gran parte del design della FPU. Bisogna anche ricordare, come riporta avvelenato, che tutti quei programmi che usano molte variabili a 64 bit avranno notevoli vantaggi nel passaggio alla modalità x86-64, in quanto si evitano tantissime operazioni di "spezzettamento" e "ricomposizione" dei dati.

prima o poi la corsa ai GHz finirà non si potra' sempre alzare la frequenza. quindi la tattica dell'architettura non è da buttare.

si parla già di dual core come mai?

ricordiamoci che intel i 64 bit li deve ancora uscire. Vogliamo confrontare l'athlon64 con un itanium2?

led concordo....anzi io sono il sostenitore piu accanito della corsa all' architettura piuttosto che clock...del resto re ti regalassero uno fra un 2ghz bus250 e 2ml2 o un 3 ghz bus200 e 1ml2 cosa sceglieresti (premettendo che a sti livelli vanno bene tutti, ma era un esempio banale e irreale lol!!!)??

AH dimenticavo... i mhz e l'architettura complessa non sono state ancora unite per il semplice fatto che non è possibile!! I mhz elevati escono grazie all'architettura a più stadi! Amd se nn aumenta il numero di stadi non può salire di frequenza. Ovviamente aumentare il numero di stadi implica una perdita di efficenza a pari Mhz per via dei salti. E quello che può guadagnare intel con la frequenza amd lo riprende potenziando l'architettura a meno stadi. In conclusione si hanno du earchitetture cmq buone ma in diverse condizioni d'uso!

Alex.

dnarod. l'esempio da te portato è un po' inutile.. perché cmq maggiore cache e bus non vogliono dire architetture diverse.. in dipendenza della architetture si hanno determinate cache... infatti amd per la sua si accontenta di 512 kb e a intel non basterebe mai... sta a 1 mb ma se potessero senza costi aggiuntivi ne metterebbero pure 4 :p

dnarod.. scusa non avevo capito :D Sono ancora assonnato! :)

Cmq i veri test andranno fatti con applicativi ottimizzati per X86-64....

Ora usare un sistema operativo a 32 bit per fare i test e' inutile... e' logico che sia ottimizzato piu' per gli x86-32 e stop...

Per quanto riguarda la corsa al Mhz ... posso solo dire che una volta, prima dell'avvento della VooDoo.. l'unica cosa che si cambiava era il processore... dopo VooDoo si inizio' con le schede video... poi la ram calo a bestia e via di ram.. idem gli hard disk...

Attualmente una persona che cambia qualche componente all'anno non vede la corsa solo al mhz ma anche al GB di HD.. della ram... della scheda video e cosi' via..

Che ormai parliamoci chiaro... l'unica cosa che veramente si rivoluziona ogni volta e' il reparto video.. ogni volta nuovi chip, nuove tecnologie e revisioni di cose vecchie migliorate a bestia...

Per me la corsa al mhz e' finita quando Ati e Nvidia hanno iniziano la loro "guerra"

:)

speriamo che la maggiore "riflessività" con cui AMD sta adottando il nuovo processo produttivo gli eviti tutti i problemi che si sono verificati per mamma Intel :)

Originariamente inviato da leoneazzurro
Credo che quello che voleva dire tasso79 è che 24/46 < 2400/3200. Ad ogni modo, era noto che i programmi che utilizzano pesantemente calcoli in virgola mobile e non sono ottimizzati per le SSE2-3 (ed alcuni, come il SAP, non lo saranno per molto tempo) vengono eseguiti molto più velocemente dalla famiglia Athlon che non da quella P4 (come è vero che il video editing in genere è più rapido sui P4). Inoltre, le differenze prestazionali tra Athlon e Athlon 64 per questi calcoli in modalità 32 bit, a parità di clock, è trascurabile, poichè in pratica le due CPU hanno in comune gran parte del design della FPU. Bisogna anche ricordare, come riporta avvelenato, che tutti quei programmi che usano molte variabili a 64 bit avranno notevoli vantaggi nel passaggio alla modalità x86-64, in quanto si evitano tantissime operazioni di "spezzettamento" e "ricomposizione" dei dati.

non era per fare flame, e ho l'ho già scritto... mi scuso comunque con tasso79 se leggendo il post può sembrare il contrario
:)

Ma quanti di voi hanno provato un 64 ???
Poi vedrete chi va più forte ....
niente a che vedere con XP32 bit

Originariamente inviato da Firedraw
ricordiamoci che intel i 64 bit li deve ancora uscire.
Nessuno ti garantisce che la sua implementazione sarà più veloce di quella di AMD. Anzi, potrebbe anche risultare nettamente inferiore.
Vogliamo confrontare l'athlon64 con un itanium2?
Facciamolo pure. ;)

Originariamente inviato da DeMonViTo
Cmq i veri test andranno fatti con applicativi ottimizzati per X86-64....

Ora usare un sistema operativo a 32 bit per fare i test e' inutile... e' logico che sia ottimizzato piu' per gli x86-32 e stop...

Per quanto riguarda la corsa al Mhz ... posso solo dire che una volta, prima dell'avvento della VooDoo.. l'unica cosa che si cambiava era il processore... dopo VooDoo si inizio' con le schede video... poi la ram calo a bestia e via di ram.. idem gli hard disk...

Attualmente una persona che cambia qualche componente all'anno non vede la corsa solo al mhz ma anche al GB di HD.. della ram... della scheda video e cosi' via..

Che ormai parliamoci chiaro... l'unica cosa che veramente si rivoluziona ogni volta e' il reparto video.. ogni volta nuovi chip, nuove tecnologie e revisioni di cose vecchie migliorate a bestia...

Per me la corsa al mhz e' finita quando Ati e Nvidia hanno iniziano la loro "guerra"

:)

cio'e' possibile per un motivo: che l'elaborazione della GPU e' gestita da driver che sanno se essa e' in grado di elaborare un certo codice oppure no, nel qual caso eseguiranno i suddetti calcoli via software mediante la CPU.

Dovendo attenersi ad un codice obsoleto e tendenzialmente invariante (se non per le aggiunte tipo sse, mmx etc), le cpu non possono avere lo stesso tipo di evoluzione delle gpu, perche' se un software richiedesse il supporto ad un certo set di istruzioni per funzionare, funzionerebbe solo su hardware che le supporta e solo su quello. Anche se fosse possibile gestirle via software, sarebbe impossibile utilizzarle per via della lentezza che tale operazione causa, quindi ogni step software che rendesse necessario uno step hardware, renderebbe di fatto inutilizzabili un sacco di macchine, tutte quelle precedenti. Questo accade per esempio per gli ultimi giochi, i quali per esempio richiedono le directx9, ma funzionano sia su hardware che accelera le funzioni delle dx9, sia su hardware che non lo ha. Se la potenza di calcolo e' sufficiente, si riesce ad usarli ugualmente, se l'hardware e' vecchio, ma vecchio di anche solo un anno, il gioco e' di fatto inutilizzabile.
Finche' e' un gioco, valà, ma se sono software "seri", cio' non e' concepibile, per via della protezione di un investimento che spesso non puo' essere ammortizzato in poco tempo.
Ovviamente se i vantaggi di un'evoluzione del codice supportato a livello hardware fossero limitati a pochi programmi, non avrebbe senso.
L'unica cosa fattibile in questo caso e' aggiungere istruzioni usate solo se supportate dall'hardware.

grazie avvelenato per la precisazione, purtroppo sono ignorante in materia, ma per quello che ho capito, i 64bit mi consentirebbero di ridurre il numero di istruzioni per eseguire calcoli con quella dimensione.

Ok, ora aspettiamo i bench reali ^^

Lol non avevo letto il commento di tasso :eek:

Ritiro le "accuse" :p