Сообщение Re[13]: 32 bit от 15.03.2023 2:12
Изменено 15.03.2023 3:10 Философ
Re[13]: 32 bit
Здравствуйте, rudzuk, Вы писали:
R>А ты сам не видишь дичь в результатах своих замеров? 64-битный код с треском сливает 32-битному, работая в родном для себя режиме. И это объясняется тем, что процессор, оказывается, не так прост. фасепальм.
Во-первых я заглядывал в дизасм, в то, что получилось после джиттера. Во-вторых, я знаю что команды в современном x86 — это не инструкции. Сегодня x86 имеет RISC ядро, и сами команды декодирует в микрооперации, которые потом исполняте гипер-конвеер. Гипер-конвеерная архитектура появилаесь ещё в Pentium-4, а переупорядочивание команд в конвеере появилось ещё раньше аж в Pentium Pro, читать вот здесь.
Если ты посмотришь на модную штучку времён Core 2Duo ( Wide Dyanamic Execution) то увидишь там более 1 ALU.
В сочетании с переупорядочиванием инструкций (Out of order execution), то должен бы перестать удивлять тому, что частенько 2 команды выполняются дольше чем 5. Я этому удивляться перестал много лет назад, когда экспериментировал с командами процессора: у меня частенько rdtsc мерял 0 тактов на команду. Потом я открыл для себя fence-операции, в частности full-fence (примерно тогда уже узнал зачем нужен барьер памяти).
Понимаешь, нельзя сказать, сколько тактов займёт условный inc qword ptr [r15] и не получится его просто так сравнить с кодом аналогичного назначения для 32-бит. Поэтому и написать вручную оптимизированный ассемблерный код — совсем непростая задача.
R>Ну, сильно изменился общий результат?
Для начала расскажи как запускал. Есть серьёзное подозрение, что под дебаггером. На эту мысль наводят довольно большие цифры по сравнению с некоторыми моими. Например increment Int64 под x64 у меня более чем вдвое быстрее. Во-вторых, покажи что там компилятор паскали наоптимизировал.
Всё это получалось так: после получения резульатов на экране (код должен был отджитится) к процессу цеплялся WinDbg64. Не студией потому, что студия вностит коррективы в процесс Jitting'а, а меня тут интересовало то, что пойдёт в релиз — что будет на машине условного пользователя.
Показывай, что породил FPC для 64-бит, расскажи условия тестирования.
И наконец прекрати постить текст картинками!!!111111 У меня была идея взять твои результаты, посчитать медиану и стандартную ошибку, но с картинки это сделать невозможно.
R>А ты сам не видишь дичь в результатах своих замеров? 64-битный код с треском сливает 32-битному, работая в родном для себя режиме. И это объясняется тем, что процессор, оказывается, не так прост. фасепальм.
Во-первых я заглядывал в дизасм, в то, что получилось после джиттера. Во-вторых, я знаю что команды в современном x86 — это не инструкции. Сегодня x86 имеет RISC ядро, и сами команды декодирует в микрооперации, которые потом исполняте гипер-конвеер. Гипер-конвеерная архитектура появилаесь ещё в Pentium-4, а переупорядочивание команд в конвеере появилось ещё раньше аж в Pentium Pro, читать вот здесь.
Если ты посмотришь на модную штучку времён Core 2Duo ( Wide Dyanamic Execution) то увидишь там более 1 ALU.
В сочетании с переупорядочиванием инструкций (Out of order execution), то должен бы перестать удивлять тому, что частенько 2 команды выполняются дольше чем 5. Я этому удивляться перестал много лет назад, когда экспериментировал с командами процессора: у меня частенько rdtsc мерял 0 тактов на команду. Потом я открыл для себя fence-операции, в частности full-fence (примерно тогда уже узнал зачем нужен барьер памяти).
Понимаешь, нельзя сказать, сколько тактов займёт условный inc qword ptr [r15] и не получится его просто так сравнить с кодом аналогичного назначения для 32-бит. Поэтому и написать вручную оптимизированный ассемблерный код — совсем непростая задача.
R>Ну, сильно изменился общий результат?
Для начала расскажи как запускал. Есть серьёзное подозрение, что под дебаггером. На эту мысль наводят довольно большие цифры по сравнению с некоторыми моими. Например increment Int64 под x64 у меня более чем вдвое быстрее. Во-вторых, покажи что там компилятор паскали наоптимизировал.
| что произвёл джиттер | |||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||
Всё это получалось так: после получения резульатов на экране (код должен был отджитится) к процессу цеплялся WinDbg64. Не студией потому, что студия вностит коррективы в процесс Jitting'а, а меня тут интересовало то, что пойдёт в релиз — что будет на машине условного пользователя.
Показывай, что породил FPC для 64-бит, расскажи условия тестирования.
И наконец прекрати постить текст картинками!!!111111 У меня была идея взять твои результаты, посчитать медиану и стандартную ошибку, но с картинки это сделать невозможно.
Re[13]: 32 bit
Здравствуйте, rudzuk, Вы писали:
R>А ты сам не видишь дичь в результатах своих замеров? 64-битный код с треском сливает 32-битному, работая в родном для себя режиме. И это объясняется тем, что процессор, оказывается, не так прост. фасепальм.
Во-первых я заглядывал в дизасм, в то, что получилось после джиттера — там не было ничего экстраординарного. Во-вторых, я знаю что команды в современном x86 — это не инструкции. Сегодня x86 имеет RISC ядро, и сами команды декодирует в микрооперации, которые потом исполняте гипер-конвеер. Гипер-конвеерная архитектура появилаесь ещё в Pentium-4, а переупорядочивание команд в конвеере появилось ещё раньше аж в Pentium Pro, читать вот здесь.
Если ты посмотришь на модную штучку времён Core 2Duo ( Wide Dyanamic Execution) то увидишь там более 1 ALU.
В сочетании с переупорядочиванием инструкций (Out of order execution), то должен бы перестать удивлять тому, что частенько 2 команды выполняются дольше чем 5. Я этому удивляться перестал много лет назад, когда экспериментировал с командами процессора: у меня частенько rdtsc мерял 0 тактов на команду. Потом я открыл для себя fence-операции, в частности full-fence (примерно тогда уже узнал зачем нужен барьер памяти).
Понимаешь, нельзя сказать, сколько тактов займёт условный inc qword ptr [r15] и не получится его просто так сравнить с кодом аналогичного назначения для 32-бит. Поэтому и написать вручную оптимизированный ассемблерный код — совсем непростая задача.
R>Ну, сильно изменился общий результат?
Для начала расскажи как запускал. Есть серьёзное подозрение, что под дебаггером. На эту мысль наводят довольно большие цифры по сравнению с некоторыми моими. Например increment Int64 под x64 у меня более чем вдвое быстрее. Во-вторых, покажи что там компилятор паскали наоптимизировал.
Всё это получалось так: после получения резульатов на экране (код должен был отджитится) к процессу цеплялся WinDbg64. Не студией потому, что студия вностит коррективы в процесс Jitting'а, а меня тут интересовало то, что пойдёт в релиз — что будет на машине условного пользователя.
Тут на себя обращает внимание вот что:
это x86, как ты видишь. Т.е. цикл есть, а реально инкремента In64 vars нет — соптимизировал.
Тоже самое для In32 vars:
Самого инкремента переменных нет.
Зато в x64 он честно в цикле проинкрементил все регистры:
В общем, тесты с инкрементом переменных надо переделывать
С массивами при этом ничего неожиданного не произошло. Инкремент элемента массива делается классическим способом:
1)Int64
2) Int64 x64 — тоже ничего необычного, за исключением плясок с бубном вокруг регистра R15. Джиттеру наверное очень нравится адресовать элемент массива с помощью именно этого регистра.
2)Int32
Показывай, что породил FPC для 64-бит, расскажи условия тестирования.
И наконец прекрати постить текст картинками!!!111111 У меня была идея взять твои результаты, посчитать медиану и стандартную ошибку, но с картинки это сделать невозможно.
R>А ты сам не видишь дичь в результатах своих замеров? 64-битный код с треском сливает 32-битному, работая в родном для себя режиме. И это объясняется тем, что процессор, оказывается, не так прост. фасепальм.
Во-первых я заглядывал в дизасм, в то, что получилось после джиттера — там не было ничего экстраординарного. Во-вторых, я знаю что команды в современном x86 — это не инструкции. Сегодня x86 имеет RISC ядро, и сами команды декодирует в микрооперации, которые потом исполняте гипер-конвеер. Гипер-конвеерная архитектура появилаесь ещё в Pentium-4, а переупорядочивание команд в конвеере появилось ещё раньше аж в Pentium Pro, читать вот здесь.
Если ты посмотришь на модную штучку времён Core 2Duo ( Wide Dyanamic Execution) то увидишь там более 1 ALU.
В сочетании с переупорядочиванием инструкций (Out of order execution), то должен бы перестать удивлять тому, что частенько 2 команды выполняются дольше чем 5. Я этому удивляться перестал много лет назад, когда экспериментировал с командами процессора: у меня частенько rdtsc мерял 0 тактов на команду. Потом я открыл для себя fence-операции, в частности full-fence (примерно тогда уже узнал зачем нужен барьер памяти).
Понимаешь, нельзя сказать, сколько тактов займёт условный inc qword ptr [r15] и не получится его просто так сравнить с кодом аналогичного назначения для 32-бит. Поэтому и написать вручную оптимизированный ассемблерный код — совсем непростая задача.
R>Ну, сильно изменился общий результат?
Для начала расскажи как запускал. Есть серьёзное подозрение, что под дебаггером. На эту мысль наводят довольно большие цифры по сравнению с некоторыми моими. Например increment Int64 под x64 у меня более чем вдвое быстрее. Во-вторых, покажи что там компилятор паскали наоптимизировал.
| что произвёл джиттер | |||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||
Всё это получалось так: после получения резульатов на экране (код должен был отджитится) к процессу цеплялся WinDbg64. Не студией потому, что студия вностит коррективы в процесс Jitting'а, а меня тут интересовало то, что пойдёт в релиз — что будет на машине условного пользователя.
Тут на себя обращает внимание вот что:
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 208:
03280a4c 33c0 xor eax,eax
03280a4e 40 inc eax
03280a4f 3d80969800 cmp eax,989680h
03280a54 7cf8 jl 03280a4eэто x86, как ты видишь. Т.е. цикл есть, а реально инкремента In64 vars нет — соптимизировал.
Тоже самое для In32 vars:
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 172:
032808fb 33c0 xor eax,eax
032808fd 40 inc eax
032808fe 3d80969800 cmp eax,989680h
03280903 7cf8 jl 032808fdСамого инкремента переменных нет.
Зато в x64 он честно в цикле проинкрементил все регистры:
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 208:
00007ffd`1b290b69 33c9 xor ecx,ecx
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 210:
00007ffd`1b290b6b 488b5518 mov rdx,qword ptr [rbp+18h]
00007ffd`1b290b6f 48ffc2 inc rdx
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 211:
00007ffd`1b290b72 49ffc5 inc r13
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 212:
00007ffd`1b290b75 49ffc4 inc r12
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 213:
00007ffd`1b290b78 49ffc7 inc r15
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 214:
00007ffd`1b290b7b 49ffc6 inc r14
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 215:
00007ffd`1b290b7e 48ffc3 inc rbx
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 216:
00007ffd`1b290b81 48ffc7 inc rdi
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 217:
00007ffd`1b290b84 48ffc6 inc rsi
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 208:
00007ffd`1b290b87 ffc1 inc ecx
00007ffd`1b290b89 81f980969800 cmp ecx,989680h
00007ffd`1b290b8f 48895518 mov qword ptr [rbp+18h],rdx
00007ffd`1b290b93 7cd6 jl 00007ffd`1b290b6bВ общем, тесты с инкрементом переменных надо переделывать
С массивами при этом ничего неожиданного не произошло. Инкремент элемента массива делается классическим способом:
1)Int64
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 229:
03280acf 8d7918 lea edi,[ecx+18h]
03280ad2 8b07 mov eax,dword ptr [edi]
03280ad4 8b5704 mov edx,dword ptr [edi+4]
03280ad7 83c001 add eax,1
03280ada 83d200 adc edx,0
03280add 8907 mov dword ptr [edi],eax
03280adf 895704 mov dword ptr [edi+4],edx2) Int64 x64 — тоже ничего необычного, за исключением плясок с бубном вокруг регистра R15. Джиттеру наверное очень нравится адресовать элемент массива с помощью именно этого регистра.
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 230:
00007ffd`1b290c16 4d8bfa mov r15,r10
00007ffd`1b290c19 49ff07 inc qword ptr [r15]
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 231:
00007ffd`1b290c1c 4d8bfb mov r15,r11
00007ffd`1b290c1f 49ff07 inc qword ptr [r15]2)Int32
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 190:
03280946 ff00 inc dword ptr [eax]
C:\WorkingSet\sources\ConsoleApp12\ConsoleApp12\Program.cs @ 191:
03280948 ff4004 inc dword ptr [eax+4]Показывай, что породил FPC для 64-бит, расскажи условия тестирования.
И наконец прекрати постить текст картинками!!!111111 У меня была идея взять твои результаты, посчитать медиану и стандартную ошибку, но с картинки это сделать невозможно.