C2D E6400 и gentoo x86

[PDV]

Господа, а вопрос такой - что будет, если при установке Gentoo 2007.0 x86 (не amd64!) на машину с процессором Core 2 Duo в make.conf вписать не "-march=prescott", а "-march=nocona"? Корректно ли соберется и корректно ли будет работать в дальнейшем?

[serg_sk]

В теории работать будет. На практике - таким извращением никто не занимается.

Intel Core 2 Duo/Quad / Xeon 51xx/53xx

vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel® Core™2 CPU XXXX @ XXXGHz

32 bit profile (x86)

Код: Выделить всё

CHOST="i686-pc-linux-gnu"
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"

64 bit profile (amd64)

Код: Выделить всё

CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=nocona -O2 -pipe"
CXXFLAGS="${CFLAGS}"

[vfed]

Собирал 32х-битную систему на Athlon64 с "-march=k8". Ничего страшного не случилось

[serg_sk]

Ну я собирал на Intel Core 2 Duo с "-march=k8", оно тоже запустилось, но это изврат.

P.S. Правда собиралось и последующим переносом на Amd ATLON 64 2800+

[DaemonTux]

ИМХО чтобы получить 64 битную систему надо CHOST поправить.

[serg_sk]

DaemonTux, разговор не о битах идет

[vfed]

Имеется в виду, что разрядность определяется не флагом -march, а переменной CHOST

[sveta_067]

Ну я собирал на Intel Core 2 Duo с "-march=k8", оно тоже запустилось, но это изврат.

P.S. Правда собиралось и последующим переносом на Amd ATLON 64 2800+

Ну а в чем изврат.Я год назад собрала на сore 2 duo с "-march=k8".Работает все нормально ,собиралось без ошибок

[serg_sk]

sveta_067, а скажите, какой смысл собирать под другую архитектуру? Лично я просто переносил потом это все на amd64, т.к. на нем собирать не мог. Но чтобы юзать -march=k8 на проце от intel.... изврат, одним словом )

[sveta_067]

sveta_067, а скажите, какой смысл собирать под другую архитектуру? Лично я просто переносил потом это все на amd64, т.к. на нем собирать не мог. Но чтобы юзать -march=k8 на проце от intel.... изврат, одним словом )

Да может конечно и изврат. Пробовала менять на ходу как говорят на ="-march=nocona" - поверьте, ну ничего абсолютно не меняется.

[quadrik]

ИМХО чтобы получить 64 битную систему надо CHOST поправить.

А можно ли менять CHOST на работающей системе (с последующим emerge -e world)? или надо генту ставить заново с 64-х битного стейджа?

[serg_sk]

Можно. Я бы делал так.

Код: Выделить всё

1. Собрал бы ядро с поддержкой 64 бита. Ребут.
2. Меняем CHOST. emerge -e system. Ребут.
3. emerge -e world.

Примерно где-то так.

[vfed]

Я бы не рисковал (разве что ради эксперимента от нечего делать). Сборка заново займёт примерно такое же время

[Civil]

serg_sk
Помоему настолько менять ЦХОСТ нельзя (с i386 на i686 можно, а вот на x86_64 - нет). В конце концов получится что-нибудь вида:
glibc уже 64-х битная, а тот-же баш или перл 32-х битные... Короче проблемы будут и, что-бы так сменить цхост, нужно иметь огромный бубен и запас специальных шаманских танцев, о которых предварительно надо жестоко пытать гугл (если такие танцы вообще существуют).

[RaSla]

Господа, а вопрос такой - что будет, если при установке Gentoo 2007.0 x86 (не amd64!) на машину с процессором Core 2 Duo в make.conf вписать не "-march=prescott", а "-march=nocona"? Корректно ли соберется и корректно ли будет работать в дальнейшем?

Вполне можно.
Работать будет без нареканий, но "чисто теоретически" - чуть медленнее.

Диффиренциал производительности на глаз не заметишь точно,
а с помощью спец-средств - он очень мал.

Оптимизация под последние процы архитектуры x86_32
скорее всего лишь ставит разные приоритеты для Ассемблерных комманд.
(на разных процах некоторые комманды выполняются за разное количество Тактов)

Хотя, хотелось бы надеятся, что и в x86_32 на -march=nocona и -march=k8
используются ВСЕ регистры процессора.
(их там в 16 вместо 8 у 32-битных процов)

На практике, по крайней мере у меня на ноуте,
действительно ВИДНО прирост только в x86_64 системе,
зато даже невооружённым взглядом
(GCC компилит реально раза в 1,5-2 быстрее,
да и код x86_64 весит меньше на 5-7%)

[quadrik]

Можно. Я бы делал так.

Код: Выделить всё

1. Собрал бы ядро с поддержкой 64 бита. Ребут.
2. Меняем CHOST. emerge -e system. Ребут.
3. emerge -e world.

Примерно где-то так.

Фокус не прошел. Ошибки компиляции с жалобой на bad register name

2 vfed:
сборка то заняла то же время, но вот есть ещё время на настройку и трафик на скачку новых стейджев Эх, придется ставить заново

[vfed]

есть ещё время на настройку

Использовать старые /etc и /home никто не запрещает

[serzh-z]

действительно ВИДНО прирост только в x86_64 системе,

О да... Варианты бинарей, чтобы сравнить размер, и цифры по производительности в студию - иначе зобаню за попытку разжигания флейма.

(их там в 16 вместо 8 у 32-битных процов)

И напоследок: учите матчасть...

[serg_sk]

serg_sk
Помоему настолько менять ЦХОСТ нельзя (с i386 на i686 можно, а вот на x86_64 - нет). В конце концов получится что-нибудь вида:
glibc уже 64-х битная, а тот-же баш или перл 32-х битные... Короче проблемы будут и, что-бы так сменить цхост, нужно иметь огромный бубен и запас специальных шаманских танцев, о которых предварительно надо жестоко пытать гугл (если такие танцы вообще существуют).

Все можно если осторожно

[quadrik]

действительно ВИДНО прирост только в x86_64 системе,

О да... цифры по производительности в студию - иначе зобаню за попытку разжигания флейма.

Железо: системный блок, выступающий в роли сервера на материнско плате Intel XBX2. Процессор C2D E6400.
Софт в первом случае - 32 битная генту, полностью пересобранная с -march=prescott. 32-битный 1С 8.1 + Postgresql, собранный с 1с патчами.
Софт во втором случае - 64 битная генту, полностью пересобранная с -march=nocona. Сервер 1С тоже 64-битный.

Тест мы проводили 3 раза на каждой системе. Результат - та же база импортируется на 64-битной системе почти в полтора раза быстрее чем на 32-битной.