# [make.conf] CFLAGS y USE para HyperThreading (desvariando)

## aj2r

Hola, ¿qué CFLAGS y USE me recomendáis para sacarle el máximo probecho a la tecnología HT de mi PIV?Last edited by aj2r on Thu Feb 02, 2006 12:40 pm; edited 1 time in total

----------

## pacho2

 *aj2r wrote:*   

> Hola, ¿qué CFLAGS y USE me recomendáis para sacarle el máximo probecho a la tecnología HT de mi PIV?

 

Yo al compilar aplicaciones uso como CFLAGS y CXXFLAGS las siguientes:

-O2 -march=pentium4 -pipe -fomit-frame-pointer -msse2 -mfpmath=sse (con estos CFLAGS tienes asegurado que NO vas a tener problemas de compilación, puedes usarlos con total tranquilidad)

El MAKEOPTS lo tengo a -j3, aunque es posible que le puedas poner 4, o incluso 5 (algunos dicen que lo recomendable son el nñumero de "CPUs"+1 y otros pocos dicen que 2xCPUs +1).

A veces, si veo que la aplicación no falla, la compilo con -ffast-math (cflag con la que se gana bastante pero que puede traerte problemas, con lo que no es muy recomendable que esté incluída en el makd.conf).

En cuanto a los USEs lamento no poder serte de mucha ayuda (quitando que, aunque supongo que ya lo sabrás, yo usaría el use ntpl  :Wink: ).

Saludos  :Smile: 

----------

## Charletes

No creo que haya (casi) ningún flag USE que haga uso específico de hyperthreading; aparte de dar soporte SMP en el kernel (de esto no estoy seguro del todo!) y compilar con los CFLAGS válidos para un Pentium4, no creo que tengas que hacer nada más especial para aprovechar a tope el procesador.

----------

## LinuxBlues

Depende del modelo de pentium4 que sea...

-march=pentium4 incluye soporte MMX, SSE y SSE2

-march=prescott incluye soporte MMX, SSE, SSE2 y SSE3.

-march=nocona igual que el anterior pero con extesiones de 64bit.

Con respecto al HT, los P4 no son un dual core real, sólo los xeon son dual core. El HT lo único que hace es permitir la ejecución de dos hilos en paralelo, siempre y cuando el segundo hilo pueda utilizar ciclos de reloj que el primero no esté usando.

Puedes añadir la USE local smp (sólo afecta al Gimp) para hacer pruebas, pero yo no lo haría, ni tan siquiera activaría SMP en el kernel, porque los pentium4 no son dual core y no tienen capacidad para realizar dos tareas en paralelo. Lo único que haría es añadir el soporte nptl, como ya se ha sugerido, dado que son capaces de procesar dos hilos en paralelo si se cumple lo dicho: el primer hilo debe dejar recursos disponibles del procesador, para que se ejecute el segundo al mismo tiempo.

Una explicación tremendamente intuitiva de todo esto en Intel Dual-Core Processor Demo

----------

## pacho2

 *LinuxBlues wrote:*   

> Depende del modelo de pentium4 que sea...
> 
> -march=pentium4 incluye soporte MMX, SSE y SSE2
> 
> -march=prescott incluye soporte MMX, SSE, SSE2 y SSE3.
> ...

 

lame también aprovecha el smp. Ya se que el HT no es un SMP verdadero (y que su rendimiento es peor), pero algo (aunque sea un poco  :Wink: ) sí que se gana.

Saludos

PD: haciendo cat /proc/cpuinfo sabrás si tienes o no sse3

----------

## Ferdy

 *Quote:*   

> Una explicación tremendamente intuitiva de todo esto en Intel Dual-Core Processor Demo

 

Tan básica como peligrosa...

Y si, si tienes un HT, habilita SMP. No hacerlo porque no es lo mismo que un sistema dual-core o un sistema dual-processor es como desactivar el DMA en un disco IDE porque no va a dar el mismo I/O que un SCSI.

Saludos.Ferdy

----------

## LinuxBlues

 *Ferdy wrote:*   

> Tan básica como peligrosa...

 

SMP significa multiprocesamiento simétrico que yo sepa, una característica de la que los pentium4 no disponen.

Pero es seguro activarlo en el kernel, de hecho en un sistema con un único procesador sin HT, léase pentium3 o athlon-xp, puede usarse un kernel con SMP y no pasa absolutamente nada, exceptuando que tienes un bajón de rendimiento considerable.

Habría que ver lo que ocurre si se utilizan servicios como irqbalance, que asignan las interrupciones hardware a la CPU menos ocupada, cuando un pentium4 solo dispone de un gestor de interrupciones, supongo que se las pasaría al único gestor disponible.

No tiene por qué fallar, pero recordar que si no tenemos un dual core o dos procesadores, SMP decrementa el rendimiento en lugar de aumentarlo, y por mucho que nos hayan "vendido" el HT como una maravilla... 2 o + == SMP, 1 =! SMP.

Veo la ecuación tremendamente sencilla: con una sola CPU el SMP es imposible.

 *pacho2 wrote:*   

> 
> 
> lame también aprovecha el smp. Ya se que el HT no es un SMP verdadero (y que su rendimiento es peor), pero algo (aunque sea un poco) sí que se gana.
> 
> 

 

Supongo que sí, no lo discuto, imagino que tu apreciación se basa en benchmarks realizados con un kernel con y sin SMP, ¿te importaría compartir los resultados? Siento que las apreciaciones subjetivas no me valgan, tengo muchismo interés en comprobar los resultados.

Gracias.

----------

## Ferdy

Veamos, varias cosas básicas:

El SMP es para sistemas duales y con más procesadores; hasta ahí tienes razón. Es cierto también que una máquina con una sola CPU pierde rendimiento si se compila el kernel con SMP; otro punto para ti.

Pero tu asumes que el soporte SMP del kernel no soporta ni conoce ni se entera de que el micro sobre el que corre es HT. Y eso es falso. El planificador del kernel es capaz de tratar micros HT desde antes que saliera el kernel 2.6. De hecho el soporte se inició en el kernel 2.5 con un parche del genial Ingo Molar.

 *Quote:*   

> 2 o + == SMP, 1 =! SMP.
> 
> Veo la ecuación tremendamente sencilla: con una sola CPU el SMP es imposible. 

 

Ecuaciones sencillas pero claramente erróneas.

Saludos.Ferdy

----------

## Charletes

He estado mirando en las fuentes de linux, y hay que activar SMP y SMT (hyper-threading scheduler support) (esta última opción aparece sólo si activas SMP primero).

 *make menuconfig wrote:*   

> 
> 
> CONFIG_SCHED_SMT:                                                       
> 
> SMT scheduler support improves the CPU scheduler's decision making
> ...

 

----------

## pacho2

 *Quote:*   

> 
> 
>  *pacho2 wrote:*   
> 
> lame también aprovecha el smp. Ya se que el HT no es un SMP verdadero (y que su rendimiento es peor), pero algo (aunque sea un poco) sí que se gana.
> ...

 

Lo siento, pero yo no hago precisamente muchos benchmarks  :Sad: . Esa máquina se pasa el día calculando, y, aunque no lo creas, sí que se nota que va mejor cuando activo la opción del kernel para dar soporte al HT (SMT (Hyperthreading) scheduler support), para ello parece ser necesario activar previamente el "Symmetric multi-processing support".

Saludos

----------

## LinuxBlues

 *Ferdy wrote:*   

> Pero tu asumes que el soporte SMP del kernel no soporta ni conoce ni se entera de que el micro sobre el que corre es HT. Y eso es falso. El planificador del kernel es capaz de tratar micros HT desde antes que saliera el kernel 2.6. De hecho el soporte se inició en el kernel 2.5 con un parche del genial Ingo Molar.
> 
> Ecuaciones sencillas pero claramente erróneas.

 

No es que sean erróneas, esque al parecer los HT son la excepción que hace que se cumpla la norma.

Llevas razón, la verdad ni me había parado a mirar el planificador del núcleo y desconocía el trabajo de Ingo Molar. Sigo con el trabajo de Alan Cox en mente y no me he actualizado debidamente  :Smile:  . Una cosa más que he aprendido en el foro. Muchas gracias.

Sigue sin convencerme el HT, aunque no me cabe duda de que es un avance tecnológico muy importante...

----------

## pacho2

Yo no creo que el HT sea un gran avance. Es una estratagema de Intel, aprovechándose (si mal no recuerdo) del ACPI, para intentar competir con AMD.

Mi experiencia es que un PIV a 3.06 GHz gana bastante con HT, pero también hay que decir que un PIV a 3.06 GHz con HT no tiene NADA QUE HACER frente a, por ejemplo, una Athlon 3200 a 2.00GHz (monoprocesador) corriendo a 64 o a 32 bits.

Si compras un PIV, yo lo cogería con HT, pero, el "kit de la cuestión" es que, casi seguro, que no compraría un Intel  :Very Happy: 

Saludos  :Smile: 

----------

## Ferdy

 *Quote:*   

> Sigue sin convencerme el HT, aunque no me cabe duda de que es un avance tecnológico muy importante...

 

Claramente no va a reemplazar a una máquina dual; es algo intermedio.

Saludos.Ferdy

----------

## LinuxBlues

 *Quote:*   

> es algo intermedio.

 

¿Podrías explicar ésto? Por favor.

El HT solo mete un segundo hilo, si el primero deja recursos disponibles en el juego de instrucciones del procesador...

Eso es partir de la base de que se está usando un Wxp compilado para i586, o, a donde yo quería llegar: que GCC está realizando mal su trabajo.

GCC no es inteligente, hace lo que se le dice que haga y si por ridículo que parezca se le pide que use SSE3 para hacer un simple ld en ensamblador, lo hará. Es decir, no toma decisiones propias del tipo: no necesito este juego de instrucciones, lo dejo libre.

Ya me dirás los recursos disponibles que quedan para ejecutar un segundo hilo, compilado con un -march=nocona. Aunque sin embargo, no todo es código máquina, para eso tenemos los interpretados: python, java, vbasic y cía., mientras se usen este tipo de lenguajes, el HT sí que tiene sentido, pero sigo sin encontrárselo en ensamblador...

Por eso, agradecería una nueva explicación que me aclare más las cosas... Si no es demasiado pedir.

----------

## Ferdy

A ver... la CPU HT se comporta de cara al SO como dos CPUs; de hecho Linux las trata en principio como dos CPUs físicas y no lógicas. Con "es algo intermedio" me refiero a que es algo intermedio en cuanto al rendimiento que da. Está claro que da más rendimiento que una máquina similar monoprocesador y dará menos rendimiento que una dual o una quad.

Sobre tu mensaje

 *Quote:*   

> se le pide que use SSE3 para hacer un simple ld en ensamblador

 

Eso no es cierto... SSE3 añade algunas instrucciones entre las que claramente no se incluye 'ld' ni ninguna similar. No se de donde has sacado eso.. pero me da que te has confundido.

 *Quote:*   

> Ya me dirás los recursos disponibles que quedan para ejecutar un segundo hilo, compilado con un -march=nocona.

 

Depende MUCHO del código y del orden de las instrucciones. No es predecible.

 *Quote:*   

> Aunque sin embargo, no todo es código máquina, para eso tenemos los interpretados: python, java, vbasic y cía., mientras se usen este tipo de lenguajes, el HT sí que tiene sentido, pero sigo sin encontrárselo en ensamblador... 

 

Eso no lo entiendo... TODO es código máquina. Y un compilador claro que puede optimizar para una máquina HT y decidir acerca de las instrucciones y el orden de las mismas dependiendo de los registros que se usen y los recursos del procesador que use cada instrucción.

Saludos.Ferdy

----------

## aj2r

En mi sitema al hacer un emerge el uso de la CPU sólo llega al 50%, y si lanzo al mismo tiempo otro emerge de un paquete diferente el uso de la CPU es del 100%

----------

## Charletes

 *aj2r wrote:*   

> En mi sitema al hacer un emerge el uso de la CPU sólo llega al 50%, y si lanzo al mismo tiempo otro emerge de un paquete diferente el uso de la CPU es del 100%

 

Creo que para evitar eso está "makeopts = -j2", que juraría que es para indicar el máximo número de compilaciones que se pueden hacer en paralelo. Prueba a subirle el valor.

----------

## aj2r

Le tengo puesto -j3, se supone que debería ser el número de CPUs más uno ¿no?

----------

## Charletes

Pues sí, se supone que es eso... No tengo experiencia con SMT, sólo teoría lo siento  :Wink: 

----------

## LinuxBlues

 *Ferdy wrote:*   

> Eso no es cierto... SSE3 añade algunas instrucciones entre las que claramente no se incluye 'ld' ni ninguna similar. No se de donde has sacado eso.. pero me da que te has confundido.

 

Yo tampoco sé de dónde lo sacas, juega con comas flotantes y me cuentas.

 *Quote:*   

> Depende MUCHO del código y del orden de las instrucciones. No es predecible.

 

Bien, pon -march=pentium2 y luego -march=pentium3 -mfpmath=see y me cuentas a ver si GCC obedece a tus instrucciones o no. Independientemente del código no hace B si le has "ordenado" que haga A. Y no me discutas eso porque encima me reiré.

 *Quote:*   

> TODO es código máquina

 

Ejecuta un pyton sin shebash y me cuentas... Es decir, prueba con emerge mismo: Quítale en /usr/bin/emerge el primer

#!/usr/bin/python -O  y después me cuentas, como no tengas binfmt_misc compilado en el núcleo, montado en /proc y no tengas echo ':pycode:M::\x87\xc6\x0d\x0a::/usr/bin/python:' > /proc/sys/fs/binfmt_misc/register en local.start la cagaste Burlan Caster.   :Laughing:  Sencillamente porque te has quedado sin intérprete que lo traduzca a código máquina. Así de simple.

----------

## Ferdy

 *LinuxBlues wrote:*   

> Yo tampoco sé de dónde lo sacas, juega con comas flotantes y me cuentas.

 

No, SSE3 no añade ningún 'ld'. Leete de una vez las instrucciones SSE y en concreto SSE3.

 *Quote:*   

> Bien, pon -march=pentium2 y luego -march=pentium3 -mfpmath=see y me cuentas a ver si GCC obedece a tus instrucciones o no. Independientemente del código no hace B si le has "ordenado" que haga A. Y no me discutas eso porque encima me reiré.

 

¿Ein? ¿Qué tiene que ver eso con lo que he dicho yo? Me referia a las instrucciones máquina y no a las CFLAGS... realmente no se por donde va eso.

 *Quote:*   

> Ejecuta un pyton sin shebash y me cuentas... Es decir, prueba con emerge mismo: Quítale en /usr/bin/emerge el primer
> 
> #!/usr/bin/python -O  y después me cuentas, como no tengas binfmt_misc compilado en el núcleo, montado en /proc y no tengas echo ':pycode:M::\x87\xc6\x0d\x0a::/usr/bin/python:' > /proc/sys/fs/binfmt_misc/register en local.start la cagaste Burlan Caster.   Sencillamente porque te has quedado sin intérprete que lo traduzca a código máquina. Así de simple.

 

No, el intérprete de python no convierte el código python a código máquina. Ejecuta secuencialmente.

¿Alguno tiene que repasar sus asignaturas de la universidad o me lo parece a mi?

Saludos.Ferdy

----------

## LinuxBlues

 *Ferdy wrote:*   

> 
> 
> ¿Alguno tiene que repasar sus asignaturas de la universidad o me lo parece a mi?
> 
> 

 

Considero desafortunado este comentario, pero gracias por aportar luz y claridad de todas formas. Cuando quieras hablamos de Filosofía, la carrera que estudié, a ver quién le da un repaso a quién, ¿ok?    :Twisted Evil: 

Editado y no me refiero a chorradas de Platón ni nada por el estilo, sino de la lógica booleana, y también quizá, por qué es imposible deducir toda la Matemática únicamente con axiomas lógicos, hablo de Frege y Russell. Parches muy interesantes,

 :Smile: 

----------

## Ferdy

Pensé que hablábamos de las CFLAGS y cómo pueden influir en el rendimiento en una máquina HT  :Razz: 

 *Quote:*   

> Considero desafortunado este comentario, pero gracias por aportar luz y claridad de todas formas. Cuando quieras hablamos de Filosofía, la carrera que estudié, a ver quién le da un repaso a quién, ¿ok? 
> 
> Editado y no me refiero a chorradas de Platón ni nada por el estilo, sino de la lógica booleana, y también quizá, por qué es imposible deducir toda la Matemática únicamente con axiomas lógicos, hablo de Frege y Russell. Parches muy interesantes, 

 

Gah... ya se que estudiaste filosofía. Se me debió olvidar el smiley o quizá añadir un </ironic> al final.

OT: ¿ No te ha dado nunca por aprender lenguajes funcionales ? Tengo la impresión de que se te dará mucho mejor que la programación imperativa, dada tu extensa formación en esos temas.

Saludos.Ferdy

----------

## alexlm78

 *LinuxBlues wrote:*   

>  *Ferdy wrote:*   
> 
> ¿Alguno tiene que repasar sus asignaturas de la universidad o me lo parece a mi?
> 
>  
> ...

 

 *Socrates wrote:*   

>  Yo solo se que no se

 

No hay que confundir filosofia con matematicas clasicas, aunque parten del mismisimo lugar. Como dijo el sabio Socrates, Reconoscamos nuestro propio conocimiento como el primer paso para aprender lo que no sabemos.

Solo otra aclaracion:

En Informatica TODO es codigo de maquina, al final de todo a eso llegamos, aunque pasemos por interpretes, enlazadores, compiladores, todo termina en codigo de maquina, a un nivel o a otro, el mimisimo HTML se convierte en codigo de maquina en un punto, claro es mas largo el camino que el de un binario comilado pero aun es codigo de maquina.

Filosofia: 

http://es.wikipedia.org/wiki/Filosof%C3%ADa

Logica Booleana: 

http://es.wikipedia.org/wiki/%C3%81lgebra_de_Boole

http://es.wikipedia.org/wiki/Matem%C3%A1tica

----------

## Ferdy

 *Quote:*   

> el mimisimo HTML se convierte en codigo de maquina en un punto,

 

Claro que no.

Saludos.Ferdy

----------

## LinuxBlues

 *alexlm78 wrote:*   

> Como dijo el sabio Socrates, Reconoscamos nuestro propio conocimiento como el primer paso para aprender lo que no sabemos.
> 
> 

 

Discúlpame, pero eso es falso. Lo que Sócrates, según cita Platón, dijo es que debemos reconocer nuestra ignorancia como el primer paso para alcanzar la sabiduría. Sin ello es imposible, y aún con ello. Mi maestro es Sócrates, y efectivamente, "sólo sé que no sé nada".

 *Ferdy wrote:*   

> 
> 
> OT: ¿ No te ha dado nunca por aprender lenguajes funcionales ? Tengo la impresión de que se te dará mucho mejor que la programación imperativa, dada tu extensa formación en esos temas. 
> 
> 

 

¿Realmente ves útil programar en prolog? Se me daría de vicio, pero lo veo inútil.

 *Ferdy wrote:*   

> 
> 
> Claro que no.
> 
> 

 

Entonces, ¿cómo demonios un procesador (o dos, ya que hablamos de HT   :Very Happy:  ) es capaz de mostrarme esta página?

Esto ya empieza a ser matafísica, y por ahí sí que no paso... Wittgenstein ha ejercido gran influencia en mi modo de pensar y por la metafísica sí que no paso, pero en fin, que estamos empezando a llevar el OT al colmo...

----------

## Ferdy

 *Quote:*   

> ¿Realmente ves útil programar en prolog? Se me daría de vicio, pero lo veo inútil. 

 

No conozco prolog, pero erlang (entre otros) parece ser una maravilla. Y si no que se lo digan a Ericsson.

 *Quote:*   

> Entonces, ¿cómo demonios un procesador (o dos, ya que hablamos de HT  ) es capaz de mostrarme esta página?
> 
> Esto ya empieza a ser matafísica, y por ahí sí que no paso... Wittgenstein ha ejercido gran influencia en mi modo de pensar y por la metafísica sí que no paso, pero en fin, que estamos empezando a llevar el OT al colmo..

 

HTML es un lenguaje de marcado. Así que una etiqueta hará que en un micro se ejecuten instrucciones arbitrarias no predecibles. (dependiendo del navegador claro...) No es un lenguaje de programacion

Saludos.Ferdy

----------

