Intel se escapa con sus Mhz

[Nemes1S]

Puedes mirar pruebas de Opteron, porque van a existir Athlon 64, los FX, que van a ser casi análogos a ellos como expliqué antes. La prueba que comentas de XBitLabs ya está un tanto desfasada y ya hay otras más recientes y más aclaratorias sobre lo que va a ser el rendimiento real de los A64. Es más, el PR de los Athlon 64 754 ya parece que ha sido revisado a la baja por AMD aunque este es un tema peliagudo porque, claro, es complicado comparar con una cifra aproximada el rendimiento de un procesador de 32 bits con uno de 32/64.

Ya comenté que el problema ha sido falta de planificación combinado con un retraso excesivo de los Athlon 64, lo que ha obligado a 'tirar de Opteron' lo que al fin y al cabo, tampoco creo que nos venga muy mal ¿no? El Athlon 64 754 hubiera sido un gran micro a principios de año incluso con canal simple, ahora ya se queda un poco corto, pero en cualquier caso es bueno que exista un micro con arquitectura de 64 bits de gama algo más inferior para conseguir abarcar mercado y que los fabricantes de SW apuesten por esta arquitectura. Y de rebote, tenemos la posibilidad de adquirir Opterons (Athlon 64 FX) a precios mucho más razonables.

Lo de que un AMD a igual de 'micras' no va igual de rápido que un Intel ya lo comenté antes, es simple cuestión de diseño. Pero lo que es indudable es que si los Athlon 64 parten como va a suceder de unos 1,8-2 GHz no creo que tengan muchos problemas en llegar, con el paso del tiempo, como poco al doble de esa velocidad mediante sucesivos refinamientos del diseño y mejoras en la fabricación de los mismos. Siempre ha sucedido y no veo por qué esta vez va a ser diferente.

En cuanto a lo de los zócalos, pues hombre, a mi tampoco me parece bien que existan 3. Desde el principio el 754 me pareció muy poco interesante y tras el retraso lo demás ha terminado por ser algo inevitable… Aun así, como bien dices, nadie te va a obligar a comprarlo sabiendo que igual luego tu inversión no es ampliable, pero por lo menos estamos sobre aviso. Aunque consideremos que SIEMPRE una primera generación de micros ha tenido un formato más o menos 'fugaz'. De todas formas, este es un caso algo más complejo por estar implicadas 2 familias de micros destinadas a mercados distintos, más la particularidad de que el interfaz procesador-memoria va integrado el la propia CPU y eso determina el zócalo (no todo iba a ser positivo al integrar el controlador de memoria).

Salu2

[Juande]

Pako, no olvides que habrá dos versiones de A64. Por tanto, las pre-reviews de Opteron 1xx u Opteron 2xx funcionando como 1xx, sí dan una idea de cómo se desenvolverá una de esas versiones, los A64 de gama alta, esto es, los A64 FX-5x que no dejan de ser Opteron 1xx "remarcados" u Opteron 2xx sin el link HyperTransport destinado a enlazar con el segundo procesador en configuración dual. Eso sí, teniendo en cuenta que el FX funcionará con doble canal DDR400, cuando en la mayoría de acercamientos en forma de análisis como alguno de los puestos arriba u otros que hay por ahí, van con DDR266 o DDR333. Con lo que aún un FX dará mejor rendimiento y más si desde el principio, como indican algunos rumores, podrá usar incluso memoria DDR400 umbufered y no sólo registrada ECC, eso sí, al ser el s940, de forma limitada: si es de la umbufered entonces sólo un módulo por canal, osea, dos módulos en total, a diferencia del FX que saldrá parece a primeros de año en s939, donde ya el soporte DDR400 unbufered dual chanel será total: dos módulos por canal, cuatro módulos por tanto.

En cuanto al otro modelo, A64 de gama media en s754, hay otro acercamiento que ha salido estos días en ocworkbench. Se trata de una pequeña review de un A64 s754 a 1,8Ghz con placa basada en chipset ALI. Al parecer su PR inicial (esta gama en s754 sí llevará parece PR a diferencia de la FX), era de 3100+. Sin embargo, ha sido bajada a 2900+. En el texto del artículo así lo indican, en concreto en esta página de la review http://www.ocworkbench.com/2003/aliuli/m1687/m1687-3a.htm En realidad me parece que esta velocidad de 1,8GHz ni tan siquiera va a salir el 23 de sep. (yo apuesto por la 2,0 y la 2,2), pero bueno. Está comparado con lo más en K7, el Barton 3200+ en placas nForce2 400 Ultra.

http://www.ocworkbench.com/2003/aliuli/m1687/m1687-1.htm

Con una desventaja de 400MHz, ya está delante en todos, juegos y progs reales, salvo en la prueba del Windows Movie Maker, lo cual es lógico con esa desventaja en mhz. Simplemente con el A64 s754 2,0ghz igualaría y correría todavía con 200mhz menos. El 2.2, misma velocidad de reloj que el Barton 3200+ con el que se compara, le pasaría con una ventaja cercana al 10% a la vista de la escalabilidad que tienen los K8. Y esto el A64 single channel, es muy posible que un FX a 1,8 ya iguale al Barton 3200+.

Yo creo que el salto respecto del K7 es muy grande de forma global (que es lo que se tiene que exigir de una nueva generación de micros en cualquier compañía y el K8 bajo mi punto de vista lo cumple y con creces) y esto es algo que se irá viendo todavía más claro con el tiempo. Soy de la opinión que en estos primeros meses no vamos a ver ni un 25% de lo que realmente van a ser los K8 de aquí a un año más o menos (en ese tiempo veremos la implementación total de dual chanel DDR400 umbufered o si el mercado va por ahí la DDRII, irá escalando mhz y apuesto que bastante más rápido que P4, irá creciendo el parque de programas compilados en 64bits, etc). Y no olvidemos otras cuestiones que se van a volver muy interesantes con estos micros: son micros que se calientan bastante poco y esto trae muchas cuestiones positivas, como una mejor calidad en el entorno (me refiero a ruido). Me da que en esta materia (aunque ya se ha mejorado una barbaridad con los TBred o Barton) se va a dar una buena vuelta a la tortilla

Saludos.

[pakohuelva]

En cualquier caso habre que esperar hasta el 23 para ver que tal funciona el experimento y hasta el año que viene para ver como funcionan de verdad en 32 bits, en 64 un par de añitos por lo menos.

Lo que esta claro es que con 0.13 micras no se llega a los 4 Ghz y con 0.09, en el mejor de los casos, a los 5 Ghz asi que ya veremos que hace Intel para donde dijo diego decir digo y decir ahora que lo que importa es el rendimiento y no los Mhz.

[quadro]

voy a ser pesimista.Per el amd 64,como vosotros decis no va a ser gran cosa.Los programas optimatizados van a tardar lo suyo,por lo que no creo que de la vuelta a la tortilla.Si bien el rendimiento no parece malo,pero me parece que va a seguir detras de intel, por lo menos, lo hara de muy cerca, y no como ahora.Tambien como decis mientras amd estara subiendo el micro, intel tambien hara lo suyo.Y si el software es optimatizado para 64 bits, intel no le quedara mas remedio que pasarse tambien a 64,mas que nada por lo que habeis dicho, porque estan llegando al limite, y cada vez de cuesta mas subir.Ademas que no van estar sacando software para 32 y 64.Lo ideal para todos es que pasaran a 64.Esperemos que intel lo haga rapido,asi todo el software sera 64,sino como he dicho lo va a tener crudo amd.

[pakohuelva]

Pero aqui hay un problema.

Si intel se pasa a los 64 bits puede hacerlo o bien con arquitectura propia o bien siguiendo a AMD. SI hace lo segundo se "habra bajado los pantalones", asi que dificilmente lo hara. Si hace lo primero tendremos dos arquitecturas diferentes de 64 bits y el fin del PC como tal.

Y si intel sigue con los 32 bits durante algun tiempo mas como parece que sera pues tendremos el mismo problema, o programas para 32 o para 64. Laventaja del primer caso es que funciona en los dos asi que mas programas para Intel.

[Juande]

Pako, será la ventaja del segundo caso, no del primero, el que funcione en los dos, por lo que más programas o posibilidades para AMD no para Intel

Dentro de mi desconocimiento en cuanto a pasar a 64 bits, por lo que extraigo de cosas que leo por ahí es que se trata de una simple compilación. No se trata de que los fabricantes de soft tengan que ponerse a hacer una versión de 64 bits de su programa de turno partiendo de cero, sino de que, a través del compilador, pasar el programa de 32 bits ya existente, a 64 bits (y ello gracias a que ambos son compatibles x86. Si no fuera así, entonces sí tendrían que partir de cero. Aquí está la gran ventaja en al jugad de AMD con esto de los 64 bits x86). Y esto creo que se hace "echando leches". Es el caso del Windows XP para AMD 64 que ya hay versión beta: Microsoft no ha partido de cero para hacer este SO, sino que ha cogido su Windows XP de 32 bits y se ha puesto a compilarlo a 64 bits y como digo creo que se compilan líneas a 64 a toda leche, parece que es un proceso bastante simple y rápido, como digo por lo que he leído.

Por otra parte tampoco se tratará de que vendan el programa de 32 bits por un lado y el de 64 bits por otro, sino simplemente de que dentro del mismo, por ejemplo, CD de instalación, estarán ambas versiones y, en función de la máquina en la que se vaya a instalar, se instalará la versión de 32 o la compilada a 64.

Saludos.

[josefu]

Llego un poco tarde…
Pero intentaré dar mi opinión sobre todo lo q habeis dicho

Dentro de mi desconocimiento en cuanto a pasar a 64 bits, por lo que extraigo de cosas que leo por ahí es que se trata de una simple compilación. No se trata de que los fabricantes de soft tengan que ponerse a hacer una versión de 64 bits de su programa de turno partiendo de cero, sino de que, a través del compilador, pasar el programa de 32 bits ya existente, a 64 bits (y ello gracias a que ambos son compatibles x86.

Según tengo entendido, no es tan sólo compilar para 64 y ya esta. Hay muchas operaciones de desplazamientos de bits q toman como referencia los 32 bits la arquitectura actual y al recompilar para 64 puede provocar fallos; pero son más bien pequeños retoques, hay q ir afinando.

Al principio se ha empezado comentando sobre q amd se quedaba desfasada en la carrera de los mhz respecto a intel.
Respecto a este tema, tan sólo debeis mirar el rendimiento de la nueva tecnología centrino (p3) q a 1,5ghz rendía igual q un p4 a 2,4ghz (no se si era exactamente esa equivalencia, pero parecida, no?) por lo tanto queda claro q no importa la velocidad mientras el micro rinda.

Con lo del software optimizado, no se hasta q punto se aprovecharan los 64bits.
Según tengo entendido, lo normal en las arquitecturas de 64 bits es dejar funcionar el SO en 64bits y el espacio de usuario funcionando a 32bits xq dicen q la posible ganancia de rendimiento por trabajar con instrucciones de 64bits no compensa la cantidad de memoria necesaría para ellas.

[pakohuelva]

Lo que decia es que si programas para 32 bits podras ejecutar tanto en A64 como en la arquitectura clasica.

Y pasara a 64 bits no es tan sencillo. Puedes usar un compilador de 64 bits y obtener codigo para el A64 pero no obtendras beneficio. Para rendir tienes que cambiar todo el programa para aprovechar los 64 bits.

[Juande]

Según tengo entendido, no es tan sólo compilar para 64 y ya esta. Hay muchas operaciones de desplazamientos de bits q toman como referencia los 32 bits la arquitectura actual y al recompilar para 64 puede provocar fallos; pero son más bien pequeños retoques, hay q ir afinando.

Exacto, de eso se trata de compilarlo y hacerlo correctamente. Pero no tiene por lo que parece mayor misterio. Repito, al tratarse de modos x86 ambos. Otra cosa sería o es cuando hablamos de IA-64 (Itanium). Ahí sí, ahí hay que partir de cero zapatero En el caso de AMD con su x86-64 no, se trata de compilarlo y evidentemente compilarlo correctamente para que no haya fallos y provoque el efecto contrario: en vez de mejorar, empeorar.

Al hilo de esto, y para que sirva de ejemplo de lo que digo, he encontrado la página alemana a la que hacía referencia antes http://www.planet3dnow.de Son unas pruebas bajo SuSe Linux de 64 bits en fase Beta. Aquí se ve claramente de qué se trata el tema y la diferencia que hay entre compilar bien (o de tener el paso a 64 bits bien depurado vía compilador) a no tenerlo todavía y que tal compilación contenga fallos o errores (los cuales lógicamente, se trata de depurarlos, son todo versiones betas y para eso está, para depurar fallos y obtener un buen producto final). El artículo, con traducción por lo menos a inglés para que sea más entendible, es este: http://translate.google.com/translate?u=http%3A%2F%2Fwww.planet3dnow.de%2Fartikel%2Fhardware%2Fopteronlinux%2Findex.shtml&langpair=de%7Cen&hl=en&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools

Pongo aquí, un ejemplo de compilación de 32 bits a 64 bits ya bastante bien hecha o depurada. Paso de wav a mp3 con Lame (ganancia de un 14% de pasar a mp3 con Opteron en 32 bits a hacerlo en 64 bits):

Otro ejemplo de una compilación del programa gzip (compresión de archivos) de 32 bits a 64 bits ya también bastante depuradita (ganancia también de un 14-15% aprox.):

Y ahora, todo lo contrario, una pésima compilación del programa para codificación de video de MPEG a DivX llamado Mencoder, de 32 bits a 64 bits (tarda el doble de tiempo nada menos :p):

Y otro ejemplo de compilación de 32 bits a 64 bits en pañales o mejor dicho pésima, con SETI@Home:

En todos los gráficos, los tres últimos son el Opteron, bien en modo de 32 bits compatible; 32 bits legacy; o 64 bits -el último-). En definitiva, recordemos que todos estos ejemplos están hechos en un Linux 64 bits Beta, con programas compilados de 32 bits a 64 bits también todos en fase beta, con la diferencia que quien está encargándose de pasar de 32 a 64 el Lame o Gzip va por buen camino (ganancia de 14-15% en ambos), y quien haya hecho o esté haciendo las de Mencoder o Seti debe dedicarse a otra cosa con urgencia y dejarlo a otro que sepa xDDD

Saludos.

[pakohuelva]

Eso tambien depende del modo de funcionamiento del micro y que son tres al menos. Hay un modo nativo x86 de 32 bits, otro nativo x86-64 de 64 bits y despues uno intermedio para las compilaciones a 64 bits sin optimizacion.

Si tu compilas a 64 bits solo con el compilador la unica mejora que obtendras sera la que te de este pero perderas otras que dependen del "arte" de programar. Es como utilizar los modulos para compilar a MMX, SSE, etc, una cosa es obtener codigo compatible y otra tener un programa que realmente aproveche estas instrucciones.

[Juande]

Eso tambien depende del modo de funcionamiento del micro y que son tres al menos. Hay un modo nativo x86 de 32 bits, otro nativo x86-64 de 64 bits y despues uno intermedio para las compilaciones a 64 bits sin optimizacion.

¿te refieres al K8?

Por otra parte… no sé, pero si un programa de 32 bits inicial, se pasa su código a código de 64 bits mediante compilador (y se depura y optimiza bien después), tendremos como resultado un programa de 64 bits en toda regla y no algo intermedio ¿no? Y con la ventaja de tener bastante camino recorrido , al no empezar de cero, lo cual ayudará a ver con bastante más rapidez progs de 64 bits. A mí me parece la gran ventaja de esta iniciativa: su compatibiidad hacia atrás lo que trae el poder aprovechar el trabajo ya hecho y facilitar así el tránsito a los 64 bits de forma progresiva.

Saludos.

[pakohuelva]

Me refiero al K8, si.

Si todo eso esta muy bien pero yo hablo del programa en si. Cuando compilas en 64 bits lo que haces es cambiar una seire de datos de los 32 a los 64 en funcion de como trabaje el compilador, pero el programa no estara optimizado para 64 bits. Quiero decir que el progrmador no ha tenido en cuenta que ahora puede usar tipos de datos de 64 bits y aprovechar otras caracteristicas propias de este micro. El compilador solo traducira las instrucciones, pero si las instrucciones no estan no podra hacer nada.

Es lo que paso con el OS X, habia aplicaciones que funcionaban con la interface tradicional (Coccoa??), habia otras que podian recompilarse para aprovechar algunas caracterisitcas y po rultimo estaban las que se desarrollaban desde cero y aprovechaban toda la potencia que ofrecia el nuevo sistema.