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

← →
Barloggg (2005-08-31 13:54) [0]

Предположим имею две пары чисел 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;

← →
DimaBr (2005-08-31 13:58) [1]

А смыс-то при нынешних технологиях.
Пишем цикл на пару лимонов операций и засекаем таймером.

← →
Digitman © (2005-08-31 14:06) [2]

> Barloggg (31.08.05 13:54)

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

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

← →
Barloggg (2005-08-31 14:08) [3]

два раза складывать по одному два ворда или один раз складывать два лонгворда с преобразованием типов вот в чем вопрос.
Оба кода рабочие. Оба выдают одинаковый результат. Что быстрее? Или может правильнее спросить что элегантнее?

← →
Digitman © (2005-08-31 14:16) [4]

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

хм...

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

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

?

← →
tesseract © (2005-08-31 14:16) [5]

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

← →
Barloggg (2005-08-31 14:29) [6]

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

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

← →
Barloggg (2005-08-31 14:31) [7]

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

← →
Digitman © (2005-08-31 14:47) [8]

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

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

> я заполняю как а и 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

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

← →
Digitman © (2005-08-31 15:03) [9]

если тебе требуется исключительная оптимизация алгоритма сложения по производительности, то лучше всего будет реализация его на встроенном ассемблере - в этом случае можно будет явно задействовать мощь мультиконвейерной архитектуры ЦП, позволяющей в ряде ситуаций параллельную загрузку/выполнение нескольких "независимых" маш.инструкций

например,

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

← →
tesseract © (2005-08-31 15:06) [10]

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

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

← →
Barloggg (2005-08-31 15:29) [11]

Хелп говорит, что размер выделяется под наибольший из возможных вариантов представления данных...
Проверил. В такой формулировке все поровну. значит используются одни и те же ячейки памяти. И кстати операций сдвига тут скорее всего нету. все же кратно одному байту.

← →
Barloggg (2005-08-31 15:31) [12]

Насчет предварительного заполнения - неактуально. и там и там заполнение.
to [8], да, опечатка. действительно sum а не ab...

> Barloggg (31.08.05 14:29) [6]

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

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

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

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

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

Вы здесь все точно что-то курите ...

>> Вы здесь все точно что-то курите ...

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

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

2 Anatoly Podgoretsky © (01.09.05 00:55) [17]

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

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

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