AMD o Intel così come la marca di memoria - pagina 13

 
joo >> :

Hai ragione, mmm, anche se sono un sostenitore del campo AMD. I primi due test nello script fanno un buon lavoro per mostrare esattamente la potenza di calcolo di un singolo core nelle applicazioni compilate da MT. Entrambi questi test sono molto piccoli e di piccole dimensioni per non "toccare" la RAM per una maggiore purezza dell'esperimento. Il terzo test è progettato come un test di memoria in scrittura e non ha calcoli speciali.

Per utilizzare tutti i core del processore, la logica di test deve permettere il parallelismo dei calcoli e anche il compilatore e la stessa piattaforma MT devono permetterlo. Per quanto ne so, devo essermi sbagliato, il linguaggio MQL5, come MQL4, non fornisce caratteristiche per costruire il parallelismo nel codice. Mi dispiace per questo.

Più tardi posterò lo script aggiornato che funziona in modo più "fluido" con l'output dell'indice di performance finale relativo al mio processore (AMD Atlon X2 3800).

Per Kombat -> l'elaborazione degli oggetti grafici non ha davvero bisogno della potenza del ferro, perché anche l'elaborazione di decine di migliaia di oggetti al secondo non influenzerà le prestazioni, e nel tester non è davvero necessario. IMHO.



La velocità è fondamentale solo quando si ottimizza. È su questo che dovrebbero essere condotti i test. Beh, ho già detto tutto: Expert Advisor standard, citazioni nell'archivio con esso, file *.set con una serie di parametri da ottimizzare. Tutto.

 

Sì, non sono un sostenitore del campo di nessuno. Mi piace ancora lo Zilog Z80! ))) A causa della mia infanzia: ho progettato io stesso la sua scheda, l'ho assemblata e saldata...

A proposito, il nuovo AMD è molto attraente. La cache è a posto. Anche la frequenza è normale. Beh, lavorare con la memoria è sempre stato molto buono per AMD. Intel ha messo da poco un controller sul processore mentre AMD è stata la prima.

Ma non ricordo, la cache può essere ridistribuita a carico parziale, quando il nucleo caricato è allocato di più.

 
Svinozavr >> :

La velocità è fondamentale solo quando si ottimizza. È su questo che i test dovrebbero essere condotti. Beh, ho già detto tutto: Expert Advisor standard, citazioni nell'archivio con esso, file *.set con una serie di parametri da ottimizzare. Tutto.

Forse farete un test? E chi è interessato, sarebbe felice di gestirlo. ;)

 
Svinozavr >> :

Puoi controllarlo "tagliando" lo script in una sezione - potrebbe adattarsi ai tuoi 256KB.

Incredibile!

Ho seguito il tuo consiglio. Provato sullo stesso computer tutti i tipi di operazioni separatamente. Questo è quello che ho ottenuto:

Totale: poco più di 37 millisecondi!

Allora, che conclusione dobbiamo trarre da questo? Che la dimensione del codice influisce sulle prestazioni? Ma perché così tanto? Si rimuovono solo un paio di righe di codice e si ottiene questo effetto.

 


 
begemot61 >> :


Amico, non lo capisco per niente. La dimensione della cache L2 è di 2 Mb, la frequenza del processore è di 3,8 GHz. Perché è in ritardo rispetto al Celeron di Svinozavr?

L'unica cosa che è zoppa è la RAM, a 266 MHz. Contro i suoi 400.

begemot61, potresti testarlo individualmente come ho fatto sopra. Sarà molto interessante vedere i risultati del processore a 3,8GHz.

 
begemot61 >> :


Mmmm... Beh, la memoria è lenta, ok. Ma in primo luogo, non così lento, e in secondo luogo, non dovrebbe avere nulla a che fare con esso. (>> e poi?

Puoi, come benik, fare un'analisi sezione per sezione? Beh, l'immagine assomiglia molto a un quarto di mb di cache...

 
Mathemat >> :

Oh, cavolo. Sono sorpreso all'estremo. Non mi ero reso conto che il vecchio Celeron fosse così veloce...


Credo che sia questo il punto, non è così vecchio. È una tecnologia a 45 nm. Sono il vecchio con la tecnologia a 90 nm. E quello di begemot61 è di 90nm. Potrebbe essere questa la ragione del ritardo?
 
C'è un'altra cosa: il multitrading (due core virtuali) può interferire. Se il bios lo permette o c'è un software speciale, puoi disabilitarlo.
 
benik >> :


Penso che questo sia il punto: non è così vecchio. È una tecnologia a 45 nm. Sono il vecchio con la tecnologia a 90nm. E quello di begemot61 è di 90nm. Forse è questa la causa del lag.

Tutti e tre i modelli sono diversi. Forse è a causa della logica del predittore di transizione - è in costante miglioramento, e il quarto pentium in questione è il più vecchio. E questo predittore influisce direttamente sull'efficienza della cache. Però non è ancora molto chiaro.

Ecco un'altra cosa: l'intera cache è divisa in una cache di istruzioni e una cache di dati. Forse, di nuovo, questa divisione è "storta" in 4?

In breve, anche se non è chiaro alla fine, ma è molto simile ai problemi di usabilità della cache. Tuttavia, c'è anche un parametro come la quantità di operazioni per clock. Ma dovrebbe essere lo stesso qui. No, non credo.

Indovinello, però!!!))