Tengo una pregunta para todos???
-
-
xD he planteado mal la pregunta, me refiero a si lo que comentas de que ha mejorado el predictor, que permite aprovechar mejor el paralelismo tiene que ver con el Turbo Boost (antes llamado Hyper-Threading) o esto es algo diferente y no se relaciona, no conozco muy bien como funciona.
La verdad es que esos graficos tan simples no representan bien la complejidad de una arquitectura… hacer un conjunto eficaz es algo muy complicado. Desde mi punto de vista el i7 no es simplemente un Core con un controlador de memoría integrado, hasta ahora los procesadores se hacían para trabajar con los núcleos independientes simplemente se empaquetan en un mismo integrado y se intercomunicaban a través del L3, i7 ha sido el primer cambio de dirección en los procesadores Intel (de sobremesa) se ha construido para trabajar con multiples nucleos y ser eficaz manejando los nucleos segun se necesite un nivel u otro de paralelismo. Y en el futuro lo que se quiere lograr es que dependiendo del tipo de carga los núcleos puedan ser más flexibles y variar el paralelismo desde que varios núcleos trabajen en una sola tarea hasta que un núcleo pueda trabajar en varias unido al resto, hasta hace años el HT de Intel era lo más parecido y a mi parecer funcionó muy bien en su día, ahora evolucionado al concepto Turbo Boost.
No se si estoy en lo cierto...
-
Bueno, Turbo Boost y HT son dos cosas diferentes, HT(Hyper-Threading), al que ahora llaman SMT(simultaneous multi-threading), emula un núcleo virtual con intención de aprovechar los ciclos perdidos como ya sabes. El Turbo Boost simplemente consiste en que cuando solo un nucleo está siendo utilizado la velocidad de ese núcleo aumenta (por ejemplo, creo que en el i7 920 aumenta desde 2,6Ghz hasta 3,2Ghz). Esta última tecnologia no es gran cosa, pero bueno, para quién no haga OC está bien.
Bueno, el branch prediction se lleva a cabo en todos los micros, ya sean Intel o AMD, y segun tengo entendido, se encarga de "predecir" que camino va a seguir la instrucción inicial (me imagino que es si tiene que ir a la ALU, a la FPU o lo que sea). Bueno, en este aspecto los Core 2 tuvieron un cambio significativo ya que Intel metio dentro de su funcionamiento un detector con bufer, para que en caso de que se repita una instrucción esta tome directamente el camino sin que el predictor necesite volver a predecirlo, asi se ahorra tiempo.
En los Core 2 el detector está antes de la fase de decodificado y como sale en la imagen, en el bufer se guardan instrucciónes (que por lo visto tienen un limite de 18). En los i7 han puesto el detector despues de la fase de decodificado y en vez de guardar instrucciones solamente guarda las repeticiones (el búcle), y asi en vez de almacenar las instrucciones en el bufer como en los core 2 almacena las repeticiones (me imagino que les asignará un identificador), y por esto, pues el detector del i7 supuestamente almacena más "repeticiones" que los core 2 (almacenar repeticiones requiere menos espacio que almacenar instrucciones), por eso es más eficiente.
El SMT (o HT), como he dicho arriba aprovecha los ciclos perdidos en que las unidades de ejecucion no están siendo utilizadas, y así, mientras el ciclo se repite y las unidades de ejecucion estan en "idle" se aprovecha ese estado para realizar en paralelo otros calculos. La verdad es que es muy buena idea, creo que es una de las pocas tecnologias "rompedoras" de los Pentium 4.
En este gráfico se ve la eficiencia del SMT (HT). Los cuadrados blancos son las unidades de ejecucion que no están siendo utilizadas, las azules son las que están calculando un "hilo" y las verdes las que están calculando "otro hilo". Imagenes de X-Bit.*Como se ve en la imagen sin SMT el cuadrado grande se divide en dos trozos, azules con blancos en la parte de arriba y verdes con blancos en la de abajo. Con SMT aparece todo intercalado.
-
Bueno,locote…creo que han respondido claramente a tu pregunta y explicado con un lenguaje llano
para que no te queden dudas en cuanto a la elección.Como ves era un pregunta de respuesta muy simple... -
Si el HT o SMT funciona realmente bien. Lo poco que había leído del Turbo boost es que funciona en conjunto con el HT aumentando la eficiencia de cada núcleo según se necesite aumentando la frecuencia y demás, por eso preguntaba, no se hasta que punto es una tontería o algo más complejo.
Ya veo, aunque no debería ser más rápido el predictor al ahorrarnos la decodificación?
-
El Ht y el turbo boost funcionan a la vez, es como un cool and quiet pero al reves, aumentando potencia. Ah, y si hay diferencias, aparte de lo dicho aqui, mejor tbl, bus qpi, para leer mas :
AnandTech: Nehalem - Everything You Need to Know about Intel's New Architecture
-
…...La verdad es que esos graficos tan simples no representan bien la complejidad de una arquitectura...
Amen.
-
Si el HT o SMT funciona realmente bien. Lo poco que había leído del Turbo boost es que funciona en conjunto con el HT aumentando la eficiencia de cada núcleo según se necesite aumentando la frecuencia y demás, por eso preguntaba, no se hasta que punto es una tontería o algo más complejo.
Ya veo, aunque no debería ser más rápido el predictor al ahorrarnos la decodificación?
Pues si, tienes razón , me trabado ;). De todas formas para el ususario de a pie las mejoras en el branch prediction no se notan, en servidores parece que si.
El Ht y el turbo boost funcionan a la vez, es como un cool and quiet pero al reves, aumentando potencia. Ah, y si hay diferencias, aparte de lo dicho aqui, mejor tbl, bus qpi, para leer mas :
AnandTech: Nehalem - Everything You Need to Know about Intel's New Architecture
Si bueno, en estos últimos post estabamos refiriendonos más a los cambios en el núcleo en si y yo voy con la idea en la cabeza de que es una parte que no a cambiado demasiado. Mejor TLB tiene como dices, ya que tiene un TLB de nivel 2 complementando al primero (como pasa en la caché) y por lo demás, pues la tecnologia Macrofusion (que fusiona los micro-ops y macro-ops para acelerar el proceso) trabaja ahora en 64 bits en vez de 32 bits como en los core 2. Pero vamos, quitando el QPI, el controlador de memoria y el HT, la parte "poderosa" no ha sufrido un cambio tan bestial como en los Core 2, que al fin y al cabo, es lo que realmente se nota en el rendimiento de un micro (y más que nada es que el QPI y el controlador de memoria no son ninguna revolución, ya que llevabamos años esperandolo).
Me pregunto Sandy Bridge, aparte de las SSE5, que aportará….
-
Al final el mendas ha conseguido abrir un debate. Menos mal que aquí somos civilizados, porque en cualquier otro sitio, este hilo llevaría más de 100 páginas de insultos.
PD: Por cierto, seguid, que esto está interesante.
-
Al final el mendas ha conseguido abrir un debate. Menos mal que aquí somos civilizados, porque en cualquier otro sitio, este hilo llevaría más de 100 páginas de insultos.
xDDDD, visto así tienes razón
Una cosa que me gustaría saber es como hará Intel para desactivar el HT en los i5, es una cosa tan interna que no se me ocurre como lo pueden hacer, aparte de capandolo en BIOS….
-
Intel creo que ha estado muy acertada con el Turbo Boost, porque realmente tienen unos procesadores con mucho potencial en overclock y mejor que mejor que sea algo automático en momentos puntuales e independiente en sus núcleos. Es decir que el micro no se sobreesfuerza y tampoco tiene un consumo habitual alto, si eso lo unimos a un HT que trabaje dependiendo de la tarea aumentando el numero de hilos tenemos un procesador muy interesante.
Hace tiempo que comentamos las novedades del i7 y creo que son significativas, por lo que hablamos antes este es el primero creado exclusivamente para multinucleo, 64bit, etc.
No creo que sea complejo anular ese pase de datos a los huecos libres entre las instrucciones de un hilo, simplemente anularán/eliminarán la parte que se encargaba del HT.
De Sandy Bridge, por lo que he leído, se espera mucho; mejor eficiencia en consumo, esté parece que entrará directo al sector portátil, más interconexión interna, nuevas instrucciones, 32nm, que sea modular, GPU incorporado… imagino que intentarán hacer lo que AMD anunció sumar los ciclos de los core para trabajos mono hilo. No se pero a mi me suena muy diferente a i7 pero lo que llegue a las tiendas habrá que ver.
-
Intel creo que ha estado muy acertada con el Turbo Boost, porque realmente tienen unos procesadores con mucho potencial en overclock y mejor que mejor que sea algo automático en momentos puntuales e independiente en sus núcleos. Es decir que el micro no se sobreesfuerza y tampoco tiene un consumo habitual alto,(…)
Básicamente lo que haría el C1E,bajando y subiendo el multi,pero integrado en el micro?
HT aparte,que ventajas tiene eso a programarlo en Bios? Pregunto…Edito: pregunta tonta..."independiente".>Sorry
-
Intel creo que ha estado muy acertada con el Turbo Boost, porque realmente tienen unos procesadores con mucho potencial en overclock y mejor que mejor que sea algo automático en momentos puntuales e independiente en sus núcleos. Es decir que el micro no se sobreesfuerza y tampoco tiene un consumo habitual alto, si eso lo unimos a un HT que trabaje dependiendo de la tarea aumentando el numero de hilos tenemos un procesador muy interesante.
Hace tiempo que comentamos las novedades del i7 y creo que son significativas, por lo que hablamos antes este es el primero creado exclusivamente para multinucleo, 64bit, etc.
No creo que sea complejo anular ese pase de datos a los huecos libres entre las instrucciones de un hilo, simplemente anularán/eliminarán la parte que se encargaba del HT.
De Sandy Bridge, por lo que he leído, se espera mucho; mejor eficiencia en consumo, esté parece que entrará directo al sector portátil, más interconexión interna, nuevas instrucciones, 32nm, que sea modular, GPU incorporado… imagino que intentarán hacer lo que AMD anunció sumar los ciclos de los core para trabajos mono hilo. No se pero a mi me suena muy diferente a i7 pero lo que llegue a las tiendas habrá que ver.
Pues si, es bastante buena idea lo malo que tienen los i7 es que al ser tan complejos y tener tal número de transistores se calientan bastante también, no es raro verlos pasar fácilmente de 70ºC con un mero OC a 3Ghz (en el caso del 920) en algunos casos. Cuando pasen a 32nm seguro que suben mucho más facilmente que ahora.
Y por lo que dices, parece que tanto los Bulldozer como los Sandy Bridge son una nueva vision de los micros multicore (aunque la GPU integrada me imagino que la integrarán solo en los modelos de gama baja, no tiene sentido que los de gama alta la tengan), sobretodo si son capaces de usar todos los cores para una aplicación monohilo. Las tarjetas gráficas reparten el trabajo entre los procesadores asi que en CPUs en teoría, aunque de una manera más compleja, también se tendría que poder….
-
Bueno, el branch prediction se lleva a cabo en todos los micros, ya sean Intel o AMD, y segun tengo entendido, se encarga de "predecir" que camino va a seguir la instrucción inicial (me imagino que es si tiene que ir a la ALU, a la FPU o lo que sea). Bueno, en este aspecto los Core 2 tuvieron un cambio significativo ya que Intel metio dentro de su funcionamiento un detector con bufer, para que en caso de que se repita una instrucción esta tome directamente el camino sin que el predictor necesite volver a predecirlo, asi se ahorra tiempo.
El branch prediction si mucho no me equivoco es el encargado de "predecir" si la instrucción que se está decodificando/ejecutando va a saltar a otra parte del código o no. Es una función fundamental en los procesadores segmentados de hoy día y una de las razones de que el pentium 4 y su pipeline interminable al final fuesen más lentos a igual velocidad de reloj que procesadores de pipeline más corto.
A grosso modo, esto va de que un procesador no ejecuta una instrucción cada vez sino que tiene un pipeline que divide en etapas las instrucciones, y cada etapa hace una cosa. Así, extrae la primera instrucción, y cuando la manda a decodificar(etapa2) ya está extrayendo la siguiente instrucción. Con lo que si tenemos un pipeline de 10 etapas, se están "ejecutando" a la vez 10 instrucciones. ¿Pero qué pasa si la instrucción que decodificamos manda saltar a otro punto del código? Pues que hay que vaciar el pipeline entero porque las instrucciones que siguen ya no se van a ejecutar. Y esto tiene su tela, porque algunas ya han modificado datos y hay que "deshacer" los cambios. Por eso, tener una buena unidad de predicción es fundamental para saber cuanto antes qué va a pasar y minimizar las etapas en las que el procesador no va a hacer nada por tener el pipeline vacío.
Espero haberme explicado xD
-
El branch prediction si mucho no me equivoco es el encargado de "predecir" si la instrucción que se está decodificando/ejecutando va a saltar a otra parte del código o no. Es una función fundamental en los procesadores segmentados de hoy día y una de las razones de que el pentium 4 y su pipeline interminable al final fuesen más lentos a igual velocidad de reloj que procesadores de pipeline más corto.
A grosso modo, esto va de que un procesador no ejecuta una instrucción cada vez sino que tiene un pipeline que divide en etapas las instrucciones, y cada etapa hace una cosa. Así, extrae la primera instrucción, y cuando la manda a decodificar(etapa2) ya está extrayendo la siguiente instrucción. Con lo que si tenemos un pipeline de 10 etapas, se están "ejecutando" a la vez 10 instrucciones. ¿Pero qué pasa si la instrucción que decodificamos manda saltar a otro punto del código? Pues que hay que vaciar el pipeline entero porque las instrucciones que siguen ya no se van a ejecutar. Y esto tiene su tela, porque algunas ya han modificado datos y hay que "deshacer" los cambios. Por eso, tener una buena unidad de predicción es fundamental para saber cuanto antes qué va a pasar y minimizar las etapas en las que el procesador no va a hacer nada por tener el pipeline vacío.
Espero haberme explicado xD
Sin duda que te has explicado jaja, por fin he entendido qué es lo que se predice :risitas:.
-
Encima de todo lo visto en los graficos se ve que de los i5 para abajo ya no traen QPI, en su lugar el veterano DMI ja ja, pues a esta marcha los i3 van a ser Core2 con controladora DDR3.
Parece mentira que este post se este poniendo tan interesante, con el principio que tiene …..
Habreis oido hablar de que las instrucciones x86/64 son muy mal aprovechadas por los programadores y que en los pc, el software ademas de no aprovechar bien todas las posibilidades de las instrucciones solo usan una parte de ellas. Pues CISC (x86) surgio de la necesidad de escrivir software cada vez mas complejo y en el menor tiempo posible, el sistema de instrucciones CISC mas complejo simplifcava la labor del programador y ahorrava tiempo, sin enbargo hasta la actualidad no se ha aprovechado correctamente el sistema CISC.
La arquitectura RISC usa instrucciones mas sencillas, breves, mas versatiles, en lugar del uso de tantas instrucciones especificas y mas grandes de x86, entonces programar para RISC es mas lento, da mas trabajo, pero el soft usa el micro mas a fondo y corre mas rapido. Os habreis fijado que el soft para sistemas RISC se actualiza mucho menos, tarda mas en concluirse, pero suele funcionar mejor a la primera sin parches constantes y funcionando eficaz y eficientemente.
Esta claro que el soft cada vez es mas complejo, y constantemente encontramos mas usos y le pedimos mas, pero x86 lo que hace es micros cada vez mas complejos, e intenta ir sacando mejor provecho de las instrucciones CISC, y asi paga constantemente hardware nuevo y cada vez mas complejo, y todos contentos (fabricantes de soft y de hard).
Me consta que una de las principales mejoras que ha habido en los x86 recientes, consiste en la habilidad adquirida de poder subdividir ciertas instrucciones en sub-instrucciones RISC mas cortas para manejo interno, mejorando asi el aprovechamiento de los ciclos a nivel interno (core-L1 se supone). (Total , a final de cuentas traer partes de RISC para subsanar debilidades del CISC moderno).
Ha habido mejoras y muchas, las hay casi con cada referencia de micro que sale al mercado, y se va puliendo cada vez mas el funcionamiento de la arquitectura PC , pero eso no quita que CISC nacio torcido porque fue fruto del afan de crecimiento rapido del sector (el crecimiento era inevitable, pero las prisas y la perfeccion se llevan a ostias).
A mi la verdad, hace rato ya que una mosca detras de la oreja me dice que esa version nueva del HiperThreading, SMT o multihilo simultaneo por nucleo, va a ser precisamente el deglosado en sub-instrucciones RISC a nivel interno, y por eso no todas las opreaciones le sacan provecho, porque con ciertas instrucciones CISC x86/64 se puede hacer el deglosado a sub-instrucciones RISC para manejo interno, y con otras no.
Je je, me cuadra todo demasiado que me presenten pruebas o argumentos convincentes.
No digo exactamente que RISC sea mejor, es mas elitista, porque el codigo da mas faena de desarrollar para esa plataforma y el soft se encarece, pero al mismo tiempo el codigo es mas corto, mas limpio y mas eficiente, y aprovecha el micro mejor.
Yo a final de cuentas, miro de tener una plataforma actual y busco la mejor relacion rendimiento/precio dentro de mis posibilidades, y para lo que lo voy a usar, un AMD overclockeado con una grafica decente subida tambien, un raid0 con el maximo numero de discos posible, y el resto de matices segun este el bolsillo.
Bueno si eso, la fuente con cierta calidad, siempre.Salu2.
-
Espero haberme explicado xD
Sí, te has explicado perfectamente, gracias por refrescarnos la memoria jeje. Pues no se que decir tampoco entiendo mucho de esto, pero tendrá algo que ver en la mejora del predictor el que trabaje con instrucciones ya decodificadas… uhm claro es más lento porque siempre hay que esperar a que se decodifiquen pero es más eficaz trabajar con estas ya decodificadas que es lo que decia Wargreymon.
Los i5 e i3 son un intento de simplificar los micros Nehalem para meterlos en el mercado bajo coste y en el de bajo consumo de portátiles... pero a mi no me convencen lo más minimo. Y tampoco creo que vaya a funcionar muy bien el i7 en portátiles, quizas en alta gama. Eso mismo les pasó con P4, no servian para portatil porque eran muy calientes y complejos, un portatil funcionaba mucho mejor con un PM que era mucho más sencillo pero eficaz.
Yo por lo menos prefiero en un portátil un C2D de bajo consumo que ningún i7 por mejores bench que saque.
-
Encima de todo lo visto en los graficos se ve que de los i5 para abajo ya no traen QPI, en su lugar el veterano DMI ja ja, pues a esta marcha los i3 van a ser Core2 con controladora DDR3.
No creo, se supone que los i5 vienen sin SMT y los i3 sin SMT y sin Turbo Boost. Como los capen más van a dejar de ser nehalem….. Además, no creo que puedan tener el controlador de memoria integrado sin intefaz QPI, a no ser que no lo lleven tampoco.....
-
El branch prediction parece que es como aquellos programas tipo "Navegue más rápido!" que se vendían cuando navegavamos a 5kb/s.
Precargaba los enlaces en los que todavía no habías pinchado,pero si saltabas a otra pagina externa,iba peor…A no ser para programas creados específicamente para Intel o AMD,dependes de si "acierta" en su predicción.(como el hombre del tiempo):p
Puede ser esta,en parte,la razón de tantas diferencias entre benchmarks sintéticos y de juegos? Que vayan mejor con un micro que con otro,a la misma frecuencia?Salu2
-
El branch prediction parece que es como aquellos programas tipo "Navegue más rápido!" que se vendían cuando navegavamos a 5kb/s.
Precargaba los enlaces en los que todavía no habías pinchado,pero si saltabas a otra pagina externa,iba peor…A no ser para programas creados específicamente para Intel o AMD,dependes de si "acierta" en su predicción.(como el hombre del tiempo):p
Puede ser esta,en parte,la razón de tantas diferencias entre benchmarks sintéticos y de juegos? Que vayan mejor con un micro que con otro,a la misma frecuencia?Salu2
El Branch Prediction puede tener una parte pequeña de responsabilidad en eso, pero la razón principal de que unos micros rindan más que otros a igual frecuencia es que son capaces de ejecutar más instrucciónes en un ciclo de reloj. Si estoy en lo cierto, en un procesador de 3000mhz hay 3000 ciclos por segundo. El asunto es que la cantidad no es exacta, por ejemplo, teoricamente los Pentium 4 podía realizar un máximo de 2 operaciónes por ciclo, pero eso no significa que las pueda hacer siempre, solo en determinadas situaciones (y en el caso de los Pentium 4 con un pedazo pipeline de 28 etapas tardaba una barbaridad en ejecutar una instrucción, de ahí su escaso rendimiento comparado con los K8 a igual frecuencia).
Los K8 realizan 3 operaciónes por ciclo como máximo y tienen un pipeline de 13 etapas si no me equivoco. En los K10 es similar, antes hablabamos de cambios significativos entre Core 2 y Core i7 pero no hay duda de que entre el K8 y el K10 la diferencia si que es muy poca. Los Core 2 Duo pueden realizar hasta 4 operaciones por ciclo, en parte gracias a Macrofusion y si nehalem tiene más posibilidades de ejecutar 4 operaciones por ciclo que los Core 2 es en parte por la mejora en macrofusion (pasa de 32 a 64 bits). Lo único que tienen los K10 que no tienen ni los Core 2 ni los i7 a nivel interno es capacidad de leer datos de 32bits directamente al hacer el fetch (al menos tengo entendido que los i7 no poseen esta caracteristica), lo cual también tiene su impacto a la hora de ejecutar las instrucciónes (un instrucción de 32 bits de largo un core 2 lee primero los primeros 16 bits y luego los otros 16 bits, mientras que un K10 lo hace de golpe).
En resumidas cuentas (P4, K8/10 y Core2/i7) :
P4-> 3000mhz * 2 operaciones por ciclo = 6000 millones de operaciones por ciclo
K8/K10-> 3000mhz * 3 operaciones por ciclo= 9000millones de operaciones por ciclo
Core 2/i7-> 3000mhz * 4 operaciones por ciclo= 12000millones de operaciones por ciclo*A tener en cuenta que estamos hablando del maximo, no quiere decir que esas cifras se cumplan siempre, es un simple máximo teorico. Se supone que está es la principal razón de las diferencias de rendimiento de los diferentes micros a igual frecuencia.