AMD o Intel così come la marca di memoria - pagina 73
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Perché. Sono anche molto interessato alla velocità di calcolo delle cose serie
Beh, siamo in tre. Ancora non molto.
Ho capito molto bene la tua idea. Ma penso che carichiamo il tester in modo sbagliato. Il mio punto, d'altra parte, non sembra averlo capito. Ma non importa, in generale. Per l'orientamento, per così dire, "sul terreno", quest'ultimo esperto andrà bene.
OK. Non è un casus belli per i mariti decenti, vero? ))) Sono anche interessato alla velocità di esecuzione del codice nello specifico, poiché i miei indicatori (improvvisamente, hanno visto) sono abbastanza esigenti in termini di risorse anche in esecuzione pubblica.
Penso che anche Grasn apprezzerebbe l'opportunità di contare più velocemente
No. Tutti non vedono in MT compiti ad alta intensità di risorse, a parte il lavoro dell'ottimizzatore. E anche se lo fanno, non li usano nel loro lavoro quotidiano. Almeno la maggior parte di loro lo fa. Ma non importa. Aspetterò la MT5. La velocità del codice può essere vista ad occhio nudo. E c'è anche CUDA. Ho scaricato dal sito nVidia i toolkit, li studierò. E non è un problema trasferire il codice in dll.
Per quanto riguarda CUDA, ho visto esempi di calcoli accelerati da un fattore di 10-100. Per alcune applicazioni mediche. E la programmazione CUDA è già insegnata nelle università. Ma è molto noioso. Cioè C è un linguaggio simile, ma è necessario dividere correttamente il compito, prendere in considerazione le peculiarità della GPU e i calcoli interi. Risulta essere una programmazione di livello molto basso. E non tutti i compiti possono essere facilmente ridotti a questo tipo per ottenere un guadagno reale dopo sei mesi di lavoro. Anche se, per esempio, le operazioni con matrici intere si traducono quasi perfettamente in CUDA.
C'è il progetto OpenCL, che è un ambiente di calcolo distribuito. Quasi tutti sono coinvolti, comprese AMD e nVidia. C'è un livello superiore di astrazione lì. Il link contiene un esempio di codice che, come potete vedere, è C (lo standard C99).
Ho studiato le fonti, riferirò nel pomeriggio, ora è ora di dormire.
I risultati sono più o meno chiari.
Cercherò di descrivere brevemente i miei risultati.
Durante l'ottimizzazione dell'Expert Advisor, il tester utilizza diverse decine di MB di memoria. Io, per esempio, ho un file fxt per un anno con minuti di aperture per circa 36 MB. Questa storia è immagazzinata nella memoria e vi si accede più o meno casualmente. In questa modalità la memoria non fornisce abbastanza prestazioni per fornire al processore la quantità di dati che potrebbe elaborare nel caso "ideale". Qui il ruolo importante è giocato dalla cache.
Qui inizia la parte più interessante.
1) Ovviamente, nei casi di cache misses la velocità e la latenza degli accessi alla memoria giocano un ruolo importante. Qui i processori possono essere divisi in 2 gruppi:
a) Atom e Core 2 - il controller di memoria è nel chipset "north bridge" (North Bridge - NB).
b) tutti gli altri con controller di memoria integrato (nel processore) - ICP.
I processori del gruppo "a" in questo caso possono perdere significativamente rispetto ai processori del gruppo "b". Detto questo, il Core i7 ICP è molto più efficiente rispetto ai processori AMD. Questa è una delle ragioni della vittoria senza riserve del Core i7.
2) Perché una cache mascheri efficacemente la latenza deve essere il più grande possibile, associativa (x-way nelle schermate di CPU-Z) e con meno latenza intrinseca.
E qui i processori si allineano chiaramente in termini di velocità a seconda del volume della cache (a parità di altre condizioni).
- La CPU più lenta è Celeron con 512KB di cache (non prendo in considerazione Atom - la sua architettura è progettata per l'economia piuttosto che per le prestazioni);
- Athlon - le loro basse dimensioni della cache hanno meno effetto a causa dell'ICP;
- Celeron 900 con 1 MB di cache;
- Processori Core 2 con 3-6 MB di cache; i modelli con un volume di cache maggiore sono un po' fuori luogo;
- Phenom II, qui 6 MB di cache (e con la massima associatività - fino a 48-way!) sono combinati con ICP;
- e il più veloce - Core i7 - qui combina tutte le cose più progressive - 3 canali (e generalmente molto veloce) RPC e il più grande (e ancora molto veloce) cache L3 con 8 MB.
Per quanto riguarda il motivo per cui l'efficienza del Phenom scende quando viene overcloccato e quella del Core i7 sale.
In entrambi questi processori, la cache ICP e L3 hanno un clock separato (mentre la cache L1/L2 funziona sempre alla frequenza della CPU).
Ma il metodo di overclock di Belford comporta l'aumento del moltiplicatore della CPU (lui ha un processore BE - Black Edition series - con un moltiplicatore libero, normalmente il moltiplicatore in cima è limitato), senza overclock della cache L3.
Mentre l'overclocking del Core i7 (ad eccezione dell'XE) è possibile solo aumentando la frequenza di base (BCLK). Questo overclocca anche i circuiti integrati con cache L3 (nel Core ix questo si chiama Uncore).
Quindi la velocità L3 del Phenom di Belford è sempre fissata a 2009,1 MHz. E a YuraZ accelera da 2,13 GHz alla pari, a 3,2 GHz quando il processore è overcloccato a 4 GHz. (Frequenza CPU BCLK x 20, Uncore BCLK x 16). E per lo Xeon a 3,33 GHz di frequenza della CPU, l'Uncore gira a 2,66 GHz.
Anche a 2,13 GHz la cache L3 del Core i7 è notevolmente più veloce di quella del Phenom a 2 GHz. E naturalmente molto più veloce a 3,2 GHz, il che assicura l'eccellente scalabilità del Core i7 in questo test.
Ora questo è a livello di speculazione, poiché non ho fatto alcuna ricerca dettagliata. Ma sembra che la velocità di ottimizzazione dipenda fortemente dalla dimensione della cache e dalle prestazioni, e un po' meno dalla frequenza del processore.
Cercherò di descrivere brevemente i miei risultati.
Durante l'ottimizzazione dell'Expert Advisor, il tester utilizza diverse decine di MB di memoria. Io, per esempio, ho un file fxt per un anno con minuti di aperture per circa 36 MB. Questa storia è immagazzinata nella memoria e vi si accede più o meno casualmente. In questa modalità la memoria non fornisce abbastanza prestazioni per fornire al processore la quantità di dati che potrebbe elaborare nel caso "ideale". Qui il ruolo importante è giocato dalla cache.
Qui inizia la parte più interessante.
1) Ovviamente, nei casi di cache misses la velocità e la latenza degli accessi alla memoria giocano un ruolo importante. Qui i processori possono essere divisi in 2 gruppi:
a) Atom e Core 2 - il controller di memoria è nel chipset "north bridge" (North Bridge - NB).
b) tutti gli altri con controller di memoria integrato (nel processore) - ICP.
I processori del gruppo "a" in questo caso possono perdere significativamente rispetto ai processori del gruppo "b". Detto questo, il Core i7 ICP è molto più efficiente rispetto ai processori AMD. Questa è una delle ragioni della vittoria senza riserve del Core i7.
2) Perché una cache mascheri efficacemente la latenza deve essere il più grande possibile, associativa (x-way nelle schermate di CPU-Z) e con meno latenza intrinseca.
E qui i processori si allineano chiaramente in termini di velocità a seconda del volume della cache (a parità di altre condizioni).
- La CPU più lenta è Celeron con 512KB di cache (non prendo in considerazione Atom - la sua architettura è progettata per l'economia piuttosto che per le prestazioni);
- Athlon - le loro basse dimensioni della cache hanno meno effetto a causa dell'ICP;
- Celeron 900 con 1 MB di cache;
- Processori Core 2 con 3-6 MB di cache; i modelli con un volume di cache maggiore sono un po' fuori luogo;
- Phenom II, qui 6 MB di cache (e con la massima associatività - fino a 48-way!) sono combinati con ICP;
- e il più veloce - Core i7 - qui combina tutti i più progressivi - 3 canali (e generalmente molto veloce) RPC e il più grande (e ancora molto veloce) cache L3 di 8 MB.
Per quanto riguarda il motivo per cui l'efficienza del Phenom scende quando viene overcloccato e quella del Core i7 sale.
In entrambi questi processori, la cache ICP e L3 hanno un clock separato (mentre la cache L1/L2 funziona sempre alla frequenza della CPU).
Ma il metodo di overclock di Belford comporta l'aumento del moltiplicatore della CPU (lui ha un processore BE - Black Edition series - con un moltiplicatore libero, normalmente il moltiplicatore in cima è limitato), senza overclock della cache L3.
Mentre l'overclocking del Core i7 (ad eccezione dell'XE) è possibile solo aumentando la frequenza di base (BCLK). Questo overclocca anche gli IC con cache L3 (nel Core ix questo è chiamato Uncore).
Quindi la velocità L3 del Phenom è sempre fissata a 2009,1 MHz. E con YuraZ accelera da 2,13 GHz alla pari, a 3,2 GHz quando il processore è overcloccato a 4 GHz. (Frequenza CPU BCLK x 20, Uncore BCLK x 16). E per lo Xeon a 3,33 GHz di frequenza della CPU, l'Uncore gira a 2,66 GHz.
Anche a 2,13 GHz la cache L3 del Core i7 è notevolmente più veloce di quella del Phenom a 2 GHz. E naturalmente molto più veloce a 3,2 GHz, il che assicura l'eccellente scalabilità del Core i7 in questo test.
Ora questo è a livello di speculazione, poiché non ho fatto alcuna ricerca dettagliata. Ma sembra che la velocità di ottimizzazione dipenda fortemente dalla dimensione della cache e dalle prestazioni, e un po' meno dalla frequenza del processore.
Grazie. Penso che sia molto convincente. Sono d'accordo.
Un piccolo chiarimento. Sarebbe corretto assumere che la velocità di ottimizzazione dipende più dalla dimensione della cache e dalle prestazioni che dalla frequenza della CPU?
Un piccolo chiarimento. È corretto assumere che la velocità di ottimizzazione dipende più dalla dimensione della cache e dalle prestazioni che dalla frequenza del processore?
Si scopre che è così. Ma è ancora una supposizione per ora e l'ho sottolineato nel mio post!