Tengo una pregunta para todos???

[Wargreymon]

Donde esté un dibujito…

Eso sería la parte del i7 "poderosa", vamos, la madre del asunto (quitando controlador integrado y demás).

Y esto sería la parte "que calcula" (ambas imagenes son de X-Bit).

Este último es exactamente igual en los i7 que en los core 2, la diferencia, pues basicamente que tienen más "chicha" y en este asunto la diferencia es que en determinadas situaciones tanto los core 2 como los i7 pueden ejecutar 4 operaciones por ciclo, no siempre, pero el ejecutar 4 operaciones por ciclo es más probable en el i7 que en el core 2, basicamente por una ligera modificacion en el branch prediction, lo demás es igual. Curiosamente en teoría el branch prediction de los core 2 es más rápido que el de los i7, pero el de los i7 es más efectivo (se "confunde" menos).

Puede parecer una tontería por que lo es, pero por estas razones para mi los i7 son Core 2 con controlador de memoria integrado…. (soy raro :p).

[Bm4n]

Que te refieres al HT?

[defaultuser]

Toma ya un optimizado del set de instrucciones para que el HT sea mas eficaz y ya tenemos nucleo nuevo.

Esta claro que en buses y en general supera a la plataforma PhenomII, pero a ver si afinal el i7 no va a ser tan monstruoso

Salu2.

[Wargreymon]

@Bm4n:

Que te refieres al HT?

HT? No he dicho nada del HT (al SMT te refieres no?)…

[Bm4n]

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...

[Wargreymon]

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.

[XRAYBoY]

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...

[Bm4n]

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?

[Javisoft]

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

[defaultuser]

@Bm4n:

…...La verdad es que esos graficos tan simples no representan bien la complejidad de una arquitectura...

Amen.

[Wargreymon]

@Bm4n:

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.

@Javisoft:

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á….

[cobito]

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.

[Wargreymon]

@cobito:

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….

[Bm4n]

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.

[XRAYBoY]

@Bm4n:

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

[Wargreymon]

@Bm4n:

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….

[NOLDOR]

@Wargreymon:

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

[Wargreymon]

@NOLDOR:

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:.

[defaultuser]

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.

[Bm4n]

@NOLDOR:

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.