|
|
| Посл.отвђт | Сообщенiе |
|
|
Дата: Апр 19, 2004 12:47:15 Стас, извиняюсь, проглядел. Старость. Не ругайси. :) |
|
|
Дата: Апр 19, 2004 22:06:57 · Поправил: boozook Всем Здрасти! Вот решение для степени тройки, банальное конечно :), зато без циклов: log2_3 QWORD 03FF95C01A39FBD68h ;это log23 ... mov [esp-8],eax ;это mov dword ptr [esp-4],0 ; чтобы FPU не посчитало его за отрицательное fld1 fild qword ptr [esp-8] fyl2x ;log2eax fdiv log2_3 ;log3eax fld st(0) ;копия frndint ;если целое - тогда округляцца не будет fcomip st(0),st(1) ;результат в ZF ;проверки на ноль нету(можно установить обработчик исключения - деления на ноль :)) ;если что, в st(0) остается log3eax ... S_T_A_S_: bsf / bsr очень медленные инструкции ну, jcc, если не будет верно предсказываться, может оказаться значительно медленнее... тут нужно смотреть по коду |
|
|
Дата: Апр 20, 2004 06:20:53 boozook Ну давайте посмотрим, напаример, AMD's 22007.pdf: BSF reg16/32, mreg16/32 VectorPath 8 тактов! Это только одна инструкция. Теперь вот это: lea edx,[eax-1] test eax,edx je @powerof2 Что будет быстрее работать? jcc ни куда не денется в этих 2х случаях. А вот сам код - безусловно разное время занимает :) imho само по себе отсутствие циклов не является условием хорошей скорости. Вот FYL2X 116-126 тактов безусловно занимает. Это без деления даже. Мой цикл столько будет выполняться в самом худьшем случае. А в большинстве случаев - на порядок меньше тактов. А еще размер.. И, вероятно, можно быстрее сделать. Вот как? captain cobalt требования к алгоритму к сожалению не указал, но как правило подразумевается оптимизпция по скорости и/или размеру. Судя по тому, что он молчит, у кого-то еще есть порох в пороховницах :) |
|
|
Дата: Апр 20, 2004 19:18:47 Все эти недостатки - скорее bottlenecks процессора, чем алгоритмов. Та же bsf на PPro декодируется только на 2 микрооперации, т.е. должна бы выполняться за один такт. В то же время на P4 задержка достигает 4 такта, а на Атлонах - 8. FYL2X на P4 вообще до 200 доходит :) ...ничего, подождем K9, ну и еще этот способ 64-разрядные числа будет понимать ;) jcc ни куда не денется в этих 2х случаях Ну можно же использовать setcc, cmovcc, тогда c проверкой нуля будет что-то вроде: test eax,eax setz al,3 lea ecx,[eax-1] test eax,ecx хотя, если ноль встречается редко, вместо setz лучше использовать je на какой-нить код для установки флага :) |
|
|
Дата: Апр 20, 2004 22:04:28 эти недостатки - скорее bottlenecks процессора, чем алгоритмов Как же рассматривать алгоритм отдельно от процессора, если алгоритм процессорозависим? Хотя про интеловские процы верно подмечено. Дальше больше, но медленнее ;) ЗЫ Про 0 imho тут не надо думать. Его не будет по условию - это не натуральное число. |
|
|
Дата: Апр 21, 2004 00:06:31 Как же рассматривать алгоритм отдельно от процессора, если алгоритм процессорозависим? Почему? Я могу и в уме(на калькуляторе:)) исполнить эти алгоритмы. [offtop] про интеловские процы... Да не, я ничего не имею против интела. Техаса тоже ждем :) Просто с floating point АМД всегда была в ладах... [/offtop] это не натуральное число Наверное, в глаз что-то попало ;) А вообще, тема же создана не для дела - так, поупражняться... как я понял |
|
Powered by miniBB 1.6 © 2001-2002
Время загрузки страницы (сек.): 0.048 |