pos eso a kien le interese k sus programitas chuten mejor os recomiendo
sigais los pasos de esta web...
es muy interesante
http://www.angelcode.com/articles/mmx/mmx.aspsaludos!!!
Vale la pena meterse a programar ensamblador para optimizar hoy en dia? Alguno lo hace? No es mejor invertir ese tiempo en utilizar o optimizar buenos algoritmos?
Incluso desde el Quake3 creo ke no se usa nada de ensamblador. Y el Quake2 solo usaba ensamblador para implementar el renderer por software, por hardware creoke no usaba ensamblador tampoco.
Creo ke desde ke se hizo indisopensable la aceleracion por hardware, se acabó el ensamblador... bueno hasta ke salieron los vertex y pixel shaders..... Aunke ahora creo ke con la llegada del GC...
De todas formas, muy interesante el articulo.
Pues anda que no se utiliza ensamblador para programar consolas aún... (ahora pondría el caso de la GameBoyAdvance... ^_^')
Sync
SIEMPRE merecerá la pena optimizar en ASM.
Precisamente porque la gente ya no se preocupa, todo requiere cada vez equipos más potentes.
"Esta función la dejo así"... "esta otra también, no va mal"...
así, función a función... el código acaba con un montón de cosas sin optimizar.
OJO, tampoco digo de hacer muchas cosas en ASM, peor joer, hay cosas que si merece la pena.
el ASM siempre estara ahi para ser usado, porque te permite 'hablar' con el hardware directamente sin intermediarios. Los lenguajes de alto nivel son muy eficientes a la hora de definir y resolver problemas de una cierta complejidad, a traves de la abstraccion, pero la mayoria de lenguajes (incluyendo el C++) son incapaces de acceder al hardware con total libertad, como mucho accederias a los registros del procesador, pero no mucho mas
ademas, el ASM es muy util a la hora de realizar ciertas tareas, como por ejemplo intercamabiar numeros (muy util para intercambiar direcciones de memoria y no tener que hacer memcpy's por un tubo para intercambiar dos buffers en memoria), precesar vectores (las instrucciones SIMD son fantasticas, yo las uso para procesar mis vectores de 4 componentes y lo hace de una pasada y ademas en un solo registro), generar texturas o mezclarlas, y muchas cosas mas, pero lo importante del ensamblador es su capacidad para ejecutar ciertos procesos con una rapidez que, evidentemente, el lenguaje de alto nivel no tiene...
bueno, al menos esta es mi opinion, a mi el ensamblador me gusta, y creo que lo he dejado claro :sonriendo:
ASM rules!!
Creo q pocas personas puede sacar mejor codigo q un compilador de c/c++ actual, puede q en ciertas partes del codigo merezca la pena, pero por lo general asm es inutil(glDisable(GL_FLAME);).
Aprovecho para decir q si teneis la oportunidad de probar el compilador de intel para c++, lo probeis. Se instala en el IDE del vc6.0 y en .NET.
Saludos
bueno, es cierto, los compiladores de C/C++ cada vez estan mas afinados, pero aun no del todo, asi que aun hay hueco para el ASM.
glEnable(GL_ENGINE); :lengua:
pero cambiando de tema... creia que el compilador de C/C++ de Intel era de pago... hay una version de prueba?? porque espero que no sea como la version de prueba del VTUNE, que despues de tener que hacer lo del registro para que te mande el link al correo y despues de todo, no te baje nada porque dice que el link no existe :enfadado:
un saludo
Si, es de pago, pero acaso el vc++ no lo es? seamos realistas, quien de este foro tiene el vc pagado (aunque sea la version de estudiante)?. Con esto no quiero dar pie a q la gente piratee ni mucho menos, pero no creo q haga mucho daño a nadie q pilles un programa pirata para hacer tus cosas (siempre q no sea para vender o similar).
Yo he probado el compilador de intel con un programa mio, un efecto agua con perlin noise, todo CPU, y en mi pc, un p3 800, sube la friolera de 40 fps (de 80 a 120) y en un amd 1700 sube unos 60 fps (hasta 200). Comprobaldo vosotros mismos, eso si el tamaño del exe sube unos 8kb (hasta 28kb).
Mejor dedicarse a indicarle al compilador la optimizacion que deseais, hoy programar en ASM en las peceras es perder el tiempo, a dia de hoy los compilatas hacien mas que bien su trabajo, no quiero negar que en ASM sera todo mas rapido...... pero perder tanto tiempo en 2 frames mas por segundo..... que el codigo en C tambien es factible de ser optimizado!!
[Contestando a ethernet]
Yo tengo el VC++6.0standard, pagado, luego os quejareis que en este pais se piratea mucho y no vale la pena vender juegos :ojo:
Saludos.
vale q tengas el vc pagado, pero supongo q no eres un chaval q usa el vc para hacer 4 holas mundo y abrir 4 ficheros, entre otras cosas porq alguien de esas caracteristicas no tiene dinero para comprar el vc (a no ser la version estudiante).
De todas maneras tener pirata el vc no impleca q te guste el pirateo ni q vayas a piratear juegos.
Repito q con este post no estoy defendiendo la pirateria.
Saludos
Pues mira, yo tg de pago el Visual Studio.net edicion profesional (version estudiante, sin manuales) y tb el visual studio 6, tb comprado... unas 20000 ptas cada uno...
Esta bien k los novatos se lo pillen pirata o algun compilador gratuito... total para el fiasco k se llevan como programador... todo el dia de aki pa alla en la red en busca del tan deseado codigo fuente de tal y tal :lengua:
El ensamblador no es antiguo para nada, y esos 2 fps k comentas se ganan solo en pantalla con un cubo... si pones en pantalla unos 20000 por ejemplo... la ganancia de fps es abismal... hoy dia nadie programa bien y los pocos k lo hacen... son considerados gurus... No hay nada mas k ver lo k dice ethernet...
Con en el ensamblador no se pierde tiempo, sino k lo ganas... y encima en mejorar el rendimiento y buen aprovechamiento del hardware, k hoy dia con tanta nvidia y ati parece k el programador de verdad ya es un dinosaurio... menos perder el tiempo con tanto cutre chat, tanto foro y tanta mierda y mas a lo k hay k darle.
Amen y todos a callarse la boca (mas bien dicho, no hagais ruido con el teclado aki y hacerlo en el visual o el borland :lengua:)
saludos desde un grafista/"semiprogramador"
El render de un cubo o 20K o lo que sea se realiza hoy en día a través de la API (Direct3D, OpenGL...) ya que las aceleradoras no se pueden programar a bajo nivel (y no me refiero a los vertex & pixel shaders). Así que tenemos que por muy bien que se programe uno su renderer en asm (un renderer por software se entiende) siempre irá "infinitamente" más lento (y ya no digamos si se intenta alcanzar la calidad gráfica que son capaces de alcanzar los bichos de hoy en día) que utilizando la aceleración que obtienes a través del API (gracias a la aceleradora claro). Así que tenemos que el asm se puede seguir utilizando para rutinas bastante concretas (rutinas matemáticas por ejemplo). Aún así el incremento de FPS debe ser poco si se ha desarrollado un buen código en C/C++. Es por esto que por ejemplo la versión acelerada de quake2 no contiene una sóla línea de asm...y la verdad no digo que no se pueda optimizar más pero a mi cuando jugué por primera vez con mi Voodoo2, P133Mhz y 32MB RAM, me iba como un tiro :riendo:
Saludos
Esta claro qe cuanto a mas bajo nivel se programe mejor tirara.. y podeis llamar vagos a los programadores de hoy en dia (muchos lo son), pero parece qe se le olvida a todo el mundo qe ya no estamos en la epoca del spectrum, y hoy en dia hacer un videojuego conlleva un trabajo bastante mas pesado (y no solo en programacion pero bueno..).
Tpco estoy de acuerdo conqe siempre se gane optimizando en asm, la mayoria de las veces el compilador se sobra para hacer el codigo igual de rapido.
qe sueño XD
Me niego rotundamente a decir q puedo programar mejores rutinas en asm q una persona q esta 8 horas al dia dandole caña a unas rutinas para eso. Me refiero a las personas q programa drivers y cosas en bajo nivel. Si alguien cree q puede q me avise. Otra cosa muy diferente es optimizar una parte del codigo con asm, pero eso no es programar en asm, por q no es ni un 1% del total del codigo.
Por cierto el post por encima del de berserker no es para hacerlo mucho caso. Ya me parece haber visto mas post cargados del señor de mas arriba. No convirtamos el foro en un sumidero de comentarios asquerosos, gracias
saludos
Por cierto, sabeis si el Visual Studio 6 hace algun tipo de optimizacion (o se puede activar) para distintas CPUs? Si hace optimizacion MMX, 3DNow!, SSE...?
Para DraKKar: me suena que hay que incluir unas librerías de Intel. Que no sé si se pueden bajar gratuitamente o hay que comprarlas...
Por lo demás, hay que decir que entreveo un pique Berserker <-> ethernet que creo que es mejor que no desarrolleis en los foros (ni en C ni en ASM XDDD)
Algo que veo que ha sido muy obviado: el ensamblador se utiliza ampliamente en la programación de consolas (por la experiencia que tengo, mi SyncAGB es 100% código ensamblador del chip ARM7TDMI, así como el resto de motores de sonido y algunos motores 3D que hay para la misma consola) y en la programación de algunas recreativas serie B que se basan en chips de Intel de la serie 80x86 y necesitan estar bastante optimizadas (en el fondo son como PCs antiguos)
Eso sí: para Windows o para Linux, la programación en ensamblador tiene muchos más inconvenientes que ventajas. Yo hace tiempo que he dejado de programar en ensamblador para estas plataformas. Aunque creo conocer bastante a fondo la arquitectura de los procesadores actuales, el tiempo empleado en el desarrollo de un código en ensamblador más óptimo que el que genera el propio Visual C++ no me compensa el tiempo dedicado a programarlo. Ahora bien, para los más puristas, tened en cuenta que podeis compilar vuestro .C en un .ASM y luego ahí depurad lo que podais (hay un mensaje sobre cómo hacerlo en otro post de estos foros)
Venga, un saludo
Sync
Citar
El 2002-08-29 12:50, DraKKaR escribió:
Por cierto, sabeis si el Visual Studio 6 hace algun tipo de optimizacion (o se puede activar) para distintas CPUs? Si hace optimizacion MMX, 3DNow!, SSE...?
Creo que no. Si se examina el código generado, se ve que solo emplea instrucciones genéricas del 80486...
En cuanto a lo de usar o no ASM, solo decir que la libreria de microsoft D3DX hasta la versión DX7 sólo eran un conjunto de funciones de ayuda escritas en C. A partir de la versión DX8 ya no hay código C, las funciones las han hecho directamente en ensamblador. Si trazais una de esas funciones (por ejemplo D3DXMatrixMultiply)vereis que dispone de código normal,SSE,MMX,3DNOW, y salta a uno u otro dependiendo del procesador que tengas.
saludos
Fiero no estoy muy seguro de estar en lo correcto, pero si con lo de trazar te refieres a debuguear la ejecucion de tu programa, las instrucciones que te apareceran estaran siempre en ensamblador(dado que lo que estas viendo en la pantalla de debug es lo que esta ejecutando el procesador), a menos que tengas el codigo fuente original(pues en ese caso puedes elegir entre ver el codigo ensamblador o el codigo C o ambos mezclados, al menos asi es el debug de Borland), sin embargo dudo que Microsoft te haya entregado el codigo original de las librerias DirectX :sonriendo:.
Lo que me hace pensar esto, es que como tu has dicho, el codigo cambia a un tipo de instrucciones segun el procesador que tengas.
Saludos.
[ Este Mensaje fue editado por: HaltedMode el 2002-08-29 13:42 ]
:riendo:
¡Saludos!
Citar
El 2002-08-29 13:39, HaltedMode escribió:
Fiero no estoy muy seguro de estar en lo correcto, pero si con lo de trazar te refieres a debuguear la ejecucion de tu programa, las instrucciones que te apareceran estaran siempre en ensamblador(dado que lo que estas viendo en la pantalla de debug es lo que esta ejecutando el procesador), a menos que tengas el codigo fuente original(pues en ese caso puedes elegir entre ver el codigo ensamblador o el codigo C o ambos mezclados, al menos asi es el debug de Borland), sin embargo dudo que Microsoft te haya entregado el codigo original de las librerias DirectX :sonriendo:.
Lo que me hace pensar esto, es que como tu has dicho, el codigo cambia a un tipo de instrucciones segun el procesador que tengas.
Estás en lo cierto, eso pasa por ejemplo al debugear código de las MFC o de otras librerias en las que se cuenta con el código fuente en C. Sin embargo a partir de DX8 ya no viene el código fuente en C. Se nota que está programado directamente en ASM al ver el código, además eso de saltar a un grupo de instrucciones u otro no lo hace ningun compilador :ojo:
saludos
para synchrnzr:
al mensaje q me referia era al de WhiteBlaizer q si lo has leido va con animo de ofender. Por lo menos he visto q se sigue con la tematica del thread ( q me parece muy interesante)
Saludos
tarjeta de red o como sea :sonriendo:
Si has leido lo que puse... no va con animos de ofender a nadie, asi es como lo ves tu... pork lo mas seguro te sentiras identificado con algo k haya dicho en este post o en otros... si su majestad se ha molestado k se le va a hacer... tu mismo con el dolor :lengua: no te voy a pedir disculpas.
Hay k ver como os pone internet... k pocas neuronas de compresion se os keda... si cogeis todo como si os insultaran... anda ya y el k se ofenda con algo k se meta bajo tierra y k no sepa de los demas.
Por cierto se me olvidaba reirme:
ajajajajjaajajajajajaa :riendo: es buenismo. La variedad de peña rara k se encuentra uno...
joder el post crece.. me ausento y no veas k de peña...
yo ahora estoy aprendiendo ASM.. ensamblador!! no me gusta decirle ASM como los guiris.
uno no se puede o deberia llamarse asi mismo programador si no sabe ensamblador, weno es mi opinion.
el ensamblador es lo mejor para optimizar y aumentar el rendimiento, es mi opinion.. hay kien dice k ya no hace falta pero yo lo estoy aprendiendo por gusto, es mu intertesante el ensamblador.
el programa k uno hace debe estar optimizado al 100% y usar el 100% de lo k hoy dia existe... tecnologia mmx, optimizacion para los pentium 2, 3, 4 y amds(con su 3dnow).
os recomiendo useis ASM y las funciones del c++ inline.
las funciones inline mejoran mucho el rendimiento del programa y su rapidez pero aumenta el tamaño del exe, no hay k abusar de ellas.
ahora estoy liao con el ensamblador y las cg de nvidia k son muy muy potentes... tan potentes k en el siggraph de este año han puesto el final fantasy(la peli) en tiempo real con una quadro ddc, el programa es de nvidia promocionando su cg... ami me ha engatusao jeje.
saludos
gueno, gueno, vayamos por partes, decia jack el destripador... :sonriendo:
bueno, despues de este caustico chiste malo, vayamos a lo que vamos...
El ASM (o ensamblador para los amantes de los terminos faciles :sonriendo:) es muy bueno precisamente por el hecho de aprovechar la maquina, porque imaginemos que tenemos un motor o mas que un motor, un juego corriendo y que en cada frame el codigo utiliza un 97% de la CPU. Si ese codigo se pudiera optimizar con el ensamblador y, digamoslo como un ejemplo, somos capaces de ganar un 15% de CPU sustituyendo ciertas funciones de alto nivel por otras con partes escritas en ASM o totalmente escritas con ASM, eso simple y llanamente significa que nos sobraria un 18% de CPU para poder implementar mas efectos, con lo cual ganariamos mucho, y en cualquier caso, aun no ganando nada 'visualmente', el codigo siempre se ejecutara mas rapidamente o utilizara la cache de una manera mas eficiente, y eso es decir mucho cuando se habla de procesos criticos, como tareas de render o en este caso, cualquier proceso que complemente al render, que ya es mucho ganar...
en cuanto a lo de la exhibicion de NVIDIA, si, ya habia escuchado algo parecido, incluso antes de eso hicieron un render en tiempo real de la misma pelicula, pero usando una GeForce3 y el invento tiraba a 20FPS, creo, venia en una pagina de internet, solo que no lo recuerdo, sino pondria el enlace... tambien he escuchado que ATI, no queriendo quedarse atras, ha hecho lo mismo, pero renderizando unas secuencias del señor de los anillos utilizando el hardware de la nueva Radeon 9700, estaria bien poder ver esos videos del render (o estar alli, que estaria de lujo...)
en cuanto a lo del CG de NVIDIA... que se lo metan por el culo, yo no lo he probado, pero no estoy conforme con esa metodologia que esta siguiendo NVIDIA, ya que parecen querer imponer el CG con sus tarjetas junto a la tecnologia CineFX (o algo asi se llamaba) y me parece que estan cayendo en el mismo error en el que cayo en su dia 3DFX y que, en mi opinion, les costo su caida como empresa...
Seria mucho mejor esperar a que, en el caso de las dos plataformas, OpenGL (en su version 2.0, que ya hay drivers para ciertas tarjetas, como las de 3DLabs, en beta, eso si) o Direct3D (no conozco mucho ese mundillo, asi que no digo nada...) asentaran de forma generica los shaders y estructuras para animacion, coño... si hasta ATI esta deacuerdo en eso con 3DLabs, pero no... tienen que llegar los señores de NVIDIA y decir 'por favor... queremos mas... y queremos que los demas hagan lo que nosotros queramos...'...
En fin, perdon por la acidez del comentario, pero a mi ese tipo de actitud me revuelve el estomago... en fin, espero que NVIDIA no se equivoque...
Si, vi lo de FF con una Quadro...¿salió algún video para poder verlo?...a ver que tal era la calidad gráfica y demás :sonriendo:
En cuanto al ensamblador pues bueno quien más quien menos ha dedicado su tiempo a aprender algo pero a mi parecer no merece la pena el tiempo necesario para desarrollar una rutina en ensamblador que compita con la desarrollada en C/C++...además siempre se puede optimizar más el código (para el render o lo que sea), utilizando otros algoritmos más óptimos que los que utilices. Así que yo personalmente prefiero dedicar el tiempo a buscar nuevos métodos para descartar más polígonos y más rapidamente o un sistema de colisiones más rápido que crearme una rutina que concatena matrices (o lo que sea) en ensamblador...
Saludos
Curioso post.
Atras quedaron los dias en los que utilice el ensamblador (epoca del MSDOS, modo 13h, etc). Actualmente pienso que es preferible saber analizar la complejidad de un algoritmo o las ventajas de utilizar una u otra estructura de datos; ¿porque es rapido un arbol?, ¿que complejidad tiene?, ¿para este problema conviene utilizar una tabla hash o irse a por una lista?, ¿porque no utilizar monticulos en lugar de esperar a tener todos los datos y ordenar despues?. Las librerias STL te ofrecen montones de estruturas de datos y algoritmos, pero hay que saberlos utilizar.
En fin, lo dicho, estoy con Berserker. Yo creo que el ensamblador solo debe de utilizarse cuando sea estrictamente necesario, mientras tanto preocupate de asegurar que tus estructuras de datos y algoritmos den la talla en la tarea asignada (y bajo cualquier caso de uso).
Saludos.
[ Este Mensaje fue editado por: frodrig el 2002-08-29 22:09 ]
Un aspecto q no se ha tratado en el post es el tema de la portabilidad. Nadie se ha parado a pensar q todos los procesadores no son de la familia x86?.
Personalmente la filosofia de id me ha gustado por ese tipo de aspectos ( y por tantos otros) y sino solo teneis q mirar los fuentes del quake2 :sonriendo:) (no mireis la parte de render por soft XDDDD).
Saludos
eso ya no es un problema hoy dia, de hecho si te fijas en el principal competidor de Intel y segundo suministrador de procesadores para PCs, el juego de instrucciones es compatible totalmente con el de Intel, bueno... hasta cierto punto.. quiero decir, por decirlo de manera concreta, los Athlon XP soportan hasta las instrucciones SIMD de primer nivel, o SSE, las que no soporta son las SIMD de segundo nivel o SSE2, que son las que lleva el Pentium4, asi que en cuestion de portabilidad... no, que yo sepa no hay ningun problema... que yo sepa, claro...
de todas formas entiendo tu postura, ethernet, lo cierto es que si el alto nivel fuera tan preciso y tan rapido como el ensamblador, no estaria hoy dia jugando con el ASM, pero lo cierto es que el ASM estara ahi siempre, de forma que uno no tiene porque programar con ASM para que un programa sea preciso, tambien hay muchos metodos de optimizacion de alto nivel, solo que si quieres exprimir la maquina A FONDO, entonces no tienes otra alternativa, y sinceramente, no la tendras nunca... las cosas son asi :sonriendo:
un saludo
ahhh... un momento, casi se me olvidaba... alguien sabe si la Radeon 9700 utiliza el mismo concepto de VPU que la P10 de 3DLabs, quiero decir lo de las multiples VPUs virtuales a traves de multi-threading... es que estoy pensando en cambiar de tarjeta y coger una de nueva generacion, y una cosa tengo clara... no sera una NVIDIA, ya he tenido 2, una TNT2 y una GeForce2 (la que tengo ahora), pero ya va siendo hora de cambiar... y aunque es una pasta, estaba pensando inicialmente en la 3DLabs, lo que pasa es que es cara con creces y la Radeon 9700 no se como va de precio pero en la pagina de ATI no ponen mucha informacion... alguien me puede 'iluminar'? gracias de antemano
ahora si... un saludo :sonriendo:
Q yo sepa no solo existen intel y amd... de todas maneras, en el ambito de la programacion de juegos, en los ultimos tiempos no tiene mucho sentido la portabilidad puesto q se esta usando DX en la gran mayoria de juegos, q por otra parte es logico viendo el segmento de mercado q compra (o piratea) juegos.
Saludos ;D
Hace tiempo lei en un tutorial sobre optimizacion de codigo, escrito por un experto en el tema, que cogio un algoritmo escrito en C y lo paso a ensamblador consiguiendo mejorar el rendimiento bastante. Pero despues tomando como guia el codigo ensamblador lo volvio a pasar a C, consiguiendo mejorar un poco mas el rendimiento.
El ensamblador mejora el rendimiento, pero el compilador puede llegar a optimizar mas que una persona, solo hay que saber que es lo que esta haciendo y como escribir el codigo.
Citar
El 2002-08-29 22:47, ethernet escribió:
Q yo sepa no solo existen intel y amd... de todas maneras, en el ambito de la programacion de juegos, en los ultimos tiempos no tiene mucho sentido la portabilidad puesto q se esta usando DX en la gran mayoria de juegos, q por otra parte es logico viendo el segmento de mercado q compra (o piratea) juegos.
Saludos ;D
en linux tb se juega!
[ Este Mensaje fue editado por: seryu el 2002-09-01 22:54 ]
Se juega a los juegos de id y al tux racer q no esta nada mal, pero el segmento de mercado es windows clara y rotundamente.
Saludos