NEWS: Virgen del amor hermoso, madre de San Agustin, que radical esta AMD
-
Noticias frescas y por lo menos para mi un poco chocantes:
Las empresas DRC y Xtremedata,inc. van a implementar en el Socket940 (el de los servidores y workstation Opteron) coprocesadores matematicos que iran directamente ensamblados en el socket:
[Un vecino para el Opteron :: ChileHardWare ::](Un vecino para el Opteron :: ChileHardWare ::)
AMD considers Clearspeed math co-processor
Electronic News - Co-processor Gives Opteron x300 Boost
Start-up could kick Opteron into overdrive | The Register
Datos técnicos del coprocesador en PDF
XD1000 FPGA COPROCESSOR MODULE for SOCKET 940
¿AMD prepara un Anti-HyperThreading?, pues ni más ni menos se trata se meter procesadores en paralelo y que ellos mismo en lugar de ejecutar tareas multihilo (varia cosas a la vez) que todos puedan ejecutar una tarea de forma simultanea sin necesidad de que el software este preparado (vamos todos los micros trabajando en el mismo hilo)
VivaLinux! » ¿AMD prepara un Anti-HyperThreading?
Techworld.com - AMD plans anti-hyperthreading
AMD étudie l'anti-HT pour son K10
Ya estan listas las especificaciones del nuevo estandart HyperTransport 3.0 State-of-the-Art Specifications:
Planet 3DNow! - Das Online-Magazin für den AMD-User
HyperTransport Consortium - Technology - HyperTransport 3.0 State-of-the-Art Specifications
AMD FX64: Quad-channel contra el Conroe EE, parece que será un nuevo FX de 2.8-3Ghz con un bus de 256bits y que al parecer incorporara una cache L3 para suplir las carencias de la DDR2, esta noticia esta un poco cogida por los pelos porque solo hay rumores (y nada oficial) pero como se dice en mi pueblo cuando el río suena agua lleva y teniendo en cuenta como ha puesto el panorama el Conroe no seria nada de extrañar que esto acabe siendo completamente cierto.
AMD FX64: Quad-channel contra el Conroe EE :: ChileHardWare ::
Que?, ¿como se os ha quedao el cuerpo muchachada?, a mi para mear y no echar gota, mira lo que os digo. :risitas:
-
Dudo mucho que el nuevo FX64 incorpore un bus de 256 bits; sería un cambio demasiado drastico y supondria que las aplicaciones basadas en codigo x8086 no funcionarian sobre el. A no ser que dicho procesador este dedicado a un segmento muy muy concreto (que por supuesto no es el domestico) sobre el que se ejecutan programas muy concretos y nada que ver con codigo x8086.
Con respecto al coprocesador, en que tipo de aplicaciones se le va a sacar probecho??? Con la potencia de calculo existente hoy en dia no le veo mucha utilidad la verda, además por lo que comentas ira directamente sobre el socket asi que en una placa multizocalo perderas un procesador solo por tener dicho coprocesador y este funcionara bajo la tutela del resto de los procesadores ya que no tendra las etapas correspondientes a la busqueda y decodificacion de instruccions (Frontend); además el echo de que un procesador decodifique instrucciones y que luego no las ejecute rompe un poco el cauce del procesador por lo que necesitaria salidas especificas para esas etapas. Y no olvidemos que hoy por hoy salir del procesador es muy perjudicial ya que los retardos penalizarian muchisimo.
No se pero en mi opinión si dicho coprocesador es realmente necesario y efectivo, creo que seria mucho mejor integrarlo el la misma pastilla del procesador; por ejemplo sacrificar uno de los cores de un procesador dualcore.
-
Sergiman, tan dificil seria que le metan un bus de 256bits?, no se yo de todos modos ese coprocesadro matematico (integrado para sobremesa o ensamblado en un segundo socket para sevidores) parece que es lo que le falta a AMD para ponerse a la altura o superar a Intel en los calculos FPU, de echo a nivel de servidores yo por lo menos creo que sera muy interesante porque es como un turbo para AMD y a ella no le va a costar un duro ya que los dolores de cabeza van para terceros.
De todos modos pase lo que pase parece que tanto Intel como AMD tiene ases en la manga y la partida solo acaba de empezar. -
yo creo que se refiere al bus de comunicacion con la memoria, para asi aprovechar los 4 bits de subida/bajada por ciclo de la DDR2 para de algun modo suplir las altas latencias de esta
-
Sufro Dejavu.
En fin, paciencia a ver qué sale de todo esto.
-
packosoft es que aunque la DDR-II te de 4 datos (4 bytes) por ciclo lo que han echo hasta ahora tanto Intel como AMD ha sido aumentar el tamaño de las linea de la cache. Si tienes un jerarquia de memoria principal capaz de ofrecer mas datos en lugar de utlizar un bus mas grade que romperia con todo lo anterior y por lo tanto no serviria para ejecutar codigo X8086, ponen caches mas grandes. Al procesador no le interesa para nada tener que salir fuera para encontrar los datos para trabajar; date cuenta de que este es el dispositivo mas rapido de todo el pc, si tuviera que esperar para obtener datos de un HDD que tiene un tiempo de respuesta de varios ms lo matarias; en el caso de que el dato no este en cache no te queda mas remedio pero si pones caches muy grandes que te permitan ambergar muchos datos por el principio de localidad de los programas estos volveran a ser referenciados por el procesador y te ahorraras un monton de ciclos en viajar por el bus, solicitar el dato a la memoria, que esta te responda y volver de nuevo hacia el procesador.
Por poner un ejemplo, el dual chanel lo que pretende ni mas ni menos es que con la mitad de accesos a memoria principal llene una linea completa de cache. Si nos fijamos bien todos los avances en cuanto a la memoria han sido en cuanto a su interfaz no a los chips de memoria; por eso que cuanto mas rapidos son los modulos mas altas son las latencias ya que dichas latencias son las que son y si tu le bajas la señal de reloj necesitara mas ciclos para responder.
Por lo que yo se, las instrucciones X8086 impiden o no permiten aumentar el tamaño del bus.
-
si para la DDR se utilizan los 2 flancos para aumentar el rendimiento, con la ddr2 se utilizan 4 flancos, con lo que se tardaría la mitad en acceder a los datos de la memoria, al menos asi lo entiendo yo, no creo que esto influya para nada en el tipo de instrucciones que es capaz de ejecutar el procesador, entre otras cosas porque el controlador de memoria va embebido en el propio micro. De todos modos, el aumento de la caché no siempre es sinonimo de aumento de rendimiento, depende de como sea la arquitectura interna del procesador, por no contar con que buscar el dato en la cache tambien supone una perdida de rendimiento y tiempo, y que cuanto mas grande es esta mas se pierde. Sino fuera asi, tanto AMD como intel ya habrian sacado sus versiones High-end con caches monstruosas de 9MB tipo itanium
-
Por cierto, no me habia fijado en esto (es nuevo de hoy). Definitivamente los Conroe van a fundir.
New WR:
2x1900XT Crossfire @712 core/738 mem (Stock HSF)
Stock Intel D975XBX (Stock HSF)
Conroe @ 2.72GHz (Stock HSF)
Aquamark 03 -> 153,219 pointsPrevious WR:
7900GTX SLI at 931/1075 (Hielo seco o LN2)
FX-60 @ 3.76Ghz (Hielo seco, LN2 o triple stage)
Aquamark 03 -> 152,653 points -
Pues por lo que yo se si que influye, ademas el echo de que el controlador de memoria este integrado en el propio procesador no tiene nada que ver.
Por supuesto que por tener más cache no quiere decir que sea mejor, pero como la organizacion de la cache no la informan los fabricantes debemos suponer que ese aumento si que repercute en el aumento del rendimiento. Ademas el procesador no busca el dato que necesita en la cache sino que lo busca en el "Directorio cache"; y buscar un dato en cache es muchisimo menos pernicioso para el procesador que buscarlo en memoria.Sabeis desde cuando esta con nosotros el bus de 64 bits??? Desde los primeros Pentium, es decir desde el principio de la quinta generacion y estamos en la optaba. Si fuera tan facil poner un bus mas ancho lo habrian echo ya.
Ademas, el echo de tener un bus tan ancho penaliza mucho la velocidad de dicho bus; no es lo mismo sincronizar 64 lineas que 256.