Ночные странности

← →
bems © (2014-12-03 05:50) [0]

есть такая строчка
Result := Result shl 4 + Result shl 3 + Result shl 1; // * 26

вопрос в том, а не лучше было бы просто умножить?

← →
Pavia © (2014-12-03 06:14) [1]

Умножение занимать 5-7 тактов.
Данный код 3 такта.

← →
junglecat © (2014-12-03 08:51) [2]

(Result shl 4) or (Result shl 3) or (Result shl 1)?

← →
Sha © (2014-12-03 09:33) [3]

> bems © (03.12.14 05:50)
Почему бы не проверить? Скорее всего, умножение будет быстрее.

> junglecat © (03.12.14 08:51) [2]
Результат будет отличаться в общем случае.

← →
junglecat © (2014-12-03 09:42) [4]

> будет отличаться в общем случае

ну да. мне почему-то всегда инстинктивно хочется or вставить, если я вижу shl )

← →
MBo © (2014-12-03 09:45) [5]

>а не лучше было бы просто умножить?
Эта строка влияет на общее время выполнения программы?

← →
jack128 © (2014-12-03 09:51) [6]

> вопрос в том, а не лучше было бы просто умножить?

Лучше. По крайней мере пока нету результатов замеров производительности.

← →
junglecat © (2014-12-03 10:04) [7]

> Умножение занимать 5-7 тактов

так много? а не те же 3 такта? по крайней мере, на каком-нибудь core duo

← →
Rouse_ © (2014-12-03 12:29) [8]

> bems © (03.12.14 05:50)
> есть такая строчка
> Result := Result shl 4 + Result shl 3 + Result shl 1; //
> * 26
>
> вопрос в том, а не лучше было бы просто умножить?

Лучше просто умножить, т.к. этот код выполняется медленнее, чем умножение.

← →
bems © (2014-12-03 14:32) [9]

> (Result shl 4) or (Result shl 3) or (Result shl 1)?

нет, речь о сложении

> Почему бы не проверить? Скорее всего, умножение будет быстрее.

тогда мне не о чем было бы создать топик

> Эта строка влияет на общее время выполнения программы?

я не видел всей программы

← →
MBo © (2014-12-03 15:55) [10]

И всё-таки вопрос не очень понятен.

Почему так кто-то написал?
Может, экономил на спичках в пору, когда умножение могло быть медленнее двух сложений и трех побитовых операций.

← →
Dimka Maslov © (2014-12-03 17:14) [11]

У меня получается, что умножение таки на 10% медленнее.
Intel G3250 3.2 ГГц 32 битный код в Delphi2009

Но если взять 64 битный код MSVC++2013 то умножение происходит на 2% быстрее.

← →
Sha © (2014-12-03 17:29) [12]

> Dimka Maslov © (03.12.14 17:14) [11]
> У меня получается, что умножение таки на 10% медленнее.

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

← →
Rouse_ © (2014-12-03 18:28) [13]

> Dimka Maslov © (03.12.14 17:14) [11]
> У меня получается, что умножение таки на 10% медленнее.
> Intel G3250 3.2 ГГц 32 битный код в Delphi2009
>
> Но если взять 64 битный код MSVC++2013 то умножение происходит
> на 2% быстрее.

Эт смотря как мерять:

function T1(V: Integer): Integer; begin Result := V shl 4 + V shl 3 + V shl 1; // * 26 end; function T2(V: Integer): Integer; begin Result := V * 26; end; procedure TForm1.Button1Click(Sender: TObject); var I: Integer; S: dword; begin S := GetTickCount; for I := 0 to $7FFFFFF do T1(I); Memo1.Lines.Add(IntToStr(GetTickCount - S)); S := GetTickCount; for I := 0 to $7FFFFFF do T2(I); Memo1.Lines.Add(IntToStr(GetTickCount - S)); end;

← →
Dimka Maslov © (2014-12-03 23:20) [14]

> Эт смотря как мерять:

Тут ещё от системы зависит. Помнится мне, я тестировал быстродействие "CYRIX 166+" и Intel Pentium 166. На каких-то задачах цырикс показывал большее быстродействие, а на других - серьёзно проигрывал.

← →
Rouse_ © (2014-12-04 00:27) [15]

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

← →
Inovet © (2014-12-04 03:43) [16]

> [15] Rouse_ © (04.12.14 00:27)
> за исключением одного очень специфического случая

8086?

← →
Pavia © (2014-12-04 12:23) [17]

i5-4570
c ключевым словом Const
188 203
188 187
188 187
188 187
188 187
188 187
187 204
187 188
188 203
203 188
Частота дескритизации счётчика и переключение задач делают интервал 10-1000 мс недостоверным. Поэтому увеличил время замера.

Без ключевого слова Const
1860 1562
1844 1562
1844 1563
Тест не корректный так как D7 генерирует код рассчитанный на параллельную работу. Т.е значение V - в выражение на разных тактах может меняться. Откуда имеем лишние обращение к кэшу.

c ключевым словом Const
1531 1531
1516 1531
1531 1516
1516 1515
1516 1515
1516 1515
1531 1515

Собственно результат говорит о конвейерной обработке и умножение разных команд идут в параллели.

> Умножение занимать 5-7 тактов.
> Данный код 3 такта.

Давно не обновлял таблицы. На 4 поколение i7 умножение уже 4 такта. А в коде со сдвигами я не учёл еще один такт. Итого 4 против 4.

Но умножение занимает 1 вычислительный блок(АЛУ) и то не полностью, а вот код со сдвигами несколько.
Так что если надо и другую арифметику, то лучше imul.

> > [15] Rouse_ © (04.12.14 00:27)> за исключением одного
> очень специфического случая8086?

Думаю Розыч о LEA который позволяет умножать на 3, 5 и 9 за 1 такт.

← →
Rouse_ © (2014-12-04 13:01) [18]

> Думаю Розыч о LEA который позволяет умножать на 3, 5 и 9
> за 1 такт.

Угу:

function T3(V: Integer): Integer; asm mov edx, eax shl edx, 4 lea edx, [edx + eax * 8] lea eax, [edx + eax * 2] end;

← →
Sha © (2014-12-04 13:55) [19]

function T4(V: Integer): Integer; asm lea edx, [eax + eax * 8] lea edx, [edx + edx * 2] sub edx, eax mov eax, edx end;

> Sha © (04.12.14 13:55) [19]

Тогда уж:
function T5(V: Integer): Integer; asm lea edx, [eax * 8] lea edx, [edx + edx * 2] lea eax, [edx + eax * 2] end;
;)

Так в lea же фиксированные значения, сдвигом по сути умножается. Или уже поменялось всё?

Сдвигом, но за один такт, т.е. function T5 исполняется всего за 3 такта.

Конечно совпадет, у тебя (V * 27) - V, у меня (V * 24 + V * 2) в итоге что и хотели, V * 26 :)

А..., по тактам у меня шустрее, но время будет идентично по всех трех функциях T3-T5 на финализации :)

← →
имя (2014-12-09 19:11) [27]

Удалено модератором

Ночные странности Найти похожие ветки