O>>Ноооо, можно перейти в 64х разрядную среду, сделать что нужно, и вернуться назад.
O>>Но компилятор таким трюкам конечно же не научить. Только асм, только хардкор.
кт>Во времена MS-DOS нечто похожее удавалось, но там среда мизерная, по сути отсутствовала. В какой-нибудь Windows 10 затраты на переключения убьют весь выигрыш от 64-разрядов посреди 32-х разрядной среды.
Не убьют, такие переключения происходят при каждом сисколле, так что если делать переключение перед какими то долгими вычислениями то все будет ништяк, т.к. переключение в другой режим это просто far jump с некоторой обвяхкой, и накладные расходы у него соответствующие. С компилятором возиться тоже вощемто нафиг не нужно, достаточно напистать честную 64хбитную длл, но зависящую только от ntdll.dll, затем с помощью этого трюка (для современных виндов требуется некоторая коррекция) вгрузить ее в АП wow64 процесса, получить адрес нужных экспортов и дергать за них.

Здравствуйте, кт, Вы писали:

кт>Есть еще и сигналы прерываний, на которые надо правильно реагировать. В целом да, можно организовать смесь 32+64, но на сегодняшний день, по-моему, уже нет смысла. Надо писать в 64-разрядной среде и все.
Вот тут я не согласен. Если приложение не предполагает выживание всех соков из железа. То программа должна пускаться на любом утюге и не привередничать.
Особенно если это что-то гуёвое и утилитарное. Иначе простой калькулятор котый работал на 32кГц на 8битном проце с 128байтами озу, теперь будет требовать 64бит ОС, самый последний .net core и 20Гб озу, что бы просто складывать и вычитать, ах да и качать последние обновлениия в момент кода должен был выполнять основной функционал. Хотя всем плевать все тупо созерцают. Ведь милион мух, уверенных в своей без ошибочности, это яро одобряет.

кт>К счастью, в ближайший миллиард лет переход с 64 разрядной памяти на 128-разрядную не грозит
Нас тут пугают что вот-вот и кубиты покажут превосходство и нейро сетей поменяют архитектуру. Взгляните на разрядность шин данных видео ускорителей

Можно ли компилятору (VC или gcc) подсказать, что-бы он использовал x64 команды при необходимости (с префиксом конечно же) в x32 среде Windows (и x32 бинарнике конечно же) ?
Это необходимо для ускорения вычислений над 64 битными числами.
Если нет, какие есть варианты решения данной задачи? В ручную на ассемлере очень много писать придётся.

Здравствуйте, maks1180, Вы писали:

M>Можно ли компилятору (VC или gcc) подсказать, что-бы он использовал x64 команды при необходимости (с префиксом конечно же) в x32 среде Windows (и x32 бинарнике конечно же) ?
Увы, но таких префиксов, которые были при переходе с 16 на 32, теперь нет. 64-разрядные команды распознаются только в 64-разрядной среде.

M>Это необходимо для ускорения вычислений над 64 битными числами.
Используйте команды FPU, целые числа до 2**64 там точные.

Здравствуйте, кт, Вы писали:

кт>Используйте команды FPU, целые числа до 2**64 там точные.
Это ж наверно тормоза будут куда как большие, чем в 32-х разрядными числами в обычных регистрах оперировать с учетом переноса и всех дел. Во всяком случае пока разговор про сложение и вычитание, с умножением и делением вопрос конечно интересный.

Здравствуйте, pagid, Вы писали:

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

Времена, когда FPU было сопроцессором и требовалась команда Wait для ожидания окончания выполнения инструкции давно прошли вместе с 386.
Сейчас только тригонометрия и SQRT выполняются сравнительно долго, обычная арифметика — соизмерима с обычными регистровыми командами. Легко проверяется тестами.

M>>Можно ли компилятору (VC или gcc) подсказать, что-бы он использовал x64 команды при необходимости (с префиксом конечно же) в x32 среде Windows (и x32 бинарнике конечно же) ?
кт>Увы, но таких префиксов, которые были при переходе с 16 на 32, теперь нет. 64-разрядные команды распознаются только в 64-разрядной среде.
Ноооо, можно перейти в 64х разрядную среду, сделать что нужно, и вернуться назад.
Но компилятор таким трюкам конечно же не научить. Только асм, только хардкор.

Здравствуйте, ononim, Вы писали:

O>Ноооо, можно перейти в 64х разрядную среду, сделать что нужно, и вернуться назад.
O>Но компилятор таким трюкам конечно же не научить. Только асм, только хардкор.

Во времена MS-DOS нечто похожее удавалось, но там среда мизерная, по сути отсутствовала. В какой-нибудь Windows 10 затраты на переключения убьют весь выигрыш от 64-разрядов посреди 32-х разрядной среды.
А компилятор можно научить — ведь переключения будут в системной библиотеке, а ему только смесь 32+64 генерировать, это не так и сложно.
Я работал некоторое время в 32-х разрядной среде 16-разрядной MS-DOS 6.21. Все было хорошо и весьма эффективно. Но затем прогресс нанес удар в спину — в DOS просто так новую флэшку не вставишь. Пришлось перебираться в win32 и механизм переключения стал бессмысленен.
А когда переходил на 64 разряда — первая мысль была как у автора ветки: щас квакну выполню пару команд в 64 и опять прыг в свое 32-х разрядное болото. А оно, вот оно что, Михалыч...

Здравствуйте, ononim, Вы писали:

O>>>Ноооо, можно перейти в 64х разрядную среду, сделать что нужно, и вернуться назад.
O>>>Но компилятор таким трюкам конечно же не научить. Только асм, только хардкор.
кт>>Во времена MS-DOS нечто похожее удавалось, но там среда мизерная, по сути отсутствовала. В какой-нибудь Windows 10 затраты на переключения убьют весь выигрыш от 64-разрядов посреди 32-х разрядной среды.
O>Не убьют, такие переключения происходят при каждом сисколле, так что если делать переключение перед какими то долгими вычислениями то все будет ништяк, т.к. переключение в другой режим это просто far jump с некоторой обвяхкой, и накладные расходы у него соответствующие. С компилятором возиться тоже вощемто нафиг не нужно, достаточно напистать честную 64хбитную длл, но зависящую только от ntdll.dll, затем с помощью этого трюка (для современных виндов требуется некоторая коррекция) вгрузить ее в АП wow64 процесса, получить адрес нужных экспортов и дергать за них.
У нас же многоядерные процессоры. Они могут обобщаться друг с другом и находится в разных режимах одновременно (один в long mode, другое в compatibility а третье в real) или нет?

Здравствуйте, ononim, Вы писали:

O>Не убьют, такие переключения происходят при каждом сисколле, так что если делать переключение перед какими то долгими вычислениями то все будет ништяк, т.к. переключение в другой режим это просто far jump с некоторой обвяхкой, и накладные расходы у него соответствующие. С компилятором возиться тоже вощемто нафиг не нужно, достаточно напистать честную 64хбитную длл, но зависящую только от ntdll.dll, затем с помощью этого трюка (для современных виндов требуется некоторая коррекция) вгрузить ее в АП wow64 процесса, получить адрес нужных экспортов и дергать за них.

Есть еще и сигналы прерываний, на которые надо правильно реагировать. В целом да, можно организовать смесь 32+64, но на сегодняшний день, по-моему, уже нет смысла. Надо писать в 64-разрядной среде и все.
К счастью, в ближайший миллиард лет переход с 64 разрядной памяти на 128-разрядную не грозит

_>У нас же многоядерные процессоры. Они могут обобщаться друг с другом и находится в разных режимах одновременно (один в long mode, другое в compatibility а третье в real) или нет?
Конечно, более того — при исполнении wow64 процесса каждый тред переходит туда-обратно 100500 раз в секунду. Ибо почти каждый системный вызов в wow64 версии ntdll реализован как переключение в long mode, конверсия параметров, вызов в ядро через нативную ntdll и после возврата — тоже самое в обратном порядке.
Некоторые сиссколлы вызывают ядро напрямую, но все равно там происходит переключение в long mode.
long mode — это не невесть что, а лишь аттрибут селектора, который в данный момент выбран в cs. То есть является частью контекста потока, как и все остальные регистры процессора.

Здравствуйте, kov_serg, Вы писали:

_>Нас тут пугают что вот-вот и кубиты покажут превосходство и нейро сетей поменяют архитектуру. Взгляните на разрядность шин данных видео ускорителей

Это разрядность данных (например, AVX-команды и регистры), а я про разрядность адресации.
Сначала был 8086 с адресацией 64К, а памяти — 1 Мбайт (да, те самые 640 К, которых хватит всем).
Затем память быстро превысила 1 Мбайт. Затем перешли на 32, но и память быстро превысила 4Г.
Тогда перешли на 64. А вот персоналки с 4 миллиардами микросхем по 4Гбит каждая пока не предвидится

Здравствуйте, кт, Вы писали:

кт>Это разрядность данных (например, AVX-команды и регистры), а я про разрядность адресации.
Да именно разрядность шины данных.
кт>Сначала был 8086 с адресацией 64К, а памяти — 1 Мбайт (да, те самые 640 К, которых хватит всем).
кт>Затем память быстро превысила 1 Мбайт. Затем перешли на 32, но и память быстро превысила 4Г.
кт>Тогда перешли на 64. А вот персоналки с 4 миллиардами микросхем по 4Гбит каждая пока не предвидится
Так сейчас шина адреса 48бит, а не 64. При этом всякие 8бит микроконтроллеры с 128байтами памяти досих пор спокойно работают.

Здравствуйте, kov_serg, Вы писали:

_>Так сейчас шина адреса 48бит, а не 64. При этом всякие 8бит микроконтроллеры с 128байтами памяти досих пор спокойно работают.
Так и я про то, что переходить с адреса 64 на адреса 128 нет никакой физической необходимости.
Для нас переход адресации с 32 на 64 был последним. Поэтому желательно скорее переходить в 64-разрядную среду и привыкнуть к ней. Частные случаи микроконтроллеров и малой разрядности касаются лишь не очень большой части программистов.

Здравствуйте, kov_serg, Вы писали:

_>Нас тут пугают что вот-вот и кубиты покажут превосходство и нейро сетей поменяют архитектуру. Взгляните на разрядность шин данных видео ускорителей
ЦПУ сейчас имеют 64-битную шину на канал (72-битную в случае ECC), то есть какой-нить i7 с четырёхканальных контроллером памяти де-факто имеет шину шириной в 64*4=256 бит, что уже не так уж и мало. А учитывая, что DDR3/4 отдают данные только по восемь порций за раз (архитектура 8n prefetch), то каждая транзакция чтения из памяти выдает сразу 256*8=2048 бит данных, и ни грамма меньше.

Здравствуйте, кт, Вы писали:


кт>Для нас переход адресации с 32 на 64 был последним. Поэтому желательно скорее переходить в 64-разрядную среду и привыкнуть к ней. Частные случаи микроконтроллеров и малой разрядности касаются лишь не очень большой части программистов.
Большая часть программистов (пишут на жабаскрипт, питонах и т.п.) решают утилитарные задачи им разрядность процессора не важна. Тем более потребителю глубоко фиолетово что там за фигня внутри твориться, оно должно работать и решать поставленные задачи.
Для остальных, что бы лучше привыкалось C++ int в 64битном режиме равен 32бита