AMD o Intel, así como la marca de la memoria - página 13

 
joo >> :

Tienes razón, mmm, aunque soy partidario del campo de AMD. Las dos primeras pruebas del script hacen un buen trabajo al mostrar exactamente la potencia de cálculo de un solo núcleo en aplicaciones compiladas con MT. Ambas pruebas son de tamaño muy reducido y pequeño para no "tocar" la RAM para una mayor pureza del experimento. La tercera prueba está diseñada como una prueba de memoria de escritura y no tiene cálculos especiales.

Para poder utilizar todos los núcleos del procesador, la lógica de la prueba debe permitir el paralelismo de los cálculos y, además, el compilador y la propia plataforma MT deben permitirlo. Por lo que sé, debo estar equivocado, el lenguaje MQL5, al igual que el MQL4, no proporciona características para construir paralelismo en el código. Lo siento.

Más tarde publicaré el script actualizado que funciona más "suavemente" con la salida del índice de rendimiento final en relación con mi procesador (AMD Atlon X2 3800).

Para el Kombat -> el procesamiento de objetos gráficos no necesita realmente una potencia de hierro, porque incluso el procesamiento de decenas de miles de objetos por segundo no afectará al rendimiento, y en el probador no es realmente necesario. EN MI OPINIÓN.



La velocidad sólo es crítica cuando se optimiza. Eso es lo que hay que probar. Bueno, ya lo he dicho todo: Asesor Experto estándar, citas en el archivo con él, archivo *.set con un conjunto de parámetros a optimizar. Todo.

 

Sí. No soy partidario del campo de nadie. Me sigue gustando el Zilog Z80. ))) Por mi infancia: yo mismo diseñé su placa, la monté y la soldé...

Por cierto, el nuevo AMD es muy atractivo. El caché está bien. La frecuencia también es normal. Bueno, trabajar con la memoria siempre ha sido muy bueno para AMD. Intel acaba de poner un controlador en el procesador mientras que AMD fue el primero.

Pero no recuerdo, si la caché se puede redistribuir en carga parcial, cuando el núcleo cargado se asigna más.

 
Svinozavr >> :

La velocidad sólo es crítica cuando se optimiza. Esto es lo que las pruebas deben llevarse a cabo. Bueno, ya lo he dicho todo: Asesor Experto estándar, citas en el archivo con él, archivo *.set con un conjunto de parámetros a optimizar. Todo.

¿Puede ser que hagas una prueba? Y a quien le interese, le encantará dirigirlo. ;)

 
Svinozavr >> :

Puede comprobarlo "recortando" el script a una sección - puede caber en sus 256KB.

¡Increíble!

Seguí tu consejo. Probado en el mismo ordenador todo tipo de operaciones por separado. Esto es lo que tengo:

Total: ¡poco más de 37 milisegundos!

¿Qué conclusión debemos sacar de esto? ¿Que el tamaño del código afecta al rendimiento? Pero, ¿por qué tanto? Si se eliminan un par de líneas de código, se consigue este efecto.

 


 
begemot61 >> :


Hombre, no lo entiendo en absoluto. El tamaño de la caché L2 es de 2 Mb, la frecuencia del procesador es de 3,8 GHz. ¿Por qué va por detrás del Celeron de Svinozavr?

Lo único que cojea es la RAM, a 266 MHz. Frente a sus 400.

begemot61, ¿podrías probarlo individualmente como hice yo arriba? Será muy interesante ver los resultados del procesador de 3,8 GHz.

 
begemot61 >> :


Mmmm... Bueno, la memoria es lenta, vale. Pero, en primer lugar, no es tan lento, y en segundo lugar, se supone que no tiene nada que ver. (>> ¿entonces qué?

¿Puedes, como benik, analizarlo sección por sección? Pues mucho se parece la foto a un cuarto de mb de caché...

 
Mathemat >> :

Oh, vaya. Estoy sorprendido hasta el extremo. No sabía que el antiguo Celeron fuera tan rápido...


Supongo que esa es la cuestión, no es tan antigua. Es una tecnología de 45nm. Soy el viejo con tecnología de 90 nm. Y el de Begemot61 es de 90nm. ¿Podría ser esa la razón del retraso?
 
Hay otra cosa: el multitrading (dos núcleos virtuales) puede interferir. Si la bios lo permite o hay un software especial, puedes desactivarlo.
 
benik >> :


Creo que esa es la cuestión: no es tan antigua. Es una tecnología de 45nm. Soy el viejo con tecnología de 90nm. Y el de Begemot61 es de 90nm. Tal vez eso es lo que está causando el retraso.

Los tres modelos son diferentes. Tal vez se deba a la lógica del predictor de transición, que mejora constantemente, y el cuarto pentium en cuestión es el más antiguo. Y este predictor afecta directamente a la eficiencia de la caché. Sin embargo, todavía no está muy claro.

Otra cosa: toda la caché está dividida en una caché de instrucciones y otra de datos. ¿Quizás, de nuevo, esta división está "torcida" en 4?

En resumen, aunque no está claro hasta el final, pero es muy similar a los problemas de usabilidad de la caché. Sin embargo, también existe este parámetro, como cantidad de operaciones por reloj. Pero debería ser lo mismo aquí. No. No lo creo.

Sin embargo, el enigma es que no hay que olvidar que el)