Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Какое сложение двух пар чисел быстрее?

Barloggg © (2005-08-31 13:54:00)
Предположим имею две пары чисел Word.
Хочу сложить.

Что быстрее
var a,b,c,d,sum1,sum2:word;
...
sum1:=a+b;
sum2:=c+d;

или так:
type tn=record
case integer of
0: (a,b:word);
1: (n:longword);
end;
end;
var ab,cd,sum:tn;
var sum1,sum2:word;
...
sum.n:=ab.n+cd.n;
sum1:=ab.a;
sum2:=ab.b;

Германн (2005-09-01 01:06:00) [1]
2 Anatoly Podgoretsky © (01.09.05 00:55) [17]

Digitman © (31.08.05 14:47) [8]
Уже указал на возмржность ошибки

>и работать это будет правильно лишь при таких значениях полей а и b, что ожидаемая их сумма не превышает 65535

Anatoly Podgoretsky (2005-09-01 00:55:00) [2]
Второй вариант быстрее, но еще одно но, он направильный и даст неверный результат при определенных числах, поскольку возможен перенос из младшего слова.

tesseract (2005-08-31 22:19:00) [3]
>> Вы здесь все точно что-то курите ...

Я лично пью.....

Jeer (2005-08-31 18:29:00) [4]
BFG9k © (31.08.05 18:19) [14]

Присоединяйся:)

BFG9k (2005-08-31 18:19:00) [5]
Вы здесь все точно что-то курите ...

Юрий Зотов (2005-08-31 15:45:00) [6]
> Barloggg (31.08.05 14:29) [6]

> Надо сказать этот вопрос имеет не только теоретическое
> значение...

Значит, для Вашей задачи он имеет еще и практическое значение. Но тогда я не понимаю вот чего - зачем программировать на ЯВУ кусок, в котором буквально требуется считать такты CPU?

????? (крайняя степень недоумения).

Как говорил один знакомый, "Дуся, я тащуся". Раз уж этот кусок НАСТОЛЬКО критичен к скорости, что приходится считать блох, то почему же не написать его на ассемблере?

А если он все же не НАСТОЛЬКО критичен, то какая разница? Пишите, как удобнее, да и все.

Barloggg (2005-08-31 15:31:00) [7]
Насчет предварительного заполнения - неактуально. и там и там заполнение.
to [8], да, опечатка. действительно sum а не ab...

Barloggg (2005-08-31 15:29:00) [8]
Хелп говорит, что размер выделяется под наибольший из возможных вариантов представления данных...
Проверил. В такой формулировке все поровну. значит используются одни и те же ячейки памяти. И кстати операций сдвига тут скорее всего нету. все же кратно одному байту.

tesseract (2005-08-31 15:06:00) [9]
>>получается что складывать одним большим числом быстрее ибо это одна инструкция для процессора а не две. и преобразования тут как такового нету...
Не факт компилято про этот прикол знает и соответсвенно пытается оптимизировать код.

проверь например sizeof record и packed record

Digitman (2005-08-31 15:03:00) [10]
если тебе требуется исключительная оптимизация алгоритма сложения по производительности, то лучше всего будет реализация его на встроенном ассемблере - в этом случае можно будет явно задействовать мощь мультиконвейерной архитектуры ЦП, позволяющей в ряде ситуаций параллельную загрузку/выполнение нескольких "независимых" маш.инструкций

например,

movzx eax, a
movzx ebx, b
movzx ecx, c
movzx edx, d

//следующие 2 инструкции (собственно сложение) м.б. выполнены процессором "параллельно"
add eax, ebx
add ecx,edx

mov sum1, eax
mov sum2, ecx

Digitman (2005-08-31 14:47:00) [11]

> одни и теже данные можно представить либо как одним лонгвордом
> либо как двумя вордами

пояснять не требовалось ... как говорится, понятно что лошадь, но только с рогами)

> я заполняю как а и b а вот складываю как n

ну тогда уж не

<заполнение>
sum.n:=ab.n+cd.n;
sum1:=ab.a;
sum2:=ab.b;

а

<заполнение>
sum.n:=ab.n+cd.n;
sum1:= sum.a;
sum2:= sum.b;

и работать это будет правильно лишь при таких значениях полей а и b, что ожидаемая их сумма не превышает 65535

к тому же <заполнение>, очевидно, предполагает непустое кол-во как минимум маш.инструкций сдвига, что сводит на нет всю затею

Barloggg (2005-08-31 14:31:00) [12]
получается что складывать одним большим числом быстрее ибо это одна инструкция для процессора а не две. и преобразования тут как такового нету...
Но я сижу на тонком клиенте и проверить скорость работы не могу... может кто-нибудь проверит?

Barloggg (2005-08-31 14:29:00) [13]
Так... похоже не все понимают о чем идет речь...
Вот эта формулировка
type tn=record
case integer of
0: (a,b:word);
1: (n:longword);
end;
end;
предполагает что одни и тежеданные можно представить либокак одним лонгвордом либокак двумя вордами. По числу байт это едино и в памяти они занимают одно и тоже место.

Так что я заполняю как а и b а вот складываю как n.
Надо сказать этот вопрос имеет не только теоретическое значение...

tesseract (2005-08-31 14:16:00) [14]
Давайте подумаем какой у на процессор - 32бита, и АЛУ, и регистры у него такие-же. Т.Е процессору всё равно cardinal(longword) или byte. Для него все числа одинаковые - 32 бита.
Процессор захряпывает данные из кэша тоже по 32 бита, т.е. Если есть два числа по 32 бита он и первое и второе считает за один такт. А если допустим первое число -8 бит, а второе -32 ? тогда он первое считает за 1 такт, но на второе потратит 2 только на считывание, потом он дожен две части сложить и отбросить лишние биты!!!! Т.Е работаете на intel - работайте с 32 битами.

Digitman (2005-08-31 14:16:00) [15]

> Оба кода рабочие

хм...

sum.n:=ab.n+cd.n; //здесь ты сложил два лонгворда, результат сложения поместил в третий логгворд

sum1:=ab.a; //а сумму почему-то читаешь из первого слагаемого, а не из результата, который ты записал в sum
sum2:=ab.b; //и здесь тоже к sum не обращаешься

?

Barloggg (2005-08-31 14:08:00) [16]
два раза складывать по одному два ворда или один раз складывать два лонгворда с преобразованием типов вот в чем вопрос.
Оба кода рабочие. Оба выдают одинаковый результат. Что быстрее? Или может правильнее спросить что элегантнее?

Digitman (2005-08-31 14:06:00) [17]

> Barloggg (31.08.05 13:54)

что-то огород с записью непонятен ..

поясни, что ты имел ввиду при этом ...

DimaBr (2005-08-31 13:58:00) [18]
А смыс-то при нынешних технологиях.
Пишем цикл на пару лимонов операций и засекаем таймером.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »