> Ты хочешь намекнуть на то, что процесс пользуясь mmap и munmap может
> мапить себе разные кусочки физического адресного пространства и таким образом получить
> доступ ко всем 64Гб наличной физической памяти?Я не хочу намекнуть, а прямо говорю, что начальное утверждение в #175:
"На 32-битной системе процессу доступно лишь 3Gb виртуального адресного пространства. Это значит, что он максимум сможет иметь 3Gb физической памяти в своём распоряжении, даже если система умеет в PAE и имеет на борту 64Гб физической памяти."
...неверно в корне и глаз режет. В распоряжении "процесса" ещё в лохматые времена физической памяти согласно конструктиву получалось иметь больше, чем адресовывалось сразу согласно машинно-кодовой (!) модели работы: DOS extenders и проч. (и это был класс ПО, действительно приносивший профит).
Ну хорошо, пусть будет "доступно одновременно", без переписывания селекторов, так всё равно неверно -- за счёт предзаписанных селекторов всё равно можно сразу больше.
Хорошо, пусть в винде и в прочих это традиционно монолит. Тогда другое твоё утверждение:
> Но если всё-таки это нужно, то насколько это будет эффективнее, чем использование процессом 64-битного режима с 64-битной адресацией?
А понятия не имею! Вот когда *ты* в последний раз работал с указателями на ассемблере 386+? Правильно, ты работаешь из высокого уровня, а значит, основной оверхед будет немного не там, где ты сейчас его ищешь. И в 2017-м ты никуда не денешься от наличия mmap.
Если же у тебя большие массивы, сравнимые с максимальным конструктивным объёмом хотя бы даже 32-разрядной арх-ры, то и так эту задачу следует решать за счёт распределённой обработки.
