Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Ver: Modo: Orden:
Detrás del lanzamiento del Mac Mini | 25 comentarios (25 temáticos, editoriales, 0 ocultos)
Tienes razón. (none / 0) (#15)
por yum (almula@BORRALOteleline.es) a las Mon Jan 24th, 2005 at 10:06:12 PM CET
(Información Usuario)

Ya se acabó el subir el rendimiento subiendo la frecuencia del procesador y ahora viene otra etapa de cambios diferente: multi core y cambio a 64bits que aun no tienen garantizado un alto rendimiento, no habia tenido en cuenta este "detalle", gracias por la puntualización. Tambien tienes razón en lo referente a los juegos y el tipo de genero que prefieras ;-)

Ahora añado yo un par de puntualizaciones interesantes a corto plazo sobre los G4 vs. G5. Parece ser que aun siendo significativo la diferencia entre ambos en rendimiento, no se observa una diferencia tan brutal como a simple vista deberia resultar. Uno de los motivos que se aducen es que actualmente apple usa gcc como compilador y no parece estar aun demasiado optimizado para G5 con lo cual su rendimiento es menor. IBM está trabajando en su propio compilador (Xl C/C++) y promete que cuando esté listo el rendimiento puede aumentar en un 200% frente a gcc. Además a la salida de tiger y la utilización de coreimage le faltan aun al menos 4 meses. A corto plazo quizá sea buena idea entrar con el mac mini y dar el salto a G5 cuando bajen de precio y aumente su rendimiento.

[ Padre ]


Y tú también (none / 0) (#16)
por man ls a las Tue Jan 25th, 2005 at 03:08:57 AM CET
(Información Usuario)

Tú también tienes razón: se me había olvidado la mejora de rendimiento de los procesadores de 64 bits, y no está muy clara tampoco.

Ahora que, qué pena lo de IBM, hacer su propio compilador en lugar de trabajar con gcc. Se supone que a estas alturas habrían aprendido a cooperar y no a ir a su bola... ¿Sabes la licencia que va a tener, por si por lo menos es libre?

[ Padre ]


Datos del compilador de IBM (none / 0) (#17)
por yum (almula@BORRALOteleline.es) a las Tue Jan 25th, 2005 at 10:42:47 AM CET
(Información Usuario)

La verdad que no se demasiado sobre el compilador, mis fuentes sobre él se limitan a leer opiniones de usuarios y a un par de comparativas leidas en la red.

En este enlace hay una pequeña comparativa entre GCC y XL C/C++ y las resultados arrojan que es tan "solo" un 16% segun las pruebas que han hecho. De todas formas estas pruebas tienen casi 6 meses.

He encontrado un documento en pdf que habla sobre el compilador de IBM y algunas de las ventajas que ofrece. Tras un vistazo rapido me he encontrado que tambien promete optimización para el G4. En faq-mac hablan de ello, aunque la noticia es muy vieja. Al parecer lo que se espera es la salida de la V7.0

Sobre la licencia no se nada... a ver si me entero de algo más, porque en este sentido las noticias están demasiado escondidas.

[ Padre ]


 
Rendimiento (none / 0) (#20)
por ridiculum a las Thu Jan 27th, 2005 at 11:04:14 AM CET
(Información Usuario)

El salto a los 64bits no se hace por obtener mas rendimiento. Ni siquiera esta garantizado el obtener el mismo rendimiento. El caso de x86-64 es especial y normalmente se obtienen mejores tiempos por que x86 tiene un numero de registros de proposito general muy limitado, y en x86-64 ha sido aumentando a el doble. Tambien se ha duplicado el numero de registros para instrucciones vectoriales.
Asi que la mejora no viene por el echo de ser de 64 bits, sino por este tipo de detalles.

Y ya que hablamos de x86-64, un detalle que acabo de leer en la wikipedia y no termino de pillar:

It is interesting to note that since SSE and SSE2 are a basic feature of the AMD64 instruction set and since they duplicate the features of the traditional x87 FPU, MMX and 3DNow! perfectly, Microsoft has chosen to not save the FPU/MMX registers across context switches in Windows XP 64-bit Edition for 64-bit programs. This effectively obsoletes the x87 FPU, MMX and 3DNow!, reducing the clutter of the instruction set and eventually allowing for better CPU designs.

Dice que no se salvaran los registros de la fpu/mmx (son los mismos en x86) en los cambios de contextos. Eso significa que los programas que usen la fpu, y seproduce en un cambio de contexto en mitad de su uso, el programa puede fallar: obligan a usar la unidad vectorial -> El compilador debera generar codigo SSE/SSE2 cuando se use coma flotante. ¿Alguien puede verficar eso?

[ Padre ]


No confundamos (none / 0) (#21)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Thu Jan 27th, 2005 at 05:21:46 PM CET
(Información Usuario) http://speedball.servemp3.com

Creo que en realidad Linux hace lo mismo, no guarda el contexto de la FPU cuando se salta de aplicación, sino que activa un flag para que cuando una aplicación quiera realizar cualquier aplicación sobre la FPU, salte una excepción cogida por el sistema operativo y entonces es cuando se realiza el cambio de contexto. De esta manera si la nueva aplicación no usa FPU no se realiza el cambio de contexto.

Por lo que dicen los de Microsoft se ve que el cambio de contexto en Windows no esta especialmente optimizado.

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]


 

Detrás del lanzamiento del Mac Mini | 25 comentarios (25 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda