Асм рулит?

← →
debuger © (2004-09-30 17:45) [0]

Доброго времени суток.

Вопрос такой: рулят ли(по скорости канешна) асмовые вставки.
Если предидущий ответ положителен, дайте линки на доку по написанию таковых. Произвожу только вычисления(что-то на ковго-то умножить, отнять, усреднить), т.е. проэкт мой чисто вычислительного характера.

← →
Суслик © (2004-09-30 17:50) [1]

Асм вставки делают исключительно для кртости. Т.е. кто делает, тот крут. Кто не делает, тот ламер.

Глупый ответ, на групый вопрос.

← →
Ega23 © (2004-09-30 17:52) [2]

Кстати, в слове Debugger два "g"

← →
begin...end © (2004-09-30 18:07) [3]

> Вопрос такой: рулят ли(по скорости канешна) асмовые вставки.

Зависит от качества вставок.

← →
icebeerg © (2004-09-30 18:15) [4]

> Вопрос такой: рулят ли(по скорости канешна) асмовые вставки.

и от количества вставок в общем ебеме программного кода

← →
debuger © (2004-09-30 18:15) [5]

2 Ega23. Кстати при выборе ника, него отношение к реальной жизни не рассматривалось.

Остальным пасиба.

← →
VMcL © (2004-09-30 18:15) [6]

>>debuger © (30.09.04 17:45)

Рульность асмовских вставок зависит от их написателя, от процессора и от оптимизатора. Оптимизатор ЯВУ может так соптимизировать код, что и ручная оптимизация ничего не улучшит (для данного процессора).

← →
debuger © (2004-09-30 18:28) [7]

Пасиба, только я в асме не ногой. Дайте линки на нармальные доки по написанию этих вставок.

← →
Суслик © (2004-09-30 18:29) [8]

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

← →
debuger © (2004-09-30 18:35) [9]

Да!
Не хватает процессорного времени на перещет всей трататни.
Я и так висю на 1.5 Г. И сказать заказчику, что комп не менее 2.5 Г, почему-то мое руководство не хочет.

← →
Суслик © (2004-09-30 18:38) [10]

> [9] debuger © (30.09.04 18:35)
> Да!
> Не хватает процессорного времени на перещет всей трататни.
> Я и так висю на 1.5 Г. И сказать заказчику, что комп не
> менее 2.5 Г, почему-то мое руководство не хочет.

Понимаешь в чем дело, писать на асме несложно. Писать оптимально сложно. На это нужен опыт. И опыт большой. Этому за месяц не научисся.

Зачастую оптимальность алгоритма заключена в самом алгоритме :)))
Посмотри - может у тебя этот случай.

← →
DiamondShark © (2004-09-30 18:40) [11]

Может тогда лучше алгоритмом заняться?
Книжки по численным методам почитать...

← →
Игорь Шевченко © (2004-09-30 18:40) [12]

> Дайте линки на нармальные доки по написанию этих вставок.

www.yandex.ru

← →
debuger © (2004-09-30 18:46) [13]

Спасиба всем.
Алгоритм у меня нормальный (просто требование к системе злые), книжек по ЧМВ начитался(и они не используются).
Построением алгоритмов занимаюсь дольше чем их программингом, и давно строю довольно приличные по оптимальности.

← →
Суслик © (2004-09-30 18:49) [14]

> [13] debuger © (30.09.04 18:46)
> Спасиба всем.
> Алгоритм у меня нормальный (просто требование к системе
> злые), книжек по ЧМВ начитался(и они не используются).
> Построением алгоритмов занимаюсь дольше чем их программингом,
> и давно строю довольно приличные по оптимальности.

Ты не горячись. Я же с тобой пиво не пил, деталей знать не могу.

Просто твое желание использовать асм и получить серьезную выгоду очень легкомысленно. Что и наводит на мысль о совете продумать алгоритм.

← →
TUser © (2004-09-30 19:15) [15]

Рулят, если писать их с умом. Т.е. ты олжен точно знать, как эту задачу решает компилятор/оптимизатор (напр., посмотреть в CPU), хорошо понимаь алгоритм, и понимать, на чем твой алгоритм выигрыват, а в чем он хуже, и каков баланс.

Недавно здесь проскакивала ссылочка, по которой я нашел текст, об оптимизации асмовского кода для Пентиумов. Лежит на работе, завтра могу выслать (только помылу попроси).

← →
Anatoly Podgoretsky © (2004-09-30 19:27) [16]

Искать особо и не нужно - Intel.com оптимизация кода для процессоров Пентиум, но если ты совсем не знаешь ассемблера, то как правило результат по скорости хуже чем на Паскале.
Кроме того меня смущает твое заявление об 1.5 гб, у тебя что программа такого размера, весьма сомневаюь, значит алгоритмы.

← →
Palladin © (2004-09-30 19:33) [17]

ИМХО
Здесь дело не в АСМовских вставках. Возможно имеет место пооптимизировать алгоритм обработки...

← →
jack128 © (2004-09-30 19:46) [18]

Anatoly Podgoretsky © (30.09.04 19:27) [16]
Кроме того меня смущает твое заявление об 1.5 гб, у тебя что программа такого размера, весьма сомневаюь, значит алгоритмы.

Да нет, человек имеет в виду, что его прога висИт на проце 1.5 гигагерца

← →
GuAV © (2004-09-30 20:01) [19]

> Асм рулит?

http://delphimaster.net/view/1-1096054352/

← →
debuger © (2004-09-30 20:24) [20]

интерессная эпопея.

← →
GuAV © (2004-09-30 21:21) [21]

> интерессная эпопея.

про биты в байте ещё интереснее было...

← →
Никита © (2004-09-30 21:31) [22]

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

← →
GuAV © (2004-09-30 21:49) [23]

Никита © (30.09.04 21:31) [22]

да. именно к такому выводу и приводят ветки про биты и про поиск.

← →
debuger © (2004-09-30 22:12) [24]

← →
Alekc (2004-09-30 22:57) [25]

Кстати, по поводу оптимизатора ЯВУ... напишите в дельфи несколько строчек "<variable> := 0;" и посмотрите на код после компиляции... если он на простейшем примере столько лишнего лепит, то что же будет на сложных циклах ?...

← →
GuAV © (2004-09-30 23:05) [26]

Alekc (30.09.04 22:57) [25]

Он оптимизирует достаточно хорошо в большинстве реальных ситуации. Всё же это не искуственный интеллект.
Он действует по шаблонам.
Например есть известный случай, такое часто бывает:
mov ebx, eax
mov eax, ebx

← →
Amoeba © (2004-10-01 10:23) [27]

Если очень нужно, то материалы по asm"у на русском найдешь на сайте А.Подгорецкого

← →
Sens © (2004-10-01 10:45) [28]

to debuger
А может опишешь задачу, которую пытаешься решить?
Как-то мне не понятно, какая такая задача может тормозить на 1,5Г???

У меня был неописуемый случай, когда сам свою прогу оптимизировал по скорости работы в ... очень много раз (скажу что в 1000-чи, не поверят). А задача была - разобрать log файл сквида и запихать его в базу (Access) для дальнейшей обработки.
~650000 строк сейчас обрабатывается на cel 1800 ~25сек (разбор строк, занесение в базу и предварительная обработка запросов), до этого было около 4-х часов. (АСМ не использовал).

Так что нужно с алгоритмом разобраться, а потом только думать об асме.

С уважением.

Возможно дела не в самом алгоритме как таковом, а в вмособе его применения. Например как там выделяется память, что используется в качестве буфера, как передаются параметры, имеется ли рекурсия и пр... Все это относится не к матиматике алгоритма, а имено к програмированию. Вот это вам и могут здесь подсказать, к томуже небывает идеальных алгоритмов!

> Вопрос такой: рулят ли(по скорости канешна) асмовые вставки.
> Произвожу только вычисления(что-то на ковго-то умножить, отнять, усреднить), т.е. проэкт мой чисто вычислительного характера.

Ты работает с видео?
Если да, тогда тебе прямой путь с использованию SSE2
есть команды параллельного умножения и сложения сразу нескольких (4-х операдов с плавающей запятой).

> Если предидущий ответ положителен, дайте линки на доку по написанию таковых.

www.intel.com

Instruction Set Reference vol 2A-B.
Programming Guige vol 3

2 debuger: напиши здесь код какой-нить простенькой функции, которую ты наиболее часто используешь.

Имею опыт написания асемблерных вставок. Результат:
1 Ассемблерные вставки сильно скорость не подымают. Штатный оптимзатор кода работает достаточно хорошо. Можно неделю кодить и обнаружить, что получаещь увелечение скорости 3-5%.
2 Много с этими вставками бился - пришел к выводу: попутки "вылизать" код - безполезная трата времени (убиваеться многог времени а реальный приост - единицы, реже десятки процентов). Единственный путь - глобальная оптимизация алгоритма с "ранним" отсечением тупиковых ветвей для просчета.
3 единственный путь оптимизации за счёт асм. вставок - использование ММХ и SSE инструкций с оптимизацией под конкретный процессор (заточка кода под особенности конвеера команд процессора). В этом случае возможно получить реальный результат.

Интересно, можно ли ускорить стандартную функцию Round?

from System.pas

procedure _ROUND; asm { -> FST(0) Extended argument } { <- EDX:EAX Result } SUB ESP,8 FISTP qword ptr [ESP] FWAIT POP EAX POP EDX end;

К примеру, сделать специально для типа Double?

Рыба © (02.10.04 21:06) [32]

Управлением Coprocessor Control Word можно понизить точность FPU. Однако не советую.

Приведенную функцию переписывать не нужно.

У меня распознавание видеопотока в риальном времени.
Тромозили две вещи:
- съем данных
- паганая рекусрия, которую быстро не опишешь.

Переписал первое, к скорости прибыло 3х.
Второе, особо сильно пока не прилизывается.

Все пасибо. Асма пока не хочу :)

DSA © (01.10.04 12:05) [31]
Штатный оптимзатор кода работает достаточно хорошо. Можно неделю кодить и обнаружить, что получаещь увелечение скорости 3-5%.
смотри ветку, ссылку на которую дал GuAV. там ускорение в разы..

> там ускорение в разы..

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

довольно часто изменение алгоритма даёт больше ускорение чем переписывание на асм.

Кто-нибудь скажет зачем в генерируемом коде много идущих друг за другом строк:
add [eax], al

Это тупо нули. Заполнение места. Чтобы процедуры были по смещению кратному 4.

а почему тогда не nop"ы?

Асм рулит? Найти похожие ветки