Tengo una pregunta para todos???
-
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.
Ryzen 5 3600 - Tuf B550 pro - 2x 8g 3600c18 - Strix rtx 2060 - M2 1TB
-
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.
-
Por cierto, ya que hablabamos de futuros lanzamientos, en 2010 tenemos i9s:
Son los hexacore, con 6 núcleos, 12 hilos, 12Mb de L3 y de 32nm. Y teniais razón, parece que los Core i3 no son nehalem, son los core 2 xD.
-
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 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.
me parece que el ciclo no corresponde con el periodo de la frecuencia. En pics por ejemplo tienes 1 ciclos máquina por cada 4 ciclos de reloj, y una instrucción ocupa un ciclo maquina, menos algunas operaciones de salto que tardan 2 ciclos maquina
-
me parece que el ciclo no corresponde con el periodo de la frecuencia. En pics por ejemplo tienes 1 ciclos máquina por cada 4 ciclos de reloj, y una instrucción ocupa un ciclo maquina, menos algunas operaciones de salto que tardan 2 ciclos maquina
Te refieres a esto? http://es.wikipedia.org/wiki/Microcontrolador_PIC
No he oido hablar nunca de ciclos máquina….
-
Aki en la parte de reloj lo pone:
PIC16F87X - Wikipedia, la enciclopedia librePero puede que que los procesadores funcionen de otra manera. no lo se la verdad….
-
Lo que pasa es que eso no es un microprocesador x86, es un microcontrolador, no están orientados para lo mismo ni a realizar el mismo tipo de calculos. Si no me equivoco, esos chips se utilizan para controlar circuitos electronicos y son preprogramados.
No me habia fijado nunca en los PICs, me gustaría saber si tienen ALU y FPU…. (aunque me parece que no, y si tienen, serán muy simples...).
-
Lo que pasa es que eso no es un microprocesador x86, es un microcontrolador, no están orientados para lo mismo ni a realizar el mismo tipo de calculos. Si no me equivoco, esos chips se utilizan para controlar circuitos electronicos y son preprogramados.
No me habia fijado nunca en los PICs, me gustaría saber si tienen ALU y FPU…. (aunque me parece que no, y si tienen, serán muy simples...).
un microcontrolador es un miniordenador, con su cpu, su memoria, sus buses de e/s,…..
Tienen normalmente una arquitectura Von Neumann o Harvard.... con instrucciones risk.
Lo hay incluso de 32 bits.... -
Sí, un ciclo maquina es el numero de ciclos que tarda un procesador en resolver una instrucción, a veces tarda más o menos dependiendo del tipo de instrucción que sea, más compleja o menos, no lleva el mismo tiempo una suma simple que una raiz cuadráda con decimales (es un decir).
PD. Puedes medir el trabajo de un procesador en Hz o en Flops, lo más real es lo segudo.
-
Sí, un ciclo maquina es el numero de ciclos que tarda un procesador en resolver una instrucción, a veces tarda más o menos dependiendo del tipo de instrucción que sea, más compleja o menos, no lleva el mismo tiempo una suma simple que una raiz cuadráda con decimales (es un decir).
PD. Puedes medir el trabajo de un procesador en Hz o en Flops, lo más real es lo segudo.
Supongo que ninguna CPU "de las de ahora" tarda menos de un ciclo en ejecutar una instrucción…
-
Depende mucho del tipo de procesador, pero si, logran hacer muchos FLOPS por hercio. Hay otra medida también que es IPS, instrucciones por segundo. Seguro que os suena mucho más MIPS y GFLOPS. Esto de los FLOPS tampoco es una referencia real de rendimiento en un sobremesa, pero es una buena referencia, sobre todo en procesadores gráficos.
Processors - Intel
microprocessor export compliance metricsPD. Más medidas, MTOPS, million theoretical operations per second. Una operación puede constar de más de una instrucción.
