Tengo una pregunta para todos???
-
Aqui un poco mas de luz:
AnandTech: Intel Quietly Announces Core i5 and Core i3 Branding
Me parece una tremenda cagada renombrar los Core 2 Duo y Quad y llamarlos i3. Como no tenemos suficiente en gráficas, vamos a empezar con refritos tambien en CPUs, madre mia….
-
pues a mi me gusta esa idea, ahora podre decir que tengo un i3
-
pues a mi me gusta esa idea, ahora podre decir que tengo un i3
Si la gente que tiene un AMD zocalo 939, casi puede decir que tiene un AM2/AM2+ para que nos vamos a engañar.
-
pues a mi me gusta esa idea, ahora podre decir que tengo un i3
Se supone que solo son i3 los de 45nm ehh xD
-
Si la gente que tiene un AMD zocalo 939, casi puede decir que tiene un AM2/AM2+ para que nos vamos a engañar.
C_ño,esa me la apunto para el 2º PC .He actualizado a AM2+ sin gastar un pavo!:D
-
Mirad lo que opina el CEO de vmware sobre x86 y el esfuerzo de intel para "cuajarlo" en dispositivos moviles:
Noticias3D Via DarkVision Hardware
_"Intel está intentando "cuajar" su arquitectura x86 en todo, pero el CEO de VMware, Paul Maritz, no ha tardado en responder a esta estrategia en la conferencia de Tiecon en Silicon Valley. Maritz ha explicado que los procesadores x86 no son adecuados porque son "cerdos hambrientos" con funciones inútiles para este tipo de dispositivos.Para Maritz, todas esas "funciones inútiles" consumen electricidad para nada, gracias según Meritz a la complejidad que el set de instrucciones de Intel ha acumulado en estas CPUs durante los años para soportar algunas funciones que, según Meritz, nadie utiliza, calificándolos como "chatarra de silicio"._
Je je, los trapos sucios suelen ser informacion poco accesible, hasta que a alguien le interesa remover….
Salu2.
-
Mirad lo que opina el CEO de vmware sobre x86 y el esfuerzo de intel para "cuajarlo" en dispositivos moviles:
Noticias3D Via DarkVision Hardware
_"Intel está intentando "cuajar" su arquitectura x86 en todo, pero el CEO de VMware, Paul Maritz, no ha tardado en responder a esta estrategia en la conferencia de Tiecon en Silicon Valley. Maritz ha explicado que los procesadores x86 no son adecuados porque son "cerdos hambrientos" con funciones inútiles para este tipo de dispositivos.Para Maritz, todas esas "funciones inútiles" consumen electricidad para nada, gracias según Meritz a la complejidad que el set de instrucciones de Intel ha acumulado en estas CPUs durante los años para soportar algunas funciones que, según Meritz, nadie utiliza, calificándolos como "chatarra de silicio"._
Je je, los trapos sucios suelen ser informacion poco accesible, hasta que a alguien le interesa remover….
Salu2.
Y tiene razón, la arquitectura x86 es para windows, linux y se acabó. Comparada con ARM es muy ineficiente en lo que respecta a consumo/rendimiento, por mucho que los Atom consuman poco, un micro ARM no tiene problemas para rendir más y consumir menos que los Intel Atom.
Y aparte de para que sirven las instrucciónes SSE4 en un móvil por ejemplo? o las SSE3?, para esos usos no valen para nada.
-
Y tiene razón, la arquitectura x86 es para windows, linux y se acabó….....
x86 no deveria ser para nada, es un tongo que nacio en Silicon Valley y como ha tenido un exito comercial muy grande ha salido hacia adelante como un cohete, sin enbargo es la arquitectura mas ineficiente que existe, en tu pc actual hay un monton de codigo que se ejecuta en valde ¿no te parece que te venden la bicicleta? encima ponen remedios para que se ejecute algo menos de codigo en balde, y te lo venden como que ahora cada nucleo tiene dos lineas de trabajo, te engañan aprovechando las lagunas de lo que es mentira y lo que es algo explicado a medias.
A x86 no hacen mas que ponerle parches en el microcodigo pero nacio ya torcido, con un microcodigo que nunca se ha llegado a aprovechar completamente, y cada vez el microcodigo es mas complejo y extenso.
Salu2.
PD: Soy bastante detractor de la panacea que se ha montado intel;
! @defaultuser:
! > ….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...
! -
Risc es muchisimo mejor que cualquier cisc
mirate por ejemplo los powe6 de IBM cuantas vueltas dan a los proces x86, ya ni te digo el power7 que esta en otro mundo
En los ochenta se buscaron dos soluciones para incrementar la velocidad de los chips y que no se estancaran:
Una idea era la de incluir un canal por el cual se pudieran dividir las instrucciones en pasos y trabajar en cada paso muchas instrucciones diferentes al mismo tiempo. Un procesador normal podría leer una instrucción, decodificarla, enviar a la memoria la instrucción de origen, realizar la operación y luego enviar los resultados. La clave de la canalización es que el procesador pueda comenzar a leer la siguiente instrucción tan pronto como termine la última instrucción, significando esto que ahora dos instrucciones se están trabajando (una está siendo leída, la otra está comenzando a ser decodificada), y en el siguiente ciclo habrá tres instrucciones. Mientras que una sola instrucción no se completaría más rápido, la siguiente instrucción sería completada enseguida. La ilusión era la de un sistema mucho más rápido. Esta técnica se conoce hoy en día como Segmentación de cauce.
Otra solución más era utilizar varios elementos de procesamiento dentro del procesador y ejecutarlos en paralelo. En vez de trabajar en una instrucción para sumar dos números, esos procesadores superescalares podrían ver la siguiente instrucción en el canal y tratar de ejecutarla al mismo tiempo en una unidad idéntica. Esto no era muy fácil de hacer, sin embargo, ya que algunas instrucciones dependían del resultado de otras instrucciones.
Ambas técnicas se basaban en incrementar la velocidad al añadir complejidad al diseño básico del CPU, todo lo opuesto a las instrucciones que se ejecutaban en el mismo. Siendo el espacio en el chip una cantidad finita, para poder incluir todas esas características algo más tendría que ser eliminado para hacer hueco. RISC se encargó de tomar ventaja de esas técnicas, esto debido a que su lógica para el CPU era considerablemente más simple que la de los diseños CISC. Aun con esto, los primeros diseños de RISC ofrecían una mejora de rendimiento muy pequeña, pero fueron capaces de añadir nuevas características y para finales de los ochenta habían dejado totalmente atrás a sus contrapartes CISC. Con el tiempo esto pudo ser dirigido como una mejora de proceso al punto en el que todo esto pudo ser añadido a los diseños CISC y aun así caber en un solo chip, pero esto tomó prácticamente una década entre finales de los ochenta y principios de los noventa.
Lo unico que paso fue que los de CISC cogieron lo que pudieron de RISC para poder evolucionar, pero es una arquitectura que estaba mal desde un principio y RISC era la evolucion logica -
La arquitectura x86 es para lo que es: PCs, estaciones de trabajo y servidores pequeños. Hablar de eficiencia en el consumo de silicio no tiene mucho sentido cuando la guerra se centra en el rendimiento bruto. Es verdad que los procesadores x86 actuales tienen muchas µinstrucciones que apenas se usan, pero cuando se usan incrementan el rendimiento de alguna forma.
El razonamiento del tío de vmWare no lo termino de comprender. Técnicamente hablando, un procesador x86 podría ser por ejemplo un 8086, que tiene un número reducido de instrucciones. Es decir, que para poner en funcionamiento una plataforma x86 y poder ejecutar la gran mayoría de aplicaciones existentes (y si no se puede no hay más que recompilarlas), no hace falta incluir el repertorio SSE (quizás sí MMX), x64 ni ningún otro que ofrece instrucciones especializadas. Por ejemplo, la mayoría de las distribuciones Linux, tiene el nucleo compilado para i386 o a lo sumo i586 (pentium), por lo que en el peor de los casos, habría que incluir µcódigo del Pentium, aunque es perfectamente funcional en 386. Está claro que en un dispositivo móvil no vas a ejecutar Crysis ni te vas a poner a convertir videos FullHD o ha renderizar modelos 3d.
No soy pro nada. Simplemente no veo a x86 tan inutil en plataformas móviles como el de vmWare. Solo hay que saber incluir el repertorio de instrucciones que vaya a ser más util. Todo esto no quita que existan arquitecturas (como la ARM) que superan a x86 en este aspecto.
-
Risc es muchisimo mejor que cualquier cisc …
Veo que estamos mas o menos de acuerdo en las razones por las que RISC es intrinsecamente mas eficiente, pero no es mejor asi sin mas ni menos, una combinacion apropiada de los dos enfoques seria lo ideal.
La arquitectura x86 es para lo que es: PCs, estaciones de trabajo y servidores pequeños. Hablar de eficiencia en el consumo de silicio no tiene mucho sentido cuando la guerra se centra en el rendimiento bruto. Es verdad que los procesadores x86 actuales tienen muchas µinstrucciones que apenas se usan, pero cuando se usan incrementan el rendimiento de alguna forma.
Todo es muy relativo cuando no se puntualiza, los RISC muchas veces se dan al lujo de ser menos complejos porque les basta para lo mismo. Los x86 no solo usan instrucciones "tontas", si no que en su constante mejora no ha hecho mas que fragmentar y dividir el trabajo, primero con la segmentacion de caudal y posteriormente creando instrucciones nuevas que cada vez tiene mas de RISC, no se puede cambiar una arquitectura de golpe,pero poco a poco CISC va tomando detalles de RISC para ir limando sus puntos negros.
El razonamiento del tío de vmWare no lo termino de comprender. Técnicamente hablando, un procesador x86 podría ser por ejemplo un 8086, que tiene un número reducido de instrucciones. Es decir, que para poner en funcionamiento una plataforma x86 y poder ejecutar la gran mayoría de aplicaciones existentes (y si no se puede no hay más que recompilarlas), no hace falta incluir el repertorio SSE (quizás sí MMX), x64 ni ningún otro que ofrece instrucciones especializadas. Por ejemplo, la mayoría de las distribuciones Linux, tiene el nucleo compilado para i386 o a lo sumo i586 (pentium), por lo que en el peor de los casos, habría que incluir µcódigo del Pentium, aunque es perfectamente funcional en 386. Está claro que en un dispositivo móvil no vas a ejecutar Crysis ni te vas a poner a convertir videos FullHD o ha renderizar modelos 3d.
Lo que dice el CEO de vmware no es ninguna novedad, RISC desperdicia mucha menos energia, porque no ejecuta codigo en balde, y porque no se dedica a partirlo pegarlo y darle paseos por una arquitectura mas compleja y con mas elementos.
A los dispositivos ultraportatiles no les falta potencia ralmente, de lo que mas pecan es de autonnomia, si hubiera uno que de verdad aguantara todo el dia o mas ya estava yo ahorrando, pero para acceder a net y cosas similares no para editar un video.
Hay portatiles que te permiten correr Crysis, y editar tambien, pero no los hay que te aguanten el fin de semana haciendo algunas visitas a la red por ejemplo.Salu2.
PD: x86 gano la batalla comercial hace tiempo, por eso ahora se escucha que x86 es para esto y para aquello, pero es tecnicamente inferior, desaprovecha mas el hardware y desperdicia mas energia, en los ultraportatiles (UMD) x86 no pinta nada, pero nada, es de risa, pero como es logico intel esta x la pasta y si tiene una opcion de colar x86 en estos dispositivos lo hara contandonos a los compradores que es buena idea para terminar de cuajar la cosa, y el punto de la cuestion es que por supuesto que te engañaran para seguir enriqueciendo, a ti y a mi.