Откуда Вы взяли такие такты? Со времен Пентиума DAA - 3 такта, DAS - 3 такта, INTO - срабатывание 56 тактов, пропуск - 4 такта. Откуда взялись сотни тактов? Современные процессоры могут добавить задержку от 0.33 до 1.5 тактов. И, да, меня волнует эффективность моих программ, поэтому и использую аппаратную поддержку точных вычислений. И волнует надежность, поэтому и нужен аппаратный контроль переполнения.
Например, в PL/1 глубина стека задается в заголовке главной программы. Т.е. это принадлежность самого языка, а не редактора связей. Но это ладно. В представлении многих LLVM - это такая волшебная палочка в руках волшебников, которая все превращает в идеальный код. Но я не случайно спросил о стеке, потому что, похоже, в LLVM нет такого понятия вообще. Т.е. виртуальный процессор LLVM не очень похож на настоящие, как и у байт-кода, к примеру.
Шикарный совет не пользоваться FPU! И точность 80 бит здесь ни при чем. Попробуйте составить таблицы хотя бы для точности 32 бита. Как говорится, счастливого пути!
Конечно, если в игрушках какие-нибудь текстуры нужно быстро чуть повернуть, можно упрощенный расчет применять. Но не все сводится к текстурам...
Разумеется позволяют. Правда, это зависит от того, как редактор связей оформляет секции в exe-файле, например:
Object table:
# Name VirtSize RVA PhysSize Phys off Flags
-- -------- -------- -------- -------- -------- --------
01 .PROGRM 00A64F00 00001000 00A64F00 00000200 E8000020 [CEPRW]
02 .rsrc 00324200 00A66000 00324200 00A65200 42000040 [DIR]
03 .reloc 0002D3F0 00D8B000 0002D3F0 00D8A200 42000040 [DIR]
Key to section flags:
C - contains code
D - discardable
E - executable
I - contains initialized data
P - may not be paged
R - readable
W - writeable
Здесь программа может исправлять свои коды и данные (здесь и данные также пишутся в одну секцию с кодами). А вот "ресурсы" здесь неизменяемые, как и таблица настроек.
Спасибо, но это не то. Это то, что я назвал «телеметрией» самого процессора. Она тоже важна. Но, на мой взгляд, нужно и более простое средство: сколько тактов отработал заданный кусочек, а не сколько было при этом промахов или непредсказанных переходов.
Тогда получается, что только если действие короче 5 байт (что мало реально, разве какой-нибудь int 3), его не надо выносить из кода. Потому, что даже без подготовки параметров один вызов и короткий условный его обхода на байт длиннее, чем длинный условный. Правда, есть нюанс: длинный условный вроде декодируется дольше из-за префикса 0F и выигрыш в байт не обязательно даст или необязательно всегда даст выигрыш в скорости.
Как ни горько это писать, ошибся с выравниванием на 16. Это трансляторы IBM любители везде перед подпрограммами вставлять align 10h.
Невнимательно посмотрел. Пришлось посмотреть повнимательней.
И хотя в ядре есть и выравнивание на 8: 0740BD5C DC0D90BD4000............. FMUL64 [0040BD90]
0740BD62 EB96..................... JMPS 0740BCFA
0740BD64 90...................... NOP
0740BD65 90...................... NOP
0740BD66 90...................... NOP
0740BD67 90...................... NOP
0740BD68 DD 00000000 3FF00000-FFFFFFFF 7FEFFFFF
Все-таки подпрограммы в ядре XP или не выравниваются или выравниваются только на слово: 07404E93 F390.................. REP PAUSE
07404E95 EBF4.................. JMPS 07404E8B
07404E97 90.................... NOP
07404E98 8BFF.................. MOV EDI,EDI
07404E9A 9C.................... PUSHF
07404E9B 8B542410.............. MOV EDX,[ESP]+10
И именно это выравнивание на слово (а не мифическое выравнивание на 16) иногда сползает: 0740E392 5D..................... POP EBP
0740E393 C20C00................. RET 000C
0740E396 90..................... NOP
0740E397 55..................... PUSH EBP
0740E398 8BEC................... MOV EBP,ESP
0740E39A 56..................... PUSH ESI
0740E39B 57..................... PUSH EDI
От остальных претензий не отказываюсь.
Объяснение скачков туда-сюда улучшением работы кэша, так себе объяснение.
Ведь в приведенном примере переходом в 6 байт выполняется «удаленный» код лишь из 7 байт. Если бы он был не «удаленный» и обходился двухбайтовым условным переходом, то вместо 6 байт условного перехода было бы 9 байт кода. Неужели из-за этих жалких трех байт разницы длины будет ощутимо быстрее выполнение? Скорее уж, это какие-нибудь белые нитки от редактора связей.
Во-первых, главред Хабра сам призвал повторять материалы с других площадок, поскольку аудитория у Хабра больше.
Во-вторых, на RSDN ничего не объяснили, а некоторые даже ничего и не поняли.
В-третьих, если пустые команды (а, не MOV EDI,EDI) нужны для какой то технологии, то почему их разное количество в разных местах и почему, если их сдвинуть, то все начинает быть кратно 16?
Откуда столько знаков? Под мантиссу отводится 53 бита если перевести 53 единицы в десятичное число получится 9007199254740991, как раз 16 цифр. Внутренне представление FPU 80 бит, но и там столько десятичных цифр не набирается
В принципе согласен, но из всех неприятностей эта так же вероятна, как смерть от кирпича с крыши.
Хуже другое: отладчик и дизассемблер этого не понимают и показывают истинные команды))
Но это беда всех макрорасширений — в конечном коде можно заблудиться при отладке.
Например вот так https://habr.com/ru/post/536990/
Они не разные
Правильно. Зачем нужны легковые автомобили, когда можно прекрасно ездить на самосвале. У него и кабина просторнее и обзор лучше.
А вот сейчас стало обидно за компиляторы, которым надо реализовывать логические переменные true-false
я имею ввиду Win API - там четыре
первые четыре - через RCX, RDX, R8 и R9
Сообщите свои соображения разработчикам AMD64. Очевидно, они их не учли и в результате имеется двадцать лишних байтовых регистров.
Откуда Вы взяли такие такты? Со времен Пентиума DAA - 3 такта, DAS - 3 такта, INTO - срабатывание 56 тактов, пропуск - 4 такта. Откуда взялись сотни тактов? Современные процессоры могут добавить задержку от 0.33 до 1.5 тактов. И, да, меня волнует эффективность моих программ, поэтому и использую аппаратную поддержку точных вычислений. И волнует надежность, поэтому и нужен аппаратный контроль переполнения.
Например, в PL/1 глубина стека задается в заголовке главной программы. Т.е. это принадлежность самого языка, а не редактора связей. Но это ладно. В представлении многих LLVM - это такая волшебная палочка в руках волшебников, которая все превращает в идеальный код. Но я не случайно спросил о стеке, потому что, похоже, в LLVM нет такого понятия вообще. Т.е. виртуальный процессор LLVM не очень похож на настоящие, как и у байт-кода, к примеру.
Шикарный совет не пользоваться FPU! И точность 80 бит здесь ни при чем. Попробуйте составить таблицы хотя бы для точности 32 бита. Как говорится, счастливого пути!
Конечно, если в игрушках какие-нибудь текстуры нужно быстро чуть повернуть, можно упрощенный расчет применять. Но не все сводится к текстурам...
Подобные вопросы один персонаж еще более 200 лет назад задавал: к чему учить географию, если извозчики сами куда надо довезут?
Например, как через LLVM задать начальное значение стека в программе? То самое, которое в PE-заголовке называется size_of_stack_reserve?
а триногометрические функции Вы тоже будете командами SSE считать? И уж сразу полиномами Чебышева?
Разумеется позволяют. Правда, это зависит от того, как редактор связей оформляет секции в exe-файле, например:
Здесь программа может исправлять свои коды и данные (здесь и данные также пишутся в одну секцию с кодами). А вот "ресурсы" здесь неизменяемые, как и таблица настроек.
Невнимательно посмотрел. Пришлось посмотреть повнимательней.
И хотя в ядре есть и выравнивание на 8:
0740BD5C DC0D90BD4000............. FMUL64 [0040BD90]
0740BD62 EB96..................... JMPS 0740BCFA
0740BD64 90...................... NOP
0740BD65 90...................... NOP
0740BD66 90...................... NOP
0740BD67 90...................... NOP
0740BD68 DD 00000000 3FF00000-FFFFFFFF 7FEFFFFF
И выравнивание на 16:
0740A86E 74C1.................. JZ 0740A831
0740A870 E949FFFFFF.............. JMP 0740A7BE
0740A875 90..................... NOP
0740A876 90..................... NOP
0740A877 90..................... NOP
0740A878 90..................... NOP
0740A879 90..................... NOP
0740A87A 90..................... NOP
0740A87B 90..................... NOP
0740A87C 90..................... NOP
0740A87D 90..................... NOP
0740A87E 90..................... NOP
0740A87F 90..................... NOP
0740A880 803DD04D480000.......... CMP B PTR [00484DD0],00
0740A887 53...................... PUSH EBX
0740A888 56...................... PUSH ESI
Все-таки подпрограммы в ядре XP или не выравниваются или выравниваются только на слово:
07404E93 F390.................. REP PAUSE
07404E95 EBF4.................. JMPS 07404E8B
07404E97 90.................... NOP
07404E98 8BFF.................. MOV EDI,EDI
07404E9A 9C.................... PUSHF
07404E9B 8B542410.............. MOV EDX,[ESP]+10
0740E150 FC...................... CLD
0740E151 EBE5.................. JMPS 0740E138
0740E153 90..................... NOP
0740E154 55..................... PUSH EBP
0740E155 8BEC................... MOV EBP,ESP
0740E157 56................... . PUSH ESI
0740E158 57..................... PUSH EDI
И именно это выравнивание на слово (а не мифическое выравнивание на 16) иногда сползает:
0740E392 5D..................... POP EBP
0740E393 C20C00................. RET 000C
0740E396 90..................... NOP
0740E397 55..................... PUSH EBP
0740E398 8BEC................... MOV EBP,ESP
0740E39A 56..................... PUSH ESI
0740E39B 57..................... PUSH EDI
От остальных претензий не отказываюсь.
Объяснение скачков туда-сюда улучшением работы кэша, так себе объяснение.
Ведь в приведенном примере переходом в 6 байт выполняется «удаленный» код лишь из 7 байт. Если бы он был не «удаленный» и обходился двухбайтовым условным переходом, то вместо 6 байт условного перехода было бы 9 байт кода. Неужели из-за этих жалких трех байт разницы длины будет ощутимо быстрее выполнение? Скорее уж, это какие-нибудь белые нитки от редактора связей.
test:proc main;
dcl x float(53), s char(*) var;
x=1234.567890;
put data(time);
do to 100_000_000; s=x; end;
put data(time,s);
end test;
TIME= 19:17:44 TIME= 19:18:20 S= 1.23456788999999E+003
процессор i5-2310M 2.5 GHz
Во-вторых, на RSDN ничего не объяснили, а некоторые даже ничего и не поняли.
В-третьих, если пустые команды (а, не MOV EDI,EDI) нужны для какой то технологии, то почему их разное количество в разных местах и почему, если их сдвинуть, то все начинает быть кратно 16?
Хуже другое: отладчик и дизассемблер этого не понимают и показывают истинные команды))
Но это беда всех макрорасширений — в конечном коде можно заблудиться при отладке.