Intel cava su propia tumba: DRM emebido en Pentuim D
-
La arquietctura x86 contiene desde el principio centenares de instrucciones CISC, por lo que cada procesador compatible x86 es CISC. Las arquitecturas RISC no van a desaparecer, pues son las que permietn segmentar un micro, con lo que se puede elevar su rendimiento y frecuencia de reloj.
El 486 era un micro CISC.
El Pentium era un micro que contenia internamente dos 486 (una con la unidad de coma flotante y otro sin ella.) Ademas, dicha unidad estaba segmentada (pipeline). Eso le permitia empezar a procesar una instrucciíon antes de que la anterior hubiera terminado. Eso multiplicaba el rendimiento de los Pentium en operaciones de coma flotante con respecto a los 486.
El segmentar un micro permite aumentar su frecuencia de reloj y aumenar su rendimiento, pues puede procesar varias instrucciones a la vez (aunque no paralelamente). Pero es imposible segmentar un micro CISC, pues la segmentación requiere que las instrucciones a procesar sean "sencillas" o sea, no permiten operaciones aritmeticas que accedan a la memoria del ordenador. Solo permiet operaciones aritmeticas entre registros o operaciones de cargar/almacenar el valor de una posición de memoria en un registro.
El Pentium Pro era un micro enteramente segmentado, ello elevaba consideramente el rendimiento, pero necesitaba que antes de procesar una instrucción CISC, esta se conviertiera en una o varias operaciones RISC.
El Pentium II y Pentium III son evoluciones del Pentium Pro.
Con el Pentium 4 se elevo el numero de segmentos a 20 y en los nuevos modelos a 32 estados.Los AMD K6 creo que eran segmentados, pero no asi su unidad de coma flotante, con lo que su rendimiento en este tipo de calculos eran inferior a los micros de Intel. Para elevar su poetncia creo que legaron a incluir en el micro 3 unidades de coma flotante.
Los AMD K7 dividen cada instrucción CISC en dos instrucciones RISC (o solo a una, dependiendo del tipo de instrucción), una de acceso a memoria y otra de operacion ALU (Arimetrico-Lógica). Son micros segmentados, aunque su pipeline no es tan larga (10 ó 12 estados), con lo que a menor frecuencia de reloj consiguen un rendimiento "equivalente" a los de los Pentium 4.
Son las 04:33 y no tengo ganas de dormir. Por eso he escrito todo esto. Si me he equivocado en algo que alguien me corrija.
-
Se t agradece el esfuerzo, gracias, me va quedando mas clara la cosa, entonces segun e entendido, a mas segmentos tenga el micro mas frecuencia de reloj se consigue, en ese caso amd iria en desventaja, que la subsana por otro lado con lo que tu comentabas, pero entonces, no deveria un P4 tirar mas que un K8? En la practica la mayoria de las veces no es asi, suele ganar en multimedia pero por lo que e visto poco mas. No sera mejor tener menos mhz y utilizarlos mejor como hacen los Amds? Parece el cuento de nunca acabar pero es k no m keda todavia claro el pk en la practica no se refleja lo que ay en el papel. Saludossssss
-
Un poquito de por favor, vamos a ver, quien puede decirme ¿porque Microsoft no a puesto ninguna protección anticopia en su SO?
¿Cuantos de nosotros elegirían como jovi la informática si tuviéramos que pagar por todo lo que usamos?, ¿cuantos ordenadores dejarían de venderse?, ¿los fabricantes de de hardware acusarían una bajada de ventas?¿porque la play station I triunfo de una manera tan aplastante?.Que no se engañe nadie, la informática va unida a la piratería.
hombre, eso es un poco de demagogia barata. Está claro que la piratería existe, existió y existirá. Tambien es cierto, que en la epoca del amstrad de cinta, que era tremendamente facil copiar un juego muchisima gente se los compraba originales (porque el precio que tenian no era desmesurado). Los que aqui hay que tienen por hobbie la informatica pagan por practicamente todo lo que usan (el hardware), y algunos autentica pasta, lo que pasa es que es más facil gastarse 400€ en una grafica que 120€ en el SO, y porqué?, pues porque el SO te lo bajas, te lo prestan, etc. y sino pues te instalas alguna distribucion de linux gratuito (que no todas lo son), pero claro, ya no puedes jugar… MS no ha puesto ningun sistema anticopia a sus SO pq no le interesa invertir autenticas millonadas en sistemas que a los 2 dias están vulnerados, pero en cuanto salga alguno realmente fiable no te preocupes que lo pondran. La estrategia es crear la necesidad, para llegado un punto a la gente no le importe pagar por un producto que lleva años consumiendo gratis, esto es como lo del Digital+, que efectivamente cuando dejó de ser pirateable hubo mogollon de gente que se dió de baja, pero hubo un mogollón más que siguió dada de alta y pagando, cosa que no hubieran hecho de ningun modo si desde el principio no hubiera sido pirateable.
Salu2
Packo -
@Javisoft2004:
Se t agradece el esfuerzo, gracias, me va quedando mas clara la cosa, entonces segun e entendido, a mas segmentos tenga el micro mas frecuencia de reloj se consigue, en ese caso amd iria en desventaja, que la subsana por otro lado con lo que tu comentabas, pero entonces, no deveria un P4 tirar mas que un K8? En la practica la mayoria de las veces no es asi, suele ganar en multimedia pero por lo que e visto poco mas. No sera mejor tener menos mhz y utilizarlos mejor como hacen los Amds? Parece el cuento de nunca acabar pero es k no m keda todavia claro el pk en la practica no se refleja lo que ay en el papel. Saludossssss
Utilizar mas pipelines o etapas permite aumentar la velocidad de reloj, pero al mismo tiempo existe una gran penalización ya que si en un momento dado existe un error de predicción (frecuentemente) en una rama la CPU debe descartar todos los datos que había estado procesando, vaciar o limpiar todas las pipelines y volver a empezar. Esto reduce la eficiencia enormemente ccomo sucede en un P4. Un K8 por su parte posee muchas menos etapas y la penalización es mucho menor, además porque el K8 posee algoritmos de predicción mucho más eficientes que el de el P4. Es por esta razón que en forma efectiva un K8 puede realizar más intrcciones por ciclo de reloj, al menos un un 30% más, el presscot posee más de 30 etapas, el K8 sólo posee 13.
-
Yo no estoy de acuerdo totalmente. Lo primero es que el echo de aumentar las etapas de segmentacion conlleva la disminucion de el numero de ciclos de reloj por etapa y de esta manera se puede aumentar la frecuencia de trabajo del procesador. Si la prediccion falla, debemos vaciar los registros de segmentacion que estan entra las etapas; pero el echo de tener mas etapas no quiere decir que forzosamente tengamos que tener mas registros de segmantacion. Estas registros de utilizan en aquellas etapas donde la anticipacion de datos es necesaria para no perder ciclos de reloj en esperas que producen las dependencias de datos. Por lo tanto ante un caso de dos etapas, por ejemplo la etapa de escritura en registros y la etapa de escritura en memoria no es necesario colocar ningun registro de segmentacion porque no hay dependencias. Despues de todo este rollo, quiero decir que el echo de aumentar el numero de etapas no implica necesariamente una perdida de tiempo extra resultante del fallo en la prediccion; y tampoco quiere decir que por tener mas etapas nuestra BTB (es la unidad funcional encargada de las predicciones) sea mejor o peor.
-
Buffff, ahora si que estoy K.O.
-
Yo no estoy de acuerdo totalmente. Lo primero es que el echo de aumentar las etapas de segmentacion conlleva la disminucion de el numero de ciclos de reloj por etapa y de esta manera se puede aumentar la frecuencia de trabajo del procesador. Si la prediccion falla, debemos vaciar los registros de segmentacion que estan entra las etapas; pero el echo de tener mas etapas no quiere decir que forzosamente tengamos que tener mas registros de segmantacion. Estas registros de utilizan en aquellas etapas donde la anticipacion de datos es necesaria para no perder ciclos de reloj en esperas que producen las dependencias de datos. Por lo tanto ante un caso de dos etapas, por ejemplo la etapa de escritura en registros y la etapa de escritura en memoria no es necesario colocar ningun registro de segmentacion porque no hay dependencias. Despues de todo este rollo, quiero decir que el echo de aumentar el numero de etapas no implica necesariamente una perdida de tiempo extra resultante del fallo en la prediccion; y tampoco quiere decir que por tener mas etapas nuestra BTB (es la unidad funcional encargada de las predicciones) sea mejor o peor.
Bueno segun artículos especilizados de arstechnica, además de otras razones, el aumento de etapas penaliza el rendimiento debido a las fallas en la predicción que llegan a causar desperdicios de cilcos de reloj importantes. Para la muestra la arquitectura netburst. No esoy diciendo que la efectividad de la unidad de predicción dependa del número de pipelines, sino que al aumentar el numero de pipelines se requiere una mejor unidad de predicción.
"I talked above about how the P4's greatly-enlarged and more-complex instruction window is one place where the P4 pays a price for its deep pipeline and high clock speed. The other place where the P4 spends a ton of resources to cover the costs of deep pipelining is in its branch prediction unit. For reasons which will become even more clear in the section below, the P4's deep pipelines mean that a mispredicted branch will cost many more wasted cycles than it would on the P6."
"Following the execute stage on the P4 are the flags, branch check, and drive stages. In the flags stage any flags that the need to be set as a byproduct of the instruction's execution (i.e., a division by zero flag, overflow flag, etc.) are set in the x86's flag register. The branch check stage, stage 19, is where branch conditions are evaluated, which means that in the case of a mispredict you have to flush 19 stages (en el caso del willamete y northwood, en caso del presscot este numero asciende a 31) worth of work out of the pipeline. That's a lot of wasted cycles. Finally, there's a final drive stage dedicated to sending the results of the execution back to the ROB where they'll wait to be written back to the register file at retirement time."
http://arstechnica.com/articles/paedia/cpu/pentium-2.ars/4
http://arstechnica.com/articles/paedia/cpu/pipelining-2.ars -
El aumentar el numero de etapas sin incrementar la frecuencia de trabajo del procesador puede que produzca una pequeña perdiada de rendimiento; pero no tiene porque. Depende mucho del codigo que se este ejecutando y de lo buenos que sean los compiladores reordenando las instrucciones para asi disminuir las dependencias.
Estamos en lo de siempre, aunque tengas la mejor arquitectura sino tiene un soprte software bueno…....no tienes nada.
-
El aumentar el numero de etapas sin incrementar la frecuencia de trabajo del procesador puede que produzca una pequeña perdiada de rendimiento; pero no tiene porque. Depende mucho del codigo que se este ejecutando y de lo buenos que sean los compiladores reordenando las instrucciones para asi disminuir las dependencias.
Estamos en lo de siempre, aunque tengas la mejor arquitectura sino tiene un soprte software bueno…....no tienes nada.
Además de las fallas en predicción existen otras razones inherentes al hardware por las cuales aumentar las pipelines se causa inevitablemente una disminución en el IPC, echale una leída a los artículos de arstechnica. No tiene nada que ver con el software.
-
¿Que no tiene nada que ver con el software???
Si el programa que se ejecuta no tuviera ningun tipo de dependencias (WAW, WAR y RAW) directamente no se utilizarian los registros de segmentacion para almacenar los datos producidos por las etapas. Como he dicho antes, los compiladores juegan un papel fundamental ya que la reorganizacion de codigo puede eliminar los retasos producidos por dichas dependencias.
-
¿Que no tiene nada que ver con el software???
Si el programa que se ejecuta no tuviera ningun tipo de dependencias (WAW, WAR y RAW) directamente no se utilizarian los registros de segmentacion para almacenar los datos producidos por las etapas. Como he dicho antes, los compiladores juegan un papel fundamental ya que la reorganizacion de codigo puede eliminar los retasos producidos por dichas dependencias.
No estoy hablando de dependencias ni nada relacionado con el software, sino del IPC, instrucciones por ciclo de reloj, parámetro que depende exclusivamente de la arquitectura y efieciencia de la CPU. El IPC se ve reducido de forma inexorable al aumentar el número de etapas en una arquitectura dada. Y así el software fuese ideal iy perfectamente eficiente, de todas maneras seguiría ejecutandose más lentamente si a una CPU dada se le incrementan la pipelines y se conserva la velocidad de reloj simplemente porque ejecuta menor número de instrucciones por cliclo sea cual fueren las instucciones que se ejecuten así sean simples instrucciones de carga en registros.
-Algunas etapas son de forma inherente más complejas y son más lentas que otras Pero cada etapa debe (o debería) tomar el mismo tiempo para realizar su trabajo, pero esto no ocurre!, en lugar de esto las etapas más rápidas deben mantenerse en idle hasta que la etapa más lenta termine su trabajo, en otras palabras, la cantidad de tiempo que toma a la etapa más lenta realizar su trabajo es la que determina la tasa de instrucciones y se constituye en un desperdicio de recursos. Y esto es absolutamente independiente del software, pués, las etapas del microprocesador y las tareas que se realizan dentro de ellas de forma independiente son transparentes para cualquier compilador o ensamblador, pues estos solo se encargan de entregar las instrucciones a la CPU para que las ejecute. Entre más se subdivida la CPU en etapas, las
pipelines individuales se vuelven cada vez menos uniformes entre en longitud y complejidad el resultado de esto es que los tiempos de ejecución de instrucción (independietemente del software) se hacen más y más largos. Es muy díficil para los diseñadores de hardware hacer que las etapas sean uniformes consuman la menor cantidad de tiempo.Un ejemplo claro de estas falencias: EL P4, que sólo alcanza rendimiento aceptable al utilizar instrucciones SIMD, que realizan varias operaciones en una sola instrucción, que igual pueden implementarse en CPUs con pipelines más cortas y sin demasiado esfuerzo.-Otro problema al utilizar mayor número de pipelines algunas instrucciones podrían quedarse "colgadas"
en alguna etapa durante varios ciclos por un número razones concernientes exclusivemente al hardware.
Cuando este cuelgue ocurre todas las instrucciones que vienen de las etapas anteriores a la que se colgó
avanzan normalmente, mientras que la instrucción colgada avanza pero genera un vacío en la etapa que acaba de dejar. Cuando éste vació (llamado burbuja de pipeline) llega a la unidad de ejecución el procesador no ejecuta nada y la tasa máxima de instrucciones se ve reducida también por esta causa.Entonces ya hay tres rezones por las cuales incrementar las pipelines en una arquitectura específica penaliza el rendimiento gravemente.
-Fallas en predicción, que podría ser dependiente del software, pero en menor grado ya que las unidades de predicciín tienen una efectividad del 98%, entonces en CPUs actuales la penalización no se produce muy a menudo por fallas en predicción si por la complejidad que implica la necesidad del aumento de complejidad de la unidad de predicción y la cantidad de cilclos que la misma podría desperdiciar.
-No uniformidad exacta en el rendimiento de las etapas individuales, que independientemente del software reduce el IPC de forma importante al de una CPU ideal.
-Introducción de vacios en por cuelgue de pipelines que ocurre de forma independiente al software, y que también dsiminuye el IPC de su máximo teórico.
El ejemplo de estos tres efectos se hace evidente el el P4, la CPU más ineficiente que existe actualmente, y que es efectivamente el que mayor número de pipelines posee.
-
Bueno pues tu sigue pensando lo que quieras que yo haré lo mismo.
Por cierto, de donde has sacado eso de que "las etapas mas rapidas deben matenerse en idle", a que te refieres con idle?? No querras decir con poca carga de trabajo porque eso no es asi. La etapa de operaciones ALU en concreto las operaciones en punto flotante realizan sumas, multiplicaciones, etc..en punto flotante; por lo que la unidad trabaja o no hace nada porque los que si es seguro es que no hace "sumas normales".
-
Bueno pues tu sigue pensando lo que quieras que yo haré lo mismo.
Por cierto, de donde has sacado eso de que "las etapas mas rapidas deben matenerse en idle", a que te refieres con idle?? No querras decir con poca carga de trabajo porque eso no es asi. La etapa de operaciones ALU en concreto las operaciones en punto flotante realizan sumas, multiplicaciones, etc..en punto flotante; por lo que la unidad trabaja o no hace nada porque los que si es seguro es que no hace "sumas normales".
No sabes que es IDLE???!!!! IDLE es que no hacen nada… Y si es ciert. Crees que al incrementar las etapas todas van a funcionar de forma ideal. Que equivocado estas! Veo que no tienes ningún concepto de lo que es diseñar hardware . Es supremamente complicado la implementación el mismo pues trabaja con señales físicas que inevitablemente sufren retrasos que penalizan el rendimiento y estos retrasos se incrementan cada vez que la lógica necesaria para impementar cada vez más etapas puede volverse estremada mente compleja y larga. Alguna vez has diseñado hardware? y visto las consecuencias de implementar multiples etapas en un sistema? Pués yo sí y por eso hablo con conocimiento de causa.
Ejemplo. El P4 sin HT utiliza la unidad de ejecución sólo el 30% del tiempo, con HT(que es una optimización hardware) puede llegar a utilizarla el 40%, el resto del tiempo la unidad de ejecución se mantiene en IDLE ya que debe esperar a que las demás etapas realicen su trabajo y tengan lista la instrucción para ser ejecutadas. Esto es un ejemplo claro de como afectan el gran número de pipelines el rendimiento, absolutamente independiente del software que ejecute.
Tiendes a contradecir mucho, pero no veo argumentos que fundamenten lo que dicen ,por otra parte he logrado demostrar con argumentos supremamente contundentes y ejemplos la realidad, quisiera que hicieras lo mismo, porque hasta ahora he visto incoherencias supremamente graves en tus respuestas.
No es lo que yo pienso , es como son las cosas, si quieres seguir manteniendo tus conceptos equivocados esta bien.
Por otra parte tu ejemplo de la ALU esta muy mal hecho ya que la ALU es una unidad aparte que en cualquier arquitectura se encuetra aparte del núcleo básico de ejecución(No es ninguna etapa intermedia de la CPU por que deban pasar todas las instrucciones) de las etapas absolutamente necesarias para realizar todas las instrucciones, evidentemente la CPU utiliza la ALU solo cuando se refiere a operaciones aritmético lógicas, pero si es una operación de carga a registro o de movimiento de memoria no será necesario utilizar la ALU. Pero las otras etapas como FETCH, decode, execute, write, ect (y que podrían subdividirse on otras etapas de igual forma que la FPU y la IU) deben procesar todas las instrucciones todo el tiempo. Al subdividir cada vez mas estas etapas se produce una complejidad inimaginableí y resultan etapas que son invevitablemente más complejas que otras, complejidad que causa retrasos puramente físicos y demoras en operaciones específicas. Desde el 486 la FPU siempre ha sido una unidad aparte del núcleo básico de ejecución y se sigue menteniendo así y con mucho más razón debido a que estas unidades estan a su vez compuestas por muchas etapas.
Esta es una de las fuentes de todo lo que he explicado...
http://arstechnica.com/articles/paedia/cpu/pipelining-2.ars/4 -
1º: Lo que no se es lo que quieres decir tu con IDLE
2º: Si he diseñado hardware, pero a baja escale (circuitos digitales y unidades logicas cableadas y microprogamadas). A que escala lo has echo tu? Es que acaso eres ingeniero de Intel o de AMD???
3º: Quien ha dicho que al aumentar el numero de etapas no se incremente la complejidad??? Yo no he dicho nada de eso, es mas dije que al aumentar el numero de etapas y no incrementar la frecuencia de trabajo SI que se producia alguna perdia de rendimiento.
4º: Que me contradigo mucho???????????????????????????????????????????????????????????????????????
Dedes el principio estoy diciendo lo mismo.5º: Digas lo que digas sigo manteniendo que si el codigo que se ejecuta fuera" perfecto", es decir si no hubiera ningun tipo de dependencias, no serian necesarios los REGISTROS DE SEGMENTACION encargados de almacenar los resultados de cada etapa del CAUCE SEGMENTADO. Pero como esto no es asi se tienen que utilizar dichos reguistros. En algun examen me he encontrado con codigos a los que habia que calcularle el CPI (numero de ciclos medio por instruccion) y posteriormente se pedia una reordenacion del codigo (que es lo que hacen los buenos compiladores) que producia una reduccion de dicho CPI de hasta un 80%; dependiendo del codigo claro.
6º: ¿Que quieres decir con "no es lo que yo creo, es como son las cosas"??? Es que acaso eres poseedor de la verdad absoluta, y nosotros, el resto de mortales, somos los equivocados. Me parece que deberias de leer mas mensajes de este foro para aprender que aqui estamos para ayudarnos unos a otros y no para decir que mis ideas (en este caso las tuyas) son mejores quela de los demas. Tu has expuesto las tuyas y yo las mias, pero en ningun momento he dicho que tu seas el equivocado; cosa que tu si has echo. Me parece una aptitud muy prepotente.
7º:Que el ejemplo de la ALU no es apropiado??? Que parte del nucleo del procesador es la que esta segmentada, porque la cache no lo esta. La ALU es la Unidad Aritmetico Logica: una parte contendrá la unidad de control y otra parte todo las unidades funcionales encargadas de las operaciones aritmeticas (tanto de enteros como de punto flotante)
Por cierto, se me olvidaba: mis fuentes son las siguientes:
Tecnologia de Computadores
Estructuras de Computadores
Arquitectura de Computadores I
Arquitectura de Computadores II -
Si he diseñado hardware a muy alto nivel. Incluso he contribuido con el diseño de microprocesadores RISC de complejidad media en VHLD. Quizás algún día intel o AMD me contraten. Quién sabe?
No soy poseedor de la verdad absoluta, sólo me remito a los hechos y a artículos especializados que avalan especificamente las razones expuestas. Es posible que la baja en rendimiento dependa en menor grado del código, pero los factores que realmente afectan el rendimiento ya los he mencionado y son puramente inherentes al diseño del harware implementado en el P4, como ya he mencionado la arquitectura más ineficiente precisamente por su gran cantidad de pipeline stages. Y una vez mas, no son mis ideas pues me remito a las fuentes, no estoy inventando nada.
Bueno , pero en fin ya nos hemos desviado un poco del tema original.
-
Que ganas tengo de que un moderador cierre esta rama…
