Russian Qt Forum

Добрый день

Есть open-source приложение исходники которого решено задействовать. Приложение действительно показывает чудеса скорости за счет использования инструкций SSE. Однако при этом не видно никаких попыток разрулить SSE автоматом, при установке (ccmake) пользователю предлагается самому ввести. Напр по умолчанию SSE4.2, но собранное с ним приложение не работает на моей машине - нужно SSSE3, тогда все норм.

Можно накомпилить либов (по 1 на каждый тип SSE) и потом в runtime подсовывать нужную, но грамотно ли так делать? Вероятно проблема типовая, кто сталкивался - поделитесь опытом.

Спасибо

Сам такое не писал,но часто работал с мультимедийными программами (типа рипперов, кодеков и т.п.). Там часта ситуация, когда SSE и MMX дают существенное (а то и многократное) ускорение. Для таких программ вполне нормальное явление - несколько библиотек, закомпиленных под разные наборы инструкций (MMX, SSE, 3DNow, SSE3, SSE4 и т.п). Программа при запуске получает флаги поддерживаемых инструкций и выбирает нужную библиотеку. Некоторые позволяют выбирать либы вручную (например, EncWAVtoAC3). А кодек h.264, насколько я понял, тащит внутри себя несколько вариантов функций с разными наборами инструкций и определив тип процессора, заполняет таблицу их адресов.

Поспрашивал на др форумах - ничего нового, да, надо иметь код "под каждый". Хорошо, тогда как лучше эту батарею компилить? Очевиден такой вариант:

- создать новую статик либу и насовать в нее таргетов (по 1 на каждый SSE), отличаются именами либы, экспортируемых ф-ций (через макро) и установкой SSE компилятора. Компилить это батчем, получится куча либов.

- из приложения определиться "какой SSE" в runtime и присвоить указатели на вызываемые ф-ции

Может как-то лучше, чтобы удобнее редактировать/отлаживать?

Зачем статик?
Лучше шаред сделать для каждого из SSE и загружать нужную. Символы будут одинаковые, загрузил, разрезолвил и пользуйся.

Единицей трансляции является *cpp файл, соответственно, каждый файл может быть скомпилирован со своими настройками.
И таким образом в одну библиотеку можно запихнуть все варианты.

А для чего?

Просто мне больше нравится вариант с одной библиотекой, в которой много функций на все случаи, чем с кучей библиотек, с одной функцией

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

Разумно, но набегает 4-5 вариантов * 2 (под 32 и 64) и еще * 2 (OSX и Вындоуз). Для каждой беты перекомпилировать эту толпу... И постоянно переключать release/debug

Лучше вообще "в одно приложение". Но я пока не нашел как сделать это в Xcode 4.6

Печально, вы автоматическую сборку еще не освоили?
Тогда да, лучшее решение в одно приложение.

Я и на 4.6 пересел недавно с 3.2.6 и многие педали еще путаю. Если расскажете что то за "автоматическая" и как ее сделать в Xcode - буду признателен. Пока я не вижу как компилить серию файлов с разными установками кроме как создавать новый target(ы), что имеет свои минусы

CMake & make
И вы сможете не то что разные файлы собирать с разными параметрами, а целые сборки получать всего одной командой: сказали make all и получили - демо версию, лайт версию, дебаг версию, личную версию, версию для друга Сени и т.д. Все будет красиво разложено по своим деревьям, архитектурам и чему надо. :)

Это я могу и с IDE получить (создав N таргетов), но так ли уж это удобно, особенно для повседневного редактирования?

Повседневного редактирования чего?
И тогда непонятна эта "проблема":