LINUX.ORG.RU
Форум — Development  

Разбить процы на группы.


0

0

Доброго времени суток!
Столкнулся с проблемой, которую пока непонятно как оптимально решить. Итак,
есть программа на С, которая в основном занимается тем, что выполняет
вычисления с плавающей точкой. Время ее работы критично и поэтому приходится
крутить параметры компилятора на предмет оптимизаций под определенные
процессоры. Hо процессоров разных много, а пользователям хотелось бы
продложить на выбор не более 4-5 разных бинарников, оптимизированных под
разные _группы_ процов. Вот тут и возникает проблема, как составить такие
группы.

Если просмотреть на возможные значения параметра -march в gcc-4.3, то там их
приличное количество: i386,i486,i586,
pentium,pentium-mmx,pentiumpro,i686,pentium2,pentium3,
pentium3m,pentium-m,pentium4,
pentium4m,prescott,nocona,core2,k6,k6-2,k6-3,athlon, athlon-tbird,athlon-4,
athlon-xp, athlon-mp,k8, opteron, athlon64, athlon-fx,k8-sse3, opteron-sse3,
athlon64-sse3,amdfam10, barcelona,winchip-c6,winchip2,c3,c3-2,geode.

Все они, как я понимаю, различаются в том числе наборами инструкций и может
получиться так, что собрав прогу для одного проца, она не запустится на
другом.
Мне же нужно, чтобы определенная версия проги гарантированно запустилась на
процах определенной группы и про этом была оптимизированна для них. Hо не
совсем понятно какой критерий выбрать для разбивки процессоров на гуппы.
Видимо нужно смотреть, какие поддерживаются наборы инструкций (SSE, SSE2,
etc?), полезных для работы с числами с плавающей точкой?

По крайней мере одну группу я знаю как составить точно - это процы с x86
набором без расширений (или с ММХ). Бинарник с такими инструкциями запустится
на всём чём угодно.

Возможно еще одну группу можно составить по критерию поддержки набора SSE2?
Просто SSE мне не годится, так как в проге используются только double числа.

Что скажете?

anonymous
← Выбор DVCS
QTextEdit - как сделать возможность добавления вложенных списков? →

Я не программист, но вроде можно добавить обратную совместимость и не заморачиваться. + http://gentoo-wiki.com/Safe_Cflags немного в тему. Там правда не жеская оптимизация а именно Safe_Cflags - рабочие флаги грубо говоря.

calculator
()

Многие другие компиляторы, не GCC, умеют создавать бинарники, где содержится код как с использованием SSE, так и без.

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

Возможно, даже без специальных компиляторов, можно собрать несколько раз один и тот же код с разными опциями (пусть даже gcc?), и добавить autodetect-модуль, который будет на runtime подключать нужный из них. Подозреваю, что этот велосипед уже придуман. Mplayer ведь работает ;)

Тем самым и себя избавить от головной боли "выяснить всё заранее и достоверно", и пользователя - от мыслей "правильный ли я взял бинарник".

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

> Я не программист, но вроде можно добавить обратную совместимость и не заморачиваться. + http://gentoo-wiki.com/Safe_Cflags немного в тему. Там правда не жеская оптимизация а именно Safe_Cflags - рабочие флаги грубо говоря.

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

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

> Многие другие компиляторы, не GCC, умеют создавать бинарники, где содержится код как с использованием SSE, так и без.

icc так делает. Но на AMD процах собранные им проги будут работать без использования SSE даже если проц их поддерживает. А под Linux у меня нет другого выбора кроме gcc и icc.

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

> Возможно, даже без специальных компиляторов, можно собрать несколько раз один и тот же код с разными опциями (пусть даже gcc?), и добавить autodetect-модуль, который будет на runtime подключать нужный из них. Подозреваю, что этот велосипед уже придуман. Mplayer ведь работает ;)

> Тем самым и себя избавить от головной боли "выяснить всё заранее и достоверно", и пользователя - от мыслей "правильный ли я взял бинарник".

Это возможно хорошая и подходящая идея. Если бы можно было просто без заморочек запихать все это в один бинарник. Уж больно не хочется возиться с динамическими либами. Ссылку бы на такой материал.. А ковырять MPlayer - это самый последний вариант для меня.

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

Честно говоря, никогда этим не занимался. Но не думаю, что нужна динамическая линковка.

Насчёт ковыряться в mplayer'е, лично для меня проще (быстрее) посмотреть, как это сделано в конкретном продукте, чем гуглить, а потом читать неизвестно что неизвестно где. Вот берём mplayer-1.0_rc2_p25993, распаковываем сорцы. Делаем поиск (в mc) по строке "sse2". Смотрим на почти первую же ссылку:

cpudetect.c:143 (в функции GetCpuCaps)

и, чуть позже,

libavcodec/i386/mpegvideo_mmx.c:723 и в той же папке cputest.

Считаем, что качественный ответ на твой вопрос получен: видим и механизм определения типа процессора, и заветный if(), который, в зависимости от типа проца, выбирает, какую функцию вызвать. Вроде как, безо всякой динамической линковки. Далее спрашиваем тебя - что ещё надо?

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

> Считаем, что качественный ответ на твой вопрос получен: видим и механизм определения типа процессора, и заветный if(), который, в зависимости от типа проца, выбирает, какую функцию вызвать. Вроде как, безо всякой динамической линковки. Далее спрашиваем тебя - что ещё надо?

Спасибо, посмотрел, оказалось полезным и познавательным. А с определением проца у меня не было проблем.

Rarruga
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Выбор DVCS
Development
QTextEdit - как сделать возможность добавления вложенных списков? →