Ark del KAOS wrote:
Como veis tengo un athlon XP (2600+) de los típicos.
¿que flags creéis que debería utilizar?
Esto me va a venir bien, ya que así me podeis indicar alguna nueva implementacion al gcc 3.4
Voy a contar un poco mi experiencia, pero
Disclaimer (renuncia de responsabilidad): si tomas una decisión, tómala por tí mismo. No te bases en lo que cuento para llegar después y echarme la bronca porque las cosas no funcionan como esperabas.
En principio -m3dnow -mmmx y -msse son redundantes (en teoría), -march=athlon-xp ya las incluye y además te hace un prefecth sse. El manual de gcc dice que se ha de incluir -msse para poder usar -mfpmath=sse, sin embargo no dice que los procesadores que ya incluyen el juego de instrucciones, evidentemente, no necesitan añadirla: de pentium3 en adelante. Además teniendo las USE 3dnow mmx y sse, como las tienes, los programas que puedan beneficiarse de añadir el juego de instrucciones en el ensamblador, como xorg-x11 o mplayer ya lo harán. Y decía lo de en teoría, porque algunos programas no me han funcionado correctamente con ellas: fallos en el cálculo de posición en un fichero de texto, por ejemplo. Por lo que he visto en el código de GCC me temo que lo que falla es añadir mmx a procesadores con sse, dado que sse lo presupone o incluye de algún modo; pero si me hacen jurarlo, no lo juraría y lo que no voy a hacer es ponerme a estudiar juegos de instrucciones de procesadores por esta chorradita, dejo el march, mfpmath=sse y listo.
Con maccumulate-outgoing-args, obtienes una importante mejora, pero ojo, incrementando el tamaño del binario considerablemente. Tan sólo depende de lo que quieras obtener y realizar un contrapeso, comprobando programas y tamaños con y sin ella. quickpkg te resultará de mucha ayuda para hacer pruebas. Pero es como ganar en una cosa, para perder en todas las restantes, ya verás...
Con respecto a todo lo de los loops, he visto que hay algunos programas que se benefician y otros no, pero aún me quedan muchas pruebas por hacer y no puedo decir nada más de momento. (Andar haciendo benchmarks me parece tremendamente aburrido).

CFLAGS que añadiría a las tuyas: -momit-leaf-frame-pointer, es complementaria a -fomit-frame-pointer y te deja un registro adicional libre en las leaf functions; utilizado de forma completamente innecesaria si se tiene el -fomit-frame-pointer y si no se tiene el -momit-leaf-frame-pointer.

CXXFLAGS que añadiría (sólo con gcc-3.4.x): -fvisibility-inlines-hidden Según cuentan en
GCCWiki - Visibility, es una CXXFLAG de aplicar y ganar en rendimiento sin más, dado que no afecta al código del programa, sencillamente lo hace más rápido. La tengo desde hará unos cuatro o cinco meses (mucho antes de que gcc-3.4.4 estuviese considerado estable) y no me ha dado el más mínimo problema. Eso sí, evita a toda costa el -fvisibility=hidden de ese Wiki, dado que si el programa o ha implementado ningún parámetro de "visibilidad" modifica el código, y se lo carga. En mis pruebas, los programas dejaban de compilar tras incontables referencias a clases C++ blah::bleh que no encontraban. Hay algunos que funcionan con ella, pero conste que
no la estoy recomendando.

Insisto

Exceptuando -fvisibility-inlines-hidden en las CXXFLAGS y quizá -momit-leaf-frame-pointer en las CFLAGS, si todo te ha ido bien no toques las CFLAGS, por algo las estarás usando.
Todo punto de vista es un ápice de una pirámide invertida cuya base es indeterminable. (Pessoa)