|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Alex Korchmar 2:5020/400 14 Jun 2006 19:46:41
To : Sergey Rogulev
Subject : Re: FC5 тормозит
--------------------------------------------------------------------------------
Sergey Rogulev <Sergey.Rogulev@p13.f7.n5031.z2.fidonet.org> wrote:
AK>> Hо если давать советы уровня приложения напильников - я бы употреблял
AK>> оптимизацию как раз вида -O2 -fomit-frame-pointer -funroll-loops
AK>> а как раз про mtune бы и не вспомнил, а вспомнил бы - так написал бы
AK>> -march=pentium.
SR> ну и зря. согласно ману, mtune включает в себя march
ровно наоборот.
`-march=CPU-TYPE'
Generate instructions for the machine type CPU-TYPE. The choices
for CPU-TYPE are the same as for `-mtune'. Moreover, specifying
`-march=CPU-TYPE' implies `-mtune=CPU-TYPE'.
info gcc 3.4.4
mtune - HЕ включает ABI специфического процессора - т.е. mtune pentium
не порождает кода, не идущего на любой 386-compilant архитектуре.
AK>> почему бред? Эта инструкция действительно иногда помогает выдавить
AK>> секунды, но собирать с ней всю систему я бы, пожалуй, не рискнул.
SR> разве на счетных задачах или обработке массивов данных. для
ну а что есть в широком смысле графика и инет как не счетная задача да
обработка массивов данных. Только как раз счетную задачу я бы так
оптимизировать не стал - если там есть (важные для результата)
loop'ы нуждающиеся в разворачивании - автору надо было выпить яду.
А вот строковую - стал бы, потому что там могли пожертвовать
эффективностью ради читаемости кода.
AK>> BTW, я надеюсь ты в курсе, что оптимизации выше 3 реально существовали
AK>> только в pgcc, пять лет уже мертвом?
SR> дык. хотя при желании каждый пионер себе под этот ключ много чего может
SR> насовать... в сырцах все прозрачно.
кстати уже нет. с 3.4.4 прозрачно быть перестало. (я как раз сходил
посмотреть в toplev.c, не придумали ли там что-то о чем я еще не в
курсе, а там все стало то-о-о-онким слоем размазано)
AK>> Ой, только сейчас дошло - у тебя каким-то чудом еще и ВЫРОС размер от
AK>> применения omit-frame-pointer. IMHO, тебе надо разбираться, каких
AK>> ключей ВМЕСТО твоих насовал тебе makefile/скрипты/окружения или еще
AK>> что.
SR> не прошло и месяца как Алекс это заметил ;) действительно вырос.
SR> и ты знаешь, я к этому давно привык. он у меня еще с не к ночи
может фича именно атлоновского оптимизатора?
Только это багофича. Так быть не должно ни в каком раскладе.
AK>> тебя оказывается БОЛЬШЕ. Либо ты перепутал параметры, либо в gcc 3.4
AK>> просто есть явный баг в оптимизаторе (не очень, честно говоря,
AK>> верится)
SR> на 4.0 и 4.1 те же яйтся. можно конечно поплотнее проверить, но оно у меня
пошел проверять, заодно посмотреть что там наслесарили в ffmpeg
-rw-r--r-- 1 alx 80924 Jun 14 19:29 ffmpeg-o2.o
-rw-r--r-- 1 alx 80660 Jun 14 19:29 ffmpeg-o2-omf.o
-rw-r--r-- 1 alx 84564 Jun 14 19:30 ffmpeg-o2-omf-p4.o
-rw-r--r-- 1 alx 84620 Jun 14 19:30 ffmpeg-o2-p4.o
-rw-r--r-- 1 alx 82940 Jun 14 19:29 ffmpeg-o3.o
-rw-r--r-- 1 alx 86924 Jun 14 19:30 ffmpeg-o3-p4.o
-rw-r--r-- 1 alx 86900 Jun 14 19:31 ffmpeg-o3-p4-omf.o
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)
SR> у меня с O2 однозначно больше получается. всегда. вот o2 omf не пробовал -
что еще более странно. Все, что включает O3, ведет к увеличению кода.
Hе может не вести. К ускорению оного кода - возможно, но необязательно.
SR>>> все собрано с mtune=pentium4 (повбЫвав бы...), то нет. они
AK>> а что в этом плохого?
SR> в том что как минимум сендмейл после этого на п1-2 падает в кору...
что тоже странно, повторяю - abi - это march, mtune pentium от pentium4 вообще
непонятно чем должен отличаться, разьве что align'ами по 16 вместо 8.
AK>> (почему не надо современный дистрибутив собирать с mtune=i386,
AK>> надеюсь, понятно?)
SR> нет, непонятно.
потому что архитектура 386-го камня _абсолютно_ другая, он был
последним в серии честным CISC процессором, а не тормозным программным
эмулятором оного (pentium и последыши, сейчас - вообще все процессоры)
на базе чахоточного недоrisc-процессора с r не только is, но и
регистрами обделенного. Соответственно проигрыш производительности может быть
в наихудшем сферичном в вакууме случае в РАЗЫ, а не на проценты.
Достаточно вспомнить о существовании чудо-команды LEAVE.
SR> дистр должен по крайней мере на объявленной платформе (а она -
SR> i386 однако) нормально работать.
бяда в том что на ней современное ядро (сюрприз) даже не заводится.
А где-то в районе 2.4 поломать ухитрились даже 486-ю совместимость
(потом, правда, вроде бы восстановили обратно - но мне уже не на чем проверить)
SR> второе. а ключей там всего-то -O2 -mtune=pentium4 (причем на все архитектуры
SR> от 386 до 686)
да, на всякий случай мои ключи:
gcc -O3 -mtune=pentium4 -Wdeclaration-after-statement -Wall -Wno-switch \
-I. -I. -Ilibavutil -Ilibavcodec -Ilibavformat -D_FILE_OFFSET_BITS=64 \
-D_LARGEFILE_SOURCE -D_GNU_SOURCE -c -o ffmpeg-o3-p4.o \
ffmpeg.c
ffmpeg.c взят из репозитория прямо сейчас вместе с прочими потрохами.
19:20 MSD. revision самого файла 5416 (чорт бы взял
эту svn и ее безмозглых аффтаров и убил бы их всех ап стену)
SR> (пожимая плечами) все может быть. какнть попробую проверить.
SR> однако юмор в том, что насколько я помню оно так было всегда.
SR> и от дистра не зависит (разные пользовал). возможно зависит от
SR> конкретной софтины...
возможно софтина действительно непоказательна, а возможно abi такой
- мне лень проверять amd-шную гипотезу - нету тут их ни одного.
> Alex
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
