Intel Core un rival digno para K8 y K9
-
Sinceramente no se que modificaciones han echo en la arquitectura de estos procesador con respecto a los P4 para que tenga tanta repercusion
el PIV es un procesador "muy largo" y "estrecho"…. tiene muchas etapas en linea para completar las instrucciones...
conroe es un procesador "corto" ( 15 etapas) pero "muy ancho" lleva un monton de unidades de enteros y otro monton de unidades de coma flotante) por lo que puede realizar bastante mas trabajo ( si el programa esta bien compilado para ello ) paralelizado que cualquiera de los procesadores actuales del mercado
ademas de eso, puede ejecutar instrucciones SSe en un ciclo de reloj, la mitad que el resto de procesadores , por eso, en aplicaciones de coma flotante ( que "reconfigura" a SSe ) es una "burrada" ...
aunque me da la impresion de que sea causa de esos 4Mb de chache de nivel 2.
los 4MB de cache son compartidos, lo que implica que cuando solo usa un procesador, este dispone de 4MB de cache (por eso los fantasticos rendimientos en Superpi, "todo" le entra en la cache y casi no tiene que acceder a la memoria principal del sistema )
En cuanto al AS que supuestamente tiene AMD, supongo que al disminuir la tecnologia de integracion hasta los 65 nm les permitira incluir mas cosas en el chip y como primera opcion deberia pensar en aumentar el tamaño de la L2 por lo menos hasta los 2 Mb
AMD va a seguir el camino marcado por conroe haciendo los micros "mas anchos" con mas unidades de enteros y coma flotante…
con los K8L , ademas estrenan el HTT Version 3 con un mayor ancho de banda
Bueno, he pedido en XS a ver si alguien podia hechar unos benchmarks en el windows 64bits, como el winrar y el cinebench, a ver si alguno se anima a instalarlo y lo prueba.
yo . "enredando por ahi" , ya he visto cositas de conroe en 64 bits , y aunque tiene un aumento de rendimiento, este no es tan espectacular como el aumento de un K8….
los K8, en cinebench 64 bits, le pegan un buen "mordisco" a la diferencia de rendimiento en 32 bits....
un saludo
-
Por curiosidad, eres el mismo barton de N3D? Si es asi, seas bienvenido
(sino tambien 
) -
idem que krampak
por cierto, si hay algun atrevido, en ebay ya hay conroes ES disponibles desde menos de 300€
-
barton bienvenido a Hardlimit, buen post si señor.
Yo creí leer (no lo recuerdo donde) eso que comentas de que la cache de los cores es compartida y pensé que no era posible ya que entonces no se trata de un dual core sino de otra cosa, seria interesante hablar de ello.Otra cosa, a lo largo de la rama hemos hablado de lo que va a presentar AMD en contrapartida a Conroe y si bueno evidentemente todo lo que ha anuncia mejorara el buen rendimiento que subió a lo más alto al K8 pero como ya he dicho deberá de subir los Mhz o las operaciones por ciclo si AMD quiere aumentar la potencia bruta. Esta claro que es mejor rendimiento y aprovechamiento de los recursos que no potencia bruta sin control pero soy de los que opinan que a AMD le ha llegado la hora de tirar de la manta y subir los Mhz. Hace poco se ha anunciado que el FX-64 (dualcore 3Ghz) será en 90nm eso para mi es una señal.
Por cierto barton podrías poner sino las capturas el enlace a esos resultados con OS y software de 64bits con conroe, yo puse unos pero eran de P4 dualcore. ;D
A se me olvidava, al parecer los Intel llevan integrado un coprocesador numérico y los AMD no, sabéis esto si influye en algo o si solo sirve para software especialmente diseñado para aprovecharlo, Gracias.
-
La L2 siempre es compartida, tanto para datos como para instrucciones; a no ser que te refieras a compartirla entre los cores
Es verdad que el P4 tiene un cauce muy largo, pero si te fijas por ejmeplo los K8 tienen 15 y 17 etapas para enteros y punto flotante respectivamente y hacen 10 seg más en el SuperPi (como he comentado antes); seguramente han incluido muchas mejoras mas en la arquitectura.
El echo de aumentar el procesador en "anchura", supongo que te refieres a disponer o replicar las unidades funcionales en mayor medida suele producir una mejor en el rendimento pues puedes ejecutar más instrucciones en paralelo; pero tiene su parte negativa y es que aumentan las dependencias y por lo tanto complica la unidad de control.
-
es que en los P4 dual core (presler & co.) la caché no era compartida, cada nucleo tenia su caché (ahora dudo si en los presler en concreto es asi), pero en los A64 y conroes la caché es compartida y accesible por ambos cores
-
No lo sabia, pero de esta forma se podria hacer trabajar a los dos cores sobre el mismo programa pues ambos cores pueden acceder a los datos sobre los que trabaja el otro; o eso creo
-
La L2 siempre es compartida, tanto para datos como para instrucciones; a no ser que te refieras a compartirla entre los cores
Si me refiero a eso a que lei que las 4Mb totales las puede usar un core o el otro cuando el AMD tiene en total 2Mb pero cada core solo puede utilizar 1Mb, yo no le veo sentido y por eso he decidido ponerlo sobre la mesa porque me parece que no es posible.
es que en los P4 dual core (presler & co.) la caché no era compartida, cada nucleo tenia su caché (ahora dudo si en los presler en concreto es asi), pero en los A64 y conroes la caché es compartida y accesible por ambos cores
Uff menudo lio, esto habra que aclararlo que me parece que no esta muy claro.
Voy a buscar info y edito.Editado:
Acabo de encontrar donde lo lei y ahora si que no entiendo nada:http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2748&p=2
The cache system of the Core CPU is also very impressive. A massive 4 MB L2-cache is shared between the two cores and is accessed in only 12 to 14 cycles. Each core also has a 3 cycle 32 KB Instruction cache and a 32 KB data cache at its disposal. Note that the "Trace Cache" of NetBurst has been left behind with the return to shorter pipelines; the NetBurst Trace Cache basically functions as an instruction cache for pre-decoded instructions, and while this was apparently helpful for the long pipeline of NetBurst, Intel has apparently determined that a traditional L1 caching scheme makes more sense for Core.
Cache Architecture Overview
Just a quick look at the numbers in the above table make it clear that the memory subsystem of the Core architecture is impressive. It has twice as much L2 cache as current dual-core CPUs (the same amount as Presler), but the cache is still accessible with low latency. The shared L2 cache also allows one core to use more than 2MB of cache if necessary. Both L1 and L2 cache are accessed via a 256-bit wide bus, allowing the caches to deliver massive bandwidth to the core.
-
Si me refiero a eso a que lei que las 4Mb totales las puede usar un core o el otro cuando el AMD tiene en total 2Mb pero cada core solo puede utilizar 1Mb, yo no le veo sentido y por eso he decidido ponerlo sobre la mesa porque me parece que no es posible.
Uff menudo lio, esto habra que aclararlo que me parece que no esta muy claro.
Voy a buscar info y edito.Editado:
Acabo de encontrar donde lo lei y ahora si que no entiendo nada:http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2748&p=2
¿Por que dices que la cache L2 no puede estar compartida entre los dos nucleos? Tiene mucho sentido, por una parte pierdes en rendimiento porque la latencia de la cache es mas alta (en el Conroe es mas alta que en el AMD64) pero por otra parte tienes una gran ventaja, en los programas no optimizados para multiprocesador estarías aprovechando toda la cache de 2º nivel, mientras que si fuese exclusiva para cada nucleo solo utilizarías la mitad (el nucleo q no hace ningún trabajo tendria su cache desaprovechada).
¿Que es lo que no entiendes? A ver si entre todos podemos mejorar la arquitectura y creamos nuestro propio micro "hardlimit" :rolleyes:
-
¿Por que dices que la cache L2 no puede estar compartida entre los dos nucleos? Tiene mucho sentido, por una parte pierdes en rendimiento porque la latencia de la cache es mas alta (en el Conroe es mas alta que en el AMD64) pero por otra parte tienes una gran ventaja, en los programas no optimizados para multiprocesador estarías aprovechando toda la cache de 2º nivel, mientras que si fuese exclusiva para cada nucleo solo utilizarías la mitad (el nucleo q no hace ningún trabajo tendria su cache desaprovechada).
¿Que es lo que no entiendes? A ver si entre todos podemos mejorar la arquitectura y creamos nuestro propio micro "hardlimit" :rolleyes:
Es que entonces no existen fisicamente dos nucleos independientes sino un micro con dos caches L1 que acceden simultaneamente a una cache L2 de 4Mb que cuando esta llena hacede a la RAM.
Por eso digo que eso no es exactamente un procesador con dos nucleos sino más bien otra cosa que no se yo como llamar.
No se, me parece demasiado complejo y no tengo las ideas claras, haber si encuentro algo más porque no encuentro la logica, ya puestos podrian haber metido 3 o 4 cahes L1 y asi lo flipariamos en colores, al fin y al cabo las versiones de conroe más bajas solo tienen 2Mb.
Que follon y eso que el micro todavia no esta en el mercado. :risitas:
-
Pero es que si la L2 fuera global para los dos nucleoas; es decir no tuvieran L2 independiente uno del otro como dices sino una L2 de 4Mb para los dos cores, que pasaria si por ejemplo los dos cores hacen una peticion a cache que falla, esto provocaria que habria que traer dos lineas a cache de MP pero y si las dos corresponden a la misma linea de cache tenemos un gran problema pues cual de ellas es la que alojamos en cache.
El tener la L2 global, en mi opinion, tiene mas inconvenientes que ventajas (como por ejemplo lo que he comentado anteriormente). Otra cosa muy distinta es que dispongas de 2Mb de L2 por core y que cada nucleo pueda acceder a la L2 del otro pero solo para leer no para escribir. -
Pero es que si la L2 fuera global para los dos nucleoas; es decir no tuvieran L2 independiente uno del otro como dices sino una L2 de 4Mb para los dos cores, que pasaria si por ejemplo los dos cores hacen una peticion a cache que falla, esto provocaria que habria que traer dos lineas a cache de MP pero y si las dos corresponden a la misma linea de cache tenemos un gran problema pues cual de ellas es la que alojamos en cache.
El tener la L2 global, en mi opinion, tiene mas inconvenientes que ventajas (como por ejemplo lo que he comentado anteriormente). Otra cosa muy distinta es que dispongas de 2Mb de L2 por core y que cada nucleo pueda acceder a la L2 del otro pero solo para leer no para escribir.Tendriamos 2 nucleos independientes pero la cache no lo sería, el problema que surge al tener una cache de 2º nivel compartida es el mismo que surge al tener 2 nucleos independientes y una sola memoria común a los dos. Aunque si pienso un poquito me doy cuenta que los 256 bits de la cache L2 van a dar el mismo resultado que lo 128 bits que tiene el AMD64, porque si tenemos 2 buses de 128 bits independientes conseguiremos el mismo ancho de banda que con 1 solo de 256…
El ejemplo que has puesto de fallo surgiría muy pocas veces, la cache de segundo nivel tiene un acierto superior al 98% y por lo tanto que coincidan dos fallos de cache para los dos nucleos a la vez sería muy extraño y siempre se tiende a beneficiar al caso más común. Por otra parte, no veo problema en traerse dos paginas a cache desde memoria... no entiendo eso de que sea la misma linea de cache, si han fallado los dos las paginas de memoria no están en cache por lo tanto no están en ninguna linea o entrada.
-
Yo estoy hablando del hipotetico caso de que la cache L2 de 4Mb pueda ser utilizada por los dos cores en lugar de que cada core tenga 2 Mb. La probabilidad de fallo es pequeña y mas con ese tamaño, pero existe esa posibilidad y hay que abordarla de alguna manera; es un problema que hay que resolver pues si se produce ese caso lo que no puedes es decir "me reinicio" o algo por el estilo.
Que dos lineas de Mp vayan a la misma linea de cache dependera del tipo de L2 que se utilice; por ejemplo con una cache totalmente asociativa no existe ese problema pero no conozco nigun procesador que use este tipo de caches (suelen incrementar muchisomo el coste). Lo normal es que sea asociativa por conjuntos (en la imagen que ha puesto Espinetenbolas puedes apreciar que el conroe tiene conjuntos de 16 lineas donde estas si son totalmente asociativas).
Con respecto a lo que comentas de el tamaño de linas de cache, el tener lineas mas grandes o anchas tienes sus ventajas y sus inconvenientes. Por ejemplo al tener 256 bits te cojen mas palabras por linea (el doble) y por lo tanto tu indice de aciertos aumenta aun más. Por contra necesitas 2 accesos a MP para llenar la linea y eso es costoso en rendimieto (con los 128bits del AMD64 puedes llenar la linea con un solo acceso utilizando dual chanel y la penalizacion es menor). Pero bueno esto es como digo siempre: depende del progrma que estes ejecutando.
-
Los Conroe tiene un rendimiento acojonate, eso esta claro y no hay mas que ver que por ejemplo el recor en SuperPi esta en manos de uno de estos "bichos" y la diferencia con el primer AMD es de casi 10 seg; si si 10 seg. Sinceramente no se que modificaciones han echo en la arquitectura de estos procesador con respecto a los P4 para que tenga tanta repercusion, aunque me da la impresion de que sea causa de esos 4Mb de chache de nivel 2. Que tenga menos tamaño en la L1 da igual porque supongo que seguiran utilizando la cache de traza de los P4 y esta no se caracteriza por el tamaño en Kb sino por el numero de lineas decodificadas que sea capaz de almacenar (con esta cache de traza te ahorras el tener que volver a decodificar una instruccion que prodijo un acierto en cache, es más inteligente almacenarla decodificada y si aciertas no tienes que volver a decodificarla).
En cuanto al AS que supuestamente tiene AMD, supongo que al disminuir la tecnologia de integracion hasta los 65 nm les permitira incluir mas cosas en el chip y como primera opcion deberia pensar en aumentar el tamaño de la L2 por lo menos hasta los 2 Mb
Bueno lo del superpi ya habiamos dicho que no tiene mucho sentido comprar estos resultados entre arquitecturas distintas, pues la diferencia en superpi no es necesariamente la diferencia en rendimiento real. Es por eso que en este foro hay records de superpi separados para AMD e intel lo cual tiene mucho sentido. En cuanto al la diferencia en rendimiento del P4 al conroe ya barton lo ha explicado y en realidad la gran ganancia en rendimiento tiene NO se debe en gran parte al cache de 4MB. El Conroe no utiliza el cahce de traza del P4, de hecho conroe (afortunadamente) hereda muy poco o nada del P4.
Esta es la microarquitectura P6/PM
Esta es la micro arquitectura del conroe
Como se puede observar los esquemas son bastante similares. El conroe es un"overhauling" total de PM/P6, la evolucion mas grande se observa en el back end: un nucleo de ejecucion mas ancho, con capacdad de ejecutar mas instrucciones en paralelo, que ovbiamente resquiere una estacion de reseva (RS) mas grande (32 entradas). Las unidades de vector del conroe son mucho mas potentes (capaces de realizar operaciones SSE de 128 bits) y estan conectadas mediante 3 puertos distintos. Igualmente las ALUs escalares son mas potentes y tienen un puerto mas a su disposicion.Las unidades de Aceso a memoria son mejoradas. En P6 el rendimiento SSE sufre un cuello de botella debido a que estas funciones se agregaron a traves de los puertos 0 y 1, entonces las funciones escalares compiten con las vectoriales para la utilizacion de estos dos puertos no aprovechando adecuadamente los recursos. El conroe agrega un puerto adicional a estas unidades ademas de que se mejora el desempeño de los mismos ya que tres de ellos son dedicados exclusivamenta a operaciones aritmeticas y logicas.(netburst solo posee 4 puertos).
De nada vale tener un nucleo de ejecucion potente si no se mejora el front end para obtencion de las instrucciones por lo tanto se aumenta la logica de decoficacion, el buffer de reordenamiento (se aumento de 40 a 96 entradas). Las tecnicas que mejoran el desempeño del front end son. Micro ops y Macro ops fusion, Unidad de prediccion de ramas mas robusta y obviamente mejoras en el cache, no solo en tamaño sino tambien en eficiencia y velocidad.
En cuanto a las mejoras que AMD piensa hacer al nucleo (que ya las he posteado en otra rama) se encuentran la inclusion de un cache de tercer nivel, mejora del front ent (con esquema similar desambiguacion de memoria), Mejora de la potencia de calculo FP entre otras… La evolucion de K8 a K8L se puede ver de forma analoga a la Evolucion de P6/PM al conroe, si se observan detenidamente las mejoras parece ser similares, pero bueno habra que esperar por mas informacion por parte de AMD.
-
Pues creo que la cahce de traza es o fue una idea muy buena y no se porque habran decidido no incorporarla :vayatela: ; si te puedes ahorrar la decodificacion de las instrucciones que producen aciertos de cache bien venido sea.
El SuperPi no es mas que un benchmarks, no es que haya que fijarse solo en el para dictar sentencia de cual es mejor o peor; pero sinceramente me ha llamado mucho la atencion la enorme diferrencia que ha obtenido el conroe.
-
Pues creo que la cahce de traza es o fue una idea muy buena y no se porque habran decidido no incorporarla :vayatela: ; si te puedes ahorrar la decodificacion de las instrucciones que producen aciertos de cache bien venido sea.
El SuperPi no es mas que un benchmarks, no es que haya que fijarse solo en el para dictar sentencia de cual es mejor o peor; pero sinceramente me ha llamado mucho la atencion la enorme diferrencia que ha obtenido el conroe.
El trace cache fue algo necesario para el P4, en arquitecturas como P6 y conroe no tendria practicamente ningun efecto en relacione con las modificaciones que habria que hacer al nucleo. En P6 y conroe la RS o estacion de reserva cumple eficientemnete su labor, en netburst simplemnete colocar una RS no era suficiente debido al efecto de tener tantos pipelines (era uy dañino esperar la decodificacion de una instruccion a traves de tantas etapas) entonces intel debio diseñar algo como en trace cache.
http://arstechnica.com/articles/paedia/cpu/pentium-2.ars/2 -
Porque??? Seguirias ahorrandote la decodificacion de las instrucciones. En lugar de almacenar la instruccion "tal cual" en cache la almacenas decodificada y así no tienes que decodificar cada vez.
En las imagenes que has puesto sigue habiendo una etapa para pasar de codigo X86 a instrucciones maquina (decodificar la instruccion vamos) asiq ue no entiendo porque no se van ha beneficiar
-
Porque??? Seguirias ahorrandote la decodificacion de las instrucciones. En lugar de almacenar la instruccion "tal cual" en cache la almacenas decodificada y así no tienes que decodificar cada vez.
En las imagenes que has puesto sigue habiendo una etapa para pasar de codigo X86 a instrucciones maquina (decodificar la instruccion vamos) asiq ue no entiendo porque no se van ha beneficiar
Bueno empecemos por cual es el objetivo del trace cache?
El objetivo del trace cache es poder proporcionar al nucleo de ejecucion del P4 una sucesion suficientemente rapida de microoperaciones, sucesion que no seria suficientemente rapida con un esquema de estacion de reserva debido a lo que tardaria las microoperaciones decodificadas en llegar al nucleo de ejecucion en una CPU de tantas etapas.Igual la instruccion antes de ser almacenada si es decodificada y luego almacenada en trace cache, o sea que tecnicamente no te estas ahorrando ninguna decodificacion. La funcion del trace cache es almacenar las microoperaciones ya previamente decodificadas de tal manera que pasen directamente del trace cache al nucleo de ejecucion.
Microarquitectura netburst
Si observas la microarquitectura netburst ves que la etapa de decodificacion esta antes del trace cache , es decir, que todas las microinstrucciones almacenadas en el trace cache pasan por la etapa de decoficacion. Tecnicamente no se esta ahorrando ninguna decodificacion. Simplemente se esta haciendo decodificacion previa de varias microinstrucciones antes de que sea requerido ejecutarlas.La diferencia con P6 y conroe es que las instrucciones en P6 y conroe son tomadas directamente del cache L1 sin decodificar y decodificadas para ser almacenadas en la estacion de reserva, de esta manera el nucleo de ejecucion siempre tendra instrucciones para ejecutar en la estacion de reserva asi que no necesita cosas como trace cache. Por su parte el P4 decodifica las instrucciones con anterioridad y las guarda decoficadas en trace cache (pero si esta decodificando) entonces pasan directamente del cache al nucleo de ejecucion de forma suficientemente rapida, si se utilizara en el P4 el mismo esquema que P6 llegaria un momento en que la RS quedaria vacia debido a lo que tarda la decodificacion al pasar por tantas etapas no se podria proporcional instrucciones al nucleo de ejecucion en una sucecion suficientemente rapida, esto no pasa en P6 o conroe y por eso un esquema de trace cache no es necesario ni tendria un efecto adicional.
Asi que la RS siempre tiene instrucciones listas para despachar al nucleo de ejecucion, daria lo mismo si las tomara de un trace cache o de RS. Si intel ha decidido no utilizar el esquema de trace cache en conroe es porque sus ingenieros han considerado que no iba a ser necesario y despues de todo ellos saben mas que nosotros sobre su diseño.Bueno espero haberme hecho entender.
-
Si decodificar tienes que decodificar todas las instrucciones, pero utilizando la cache de traza lo que consigues es decodificar 1 sola vez la instruccion: cuando dio error y tuviste que traerla. Si por el contrario la instruccion pridujo un acierto la instruccion ya esta decodificada, mientras que con una cache normal aunque sea un acierto tienes que volver a decodificarla para poder meterla en el back end.
Siempre que buscas la instruccion la buscas en la cache de traza, si da error te la traes de MP decodificandola pero si produjo un acierto ya la tienes decodificada por lo que no tienes que volver a decodificarla.Yo tambien estoy de acuerdo en que los ingenieros de Intel tiene que saber más que nosotros :risitas: :risitas:
-
Si decodificar tienes que decodificar todas las instrucciones, pero utilizando la cache de traza lo que consigues es decodificar 1 sola vez la instruccion: cuando dio error y tuviste que traerla. Si por el contrario la instruccion pridujo un acierto la instruccion ya esta decodificada, mientras que con una cache normal aunque sea un acierto tienes que volver a decodificarla para poder meterla en el back end.
Siempre que buscas la instruccion la buscas en la cache de traza, si da error te la traes de MP decodificandola pero si produjo un acierto ya la tienes decodificada por lo que no tienes que volver a decodificarla.Si eso es cierto en ese caso te ahorrarias la decoficacion, solo que parecia que lo decias como si siempre te ahorraras la decodificacion, es posible que te ahorres en ciertas ocasiones algo de decodificacion, despues de todo el Trace cache es limitado y las instrucciones decodificadas no van a permanecer para siempre alli.
A lo que me refiero es que la RS en conroe cumple el mismo objetivo del trace cache en netbusrt, la RS es capaz de proporcionar instrucciones siempre en sucesion suficientemente rapida al nucleo de ejecucion, de esta manera no importa que tenga que volver a decodificar la instruccion porque como las pipelines son cortas la demora entre decodificacion de la instruccion y el momento en que las microoperaciones alcanzan la RS no es tan grande como en netburst y RS siempre tendra instrucciones para ejecutar, es por eso que trace cache no es necesario. Si las instrucciones viajaran directamente del la etapa de decodificacion al nucleo de ejecucion si habria un problema de flujo de instrucciones en P6 pero par eso esta RS igual que para el P4 esta trace cache en el que un esquema de RS no seria suficiente.
