Автор |
Сообщение |
|
|
Заголовок сообщения: |
|
|
|
Alexander писал(а): Ответ очень прост Ага - не надо использовать XCHG, о чем я и предупреждал. Alexander писал(а): если взглянуть на документацию к инструкциям. Таки последовали моему совету? Хорошо! Плохо только что уже после того как предложили заведомо провальный вариант. Цитата: XCHG хотите вы этого или нет всегда генерирует префикс LOCK. Что-ж, хрен редьки не слаще. Надеюсь теперь вы согласны что не стоит использовать XCHG reg, mem ?
Кстати, насчет XCHG reg, reg похоже не все так плохо, только сложный декодер используется и вроде все. Но в нашем случае нет пользы от использования данной комманды.
[quote="Alexander"]Ответ очень прост[/quote]Ага - не надо использовать XCHG, о чем я и предупреждал. :P [quote="Alexander"] если взглянуть на документацию к инструкциям.[/quote]Таки последовали моему совету? Хорошо! Плохо только что уже [u]после[/u] того как предложили заведомо провальный вариант. :roll: [quote]XCHG хотите вы этого или нет всегда генерирует префикс LOCK.[/quote]Что-ж, хрен редьки не слаще. Надеюсь теперь вы согласны что не стоит использовать XCHG reg, mem ?
Кстати, насчет XCHG reg, reg похоже не все так плохо, только сложный декодер используется и вроде все. Но в нашем случае нет пользы от использования данной комманды.
|
|
|
|
Добавлено: Пн мар 31, 2008 11:57 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Forthware писал(а): Запускаем tt1 и tt2 и смотрим на циферки Ответ очень прост, если взглянуть на документацию к инструкциям. XCHG хотите вы этого или нет всегда генерирует префикс LOCK. Цитата: See “Effects of a Locked Operation on Internal Processor Caches” in Chapter 7 of Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, the for more information on locking of caches.
Также надо не забывать про параллельность выполнения.
[quote="Forthware"]Запускаем tt1 и tt2 и смотрим на циферки[/quote] Ответ очень прост, если взглянуть на документацию к инструкциям. XCHG хотите вы этого или нет всегда генерирует префикс LOCK. [quote] See “Effects of a Locked Operation on Internal Processor Caches” in Chapter 7 of Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A, the for more information on locking of caches.[/quote]
Также надо не забывать про параллельность выполнения.
|
|
|
|
Добавлено: Пн мар 31, 2008 09:14 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Не знаю как у кого, но у меня ваш вариант получился приблизительно в 100 раз медленнее за V1 V2 TO V1 TO V1. Берем SwiftForth, делаем:
Код: 1 value v1 2 value v2 code t1 ' v1 >body eax addr ' v2 >body ecx addr ebx 0 [eax] xchg ebx 0 [ecx] xchg ebx 0 [eax] xchg ret end-code : t2 v1 v2 to v1 to v2 ; : tt1 counter 100000000 0 do t1 loop counter swap - . ; : tt2 counter 100000000 0 do t2 loop counter swap - . ;
Запускаем tt1 и tt2 и смотрим на циферки.
Не знаю как у кого, но у меня ваш вариант получился приблизительно в 100 раз медленнее за V1 V2 TO V1 TO V1. Берем SwiftForth, делаем:
[code]1 value v1 2 value v2 code t1 ' v1 >body eax addr ' v2 >body ecx addr ebx 0 [eax] xchg ebx 0 [ecx] xchg ebx 0 [eax] xchg ret end-code : t2 v1 v2 to v1 to v2 ; : tt1 counter 100000000 0 do t1 loop counter swap - . ; : tt2 counter 100000000 0 do t2 loop counter swap - . ; [/code]
Запускаем tt1 и tt2 и смотрим на циферки. :)
|
|
|
|
Добавлено: Пт мар 28, 2008 18:01 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Forthware писал(а): А насчет XCHG, почитайте больше про эту комманду в доках от изготовителей процессоров. Если мне память не изменяет, она не просто медленнее (особенно с памятью), но там еще есть риск зависания конвейера, к тому же использует медленный декодер...
Ага, если внимательно прочитать про 5 исполнительных устройств Пентиума, то там только одно которе умеет работать с памятью.
Вот реализация под SwiftForth
Код: 1 value v1 2 value v2 code test ' v1 >body eax addr ' v2 >body ecx addr ebx 0 [eax] xchg ebx 0 [ecx] xchg ebx 0 [eax] xchg ret end-code
[quote="Forthware"]А насчет XCHG, почитайте больше про эту комманду в доках от изготовителей процессоров. Если мне память не изменяет, она не просто медленнее (особенно с памятью), но там еще есть риск зависания конвейера, к тому же использует медленный декодер... [/quote]
Ага, если внимательно прочитать про 5 исполнительных устройств Пентиума, то там только одно которе умеет работать с памятью.
Вот реализация под SwiftForth
[code]1 value v1 2 value v2 code test ' v1 >body eax addr ' v2 >body ecx addr ebx 0 [eax] xchg ebx 0 [ecx] xchg ebx 0 [eax] xchg ret end-code[/code]
|
|
|
|
Добавлено: Пт мар 28, 2008 14:27 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Alexander писал(а): 1) зачем экономить память стека данных, если даже для любой арифметической операции нужно две ячейки; Потому что такие условия задачи. Очевидно, что они совершенно виртуальны и никакого отношения к реальности не имеют. На то она и задача. Alexander писал(а): 2) применение слова VALUE оправдано лишь в случае редкого изменения хранимого значения и частого его получения, например, для хранения идентификаторов (дескрипторов); А это уже кому как. Конечно, доступ к изменению VALUE куда как хуже чем VARIABLE, однако он есть, и не факт что полученный код будет медленнее (смотри примеры выше). Так что вполне возможно что кому то удобнее работать с VALUE всегда. К тому же, обычная (ANSI) реализация локальных переменных использует тот же принцип доступа что и VALUE, при этом вы ведь не скажете что локальные переменные оправдано использовать лишь в случае редкого изменения хранимого значения? Верно? Alexander писал(а): 3) Возможно, что применение слова VARIABLE улучшило бы читаемость алгоритма и переписывание его на ассемблер с применением инструкции XCHG. Улучшило бы, конечно! Но не соответствует условиям задачи. А насчет XCHG, почитайте больше про эту комманду в доках от изготовителей процессоров. Если мне память не изменяет, она не просто медленнее (особенно с памятью), но там еще есть риск зависания конвейера, к тому же использует медленный декодер...
[quote="Alexander"]1) зачем экономить память стека данных, если даже для любой арифметической операции нужно две ячейки;[/quote]Потому что такие условия задачи. Очевидно, что они совершенно виртуальны и никакого отношения к реальности не имеют. На то она и задача. :D [quote="Alexander"]2) применение слова VALUE оправдано лишь в случае редкого изменения хранимого значения и частого его получения, например, для хранения идентификаторов (дескрипторов);[/quote]А это уже кому как. :roll: Конечно, доступ к изменению VALUE куда как хуже чем VARIABLE, однако он есть, и не факт что полученный код будет медленнее (смотри примеры выше). Так что вполне возможно что кому то удобнее работать с VALUE всегда. :roll: К тому же, обычная (ANSI) реализация локальных переменных использует тот же принцип доступа что и VALUE, при этом вы ведь не скажете что локальные переменные оправдано использовать лишь в случае редкого изменения хранимого значения? Верно? :) [quote="Alexander"]3) Возможно, что применение слова VARIABLE улучшило бы читаемость алгоритма и переписывание его на ассемблер с применением инструкции XCHG.[/quote]Улучшило бы, конечно! Но не соответствует условиям задачи. :) А насчет XCHG, почитайте больше про эту комманду в доках от изготовителей процессоров. Если мне память не изменяет, она не просто медленнее (особенно с памятью), но там еще есть риск зависания конвейера, к тому же использует медленный декодер... :?
|
|
|
|
Добавлено: Пт мар 28, 2008 13:14 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Итак у меня возникли вопросы:
1) зачем экономить память стека данных, если даже для любой арифметической операции нужно две ячейки;
2) применение слова VALUE оправдано лишь в случае редкого изменения хранимого значения и частого его получения, например, для хранения идентификаторов (дескрипторов);
3) Возможно, что применение слова VARIABLE улучшило бы читаемость алгоритма и переписывание его на ассемблер с применением инструкции XCHG. Тогда у вас будет задействована только вершина стека (в большинстве случаев это регистр процессора), но только в том случае если адреса переменных известны заранее и вы не собираетесь их передавать в качестве параметров для выполнения вновь созданного слова.
Итак у меня возникли вопросы:
1) зачем экономить память стека данных, если даже для любой арифметической операции нужно две ячейки;
2) применение слова VALUE оправдано лишь в случае редкого изменения хранимого значения и частого его получения, например, для хранения идентификаторов (дескрипторов);
3) Возможно, что применение слова VARIABLE улучшило бы читаемость алгоритма и переписывание его на ассемблер с применением инструкции XCHG. Тогда у вас будет задействована только вершина стека (в большинстве случаев это регистр процессора), но только в том случае если адреса переменных известны заранее и вы не собираетесь их передавать в качестве параметров для выполнения вновь созданного слова.
|
|
|
|
Добавлено: Пт мар 28, 2008 08:37 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
To Alexander:
http://fforum.winglion.ru/viewtopic.php?p=13396#13396
Однако не понятно к чему ваш ответ? Условиям оригинальной задачи chess решение "V1 V2 TO V1 TO V2" не соответствует, ибо сказано: "На стеке параметров перед присвоением должен лежать только один параметр.", а к задаче Garbler не имеет ввобще никакого отношения. К чему все это?
To [b]Alexander[/b]:
http://fforum.winglion.ru/viewtopic.php?p=13396#13396
Однако не понятно к чему ваш ответ? Условиям оригинальной задачи [b]chess[/b] решение "V1 V2 TO V1 TO V2" не соответствует, ибо сказано: "На стеке параметров перед присвоением должен лежать только один параметр.", а к задаче [b]Garbler[/b] не имеет ввобще никакого отношения. К чему все это? :?
|
|
|
|
Добавлено: Чт мар 27, 2008 16:47 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
V1 V2 TO V1 TO V2
Вообще-то надо помнить о семантике слов и не забывать то, что данные лежат на вершине стека данных
P.S. Чем проще решение, тем меньше кода.
Ссмысла гонятся за скоростью на современных ПК и МК нет.
V1 V2 TO V1 TO V2
Вообще-то надо помнить о семантике слов и не забывать то, что данные лежат на вершине стека данных :)
P.S. Чем проще решение, тем меньше кода.
Ссмысла гонятся за скоростью на современных ПК и МК нет.
|
|
|
|
Добавлено: Чт мар 27, 2008 15:25 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): Та же идея насчет переменной управляющей направлением передачи данных в адрес или из адреса реализованная не в рантайме, а во время компиляции. Совершенно верно. chess писал(а): Что касается скорости кода - для VALUE по-моему предельно возможная(спасибо оптимизатору), а у вас что - другое мнение(?). Нет, я имел ввиду VECT. Неудачно выразился. chess писал(а): Совместимость с АНСИ, если вы не поняли, меня не интересует. Тем не менее, она достигнута. Пусть будет как бонус. chess писал(а): Только $TO лучше определить через USER-CREATE (для многопоточности). Да, наверно.
[quote="chess"]Та же идея насчет переменной управляющей направлением передачи данных в адрес или из адреса реализованная не в рантайме, а во время компиляции.[/quote]Совершенно верно. [quote="chess"]Что касается скорости кода - для VALUE по-моему предельно возможная(спасибо оптимизатору), а у вас что - другое мнение(?).[/quote]Нет, я имел ввиду VECT. Неудачно выразился. ;) [quote="chess"]Совместимость с АНСИ, если вы не поняли, меня не интересует.[/quote]Тем не менее, она достигнута. :D Пусть будет как бонус. :) [quote="chess"] Только $TO лучше определить через USER-CREATE (для многопоточности).[/quote]Да, наверно.
|
|
|
|
Добавлено: Чт мар 20, 2008 16:09 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Forthware писал(а): Ну так есть же вариант с флагом, который устанавливает ТО, а далше все решает сама переменная. Такое подойдет?
Та же идея насчет переменной управляющей направлением передачи данных в адрес или из адреса реализованная не в рантайме, а во время компиляции. Конечно пойдет. Причем эта переменная "закрыта" от доступа даже лучше чем STATE(ну нет необходимости ее трогать программисту непосредственно).
Что касается скорости кода - для VALUE по-моему предельно возможная(спасибо оптимизатору), а у вас что - другое мнение(?). Для вектора можно поддержать ассм-ом и будет тоже предельная. Совместимость с АНСИ, если вы не поняли, меня не интересует.
Вообщем хорошее решение. Только $TO лучше определить через USER-CREATE (для многопоточности).
[quote="Forthware"]Ну так есть же вариант с флагом, который устанавливает ТО, а далше все решает сама переменная. Такое подойдет? [/quote]
Та же идея насчет переменной управляющей направлением передачи данных в адрес или из адреса реализованная не в рантайме, а во время компиляции. Конечно пойдет. Причем эта переменная "закрыта" от доступа даже лучше чем STATE(ну нет необходимости ее трогать программисту непосредственно).
Что касается скорости кода - для VALUE по-моему предельно возможная(спасибо оптимизатору), а у вас что - другое мнение(?). Для вектора можно поддержать ассм-ом и будет тоже предельная. Совместимость с АНСИ, если вы не поняли, меня не интересует.
Вообщем хорошее решение. Только $TO лучше определить через USER-CREATE (для многопоточности).
|
|
|
|
Добавлено: Чт мар 20, 2008 15:11 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
А вот в VFX и VECT получился вполне ассемблерный:
Код: 1 value v1 ok vect v2 ok : v1. v1 . ; ok ' v1. to v2 ok : xx v2 ; ok see xx XX ( 004ABEE0 FF1590BE4A00 ) CALL [004ABE90] V2 ( 004ABEE6 C3 ) NEXT, ( 7 bytes, 2 instructions ) ok
А вот в VFX и VECT получился вполне ассемблерный:
[code]1 value v1 ok vect v2 ok : v1. v1 . ; ok ' v1. to v2 ok : xx v2 ; ok see xx XX ( 004ABEE0 FF1590BE4A00 ) CALL [004ABE90] V2 ( 004ABEE6 C3 ) NEXT, ( 7 bytes, 2 instructions ) ok [/code] 8)
|
|
|
|
Добавлено: Ср мар 19, 2008 20:56 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): Пресловутая STATE-зависимость, ну вот так заработает: Ага! chess писал(а): Рантайм в интерактиве сам по себе малоинтересен - там быстродействие некритично, так как основное время сожрет поиск по словарю. Так точно. chess писал(а): А вот это по настоящему интересная задачка: сделать слово to не читающее из входного потока, под него сделать соответствующие value и vect. Основное требование - быстрый код реализации, Синтаксис использования - старый. Как вариант допускается использование таких to, value и vect только при компиляции. Ну так есть же вариант с флагом, который устанавливает ТО, а далше все решает сама переменная. Такое подойдет?
Если такой вариант устраивает и дело только в скорости, то вот, пожалуй максимум что можно получить в рамкам ANSI и вообще переносимости:
Код: CREATE $TO 0 , : $TO-VALUE ( A -- ) STATE @ IF POSTPONE LITERAL POSTPONE ! ELSE ! THEN 0 $TO ! ; : $DO-VALUE ( A -- ) STATE @ IF POSTPONE LITERAL POSTPONE @ ELSE @ THEN ; : $DO-VECT ( A -- ) STATE @ IF POSTPONE LITERAL POSTPONE @ POSTPONE EXECUTE ELSE @ EXECUTE THEN ;
: TO TRUE $TO ! ; IMMEDIATE : IS POSTPONE TO ; IMMEDIATE : VALUE CREATE , IMMEDIATE DOES> $TO @ IF $TO-VALUE ELSE $DO-VALUE THEN ; : VECT CREATE ['] ABORT , IMMEDIATE DOES> $TO @ IF $TO-VALUE ELSE $DO-VECT THEN ;
Смотрим в СПФ: Код: >1 VALUE V1 Ok >: @V1 V1 ; Ok >: !V1 TO V1 ; Ok >SEE @V1
587100 8945FC MOV FC [EBP] , EAX 587103 A1E0705800 MOV EAX , 5870E0 ( V1+5 ) 587108 8D6DFC LEA EBP , FC [EBP] 58710B C3 RET NEAR END-CODE Ok
>SEE !V1
587120 8905E0705800 MOV 5870E0 ( V1+5 ) , EAX 587126 8B4500 MOV EAX , 0 [EBP] 587129 8D6D04 LEA EBP , 4 [EBP] 58712C C3 RET NEAR END-CODE Ok
>VECT V2 Ok >' @V1 TO V2 Ok >: GOV2 V2 ; Ok >SEE GOV2
587170 8B0D50715800 MOV ECX , 587150 ( V2+5 ) 587176 8BD1 MOV EDX , ECX 587178 FFD2 CALL EDX 58717A C3 RET NEAR END-CODE Ok С использованием ассемблера, конечно можно быстрее (особенно VECT).
Однако уточните это ли вы имеете ввиду.
[quote="chess"]Пресловутая STATE-зависимость, ну вот так заработает:[/quote]Ага! :D [quote="chess"]Рантайм в интерактиве сам по себе малоинтересен - там быстродействие некритично, так как основное время сожрет поиск по словарю.[/quote]Так точно. :) [quote="chess"]А вот это по настоящему интересная задачка: сделать слово to не читающее из входного потока, под него сделать соответствующие value и vect. Основное требование - быстрый код реализации, Синтаксис использования - старый. Как вариант допускается использование таких to, value и vect только при компиляции.[/quote]Ну так есть же вариант с флагом, который устанавливает ТО, а далше все решает сама переменная. Такое подойдет?
Если такой вариант устраивает и дело только в скорости, то вот, пожалуй максимум что можно получить в рамкам ANSI и вообще переносимости:
[code]CREATE $TO 0 , : $TO-VALUE ( A -- ) STATE @ IF POSTPONE LITERAL POSTPONE ! ELSE ! THEN 0 $TO ! ; : $DO-VALUE ( A -- ) STATE @ IF POSTPONE LITERAL POSTPONE @ ELSE @ THEN ; : $DO-VECT ( A -- ) STATE @ IF POSTPONE LITERAL POSTPONE @ POSTPONE EXECUTE ELSE @ EXECUTE THEN ;
: TO TRUE $TO ! ; IMMEDIATE : IS POSTPONE TO ; IMMEDIATE : VALUE CREATE , IMMEDIATE DOES> $TO @ IF $TO-VALUE ELSE $DO-VALUE THEN ; : VECT CREATE ['] ABORT , IMMEDIATE DOES> $TO @ IF $TO-VALUE ELSE $DO-VECT THEN ; [/code] Смотрим в СПФ: [code]>1 VALUE V1 Ok >: @V1 V1 ; Ok >: !V1 TO V1 ; Ok >SEE @V1
587100 8945FC MOV FC [EBP] , EAX 587103 A1E0705800 MOV EAX , 5870E0 ( V1+5 ) 587108 8D6DFC LEA EBP , FC [EBP] 58710B C3 RET NEAR END-CODE Ok
>SEE !V1
587120 8905E0705800 MOV 5870E0 ( V1+5 ) , EAX 587126 8B4500 MOV EAX , 0 [EBP] 587129 8D6D04 LEA EBP , 4 [EBP] 58712C C3 RET NEAR END-CODE Ok
>VECT V2 Ok >' @V1 TO V2 Ok >: GOV2 V2 ; Ok >SEE GOV2
587170 8B0D50715800 MOV ECX , 587150 ( V2+5 ) 587176 8BD1 MOV EDX , ECX 587178 FFD2 CALL EDX 58717A C3 RET NEAR END-CODE Ok[/code] С использованием ассемблера, конечно можно быстрее (особенно VECT).
Однако уточните это ли вы имеете ввиду.
|
|
|
|
Добавлено: Ср мар 19, 2008 20:41 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Forthware писал(а): Вот так не работает:
Пресловутая STATE-зависимость, ну вот так заработает:
Код: REQUIRE IDN ~chess\assm\sp-assm.f
: VSWAP ' >BODY ' >BODY 2DUP STATE @ IF >CS C=@, >CS D=@, >CS @=D, >CS @=C, ELSE @ SWAP @ ROT ! SWAP ! THEN ; IMMEDIATE
1 VALUE V1 2 VALUE V2 V1 . V2 .
VSWAP V1 V2 V1 . V2 .
: TST VSWAP V1 V2 ; SEE TST TST V1 . V2 .
Рантайм в интерактиве сам по себе малоинтересен - там быстродействие некритично, так как основное время сожрет поиск по словарю.
А вот это по настоящему интересная задачка:
сделать слово to не читающее из входного потока,
под него сделать соответствующие value и vect.
Основное требование - быстрый код реализации,
Синтаксис использования - старый.
Как вариант допускается использование таких to, value и vect только при компиляции.
[quote="Forthware"]Вот так не работает: [/quote]
Пресловутая STATE-зависимость, ну вот так заработает:
[code]REQUIRE IDN ~chess\assm\sp-assm.f
: VSWAP ' >BODY ' >BODY 2DUP STATE @ IF >CS C=@, >CS D=@, >CS @=D, >CS @=C, ELSE @ SWAP @ ROT ! SWAP ! THEN ; IMMEDIATE
1 VALUE V1 2 VALUE V2 V1 . V2 .
VSWAP V1 V2 V1 . V2 .
: TST VSWAP V1 V2 ; SEE TST TST V1 . V2 .[/code]
Рантайм в интерактиве сам по себе малоинтересен - там быстродействие некритично, так как основное время сожрет поиск по словарю.
А вот это по настоящему интересная задачка:
сделать слово to [b]не читающее [/b]из входного потока,
под него сделать соответствующие value и vect.
Основное требование - быстрый код реализации,
Синтаксис использования - старый.
Как вариант допускается использование таких to, value и vect только при компиляции.
|
|
|
|
Добавлено: Ср мар 19, 2008 19:04 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): Привожу: Код: REQUIRE IDN ~chess\assm\sp-assm.f : VSWAP ' >BODY DUP ' >BODY DUP >CS C=@, SWAP >CS D=@, >CS @=D, >CS @=C, ; IMMEDIATE Вот так не работает: Код: V1 . V2 . 1 2 Ok VSWAP V1 V2 V1 . V2 . 1 2 Ok
[quote="chess"]Привожу: [code]REQUIRE IDN ~chess\assm\sp-assm.f : VSWAP ' >BODY DUP ' >BODY DUP >CS C=@, SWAP >CS D=@, >CS @=D, >CS @=C, ; IMMEDIATE[/code] [/quote] Вот так не работает: [code]V1 . V2 . 1 2 Ok VSWAP V1 V2 V1 . V2 . 1 2 Ok [/code]
|
|
|
|
Добавлено: Ср мар 19, 2008 16:43 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
WingLion писал(а): Это я к тому, что накрутки вокруг этого уже свапа кажутся не просто дикими, а дико сумасшедшими. Такая поставлена задача. А на практике, по моему, проще просто писать V1 V2 TO V1 TO V2 где надо, и ничего не выдумывать.
[quote="WingLion"]Это я к тому, что накрутки вокруг этого уже свапа кажутся не просто дикими, а дико сумасшедшими.[/quote]Такая поставлена задача. А на практике, по моему, проще просто писать V1 V2 TO V1 TO V2 где надо, и ничего не выдумывать. ;)
|
|
|
|
Добавлено: Вт мар 18, 2008 22:13 |
|
|
|
|