LINUX.ORG.RU

Тест по оптимизации


0

0

И опять наши соотечественники провели тесты, на этот раз по использованию ключей оптимизации gcc, и опять весьма любопытные результаты.
Цитат: "Так вот, господа, сидящие за крутейшими "четверками" и Athlon'ами и воображащие себя пожирателями трюфелей и омаров (не обижайтесь, это я и про себя). Вы работаете за PentiumPro. Может быть, даже без инструкций mmx/sse..."

>>> Подробности

anonymous

Проверено: maxcom

Ответ на: комментарий от anonymous

Те кто утверждает что дефолтный RH заточенный под 386 быстрей скажем Gentoo заточенной под P4 - тем самым пытаються утверждать что 386 быстрей P4 :)

anonymous
()

А я всегда говорил что линукс использует возможности апаратуры не более чем на 20%...:)
Правда я и не подозревал что все настолько плохо...

Irsi
()

Приветствую ..
"Сранение результатов" - сильно ...
нет .. ддальше читать не стал .. башка итак болит ...
P.s. А это модно тестировать ?
lame имеет какое-ибо отношение к lam3 ? /MPI/))))
Best respect,$echo.

anonymous
()
Ответ на: комментарий от anonymous

Блин, пересобрать ядро под свои нужды сейчас каждый ламер сможет, всё
уже упаковано как надо, только мышом пару раз тыкнуть и набрать пару
слов в консоли, тем более что в книжках всё разжёвано:

zcat /proc/config.gz > /usr/src/linux/.config
make xconfig
make dep
make bzImage
make modules
make modules_install
mk_initrd
init 6

и Вы "в Хопре" :0)

Я речь веду про SuSE 9.0 в случае если grub установлен.

MrBool
()
Ответ на: комментарий от Irsi

2Irsi:
Ну конечно заточенный под i386 масдай много быстрей заточенный под конкретное железа linux :)
Иди перди куда подальше !

anonymous
()
Ответ на: комментарий от MrBool


Сменил бы он форматирование странички html, что ли... читать невозможно уже на 1024*768...

anonymous
()

опять похоже бухали :)

>>все того же 750-мегабайтного файла

внимание на размер !!!

borisych ★★★★★
()

афигедь

Ну и на фига, к примеру, тому же самому ключастому gcc все эти маму их коромыслом sse2 с мымыхами? Опять пианэры висяляца...

Antichrist
()
Ответ на: комментарий от Irsi

Irsi, чья бы корова мычала :0) Давай расскажи нам сказку про офигительную оптимизацию ядра windows под каждый проц :0) Только хочу сразу предупредить, за такую сказку тебя тут сразу закопают в дерьме ;)

P.S: А отличии от Windows, Linux позваляет себя оптимизировать под КОНКРЕТНОЕ железо, это плюс linux'у и минус windows'у .

MrBool
()
Ответ на: комментарий от MrBool

В этой статье было весьма правильно подмечено, что sse с mmx стоит использовать не всему софту, а только тому, которому это действительно нужно... Так вот - под виндами вся эта мультимедийная фигня их использует и достаточно энергично... А ядру эти инструкции действительно нах не нужны...
И кстати ребята довольно грамотно выбрали софтинку - lame, это тот софт, которому эти инструкции сам диск доктор прописал...:)

P.S. Интересно посмотреть как будут обстоять дела скажем с Ogg Vorbis и GIMP...

Irsi
()

>сидящие за крутейшими "четверками" Я слышал уже "Пни" появились.

anonymous
()
Ответ на: комментарий от Irsi

>А я всегда говорил что линукс использует возможности апаратуры не более чем на 20%...:)
>Правда я и не подозревал что все настолько плохо...
>Irsi (*) (30.10.2003 15:42:29)
Кац всегда предлагал сдацца, предлагал сдацца...

del
()

Итак:
Беру тест linpack из PGI .
беру значения по дефолту для gcc
EXTRA_FFLAGS=-O0
EXTRA_CFLAGS=-O0
производительность
ROLLED DOUBLE PRECISION LINPACK PERFORMANCE 184588 KFLOPS
EXTRA_FFLAGS=-O3
EXTRA_CFLAGS=-O3
ROLLED DOUBLE PRECISION LINPACK PERFORMANCE 572222 KFLOPS
EXTRA_FFLAGS=-O3 -march=i686
EXTRA_CFLAGS=-O3 -march=i686
ROLLED DOUBLE PRECISION LINPACK PERFORMANCE 536468 KFLOPS
проставляю ключики SS /большое Вам спасибо/ s/xp/mp/
http://www.linux.org.ru/profile/_white/view-message.jsp?msgid=415983&scro...
в итоге
ROLLED DOUBLE PRECISION LINPACK PERFORMANCE 715278 KFLOPS
вот такие мухоморы ))))

anonymous
()
Ответ на: комментарий от Irsi

2Irsi >lame, это тот софт... Да ну на...! Качественное и быстрое кодирование (и декодирование - MAD) mp3 - целочисленное с ног до головы, туда sse и 3DNow! не очень-то лепятся. Кстати, а что насчет того, что линуксовые MAD и LAME, рвут своих мастдайных конкурентов ;) Враки?

C-Pro
()

У меня еще более любопытные результаты вылезли на ссылку к источнику

%)

>500 Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request.

>Please contact the server administrator, support@linux-online.ru and inform them of the time the error occurred, and anything you might have done that may have caused the error.

>More information about this error may be available in the server error log.

>Apache/1.3.27 Server at www.linuxshop.ru Port 10000

так что не судьба. Наверное такие ключи оптимизации завернули, что сервак завалили.

OpenStorm ★★★
()

Скажите кто знает, а в исходниках lamo вообще есть инструкции mmx, sse,3dnow или автор статьи полагает что gcc сам их вставлять в код будет?

anonymous
()
Ответ на: комментарий от Irsi

to Irsi:

>А ядру эти инструкции действительно нах не нужны...

Я не стал ключи для gcc ковырять, просто включил поддержку для P4 в
ядре ( http://www.linux.org.ru/view-message.jsp?msgid=408492&scroll=section&... )
и Windows XP Professional сразу стала отдыхать :0)

>И кстати ребята довольно грамотно выбрали софтинку - lame, это тот
>софт, которому эти инструкции сам диск доктор прописал...:)

Не нравится performance бери оптимированное
http://packman.links2linux.de/index.php4?action=017 , а то что Федорчук
фигнёй страдает, так это его трудности :0)
А теперь скажи где мне взять MS Office 2000 оптимированный под P4 ;)

>P.S. Интересно посмотреть как будут обстоять дела скажем с Ogg Vorbis
>и GIMP.

Нормально будет обстоять :0)

MrBool
()
Ответ на: комментарий от anonymous

-

>в итоге >ROLLED DOUBLE PRECISION LINPACK PERFORMANCE 715278 KFLOPS >вот такие мухоморы ))))

Маленькая ремарка -msse и -msse2 будут в данном случае (DOUBLE PRECISION) иметь смысл только для P4 и x86-64 (info gcc)

PS: я вообще не понимаю зачем каким то лузерам (прости-хосподи) с какого-то линухшопа заморачиваться какими то ключами - не лузерское это дело а девелоперовское а лузеры пусть багрепорты шлют а не изображают из себя злобных буратин ;)

sS ★★★★★
()
Ответ на: - от sS

2SS )))
шарю sse && sse2 под Intel -) Конец рабочего дня у нас в Новосибирске.
но хуже от этого не стало )
2All приятного вечера)

anonymous
()

Только полные дятлы тестируют что-то там при помощи lame, скорость кодирования которого зависит практически только от частоты процессора. Практически линейно.

anonymous
()
Ответ на: комментарий от OpenStorm

Так, надоело. Методика тестирования у автора - это что-то. На основе частного делать предположения об общем. Даже порой не разобравшись в частном.
Читаем ман по gcc. По поводу ключей -mmmx -msse -m3dnow.
These switches enable or disable the use of built-in functions that allow direct access to the MMX, SSE and 3Dnow extensions of the instruction set.
Так что, если кодер не использует эти возможност в коде, то никакой компилятор не поможет, хоть обложись этими ключами. Впрочем, за одним исключением.
To have SSE/SSE2 instructions generated automatically from floating-point code, see -mfpmath=sse.
А вот он, действительно сумеет ускорить работу с нецелыми.
Не буду приводить выдержку из мана, она очень большая, но смысл в том, что есть 3 опции у этого ключа: "387", "sse" и "sse,387". С первой все понятно, все плавающие считаюцца в 80 бит (пофигу что это, флоат или экстендед), ускоряецца i387-мыми инструкциями. А вот со вторым интереснее, он ускоряет только float, но не double и не extended. Это объясняет падение производительности в последнем тесте. Поэтому надо было попробовать третий вариант. Кроме того, что-то мне подсказывает, что у атлонов sse - не сильная сторона. :)
Интересный у автора подход к выставлению флагов. "А вот на Хоботе говорят, что кому-то сказали, что у кого-то...". Это я про -funroll-loops.
Хотя, надо отдать должное автору, в конце статьи он все-же оговорился, что такое поведение может быть специфично именно данному коду. Ну и на том спасибо. :)

del
()
Ответ на: комментарий от del

Хм, пока ответ писал, уже успели добавицца аналогичные комментарии...

del
()
Ответ на: комментарий от MrBool

MrBool: я очень смутно понимаю что значит "поддержка Р4 в ядре"... В чем конкретно эта поддержка заключается, просвяти...

Ну тыб еще Office97 вспомнил... Нынче рулят танковые клинья, ковровые бомбардировки, тактическое ядерное оружие и Office 2003 ;)

Нормально гришь будет обстоять? Ню-ню... Чем-то мне это напоминает известный диалог програмера и технического писателя:
- Какой интефейс пользователя у Ваше программы?
- В стиле Unix! (гордо так...)
- Понял, пишем - "Интерфейс пользователя отсутствует". :)

Irsi
()
Ответ на: комментарий от Irsi

С GIMP - никак. Тут даже супер-пупер-гениальный оптимизатор не найдёт, куда SIMD-ы воткнуть. Так уж оно писано...

Да и вообще - Цэ - язык слишком уж низкоуровневый для того, чтоб подобные оптимизации были эффективными - требует уж больно много интеллекта от компилятора.

Antichrist
()
Ответ на: комментарий от del

>Читаем ман по gcc. По поводу ключей -mmmx -msse -m3dnow.
>These switches enable or disable the use of built-in functions that allow direct
>access to the MMX, SSE and 3Dnow extensions of the instruction set.
>Так что, если кодер не использует эти возможност в коде, то никакой
>компилятор не поможет, хоть обложись этими ключами. Впрочем, за одним
>исключением.

Вот, вот, но пионеры не верят, они считают, что компилятор сам вставит
нужный код для этих экстеншенов....:))) Сказочники мля....

McMCC ★★★
()

Было бы интересно, если бы уважаемый "тестер" после каждого теста
с ключами делал бы перезагрузку системы, а потом бы опять выложил свои
результаты....:)))))))))))))))

McMCC ★★★
()
Ответ на: комментарий от Antichrist

-

>Да и вообще - Цэ - язык слишком уж низкоуровневый для того, чтоб подобные оптимизации были эффективными - требует уж больно много интеллекта от компилятора.

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

sS ★★★★★
()
Ответ на: комментарий от anonymous

>Скажите кто знает, а в исходниках lamo вообще есть инструкции mmx, sse,3dnow или автор статьи полагает что gcc сам их вставлять в код будет?

Ты про какие инструкции в тексте Lame он же не на асме написан ИМХО gcc сам должен их генерить когда решает что это увеличит производительность иначе как бы одни и те жи исходники компились на 486 и на p4 думай перед тем как писать

anonymous
()
Ответ на: комментарий от McMCC

-

2McMCC

>Было бы интересно, если бы уважаемый "тестер" после каждого теста >с ключами делал бы перезагрузку системы, а потом бы опять выложил свои >результаты....:)))))))))))))))

Ну для первого приближения достаточно положить тесты на отдельный диск (можно даже на loop) и перед кажным тестом делать umount/mount (шоб прибить инодный и буферный кеши) ну а подгрузкой разделяемых библиотек наверное можно будет пренебречь - они с высокой долей вероятности уже будут загружены в память ....

sS ★★★★★
()
Ответ на: комментарий от Irsi

>Нормально гришь будет обстоять? Ню-ню... Чем-то мне это напоминает известный диалог програмера и технического писателя:
>- Какой интефейс пользователя у Ваше программы?
>- В стиле Unix! (гордо так...)
>- Понял, пишем - "Интерфейс пользователя отсутствует". :)
- Какие у вас есть навыки работы с компьютером?
- Навык работы в виндовс (гордо так...)
- Понял, пишем - "Навыки работы с компьютером отсутствуют". :)

ЗЫ.
Что-то распиcАлся я сегодня...

del
()
Ответ на: комментарий от anonymous

>Ты про какие инструкции в тексте Lame он же не на асме написан ИМХО gcc сам должен их генерить когда решает что это увеличит
>производительность иначе как бы одни и те жи исходники компились на 486 и на p4 думай перед тем как писать
Тааак... Вот еще один умник. Тут уже обсудили, что для поддержки ммх, 3д-прямо-счас и т.д. нужна поддержка в коде. А именно должны вызывацца специальные функции.
Вот читаем хотя-бы тут http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Vector-Extensions.html#Vector%20Ext...
И вот тут http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/X86-Built-in-Functions.html#X86%20B...
.

del
()
Ответ на: комментарий от Irsi

to Irsi :

>я очень смутно понимаю что значит "поддержка Р4 в ядре", В чем
>конкретно эта поддержка заключается, просвяти...
>Ну тыб еще Office97 вспомнил... Нынче рулят танковые клинья,
>ковровые бомбардировки, тактическое ядерное оружие и Office 2003 ;)

Я так понял ты решил постебаться ? Ню-ню, сегодня без меня ;)

MrBool
()
Ответ на: комментарий от del

>Тааак... Вот еще один умник. Тут уже обсудили, что для поддержки ммх, 3д-прямо-счас и т.д. нужна поддержка в коде. А именно должны вызывацца специальные функции. Вот читаем хотя-бы тут http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Vector-Extensions.html#Vector%20Ext... И вот тут http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/X86-Built-in-Functions.html#X86%20B...

Возникает вопрос как такой код будет компилится другими компиляторами придерживающимеся ISO и будет ли

anonymous
()
Ответ на: комментарий от anonymous

Наверно так же, как код visual C на gcc - никак.
Что за тупой вопрос?

jackill ★★★★★
()
Ответ на: комментарий от anonymous

Ну да - теоретически gcc его соберет и на другой платформе (если под нее
поддержка есть). Практически слегка подогнут напильником.

jackill ★★★★★
()
Ответ на: комментарий от anonymous

>Возникает вопрос как такой код будет компилится другими компиляторами придерживающимеся ISO и будет ли
В стандарте С этого нет. Или мне об этом ничего не известно. Если у других компиляторов функции называюцца так-же, то работать будет. Выеснять так ли это, надо в ./configure . Наверное, нормальный вариант, если это не поддерживаецца компилятором ставить свои функции с такими-же именами в блоке #ifndef..#endif

>И где же пресловутое обстрагирование от железа всякие там POSIX переносимость и тд
Что такое "обстрагирование"? А!!! Это Оптимизация и Абстрагирование!
Ну, во-первых, Вам шашечки или ехать?
Во-вторых, никто абстрагирования с оптимизацией в С не обесчал. На это еще Страуструп, АФАИР, жаловался.
В-третьих, а как Вы теоретически это себе представляете?

del
()
Ответ на: комментарий от Irsi

>В этой статье было весьма правильно подмечено, что sse с mmx стоит использовать не всему софту, а только тому, которому это действительно нужно... Так вот - под виндами вся эта мультимедийная фигня их использует и достаточно энергично...

И прекрасно работает там, где этих функций нет?

Ikonta_521
()
Ответ на: комментарий от anonymous

>Хм... а зачем тогда gimp1.3 радостно сообщает о том, что нашел/не нашел SSE и MMX?
Чтобы использать/не использовать вот эти хреновы built-in функции.

del
()
Ответ на: комментарий от Irsi

>Ну тыб еще Office97 вспомнил... Нынче рулят танковые клинья, ковровые бомбардировки, тактическое ядерное оружие и Office 2003 ;)

Не тактическое, а стратегические ракеты, с разделяемыми ядерными боеголовками.

И как там в Excel 2003 дела обстоят? Он уже научился сохранять таблицы содержащие больше 32000 строк?

>Нормально гришь будет обстоять? Ню-ню... Чем-то мне это напоминает известный диалог програмера и технического писателя:

LOL

Ikonta_521
()

А почему все на инструкциях зациклились с точки зрения оптимизации ? IMO - кэш не менее важную роль играет в этом деле, по крайней мере - учет размера его строки в создаваемых структурах данных...

Flanker521
()

А почему все на инструкциях зациклились с точки зрения оптимизации ? IMO - кэш не менее важную роль играет в этом деле, по крайней мере - учет размера его строки в создаваемых структурах данных...

Flanker521
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.