Вопросы по использованию ассеблера

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

 

Не поверю я в 1.4 раза.
Либо сишный код дубовый какой-то, либо замеры не точные.

Ну во-первых я написал "если повезёт".
А во вторых имел ввиду достаточно большие объёмы кода.
На каком-нибудь цикле ты столько не получишь.

 

cppasm

Даже 1-2% выигрыша могут оказаться очень существенными -- всё от задачи зависит. Ну а получают их обычно как раз на циклах.

 

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

 

Clerk

Опять-таки, зависит от задачи. Представьте себе, например, рендеринг трёхмерной сцены. Там же, грубо говоря, много-много-много раз выполняется один и тот же цикл. И даже небольшая его оптимизация может дать в итоге огромный выигрыш во времени рендеринга.

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

Пы.Сы. Сейчас на заказ пишу управляющую программу для рыбацкого эхолота, построенного на Атмеге-162. Делаю это на асме, как и мой предшественник. Но тот деятель способен посрамить любых индусов. Код... это что-то ужасное. Например, деление на 8 он выполняет путём вызова универсальной подпрограммы деления (где одних сдвигов у него выполняется 18), умножение тоже выполняет подпрограммой, использующей сложения и сдвиги, хотя у этой однокристаллки есть команда умножения. Половина ОЗУ у него занята промежуточными переменными, через которые, в частности, он передаёт параметры в подпрограммы -- и это для процессора, имеющего 32 регистра общего назначения. В общем, жуть неописуемая... Ну а мораль сей басни такова: если у тебя кривые руки и прямые извилины, то никакой асм не спасёт, только хуже сделает (довести прогу до работоспособного состояния он так и не смог, почему, собсно, мне и предложили заняться).

 

cppasm

Дык зайди по той ссылке, там всё приаттачено вместе с тестером, погоняй на своей машине, может в С коде чего-нибудь улучшишь

 

нада взять эту ссылку и пойти троллить С++ форумы на предмет ничтожности С++ в сравнении с асмом

 

GoldFinch
Да ладно - пусть живут ) у С одни плюсы, у асма другие - просто не стоит слишком верить в чудеса автоматической оптимизации кода

 

Ну вот скачал, погонял. Ничего не пересобирал.
Как и ожидал - результаты не однозначные.

Intel P4:

На AMD Duron результаты обратные, твой код примерно на столько же выигрывает.
Пересобрал Интеловским компилятором - ничего не поменялось.

 

cppasm
Да я тогда тестировал на AMD Turion. Сейчас попробовал на других:
Pentium M:
MSVC: Обычный результат в диапазоне: 630000 - 853000
изредка выпадает: 530000
asm: стабильно в диапазоне 400000 - 440000

Celeron Northwood-128:
MSVC: Обычный результат в диапазоне: 1410000 - 2150000
изредка выпадает: 660000
asm: стабильно в диапазоне 57500 - 610000

Почему на P4 "замусоренный" код может обогнать простой и логичный, разве только leo объяснит )

 

Кстати на счёт замусоренности.
Я алго не знаю, сильно не вникал.
Просто твой ассемблерный код перевёл на С.
Вместо esi, edi - указатели, а не обращение по индексу и т.д.
Код генерируется в итоге практически такой же как у тебя.
За исключением того что компилятор условия реализует через jcc а не через movcc.
Я утверждать не буду, но что-то мне кажется что входные данные не совсем одинаковы.
Хотя разницу я найти не могу.
Попробуй померять на массивах заполненных от 0 до 1000, и на заполненных от 1000 до 0.
Т.е. с минимумом и максимумом перестановок.
И сравнить результаты.

Просто не знаю как все компиляторы, а Intel C++ при построении кода учитывает вероятность того, что тот или иной переход произойдёт.
Т.е. можно подобрать такие данные, что все эти предсказания окажутся не верными.
Соответственно код будет медленнее.
Надо проверять на нормальном распределении.
Ну или как я предложил - минимум, максимум, а потом усреднить.

 

cppasm
генератор псевдослучайных чисел там равномерный, с одинаковым стартовым значением, реализован asm вставкой для полной идентичности получаемого набора данных.

 

Получилась хорошая иллюстрация к изначальному вопросу "где применять знания ассемблера ?" )
Вырисовывается следующая схемка:
1. Пишем простой и логичный код на С++
2. Заглядываем во что это скопилировалось на уровне асма и убеждаемся что "оптимизирующий компилятор не так чтобы совсем ничего не оптимизировал, но оптимизировал как-то не совсем так )"
3. Переписываем на асме, чтобы было логично и эффективно )
4. Переписываем опять на С++, чтобы получить кросплатформенность (условную, поскольку нюансы связанные с ускорением и уменьшением мусора будут зависеть и от компилятора и от процессора с другой системой команд)

Конечно при определённом уровне опыта гонять весь полный "цикл оптимизиции" нужно будет всё реже и реже - поскольку и так будешь представлять во что компилятся наиболее распространённые конструкции, но как я уже писал в #6 "такое понимание ооочень труднодостижимо при использовании исключительно ЯВУ, но стопудово полезно ".