# welche CFLAGS in vmware guest

## tazinblack

Hallo zusammen,

ich grübel gerade über die compiler options in einer gentoo VM welche ich gerade aufsetze. 

Diese soll nachher auf unterschiedlichen ESX Servern laufen mit Intel Xeons verschiedener Generationen.

Lass ich dann einfach -march=irgendwas weg oder setze ich das auf was Spezielles?

Danke für eure Tipps!

----------

## Max Steel

Du kannst es weglassen, oder es auf den kleinsten gemeinsamen Nenner setzen.

In der Regel reicht es inzwischen den Wert auf die älteste Generation zu setzen.

----------

## tazinblack

 *Max Steel wrote:*   

> Du kannst es weglassen, oder es auf den kleinsten gemeinsamen Nenner setzen.
> 
> In der Regel reicht es inzwischen den Wert auf die älteste Generation zu setzen.

 

Sind die neueren Generationen durchweg kompatibel mit den älteren?

----------

## Keruskerfuerst

Ich würde eher für jeden unterschiedlichen Xeon die CFLAGS unterschiedliche setzen.

Da besteht schon ein deutlicher Unterschied.

----------

## tazinblack

 *Keruskerfuerst wrote:*   

> Ich würde eher für jeden unterschiedlichen Xeon die CFLAGS unterschiedliche setzen.
> 
> Da besteht schon ein deutlicher Unterschied.

 

Dann müsste ich das für jeden Typ neu bauen, so baue ich die Kiste ein Mal und verteile sie dann

----------

## Keruskerfuerst

Wieviel Rechenleistung haben den die Server (Xeons) ?

----------

## tazinblack

 *Keruskerfuerst wrote:*   

> Wieviel Rechenleistung haben den die Server (Xeons) ?

 

Zwischen 2x6 bis 2x12 Cores oder meinst Du die VMs?

----------

## Keruskerfuerst

Dann dürfte das Kompilieren aber schnell gehen.

----------

## tazinblack

 *Keruskerfuerst wrote:*   

> Dann dürfte das Kompilieren aber schnell gehen.

 

Ist mehr ne manpower Sache

----------

## Keruskerfuerst

Ich würde eben die Standart Konfiguration für die Rechner erstellen und dann nur noch die Kompilerflags für jeden Rechner anpassen. Eben march=native.

P.S.: dann das Netzwerk einrichten und den Kernel passend bauen.

----------

## Max Steel

ICh kann tazinblack durchaus verstehen... aber am besten fährst du vmtl wirklich damit -march wegzulassen oder einen kurzen Vergleich der (durchgereichten) Flags beider Hosts zu dessen Gästen angestrengt wird und aus diesem subset an Flags das passende -march=?? aus der GCC Manual genommen wird (darin steht recht genau was alles mit welchemTyp aktiviert wird.

Was sicherlich relativ gut funktionieren dürfte für die beiden von dir genannten könnten -march=sandybridge sein (mmx, sse, sse2, sse3, ssse3, sse3.1, sse4.2, popcnt, avx, aes, pclmul)...

evtl auch noch haswell, das added zu sandybridge noch diverse andere (movbe, avx2,fsgsbase, rdrnd, fma, bmi, bmi2, f16c).

Was deine beiden Xeons aber letztlich für Generationen sind, weiß ich nicht.

Bei Intel sind die letzten (seit Pentium4) mit ein paar Ausnahmen idR, imho, aufeinander aufbauend gewesen, wenn man der GCC Manual glauben schenkt scheint das auch hier belegt zu sein.

----------

## tazinblack

Das Problem ist auch, dass ich nicht sagen kann, was kommen wird. 

Sprich wenn intel die nächste Generation mit nicht kompatiblen flags ausstattet, fang ich dann an alles umzubauen falls das kommt.

Also sollte ich wohl doch -march einfach weglassen. Dann ist die performance zwar schlechter, aber da ich sowieso nicht die HPC Anwendung schreibe spielt das eher eine nebensächliche Rolle.

Anders rum dürften das die großen Distros auch nicht anders machen. Die können ja auch nicht vorhersagen, auf welcher Hardware der Kunde das letztendlich installiert.

----------

## Keruskerfuerst

Wenn neuere Prozessoren im Server verbaut sind, dann sollte die Installation von einem älteren Server problemlos laufen.

----------

## tazinblack

 *Keruskerfuerst wrote:*   

> Wenn neuere Prozessoren im Server verbaut sind, dann sollte die Installation von einem älteren Server problemlos laufen.

 

Dann könnte ich ja mit march=native bauen

----------

## Keruskerfuerst

Und noch daran denken, dass eben das neue Mainboard vom Kernel unterstützt werden soll.

----------

## tazinblack

 *Keruskerfuerst wrote:*   

> Und noch daran denken, dass eben das neue Mainboard vom Kernel unterstützt werden soll.

 

Da das ja alles nur VMs sind, ist das kein Problem. Höchstens wenn man Änderungen an der virtuellen Hardware vornimmt

----------

