Интересно,можно будет этот LinuxBIOS поставить вместо Phoenix?А то на M2N-E очень глючный биос.

Ура товирищи! Я думаю с такой тенденцией, под лялих таки будет в ближайшем будущем нормальная поддержка производителей железа, ибо выхода у них уже не останется... :)

> на 1,8Ггц на 64битном Оптероне скорость в 2 раза большую нежели чем time ./super_proga на 3.2Ггц P4 Intel

Это так, но P4 давно морально мертв, под интелем подразумевается c2d.

жалко что для интелей такого нет... :-(

offtopic: x86_64 versus x86

> В "обычную" сборку i686 не включается даже MMX.

RTFM

> На деле, x86_64 должно быть чуть-чуть медленнее из-за необходимости
> использования для адресации 64 бит и, соответственно, излишка перекачки
> информации из памяти.

С точностью до наоборот, т.к.
1) регистров у x86_64 "немножечко" побольше
2) стандартный ABI позволяет возвращать struct и union через регистры
(когда это возможно).

> Кроме того, можно бы сравнить выполнения стандартного теста (sql-bench)
> от MySQL 5.0.x (ядро 2.6.20.1 64 битное,

С какого бодуна этот самый sql-bench стал "стандартным тестом"?

> Улыбнуло ;) info gcc однако

Воспользуйтесь собственным советом! Возможно, в таком случае вы узнаете, чем отличается "i686, pentiumpro" от "pentium2".

2Dimez:

Кстати, видимо, NVidia NCQ было испорчено в 2.6.19. Ядро 2.6.20.1 нарисовало NCQ Depth 31/32.

>RTFM

MAN GCC!!!!!!

>1) регистров у x86_64 "немножечко" побольше

Зато данных из память читать тоже "немножечко" побольше придется.

>2) стандартный ABI позволяет возвращать struct и union через регистры (когда это возможно).

-finline-fuctions входит в -O3 независимо от платформы.

>С какого бодуна этот самый sql-bench стал "стандартным тестом"?

было написано "стандартного теста (sql-bench) от MySQL ...". Почувствуйте разницу.

Не хотелось бы ловить вас на подтасовке, но придется. В GCC значение имеет последний указанный модификатор. То есть, если вы делаете "-mno-sse -msse", то SSE в итоге будет включен.
>g++ -s -O2 -march=k8 -pipe -DNDEBUG mi.cpp -o mi.x -lm

man gcc. "-march=k8" автоматически подставит "-msse -msse2 -m3dnow" и для 64-битной системы "-m64". Итог: "-s -O2 -m64 -msse -msse2 -m3dnow -pipe -DNDEBUG".

>g++ -s -O3 -ffast-math -msse2 -msse3 -march=k8 -pipe -DNDEBUG mi.cpp -o mi.x -lm

man gcc. Использование "-ffast-math" дает некорректные результаты с _ЛЮБЫМ_ "-O". "-msse2" включать было ненужно (включилось бы по умолчанию). "-msse3" k8 не умеет (разве что в режиме эмуляции? какой там cpuflags? есть "pni"?). Истог: "-s -O3 -ffast-math -msse3 -m64 -msse -msse2 -m3dnow -pipe -DNDEBUG".

>g++ -s -O3 -ffast-math -msse -mno-sse3 -mno-sse2 -march=k8 -pipe -DNDEBUG mi.cpp -o mi.x -lm

man gcc. "--ffast-math" некорректно. "-msse -mno-sse3 -mno-sse2 -march=k8" даст в итоге "-m64 -msse -msse2 -m3dnow". Итог: "-s -O3 -ffast-math -m64 -msse -msse2 -m3dnow -pipe -DNDEBUG".

Результаты 2 и 3 тестов должны были бы быть ОДИНАКОВЫМИ по модели работы GCC (+/- несколько микросекунд на обработку прерываний). А у вас разница в 412 мс., что сравнимо с 1/3 времени исполнения теста.

Вывод: подтасовка результатов.

>Да?.. Удивительно. А у меня 4-й Nforce SLI и все в пределах нормы - перегрева не замечал.

Они действительно порядочно греются. На асус а8н-е температура может и до 70 доходить. А на 570/590 чипсетах практически все производители ставят пассивное охлаждение. На асус м2н-е палец невозможно удержать на чипе, но нвидия говорит что это нормально.

По поводу биоса. Стоит ли его ставить? Обеспечит ли он туже функциональность по настройкам и по разгону что родной гигабайтовский? И можно ли родной будет обратно возвернуть после прошивки на линукс-биос?

>Вывод: подтасовка результатов.

Моё:

ed@ed-desktop:~/mi$ g++ -s -O2 -march=k8 -pipe -DNDEBUG mi.cpp -o mi.x -lm
ed@ed-desktop:~/mi$ time cat par | ./mi.x > /dev/null

real 0m3.731s
user 0m3.380s
sys 0m0.028s
ed@ed-desktop:~/mi$ g++ -s -O3 -ffast-math -msse2 -msse3 -march=k8 -pipe -DNDEBUG mi.cpp -o mi.x -lm
ed@ed-desktop:~/mi$ time cat par | ./mi.x > /dev/null

real 0m1.560s
user 0m1.468s
sys 0m0.016s
ed@ed-desktop:~/mi$ g++ -s -O3 -ffast-math -msse -mno-sse3 -mno-sse2 -march=k8 -pipe -DNDEBUG mi.cpp -o mi.x -lm
ed@ed-desktop:~/mi$ time cat par | ./mi.x > /dev/null

real 0m1.536s
user 0m1.440s
sys 0m0.016s
ed@ed-desktop:~/mi$ uname -a
Linux ed-desktop 2.6.20-8-386 #2 Tue Feb 13 05:15:43 UTC 2007 i686 GNU/Linux
ed@ed-desktop:~/mi$ cat /proc/cpuinfo | grep MHz
cpu MHz : 1406.881

Забыл сказать, что проц 64-битный.

ed@ed-desktop:~/mi$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 44
model name : AMD Sempron(tm) Processor 2500+
stepping : 2
cpu MHz : 1406.881
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm ts ttp tm stc
bogomips : 2815.53
clflush size : 64

Афтар, иди в жопу! Замучил своими проинтелевскими бреднями. И читать
`man gcc` научись, особенно в секции про "-ffast-math" и как оно на
самом деле вяжется с "-Oх" (даже подсказку дам - оно не должно
включаться этим "-Ох", потому как ломает стандарт, а вовсе не из-за
"выдачи некорректного результата" - небось аффтары mplayer и libxine
на входе из /dev/random данные цепляют, ага, а на выходе чудесным
образом видяшки играют).

Пажалста, по второму разу, для пущей корректности вообще все почти
одинаково сделаем:

darkstar src # g++ -s -O2 -march=k8 -funroll-loops -ffast-math -msse -msse2 -msse3 -pipe -DNDEBUG mi.cpp -o mi.x -lm
darkstar src # time cat par | ./mi.x > /dev/null 

real    0m1.749s
user    0m1.750s
sys     0m0.000s

darkstar src # g++ -s -O2 -march=k8 -funroll-loops -ffast-math -msse -mno-sse2 -mno-sse3 -pipe -DNDEBUG mi.cpp -o mi.x -lm
darkstar src # time cat par | ./mi.x > /dev/null 

real    0m1.389s
user    0m1.390s
sys     0m0.000s

darkstar src # g++ -s -O3 -march=k8 -funroll-loops -ffast-math -msse -msse2 -msse3 -pipe -DNDEBUG mi.cpp -o mi.x -lm
darkstar src # time cat par | ./mi.x > /dev/null 

real    0m1.271s
user    0m1.260s
sys     0m0.020s

darkstar src # g++ -s -O3 -march=k8 -funroll-loops -ffast-math -msse -mno-sse2 -mno-sse3 -pipe -DNDEBUG mi.cpp -o mi.x -lm
darkstar src # time cat par | ./mi.x > /dev/null 

real    0m0.947s
user    0m0.940s
sys     0m0.010s

И если ты такой "умный", что у p4-3.0 для тебя быстрее амд64,
и гцца должна работать не так как выдаёт на самом деле, а как
ты сказал - это всё не мои проблемы.

>Афтар, иди в жопу!

Я уступлю даме очередь.

>И читать `man gcc` научись, особенно в секции про "-ffast-math" и как оно на самом деле вяжется с "-Oх" (даже подсказку дам - оно не должно включаться этим "-Ох", потому как ломает стандарт, а вовсе не из-за "выдачи некорректного результата" - небось аффтары mplayer и libxine на входе из /dev/random данные цепляют, ага, а на выходе чудесным образом видяшки играют).

Я таки считаю мудаками всех, кто -ffast-math включает. Результат действительно генерируется некорректный. Аффтары Mplayer, libxine, quake2 (кто-там еще?) знают, что они делают: им точность особенная не нужна (ну промелькнет какой-то пиксель на отдельно взятом кадре - нестрашно, а код получается более быстрым). А тут вы пытаетесь считать функции, существующие в пределах от -1 до 1 (sin и cos). И точность вычислений таки что-то в данном случае значит.

2eduard_pustobaev
2Gharik

Кстати, как насчет sql-bench все-таки, а?

> Я таки считаю мудаками всех, кто -ffast-math включает. Результат
действительно генерируется некорректный. Аффтары Mplayer, libxine,
quake2 (кто-там еще?) знают, что они делают: им точность особенная не
нужна (ну промелькнет какой-то пиксель на отдельно взятом кадре -
нестрашно, а код получается более быстрым). А тут вы пытаетесь считать
функции, существующие в пределах от -1 до 1 (sin и cos). И точность
вычислений таки что-то в данном случае значит.

Уговорил, о сладкоречивый, считай себе на здоровье. Только тебе, дядя, 
не кажется (хинт - глянь в исходник), что заранее известная, потому
как прямо заданная, точность счёта (float) вполне позволяет таки
задействовать "-ffast-math", э? И если аффтар самой проги (не _мы_)
так написал - то наверное ему всё же виднее, что его устроит, э?

darkstar src # g++ -s -O3 -march=k8 -funroll-loops -msse -msse2 -msse3 -pipe -DNDEBUG mi.cpp -o mi.x -lm
darkstar src # time cat par | ./mi.x > test1     

real    0m1.164s
user    0m1.160s
sys     0m0.000s
darkstar src # g++ -s -O3 -march=k8 -funroll-loops -msse -mno-sse2 -mno-sse3 -pipe -DNDEBUG mi.cpp -o mi.x -lm
darkstar src # time cat par | ./mi.x > test2

real    0m1.264s
user    0m1.270s
sys     0m0.000s

darkstar src # diff test1 test2 
darkstar src # 

Из чего ясно видно, что выигрыш мы таки получаем, но не такой большой
как в первоначальном раскладе. Что неоптимально в данном конкретном случае.

> Кстати, как насчет sql-bench все-таки, а?

Впадлу, у меня дома на всей стойке mysql напрочь отсутствует. Можешь сам приложить чуток усилий ;)

>на 570/590 чипсетах практически все производители ставят пассивное охлаждение

У меня с тепловыми трубками от обоих мостов в район сокета камня на доп. радиаторы (там охлаждаться проще - сверху БП с d120 кулером, сзади - еще один кулер d120).

Вот просто из прикола сделал только что make oldconfig (2.6.20.1) у себя:

time make -j1000 bzImage
...
real: 3m4.676s
user: 5m23.888s
system: 0m33.410s

Температуры:
камень: 32С/89.5F
чипсет: 45C/113F

И кто сказал, что P-D 3.6GHz греется?

Intel, тем что вернулась на архитектуру P3 :)

>Воспользуйтесь собственным советом! Возможно, в таком случае вы узнаете, чем отличается "i686, pentiumpro" от "pentium2".

Мля забодали "спецы-оптимизаторы" я уже пример приводил... кури пример http://www.linux.org.ru/jump-message.jsp?msgid=1789041#1790113 ну и само собой info gcc, хоть обвставляйся -mmmx - НЕ БУДЕТ ГЕНЕРИТСЯ MMХ код _АВТОМАТОМ_, будут доступны встроенный функции gcc с использованием MMX. Их надо будет тебе самому как _программеру_ юзать. Вот тогда будет MMX То же самое с 3dnow!. А вот SSE(2/3) уже будет генерироваться автоматом при соответствующем -fpmath=... ну или также вручную встроенные функции можно...

>man gcc. Использование "-ffast-math" дает некорректные результаты с _ЛЮБЫМ_ "-O"

Чё за бред про "некорректные результаты" ?

Идите-ка info gcc и курите что в себя включает -ffast-math

Нужно прежде думать головой и читать info gcc перед тем как код писать.

При нормально написаном алгоритме результаты получаются 1:1

PS: Я иногда понимаю людей, которые распространяют бинарники а не исходники.... шоб никто свои ручки к ним не тянул с целью "оптимизации" а потом кричал бы про кривизну кода.

А что насчёт sql-бенча? Что мне с чем сравнивать?

Домашняя тачка, процессоры тоже по полу не валяются.:)

> Зато данных из память читать тоже "немножечко" побольше придется.

Ровно столько же. double и float везде одинаковые: 32 бита и 64 бита,
соотв.. (раз уж речь о вычислениях с плавающей точкой).


> >2) стандартный ABI позволяет возвращать struct и union через регистры (когда это возможно).

> -finline-fuctions входит в -O3 независимо от платформы.

Во-первых, за -O3 следует вообще в gaswagen отправлять. По сути эта
опция существует исключительно для тестирования самого компилятора.
А во-вторых, при чем тут inline?

`-freg-struct-return'
Return `struct' and `union' values in registers when possible.
This is more efficient for small structures than
`-fpcc-struct-return'.

If you specify neither `-fpcc-struct-return' nor
`-freg-struct-return', GCC defaults to whichever convention is
standard for the target. If there is no standard convention, GCC
defaults to `-fpcc-struct-return', except on targets where GCC is
the principal compiler. In those cases, we can choose the
standard, and we chose the more efficient register return
alternative.


Так вот у x86 стандарт -fpcc-struct-return, а у x86_64 -- -freg-struct-return