Хех... загадка :)

← →
Piter © (2006-03-03 00:41) [0]

Может ли в Delphi быть такое, что операция:

P := nil;

выполняется медленнее, чем, например:

P := Pointer($0000ABCD);

? :)

← →
McSimm © (2006-03-03 00:42) [1]

Область видимости одинаковая ?

← →
Piter © (2006-03-03 00:45) [2]

Область видимости P? Ну естественно.

Кстати, P: pointer

← →
Piter © (2006-03-03 00:46) [3]

С "P" вообще ничего делать не надо, просто меняешь правую часть и получаешь замедление (если со второго варианта на первый)

← →
Piter © (2006-03-03 00:47) [4]

Piter © (03.03.06 0:46) [3]
и получаешь замедление

естественно, не всегда, а при определенных условиях. И настройках :)

← →
McSimm © (2006-03-03 01:01) [5]

Не знаю.
Делфи нет, а наугад сказать сложно.
При обычных условиях nil должен по идее заноситься с помощью очищенного аккумулятора, т.е. две операции, а константу вероятнее всего занесет одной операцией, но она тяжелее тех двух скорее всего.

← →
McSimm © (2006-03-03 01:02) [6]

а при определенных условиях и настройках может всякое быть :)

Так что ответ на вопрос - может.
(и попробуй докажи, что я не правильно ответил :)

← →
SkyRanger © (2006-03-03 01:10) [7]

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

← →
Lamer@fools.ua © (2006-03-03 01:14) [8]

>Ну дык приведение типов вроде занимает больше памяти

Кхм...

← →
Piter © (2006-03-03 01:15) [9]

Блин, ну ты умен... так нечестно :)

А я, судя по всему, лоханулся. Действительно, операций то будет две, но там ведь копирование из регистра в память, а в обратном случае из памяти в память, что, вероятно, медленее, чем две операции с регистром :(

Черт, ну ладно, еще раз убедился, что есть люди поумнее меня :)

← →
Piter © (2006-03-03 01:16) [10]

это я к Максиму обращался в предыдущем посте :)

← →
McSimm © (2006-03-03 01:21) [11]

>Ну дык приведение типов вроде занимает больше памяти

занимаемой исходником в редакторе ?
конечно :)

← →
Lamer@fools.ua © (2006-03-03 01:22) [12]

>>Piter © (03.03.06 00:41)

Версия Delphi?
Оптимизация включена?

З.Ы.
Если оптимизация включена, то может быть, например, такое различие:
xor eax, eax // Это быстрей должно быть
vs
mov eax, $0000ABCD // чем это

Если оптимизация выключена, то получим что-то вроде этого:
xor eax, eax mov [ebp - $08], eax
vs
mov [ebp - $08], $0000ABCD
Тогда первый вариант, вероятно, будет выполняться дольше.

З.Ы.Ы. IMHO, на современных процессорах говорить о скорости отдельно взятой операции вне контекста вообще не имеет смысла, учитывая спекулятивное выполнение, кеш инструкций и данных первого и второго уровней и прочая и прочая...

← →
McSimm © (2006-03-03 01:39) [13]

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

Я совершенно не знаком с тонкостями современных процессоров, так, краем уха выидел :)
Скорее всего сейчас все действительно иначе.

← →
Piter © (2006-03-03 02:11) [14]

Lamer@fools.ua © (03.03.06 1:22) [12]
Тогда первый вариант, вероятно, будет выполняться дольше.

ага, именно про это я и говорил, все правильно. НО. В посте [9] я описал уже, ступил. Думаю, что комманды работы над регистром:

Lamer@fools.ua © (03.03.06 1:22) [12]
xor eax, eax
mov [ebp - $08], eax

все равно будут выполнено быстрее, чем копирование из памяти в регистр:

Lamer@fools.ua © (03.03.06 1:22) [12]
mov [ebp - $08], $0000ABCD

← →
Piter © (2006-03-03 02:12) [15]

Piter © (03.03.06 2:11) [14]
чем копирование из памяти в регистр

тьфу, "чем копирование из памяти в память".

← →
Piter © (2006-03-03 02:13) [16]

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

← →
Lamer@fools.ua © (2006-03-03 09:24) [17]

>>Piter © (03.03.06 02:13) [16]

mov [ebp - $08], $0000ABCD — не копирование из памяти в память.

← →
wal © (2006-03-03 09:53) [18]

> mov [ebp - $08], $0000ABCD — не копирование из памяти
> в память.
А откуда и куда?

← →
MBo © (2006-03-03 10:09) [19]

procedure TForm1.Button4Click(Sender: TObject); var t: Dword; i, m, c: Integer; begin t := GetTickCount; c := t; for i := 0 to 2000000000 do m := c; //1 // m := 0;//2 // m:=123456789; //3 Caption := Format("%d %d", [m, GetTickCount - t]); end;
первые два варианта выполняются у меня в 1.5 раза быстрее третьего.
Код варианта //1 включает в себя копирование регистра, и занимает 2 байта.
Второго - xor, 2 байта
Третий вариант - загрузка в регистр НЕПОСРЕДСТВЕННОГО значения (immediate value), занимает 5 байт (код команды и сами данные)

← →
MBo © (2006-03-03 10:10) [20]

>wal © (03.03.06 09:53) [18]
> mov [ebp - $08], $0000ABCD — не копирование из памяти
> в память.
>А откуда и куда?

непосредственного значения в память

← →
wal © (2006-03-03 10:17) [21]

> непосредственного значения
А непосредственное значение где находится?

← →
McSimm © (2006-03-03 10:22) [22]

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

← →
wal © (2006-03-03 10:47) [23]

> [22] McSimm © (03.03.06 10:22)
> Есть терминология, данные могут быть в регистре, памяти
> или непосредственно в команде.
Терминология терминологией, но на низком уровне цикл выборки непосредственных данных и цикл выборки данных из памяти мало чем отличаются.

> Конечно, все это память (даже регистры, чем не память?).
Регистры - это тоже память (даже в какойто советской книге видел определение "сверхоперативное ЗУ"), но работа с ними в корне отличается от работы с ОЗУ и по времени и по принципам обращения.
> Но работа процессора с данными в области памяти и расположенными
> в коде разная.
Но это не делает память (ОЗУ) непамятью (неОЗУ) ;)

С уважением.

← →
Lamer@fools.ua © (2006-03-03 11:01) [24]

>>wal © (03.03.06 10:47) [23]

>но на низком уровне цикл выборки непосредственных данных и цикл выборки данных из памяти мало чем отличаются.

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

>>MBo © (03.03.06 10:09) [19]

GetTickCount() --> GetThreadTimes()

← →
wal © (2006-03-03 11:05) [25]

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

← →
Lamer@fools.ua © (2006-03-03 11:53) [26]

>>wal © (03.03.06 11:05) [25]

См. З.Ы.Ы. к [12] :-)

← →
Piter © (2006-03-03 13:38) [27]

Хех, так прав я был или нет? :)

Давайте сформулирую, что быстрее все таки:

1) копирование из кода в память

или

2) XOR над регистром и копирование из регистра в память?

С учетом всех побочных эффектов, аля выборки из памяти.

Вопрос не научный, просто интересно.

← →
MBo © (2006-03-03 13:42) [28]

>Piter © (03.03.06 13:38) [27]
>1) копирование из кода в память

?
Переформулируй

← →
Crash Coredump © (2006-03-03 13:53) [29]

Piter © (03.03.06 13:38) [27]

А в связи с чем возник изначальный вопрос, если не секрет ? А то тут народ копья ломает...

← →
Piter © (2006-03-03 16:04) [30]

MBo © (03.03.06 13:42) [28]
Переформулируй

блин, ну я уж не знаю как назвать :)

Вот про это:

mov [ebp - $08], $0000ABCD

Ну если угодно, из комманды в память.

Не знаю как по другому сказать.

← →
Piter © (2006-03-03 16:05) [31]

Crash Coredump © (03.03.06 13:53) [29]
А в связи с чем возник изначальный вопрос, если не секрет ?

а вроде как вопроса и нету. Делюсь впечатлениями, а потом вот уже возник вопрос :)

← →
Marser © (2006-03-03 16:11) [32]

Удалено модератором
Примечание: Offtopic

← →
MBo © (2006-03-03 16:19) [33]

>Ну если угодно, из комманды в память.
В интеловской терминологии это immediate value - непосредственное значение. Само это число содержится прямо в машинном коде. Оптимизирующий компилятор обычно заменяет загрузку непоср. значения 0 на xor, но другие значения - так и остаются.

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

> Давайте сформулирую, что быстрее все таки:

XOR быстрее. Иначе эта конструкция не использовалась бы оптимизирующим компилятором

Игорь Шевченко © (03.03.06 17:06) [36]
XOR быстрее. Иначе эта конструкция не использовалась бы

логика, конечно, есть. И будет несомненно быстрее, если переменная хранится в регистре.

xor ecx, ecx

быстрее, чем:

mov ecx, $0

Но а вот когда идет еще и запись в память помимо xor"а...

Piter © (03.03.06 17:16) [37]

> Но а вот когда идет еще и запись в память помимо xor"а..
> .

Вот смотри:

в память можно записать из регистра

xor eax,eax // именно eax, по возможности
mov [some_mem],eax

или

mov [some_mem],0

Разработчики компилятора используют первый вариант.

Отгадай, почему ?

Игорь Шевченко © (03.03.06 17:26) [38]
Отгадай, почему ?

А потому что во многих случаях переменная хранится в регистре, тогда преимущество первого способа несомненно:

xor eax, eax

перед:

mov eax, 0

Когда же переменных много и приходится результат списывать в память:

xor eax, eax
mov $blabla, eax

уже неочевидно быстрее, чем просто:

mov $blabla, $0

Piter © (03.03.06 17:41) [39]

> А потому что во многих случаях переменная хранится в регистре,
> тогда преимущество первого способа несомненно:

Я разбираю случай, когда переменная хранится в памяти. Я специально привел два фрагмента кода. Давай ты не будешь изменять условия, ладно ?

Насчет неочевидности - марш на сайт Интел. Бегом.

Игорь Шевченко © (03.03.06 17:45) [40]
Я разбираю случай, когда переменная хранится в памяти. Я специально привел два фрагмента кода. Давай ты не будешь изменять условия, ладно ?

сначала вы просите рассказать, потом вам не нравится то, что я рассказал :)
Тогда и не спрашивайте :)

Если вы знаете, что XOR + mov с регистра работает быстрее, чем MOV непосредственного значения в память - то так и скажите.

Если вы думаете, что это так, потому что так реализовано в компиляторе Borland - это другой вопрос :)

Никто не спорит, что способ с XOR явно быстрее, если переменная хранится в регистре, что бывает ЧАСТО.

Но когда она там НЕ хранится - то может и замедление быть. Или не быть.

Я и хотел услышать про это :)

Игорь Шевченко © (03.03.06 17:45) [40]
Насчет неочевидности - марш на сайт Интел. Бегом

понятное дело. Но я хотел спросить тех, кто уже знает ответ на вопрос :)
Игорь Шевченко © (03.03.06 17:45) [40]
Насчет неочевидности - марш на сайт Интел. Бегом

Обе операции выполняются за N толи микро- толи нано- толи микронано- толи наномикро- секунд...

По сабжу:
Не пойму, а почему это стало так критично?

oldman © (03.03.06 18:25) [42]
Обе операции выполняются за N толи микро- толи нано- толи микронано- толи наномикро- секунд...

да, но что быстрее? :0

oldman © (03.03.06 18:25) [42]
Не пойму, а почему это стало так критично?

где написано, что это критично?

Если была бы проблема - то ветка в "Основной" была, а тут так, Потрепаться...

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

> Piter © (03.03.06 18:29) [43]
> где написано, что это критично?

вернемся к сабжу...

"Может ли в Delphi быть такое, что операция:
P := nil;
выполняется медленнее, чем, например:
P := Pointer($0000ABCD);
? :)
"

Отвечаю: может!
легче стало?

У тебя проблема, или так, "потрепаться"?

> Может ли в Delphi быть такое, что операция:
В Delphi может быть все :)

> выполняется медленнее, чем, например:
Какой рулеткой мерили?

Причем "

Причем:

"Может ли в Delphi быть такое..."

А ты уверен, что это Дельфи виноват?

"

Нда, господа. Если вы горите желанием порешать проблемы - идите в другие конференции, "Основная" или там "Сети". Полно вопросов, ждущих вашего ответа.

А в ветки типа "Загадка", "Пятничные задачки" можете даже не заходить, будете разочарованы.

Хех... загадка :) Найти похожие ветки