Какие стандартные методы существуют для использования специфических функций процессора в DLL? - PullRequest
4 голосов
/ 25 сентября 2008

Короткая версия: мне интересно, возможно ли и как лучше использовать процессор? инструкции внутри DLL?

Чуть более длинная версия: При загрузке (32-битных) DLL, скажем, от Microsoft, кажется, что один размер подходит для всех процессоров.

Означает ли это, что они строго построены для наименьшего общего знаменателя (т.е. минимальная платформа, поддерживаемая ОС)? Или есть какой-то метод, который используется для экспорта одного интерфейса в DLL, но использовать Код конкретного процессора за кулисами, чтобы получить оптимальную производительность? И если да, то как это делается?

Ответы [ 5 ]

6 голосов
/ 25 сентября 2008

Я не знаю ни одной стандартной методики, но если бы мне пришлось сделать такую ​​вещь, я написал бы некоторый код в функции DllMain (), чтобы определить тип процессора и заполнить таблицу переходов указатели на оптимизированные для процессора версии каждой функции.

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

Текущую информацию о ЦП вы можете найти в реестре здесь:

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor
2 голосов
/ 25 сентября 2008

Ожидается, что DLL будет работать на каждом компьютере, на котором работает WIN32, так что вы застряли в целом с набором команд i386. Не существует официального метода предоставления функциональности / кода для определенных наборов инструкций. Вы должны сделать это вручную и прозрачно.

В основном используется следующая техника: - определить функции процессора, такие как MMX, SSE во время выполнения - если они присутствуют, используйте их, если нет, подготовьте резервный код

Поскольку вы не можете позволить своему компилятору оптимизировать для чего-то другого, кроме i386, вам придется писать код, используя определенные наборы команд в встроенном ассемблере. Я не знаю, есть ли инструменты для более высокого языка для этого. Определение функций процессора не вызывает затруднений, но также может потребоваться выполнить на ассемблере.

1 голос
/ 25 сентября 2008

Intel ICC может компилировать код дважды для разных архитектур. Таким образом, вы можете съесть свой торт и съесть его. (ОК, вы получите два торта - ваша DLL будет больше). И даже MSVC2005 может сделать это для очень конкретных случаев (например, memcpy () может использовать SSE4)

Существует много способов переключения между разными версиями. DLL загружена, потому что процесс загрузки требует от нее функций. Имена функций конвертируются в адреса. Одно из решений - позволить этому поиску зависеть не только от имени функции, но и от особенностей процессора. Другой метод использует тот факт, что функция «имя-адрес» использует таблицу указателей на промежуточном этапе; Вы можете выключить всю таблицу. Или вы могли бы даже иметь ветку внутри критических функций; поэтому foo () вызывает foo__sse4, когда это быстрее.

1 голос
/ 25 сентября 2008

DLL, которые вы загружаете из Microsoft, предназначены для общей архитектуры x86 по той простой причине, что она должна работать на всех множествах машин.

До временного интервала Visual Studio 6.0 (я не знаю, изменился ли он) Microsoft использовала для оптимизации своих библиотек DLL размер, а не скорость. Это связано с тем, что уменьшение общего размера DLL дало более высокий прирост производительности, чем любая другая оптимизация, которую мог сгенерировать компилятор. Это связано с тем, что ускорения от микрооптимизации были бы решительно низкими по сравнению с ускорениями из-за отсутствия ожидания ЦП памяти. Истинное улучшение скорости достигается за счет уменьшения количества операций ввода-вывода или улучшения базового алгоритма.

Только несколько критических циклов, которые работают в основе программы, могут извлечь выгоду из микрооптимизаций просто из-за огромного числа их вызовов. Только около 5-10% вашего кода может попасть в эту категорию. Вы можете быть уверены, что такие критические циклы уже будут оптимизированы в ассемблере разработчиками программного обеспечения Microsoft до некоторого уровня и не оставят слишком много для компилятора поиска. (Я знаю, что он ожидает слишком многого, но я надеюсь, что они делают это)

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

1 голос
/ 25 сентября 2008

Простой способ получить оптимизацию SSE / SSE2 - просто использовать аргумент /arch для MSVC. Я бы не стал беспокоиться о запасном варианте - нет причин поддерживать что-либо ниже этого, если у вас нет нишевого приложения.

http://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx

Я считаю, что gcc / g ++ имеют эквивалентные флаги.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...