darksch escribió:A mí me hace un tanto gracia que cuando se habla de las gráficas de intel siempre se usa este tipo de lenguaje de "GPU chustera", "pedorra", cuando resulta que la tan alabada IGP integrada en las APUs en el mejor de los casos (porque no hay que olvidar que AMD vende versiones MUY recortadas) les saca un 40% de rendimiento a la versión equivalente de intel. Y eso cuando se lo saca, que ni de lejos es en la mayoría de casos.
Si tú lo dices...
http://www.tomshardware.com/reviews/a10-4600m-trinity-piledriver,3202-7.htmlPor lo visto nunca les han sacado ni un 40% ni por milagro divino.
no, por lo visto desde luego que no, que no te has enterado de la misa,
están comparando, un HD3000 vs Trinity y Llano. Oh sí, justo eso, la novedad de AMD contra la arquitectura gráfica vieja de intel, que supongo que aún no habría salido para portátil cuando hicieron el análisis (sí para escritorio). ¿?
También me hace gracia que al evaluar el tema del rendimiento de una cpu, que es de lo que estás hablando, no de gpus ni igps, que lo que compras principalmente es eso, una cpu, hables de hiperthreading para justificar la grandísima diferencia de rendimiento (bien por encima de ese 40% citado anteriormente si usas algo cpu intensivo, por cierto) cuando justo el i5 que mencionas NO lo usa.
Que sea el coste de implementar HT en una cpu la "razón" de no incluirlo y demás blablablas también tiene gracia, ya que representa menos del 5% del chip (y el i5 lo tiene, pero deshabilitado, mira qué problema de costes), y si AMD no tiene problema en gastar la mitad sino más de su cpu en IGP, gastar esa miseria en esa tecnología es de todo menos "caro". Si no lo implementa es porque no quiere o no sabe, punto. Más transistores ha gastado en otras "características" bastante menos útiles.
Una CPU es una CPU, para TODO lo que pueda valer, ¡ah espera!, es que para ser CPU debe ser así, así y así, y todo lo que no sea eso ya no es CPU. No, una CPU es un centro de procesamiento y punto, y cada cual lo hará como quiera y según las necesidades le dotará de unas u otras unidades de procesamiento. Por esa regla de 3, cuando a las CPUs se les introdujo SIMD, ¡eso ya no es una CPU!, ¿dónde están los EAX, EBX, ECX y EDX?, quita quita con cosas raras.
No no no, pero di las cosas bien hombre. Para tí una cpu es de todo menos una cpu, si quieres te explico lo que significan las siglas si tal, que parece que no las tienes claras (no es un centro de procesamiento, es una UNIDAD DE PROCESO CENTRAL, que es algo muy distinto, lo primero lo puede ser cualquier tipo de coprocesador o unidad de cómputo que se añada de alguna forma a un sistema, lo segundo sólo puede ser el eje sobre el que se ejecuta el soft del sistema y el de usuario, vamos, "lo mismo").
Porque me cites unos pocos registros arquitectónicos de x86 no te creas que dejará de lucirte el pelo, y te lo digo por esa burrada que has pintado aquí mismo, pintando como "equivalentes" mejoras arquitectónicas DENTRO de una cpu con el uso de GPGPU, válgame dios, poner ambas cosas al mismo nivel es lo que me faltaba por ver...
Oyes, cuando seas capaz de mezclar el código usado en GPGPU por el medio de código nativo x86 y que la cpu automáticamente lo gestione, vienes y me vuelves a hacer el mismo símil, hasta entonces, NO.
Por cierto, exacto, no lo implemente pq exacgtamente como dije, eso conlleva un coste, no sólo de montaje, sino de investigación, ahora en AMD chasquean los dedos y venga ya saben implementarlo. El dinero que Intel se gastó en desarrollar e ir mejorando esa tecnología pues AMD se lo gasta en otras cosas, no tiene vuelta de hoja.
¿Y a mí qué me cuentas de coste de I+D? Tú dijiste que era "caro" implementarlo en la cpu, desde luego nada de desarrollarlo (que yo sepa, es "caro" toda técnica implementada, incluida esas AVX anímicas que lleva bulldozer ¬¬), te aviso porque veo que no debes saberlo, que técnicas de SMT en cpus se usan a lo largo y ancho de la industria precisamente como forma "fácil" de mejorar el rendimiento y altamente rentable incluido desde los "monstruosos costes" de I+D ¬¬. Si AMD no se ve capaz será porque se dedica a hacer arquitecturas fallidas en vez de hacer algo serio.
En vez de millones en chorradas como "fusión-optimización" de recursos que se le acaban disparando al pie, si se dedicara a ampliar sus arquitecturas como debe ser, no estaría en el pozo sin fondo donde está ahora, donde se ha metido sóla, añado.
Hyper threading no es la única forma de mejorar la CPU, evidentemente, pero para eso remitirse al párrafo anterior (resumo, cada una se gasta el dinero para investigar en cosas distintas).
Después sigues con el panfleto de publicidad con tintes de ignorancia insistiendo en usar ese lenguaje colorista, con cosas como "embrutecer" y demás para lo que es diseñar MEJORES cpus, soltando el panfleto-mantra de "la GPU es la salvación de las cpus", una auténtica tontería a estas alturas porque se lleva con la misma cantinela y moda desde hace muco tiempo, y no ha habido NI HABRA una adopción masiva de GPGPU en todo tipo de programas, por mucho que sea "machacar datos", porque entre otras hay casos donde por dependencia entre datos y tipo de código las GPUS NO pueden trabajar eficientemente, y porque a nivel de desarrollo es una rotura de huevos implementar algunas características en GPU.
Hay algo que se llama evolución, igual que se pasó de pura CPU a tener que programar GPUs para el renderizado, o se pasó del monohilo al multihilo.
Las GPUs siguen sin usarse mayormente en renderizado, si te refieres al rasterizado usado en 3D en tiempo real, es otro cantar. Y el multihilo, otra técnica más vieja que Pichote, lleva con nosotros desde varias décadas, y el estado actual de esta técnica sigue siendo menos que mayoritario, mayormente por la dificultad de implementación y que no siempre es beneficiosa para el rendimiento, y sí, incluso en alguna tarea de cpu intensiva.
![[Alaa!]](/images/smilies/nuevos/sorprendido_ani2.gif "Ala!")
Cosa similar a lo que pasa con GPGPU,
pero a otra escala totalmente distinta de dificultad de implementación, y aún así mucho soft sigue sin ser multihilo.
Es lo que he dicho, la idea es acelerar las tareas que más machacan a una CPU, es decir, ¿es necesario seguir acelerando tareas que cuando empiezan no da tiempo ni a pestañear y están acabadas?, yo creo que no, lo que hay que acelerar es aquello que le das a empezar y te puedes ir y esperar a que termine. Claro que hay tareas que una GPU nunca podrá hacer, al igual que hay otras que una CPU NO debería hacer, como el tratamiento de píxeles (ya lo veremos más adelante) ya que por "software" es algo muy lento, hace años eso se aprendió a nivel de render en tiempo real (por algo salieron las aceleradoras gráficas), pues ya va siendo hora de ampliarlo a tratamiento de imágenes y video, me parece a mí.
Por cierto la idea de "embrutecer", es la de que se han gastado el pastizal en mejorar una CPU ya muy potente de por sí, no sé en que estarías pensando.
Si quieres te pongo lo que significa "embrutecer" en el diccionario de la RAE, a ver más bien es en qué estarías pensando tú (yo el castellano bien, gracias). El pastizal que tú dices está más que bien invertido (parece que AMD no gasta pastizal alguno en "optimizar" sus arquitecturas, debe tener un montón de duendecillos verdes esclavizados, pero a intel sí que le cuesta, pobre, poobree intel que gasta tanto dinero sin control).
Todo lo que has dicho antes es un disparate (hablas como si no hubiera necesidad alguna de aumentar la velocidad de las cpus), podría ponerte ejemplos y desarrollarlo, pero como te veo bastante pez y no tengo ganas de liarme, te dejo pistas, pero todo no una, sino DOS:
Hojas de cálculo.
Bases de datos.
Ya ves, tipos de soft "trivial", si sabes cómo están diseñadas estas aplicaciones, y sobre todo sus estructuras de datos, quizás entenderías el porqué te las menciono. Si sabes porqué te las menciono, puedes explayarte y darme una linda sorpresa (sí, te lo estoy poniendo como reto). Y no, para los que trabajan en serio con este tipo de soft, y sobre todo las BBDD, no son cosas de "pestañeos", ni de lejos lo que tardan. Y las GPGPUs son básicamente inútiles.
Y sé de lo que hablo, estos temas de usar GPUs para acelerar cálculos no es de ahora, ya se empezaba a intentar usar desde los 90, y a pesar de que se avance, sería de ilusos el creerse los trípticos de AMD que pareces haber cogido, ya que has dicho todos y cada uno de los mantras absurdos manejados por la casa, o por sus fans.
Ah!, también tiene su puntillo gracioso el ver cómo desprecias o acusas de "vendida" a intel a empresas como Adobe, que viven precisamente (y muy bien, por cierto, la fama que tienen en cierto sector no la ganaron en dos días) de VENDER soft.
No de amañar pruebas, como tú dices. Y sí, el uso del compilador de intel tiene mucho sentido, si quieres vectorizado automático y eficiente, y desenrollamiento de bucles y otras "naderías", hay que usar compiladores como éste. De "interesados", nada. Excepto en obtener el máximo rendimiento.
Si tan claras ves el portado a GPGPU masivo de todas sus aplicaciones, te invitaría a que dadas tus habilidades extremas como programador (según tú debe estar chupado, y es trivial y se puede usar en todo tipo de soft de "machacar datos"), a que hagas versiones alternativas de su soft pero usando sólo OpenCL, por ejemplo (y añado, ¿sabes que puedes usar el compilador de intel y OpenCL simultaneamente? de hecho, ¿sabes que de todas formas vas a tener que usar SI o SI un compilador a x86 en el soft que crees, por mucho OpenCL que introduzcas,
![[looco]](/images/smilies/nuevos2/borracho.gif "loco")
).
Te lo voy a resumir con un enlace:
http://www.tomshardware.com/reviews/photoshop-cs6-gimp-aftershot-pro,3208-10.html¡¡¡Oh, la CPU Intel w/o OpenCL va al DOBLE que la AMD!!!, de 0,30 a 0,60...ah pero espera, que cuando pones OpenCL el AMD se va a más de 5.
O voy a ver video en 1080p, que tengo al MacBook que se pilla unos calentones de cuidado y los ventiladores que van a reventar por tener que tirar de CPU, mientras el PC portátil (un Intel con Nvidia por cierto) el ventilador ni se nota y ni se calienta.
Tienes razón, mejor seguir gastando todo el dinero de investigación en mejorar la CPU (mejor no digo embrutecer que puedes entrar en cólera) que tarde o temprano llegará a esas cifras en tratamiento de píxeles. ¡Eso sí, cuando hago el cálculo de las mensualidades de la hipoteca, en el Intel obtengo el resultado 1 décima de segundo antes!, con lo que me ahorro de tiempo.
A eso añade Blender que ya está casi a punto (si no es que ya terminaron el motor bajo OpenCL) y algún codec, por cierto comercial, como
este. Si software libre lo hace...
Además, si tú mismo lo has dicho, ¿pq entonces Adobe no lo hace?, lo de usar ambos digo. Además no es un compilador x86 salvo que sea para 32-bit, pero bueno sé a lo que te refieres.
Lo de la falta de uso de OpenCL en software comercial tiene su explicación de la misma forma que cuesta mucho encontrar un Dell o HP con CPU AMD, Intel tiene mucha pasta y ejerce suficiente "influencia" para ello. No es nada nuevo, se sabe de juegos que están completos en ciertas plataformas consoleras que no llegan a ver la luz por "persuasiones" de la marca que se queda con la exclusiva del juego. Eso es así y seguirá siendo.
Ya que mencionas sobre programación, pues sí, le he hechado un vistazo a OpenCL y, por lo menos para mí, la dificultad es equivalente más o menos a la que fue el paso del monohilo al full-multihilo, es decir, no crear X hilos fijos, si no adaptar el programa a detectar los X núcleos de la máquina y adaptarse a ello. Y lo sé de 1ª mano pq he programado eso. Si bien es cierto que al principio puede resultar "raro" la programación tipo GPGPU, tb es cierto que las APIs hacen que el programador se olvide de la sincronización, cosa que no ocurre con el multihilo (que es lo difícil), lo que lo simplifica algo, y por eso digo que a mí por lo menos me parece del mismo nivel de dificultad dicho cambio.
Lo que yo creo es que tienes un concepto de CPU muy muy anticuado, las cosas cambian, de hecho la mayoría de las CPUs vendidas en la actualidad son integradas (tablets, móviles, y otros dispositivos en general). Ese concepto de sacar la pastilla de su caja, colocarla en el socket, y que sólo se dedique a "tareas típicas de CPU" llámemoslas es ya un poco deprecated.
Son 2 vías de desarrollo diferentes, haciendo analogía de balance Intel opta por un 70/30 en mejorar la parte de CPU/GPU y AMD 30/70. A mí personalmente me gusta más la de AMD pq como dije es hacia lo que está tendiendo la tecnología y pq desbloquea lo que ahora mismo son los mayores cuellos de botella de procesamiento, el problema es que ahora mismo la gente simplemente ve que en los benchmarks de CPU el Intel corre más, pero corre el riesgo de que llegado el punto le pille con los pantalones bajados sin una parte de GPU competente si se decide por fin que es la vía de hacer software.
Hay tareas que nunca podrán usar GPU que son compilar, bases de datos, y cálculos matemáticos generales, sin embargo el público demanda cosas que sí puede hacer como son imágenes, video, render en tiempo real.
Al final todo queda en la proporción precio/prestaciones, y en eso AMD ahora mismo según veo es mejor, vaya que estamos comparando 114€ con 176€, son 62€ de diferencia pero sobre 114€ no sobre 300€.
Sigue siendo muy divertido leerte, porque insistes una y otra vez en decir que GPGPU es la "senda" para mejorar el rendimiento "pesado" en cualquier tarea, cuando esto no es así. También tiene gracia leer
tu teoría de la conspiración, un tanto absurda, sobre que el soft comercial no usa OpenCL porque intel tiene "dinero" con qué pagar. Lo cual me reafirma en que o no tienes ni idea de programación avanzada, o te estás haciendo el sueco con los clarísimos problemas de desarrollo en GPGPU que... vamos, no se las salta ni un galgo. No todo es hacer sumas de supermatrices.
Una empresa desarrolladora de productos comerciales, juegos, productos ofimáticos, contables, o lo que tú quieras gana y justifica su contabilidad, y a sus accionistas a través de los beneficios que obtiene con sus ventas. Lo que tú estás soltando es, además de un disparate, imposible.
Porque intel que según tú es una fuente de dinero infinita, tendría que estar "untando" a todas las empresas desarrolladoras del mundo mundial para evitar que usen OpenCL en sus programas y así evitar que un "outsider" saque ese tan mágico soft que tú mencionas y así destruyera a la competencia totalmente, lo cual destruiría su plan maléfico de dominación del mundo del desarrollo (juaaajuaajuaaa!! intel: "soy maaalaaa!").
Y la untada a cada una de las empresas tendría que ser proporcionalmente muy importante respecto a sus ventas como para renunciar a los posibles beneficios que tú ves en el uso de OpenCL.
Dices que has programado en OpenCL y en multihilo (jajajaa, venga hombre, y dices que son equivalentes además en dificultadXD), bien, excepto que te hayas limitado a hacer poco más que proceso de matrices a piñón fijo en ambos casos, deberías saber de sobra que ambos tipos de programación tienen niveles de dificultad muy distintos, y si sabes por tanto, algo de estructuras de datos complejas, yo que sé, por ejemplo grafos, deberías conocer que ni de lejos una GPU se adapta ni a todo tipo de estructuras, ni a todo tipo de código, ni le sienta ni remotamente bien las dependencias entre datos. Y que tiene problemas en cuanto a la gestión eficiente de cantidad de kernels a lanzar según el caso, latencias entre su trabajo y el de la cpu (que es una CAJA NEGRA respecto al código x86, no es por tanto ni de lejos equivalente a tu comparación anterior con SSE que va con el código x86 ordinario).
Tema que afecta a enooormes cantidades de programas "comerciales" de ésos que dices que intel les unta para evitar que saquen versiones OpenCL (WTF?), donde la solución óptima y eficiente es NO usar GPGPU.
De la misma forma que mucho soft NO se beneficio de la programación multihilo, de la misma forma que mucho soft NO necesita en absoluto ni instrucciones vectoriales ni de coma flotante, por ejemplo.
Así que si de una vez admites que ambas sendas son DISTINTAS y no compatibles, y dejas de decir "GPGPU es el futuro para toda aplicación", ya sólo te queda ir repasando todos y cada uno de los casos donde crees que es beneficioso, porque muchas veces te estás equivocando.
1.- Codificación de video. Hasta día de hoy ni AMD ni nvidia, ni tampoco intel que tiene su propia tecnología propietaria dedicada al tema, quicksync, han sido capaces de codificar video con sus codecs y programas que los usan con el MISMO NIVEL DE DETALLE que la codificación de vídeo por soft. Lo cual es más grave cuando se tiene en cuenta que en dichos programas se les supone usar a todas estas distintas tecnologías de codificación mismo tipo de códec y calidades en sus parámetros, más allá de que cada marca tenga su implementación de cada códec o haya ayudado a crearla a la desarrolladora del programa.
Es un ejemplo sangrante, porque se han dedicado esfuerzos por los principales actores de GPGPU, se han creado distintos programas, y ninguno de éstos son capaces de dar justo la misma calidad en una plataforma que en otra. Lo cual señala a que existen problemas inherentes en dichos usos.
2.- Programas de retoque 2D o render 3D. Aquí puede haber mejores resultados aparentemente. Sin embargo ningún programa ha portado al 100% sus librerías de cálculo y/o proceso en dichas tareas, por la simple razón de que muchas tareas de CALCULO, no de hacer la contabilidad de la señorita pepis o guardar un archivo de datos, se tienen que hacer en la CPU. El hecho de que ningún programa de corte profesional, de los más avanzados, implementen GPGPU a un nivel masivo da unas cuantas pistas sobre la dificultad del tema. Y no, no creo que quienes ganan millones de dólares con sus programas se dejen untar y se "arriesguen" a que venga un Blender de la vida y les sustituya en su posición. Pensar eso sería un disparate, si las cosas van despacio en este tema, es por una buena razón.
3.- Multitud de programas de corte científico necesitan VARIAS versiones de sus librerías GPGPU para poder correr eficientemente en varias arquitecturas gráficas (bueno, y no sólo éstos), lo cual va directamente en contra de la "facilidad" de uso de GPGPU si es necesario hacer esto, lo más gracioso es que aún encima hay casos donde ni con ésas conseguirán extraer bien el supuesto beneficio de una arquitectura contra otra. Casos hay de nvidia-AMD y viceversa como ejes donde una se ve superada por la otra en este tipo de soft.
Añado que en no pocos casos no se implementan técnicas de GPGPU en este soft porque no se obtienen en las tareas exigidas obtener el nivel de rendimiento o fiabilidad del cálculo exigidas. Casi nada.
4.- Curiosamente, los juegos. Soft típico donde hace falta una cpu muy COMPETENTE ahí sea exigente, por la naturaleza de sus estructuras de datos y del código que lo conforma. Se puede usar rasterizado, se puede usar GPGPU para efectos concretos, pero la cpu sigue y seguirá siendo central en este tipo de tareas.
Una cpu mediocre te ASEGURO por experiencia propia no será capaz de dar el mismo rendimiento en juegos que una especialmente veloz. Y justo entre las dos cpus que has puesto, la i5 es un mundo respecto a la AMD, si montas una HD7950/GTX660 Ti (o superiores) en el segundo caso, estás tirando el dinero desaprovechando bastante potencial de la gráfica.
----
En fin, que sí, que mucho "deprecated" y lo que quieras, pero defender una cpu sólo porque tenga una IGP algo más competente (te animo a que te molestes en ver reviews de HD4000 vs Llano y Trinity, no de las dos últimas contra la pobre HD3000 de Sandy Bridge, ya sabes, de principios del año pasado), pero no mucho más, y que digas que ganas por todas partes y tal y cual, y que te ahorras un montón de dinero, ninguneando totalmente el papel de la CPU, es lo que faltaba por ver....
![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
, muy divertido, pero irreal.
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[buaaj]](/images/smilies/nuevos2/vomitivo.gif "mas potas")
, que lejos de usar OpenCL como mandan el tipo de herramientas que ofrece, usa el compilador de Intel para sus programas.
