Angel escribió:
Te he pillado con la guardia baja
Ni siquiera te has fijado que no he puesto ni un solo acento :-P
Animo que ya queda menos!!!
El Viernes, 27 de Febrero de 2009 10:11:03 Rafa Grimán escribió:
Hola :)
El Friday 27 February 2009, Angel escribió:
El taliban ortográfico ha visto un "mas optimo" por ahi.
¡¡¡Jaja, infieles ya sois mios!!!!
Por lo demas al taliban ortografico les gusta mucho esta lista en la que se aprende mucho y de muchas cosas.
Cachis ... me has pillado 0:)
Ehhhh ... a ver ... <pensando> ... <pensando> "más mejor" ;) Ja, ja, ja, ...
Rafa
El Viernes, 27 de Febrero de 2009 09:23:50 Rafa Grimán escribió:
Hola :)
El Friday 27 February 2009, Juan Erbes escribió:
2009/2/26 Rafa Grim�n <rafagriman@gmail.com>:
Hola :)
El Thursday 26 February 2009, Juan Erbes escribi�: > 2009/2/26 Carlos E. R. <robin.listas@telefonica.net>: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> El 2009-02-26 a las 14:08 +0100, Carlos E. R. escrib�: >>> Pero nos faltan enlaces a la idea de Intel de programar el video >>> en C. Deb� verlo en el Spectrum del IEEE, a ver si lo >>> desentierro. >> http://spectrum.ieee.org/jan09/7129 >> >> >> >> � In many ways, Larrabee is like the Cell processor, �says >> Insight 64 s �Brookwood. But because of its arcane structure, the >> Cell processor is �very hard to program. �It drives game >> developers nuts, �he says. � Larrabee will have the same >> capabilities, but it ll be easier for a �programmer to get his >> head around. >> >> >> >> A mi, la idea de que se pueda programar un chip gr�fico en C/C++ >> (en vez de lenguajes propietarios), y con instrucciones cl�sicas >> x86, me parece muy buena idea. Ahora, ya veremos en que queda la >> cosa finalmente. Habr� que esperar unos a�os. > Hasta donde pude ver, los drivers de ATI, est�n programados en > C/C++, con algun agregado, como lo tiene el kernel Linux, de alguna > instrucci�n en assembler. No son los drivers de lo que hablan, son de aplicaciones que se van a ejecutar en la GPU. Por norma general se usa DirectX u OpenGL. Pero son lenguajes algo complicados por lo que no es f�cil de hacer.
La idea es poder programar directamente en C una aplicaci�n para que se ejecute en la GPGPU y no tener que programar en OpenGL o DirectX. Muy lindo, pero que pasa si quieres ejecutar esa aplicaci�n en un hardware, donde tienes la mejor tarjeta de video, que soporta DirectX 10.1 y OpenGL 2.0, pero no tienes gpgpu? Lo mas probable es que no funcione. A ver, GPGPU es General Purpose Graphics Processesing Unit, pero una GPGPU y una GPU es lo mismo. No hay diferencia. No hay t. gráficas con GPGPU y otras sin GPGPU. GPGPU a lo que hace referencia es el uso al que se le da la GPU. Me explico:
a) tu sobrino tiene un equipo con una Quadro FX 5600 para jugar al Quake (o el juego que esté de moda ahora que no sé cuál es). En este caso se llama GPU.
b) tu sobrino se cansa de su equipo y se compra uno nuevo para jugar, te regala el suyo "antiguo" con la Quadro FX 5600 y la usas para acelerar las predicciones de bolsa de las inversiones y ahorros que tienes, pero NO la usas para jugar. Entonces se llamam GPGPU
¿Ves la diferencia? La GPGPU es el nombre que se le da a la GPU cuando se usa para trabajos no gráficos o no relacionados con aceleración 3D.
En cuanto a si funciona o no de una tarjeta aotra, lo más probable es que no te funcione. Por ejemplo: tienes tu ATI/AMD mega-ultra-fashion que acelera OpenGL tanto que tienes que llevar casco. Como ya no juegas, decide ponerte a desarrollar con su tecnología STREAM (GPGPU de AMD/ATI). Pues si lo quieres llevar a NVIDIA ... vas dado. Tienes que reescribir el código. Lo mismo ocurre al contrario, si lo quieres llevar de NVIDIA a ATI/AMD.
A ver si ahora lo ves claro, una GPU es un procesador gráfico. ¿Te acuerdas de la época del 386, que los había SX y DX? Uno venía con coprocesador matemático y otro sin coprocesador matemático. Si tu código hacía uso de coma flotante (aka decimales), el SX _NO_ lo podía hacer por hardware, pero el DX sí porque tenía coprocesador matemático. Pues esto es lo mismo, una GPU no es más que un coprocesador más (en este caso vectorial). Que, en función de para qué se usa, se llama GPU o GPGPU. Pero GPU y GPGPU físicamente son el mismo chip.
Más cosas, los Cell, las FPGAs, los chips de ClearSpeed, ... son lo mismo: coprocesadores, igual que lo es la FPU y la GPU. Unos son vetoriales, otros son muy buenos acelerando trabajos con cadenas de texto, ... Pero son eso, coprocesadores específicos para funciones específicas.
Más info. Una CPU de hoy en día (me da igual que sea de Intel, de AMD o no), tiene instrucciones SSE y MMX o Altivec. Estas instrucciones son instrucciones típicas de procesadores vectoriales. Es decir, las CPUs de hoy en día que tenemos en nuestros portátiles y equipos de casa, ya traen instrucciones vectoriales, pero no traen tantas unidades como las GPGPUs. Luego una GPGPU/GPU debería acelerar más que una CPU con SSE.
Eso parece una tactica al mas puro estilo microsoft, de tomar los estandares y protocolos establecidos, y modificarlos, para que solamente funcione con sus productos. Pues esto lo empezaron NVIDIA y ATI/AMD así que los monopolistas son ahora ellos y no Intel. De hecho, Intel, hasta que no saque Larrabee, no entra en este juego de las GPGPUs ;)
Otro elemento probable, va a ser de ese gpgpu, tampoco va a soportar DirectX 10.1 y OpenGL 2.0. Sí que lo soportan, GPGPU y GPU es lo mismo físicamente, pero en función de su uso se llama de una manera u otra.
Parece una transici�n bastante complicada. Sí porque hay que hacer mucho porting y muchas pruebas. No siempre un porting a GPGPU es efectivo. Para empezar, tienen que ser SIMD y además, tienen que ser loops que consumen mucha CPU.
Antes de enviar, vuelvo a chequear, y encuentro parte de las respuestas, pero van en camino contrario a la propuesta de intel en su Core i7: http://barrapunto.com/articles/08/11/15/1156229.shtml
http://www.muycomputer.com/FrontOffice/ZonaPractica/Especiales/especial Det/ _wE9ERk2XxDA0vdjPfH3oxoRM-A7dfAvc4xxs6uU59ginrvvp_HDRswCiDiydH8Xi
http://en.wikipedia.org/wiki/BrookGPU Donde puede leerse: Brook is licensed under the BSD license (parts are under the GNU General Public License) and is free software
http://en.wikipedia.org/wiki/CUDA Donde puede leerse: License Proprietary, Freeware
Y una larga lista de limitaciones. Ya, ¿y? Es lo mismo que ocurre con icc y gcc y MSVS. Tienes entornos propietarios y otros que son abiertos (en algunos casos libres). Cuando Intel saque Larrabee, me figuro que lo más óptimo será usar icc.
Personalmente, prefiero BrookGPU ya que es abierto. Pero ya sabes que ahora empezarán a aparecer los acuerdos entre empresas, ...
Por un lado, parece ser que entre intel y AMD, se han propuesto sacar del mercado a Nvidia, y esta como reacci�n empez� a apostar fuerte en Tesla y Cuda. Tambien el a�o pasado se hablaba de una posible fusi�n entre AMD y Nvidia. Efectivamente, es el único que no tiene CPU. Posibilidades: que se uhnda, que se alíe con VIA, que se alíe con ATI/AMD, ...
Cada compania parece querer imponer sus productos para destruir al resto, en lugar de buscar la forma de convivir pacificamente, y hacerle la vida mas facil al usuario. Volvemos a lo anterior, "que son las leyes del capitalismo salvage", pero cuando las cosas van mal "quieren ser socialistas" (para socializar las perdidas). Sip.
En vez de apuntar a la estandarizaci�n, y unificaci�n, vamos en camino contrario, porque parece ser que a la hora de comprar software propietario, vas a tener que fijarte que tarjeta de video o micro tienes en tu pc, para saber si funciona. Sip.
Rafa, aprovecho a preguntarte si intel adopt� HyperTransport en el Core i7, ya que en un link de este hilo menciona HyperTransport:
http://www.alternate.es/html/shop/productListing4C.html?cat1=3&cat2=426 &cat 3=0&tgid=68&treeName=HARDWARE&Level1=Procesadores&Level2=Sobremesa&Leve l3=So cket+1366& Sí, lo ha vuelto a incluir en sus procesadores. Parece ser que a partir de la arquitectura Nehalem el HyperThreading va a ser presencial. Pero como siempre, habrá casos en los que sea útil y otros en los que no sea útil :(
De todas formas, nos estamos "preocupando" mucho sobre el hardware cuando resulta que el sw no está a la altura. Es decir, tenemos CPUs multicore (pronto vendrán las manycore), tenemos GPGPUs/GPUs potentes, ... pero el sw no está paralelizado, el sw no está optimizado para SSE/MMX o Altivec, ... Es como tener un Ferrari en un pueblo de montaña: muy buen hardware, pero poca maner de aprovecharlo :(
Sí, es cierto que hay sw que eso de paralelizarlo es algo "raro" como puede ser un sw de presentaciones o un navegador o un procesador de textos ;) También es cierto que paralelizar un código es muy complicado.
Rafa
-- "We cannot treat computers as Humans. Computers need love."
rgriman@skype.com
-- "We cannot treat computers as Humans. Computers need love."
rgriman@skype.com
Querrás decir sin una sóla tilde. Aquí se reparte para todos. :P -- Saludos. César Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado. (Proverbio hindú) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org