AMD o Intel, así como la marca de la memoria - página 73
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Por qué. También me interesa mucho la velocidad de cálculo de las cosas serias
Bueno, ya somos tres. Todavía no es mucho.
He entendido muy bien su idea. Pero creo que cargamos el probador de manera equivocada. Por otro lado, parece que no has entendido mi punto de vista. Pero no importa, en general. Para orientarse, por así decirlo, "sobre el terreno", este último experto también servirá.
DE ACUERDO. No es casus belli para los maridos decentes, ¿verdad? ))) También me interesa la velocidad de ejecución del código específicamente, ya que mis indicadores (de repente, han visto) consumen bastantes recursos incluso en ejecución pública.
Creo que Grasn también agradecería la oportunidad de contar más rápido
No. Todo el mundo no ve las tareas que consumen muchos recursos en MT, aparte del trabajo del optimizador. E incluso si lo hacen, no los utilizan en su trabajo diario. Al menos la mayoría lo hace. Pero no importa. Esperaré a MT5. La velocidad del código se puede ver a simple vista. Y también está CUDA. He descargado desde el sitio de nVidia los kits de herramientas, los estudiaré. Y no hay problema en transferir el código a la dll.
En cuanto a CUDA, he visto ejemplos de cálculos acelerados por un factor de 10 a 100. Para algunas aplicaciones médicas. Y la programación de CUDA ya se enseña en las universidades. Pero es muy tedioso. Es decir, C es un lenguaje similar, pero es necesario dividir correctamente la tarea, tener en cuenta las peculiaridades de la GPU y los cálculos de enteros. Resulta ser una programación de muy bajo nivel. Y no todas las tareas pueden reducirse fácilmente a este tipo para obtener una ganancia real después de seis meses de trabajo. Aunque, por ejemplo, las operaciones con matrices enteras se traducen casi perfectamente a CUDA.
Existe el proyecto OpenCL, que es un entorno informático distribuido. Casi todo el mundo está involucrado en ello, incluyendo AMD y nVidia. Hay un nivel de abstracción superior. El enlace contiene un ejemplo de código que, como puede ver, es C (el estándar C99).
He estudiado las fuentes, te informaré por la tarde, ya es hora de dormir.
Los resultados son más o menos claros.
Intentaré describir brevemente mis conclusiones.
Al optimizar el Asesor Experto, el probador utiliza varias decenas de MB de memoria. Yo, por ejemplo, tengo un archivo fxt de un año con actas por aperturas de unos 36 MB. Este historial se almacena en la memoria y se accede a él de forma más o menos aleatoria. En este modo, la memoria no ofrece suficiente rendimiento para proporcionar al procesador la cantidad de datos que podría procesar en el caso "ideal". En este caso, el papel más importante lo desempeña la memoria caché.
Aquí comienza la parte más interesante.
1) Obviamente, en los casos de pérdidas de caché, la velocidad y la latencia de los accesos a la memoria jugarán un papel importante. Aquí los procesadores pueden dividirse en 2 grupos:
a) Atom y Core 2 - el controlador de memoria se encuentra en el chipset del "puente norte" (North Bridge - NB).
b) todos los demás con controlador de memoria integrado (en el procesador) - ICP.
Los procesadores del grupo "a", en este caso, pueden perder significativamente frente a los procesadores del grupo "b". Dicho esto, el Core i7 ICP es mucho más eficiente que en los procesadores AMD. Esta es una de las razones de la victoria sin paliativos del Core i7.
2) Para que una caché enmascare eficazmente la latencia tiene que ser lo más grande posible, asociativa (x-way en las capturas de CPU-Z) y con menos latencia intrínseca.
Y aquí los procesadores se alinean claramente en términos de velocidad en función del volumen de caché (en igualdad de condiciones).
- La CPU más lenta es la Celeron con 512KB de caché (no tengo en cuenta la Atom - su arquitectura está diseñada para economizar más que para el rendimiento);
- Athlons - sus bajos tamaños de caché tienen menos efecto debido al ICP;
- Celeron 900 con 1 MB de caché;
- Procesadores Core 2 con 3-6 MB de caché; los modelos con mayor volumen de caché están un poco lejos de la marca;
- Phenom II, aquí se combinan 6 MB de caché (y con la máxima asociatividad: ¡hasta 48 vías!) con ICP;
- y el más rápido - Core i7 - aquí combina todo lo más progresivo - RPC de 3 canales (y generalmente muy rápido) y la mayor (y de nuevo muy rápida) caché L3 con 8 MB.
En cuanto a por qué la eficiencia de Phenom baja al hacer overclock y la de Core i7 sube.
En estos dos procesadores, el ICP y la caché L3 se sincronizan por separado (mientras que la caché L1/L2 siempre funciona a la frecuencia de la CPU).
Pero el método de overclocking de Belford consiste en aumentar el multiplicador de la CPU (él tiene un procesador de la serie BE -Black Edition- con multiplicador libre, normalmente el multiplicador de arriba está limitado), sin overclockear la caché L3.
Mientras que el overclocking del Core i7 (a excepción del XE) sólo es posible aumentando la frecuencia base (BCLK). Esto también sobreacelera los CI con caché L3 (en el Core ix esto se llama Uncore).
Así que la velocidad L3 del Phenom de Belford siempre está fijada en 2009,1 MHz. Y en YuraZ se acelera de 2,13 GHz a la par, a 3,2 GHz cuando el procesador se overclockea a 4 GHz. (CPU BCLK x 20, Uncore BCLK x 16). Y el Xeon, con una frecuencia de CPU de 3,33 GHz, el Uncore funciona a 2,66 GHz.
Incluso a 2,13 GHz, la caché L3 del Core i7 es notablemente más rápida que la caché L3 del Phenom a 2 GHz. Y, naturalmente, mucho más rápido a 3,2 GHz, lo que garantiza la excelente escalabilidad del Core i7 en esta prueba.
Ahora bien, esto se sitúa en el nivel de la especulación, ya que no he realizado ninguna investigación detallada. Pero parece que la velocidad de optimización depende en gran medida del tamaño de la caché y del rendimiento, y algo menos de la frecuencia del procesador.
Intentaré describir brevemente mis conclusiones.
Al optimizar el Asesor Experto, el probador utiliza varias decenas de MB de memoria. Yo, por ejemplo, tengo un archivo fxt de un año con actas por aperturas de unos 36 MB. Este historial se almacena en la memoria y se accede a él de forma más o menos aleatoria. En este modo, la memoria no ofrece suficiente rendimiento para proporcionar al procesador la cantidad de datos que podría procesar en el caso "ideal". En este caso, el papel más importante lo desempeña la memoria caché.
Aquí comienza la parte más interesante.
1) Obviamente, en los casos de pérdidas de caché, la velocidad y la latencia de los accesos a la memoria jugarán un papel importante. Aquí los procesadores pueden dividirse en 2 grupos:
a) Atom y Core 2 - el controlador de memoria se encuentra en el chipset del "puente norte" (North Bridge - NB).
b) todos los demás con controlador de memoria integrado (en el procesador) - ICP.
Los procesadores del grupo "a", en este caso, pueden perder significativamente frente a los procesadores del grupo "b". Dicho esto, el Core i7 ICP es mucho más eficiente que en los procesadores AMD. Esta es una de las razones de la victoria sin paliativos del Core i7.
2) Para que una caché enmascare eficazmente la latencia tiene que ser lo más grande posible, asociativa (x-way en las capturas de CPU-Z) y con menos latencia intrínseca.
Y aquí los procesadores se alinean claramente en términos de velocidad en función del volumen de caché (en igualdad de condiciones).
- La CPU más lenta es la Celeron con 512KB de caché (no tengo en cuenta la Atom - su arquitectura está diseñada para economizar más que para el rendimiento);
- Athlons - sus bajos tamaños de caché tienen menos efecto debido al ICP;
- Celeron 900 con 1 MB de caché;
- Procesadores Core 2 con 3-6 MB de caché; los modelos con mayor volumen de caché están un poco lejos de la marca;
- Phenom II, aquí se combinan 6 MB de caché (y con la máxima asociatividad: ¡hasta 48 vías!) con ICP;
- y el más rápido - Core i7 - aquí combina todo lo más progresivo - RPC de 3 canales (y generalmente muy rápido) y la mayor (y de nuevo muy rápida) caché L3 de 8 MB.
En cuanto a por qué la eficiencia del Phenom baja al hacer overclock y la del Core i7 sube.
En estos dos procesadores, el ICP y la caché L3 se sincronizan por separado (mientras que la caché L1/L2 siempre funciona a la frecuencia de la CPU).
Pero el método de overclocking de Belford consiste en aumentar el multiplicador de la CPU (él tiene un procesador de la serie BE -Black Edition- con multiplicador libre, normalmente el multiplicador de arriba está limitado), sin overclockear la caché L3.
Mientras que el overclocking del Core i7 (a excepción del XE) sólo es posible aumentando la frecuencia base (BCLK). Esto también sobreacelera los CI con caché L3 (en el Core ix esto se llama Uncore).
Así que la velocidad L3 de Phenom siempre está fijada en 2009,1 MHz. Y con YuraZ se acelera de 2,13 GHz a la par, a 3,2 GHz cuando el procesador se overclockea a 4 GHz. (CPU BCLK x 20, Uncore BCLK x 16). Y el Xeon, con una frecuencia de CPU de 3,33 GHz, el Uncore funciona a 2,66 GHz.
Incluso a 2,13 GHz, la caché L3 del Core i7 es notablemente más rápida que la caché L3 del Phenom a 2 GHz. Y, naturalmente, mucho más rápido a 3,2 GHz, lo que garantiza la excelente escalabilidad del Core i7 en esta prueba.
Ahora bien, esto es a nivel de especulación, ya que no he hecho ninguna investigación detallada. Pero parece que la velocidad de optimización depende en gran medida del tamaño de la caché y del rendimiento, y algo menos de la frecuencia del procesador.
Gracias. Creo que es muy convincente. Estoy de acuerdo.
Una pequeña aclaración. ¿Sería correcto suponer que la velocidad de optimización depende más del tamaño de la caché y del rendimiento que de la frecuencia de la CPU?
Una pequeña aclaración. ¿Es correcto suponer que la velocidad de optimización depende más del tamaño de la caché y del rendimiento que de la frecuencia del procesador?
Resulta que sí. ¡Pero por ahora sigue siendo una suposición y así lo recalqué en mi post!