The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Arch Linux прекращает поддержку 32-разрядной архитектуры x86, opennews (??), 25-Янв-17, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


179. "Arch Linux прекращает поддержку 32-разрядной архитектуры x86"  –1 +/
Сообщение от Ю.Т. (?), 27-Янв-17, 23:31 
> Почему именно 4Гб? Почему не 3? На 32-битной системе процессу доступно лишь
> 3Gb виртуального адресного пространства. Это значит, что он максимум сможет иметь
> 3Gb физической памяти в своём распоряжении, даже если система умеет в
> PAE и имеет на борту 64Гб физической памяти.

4 гига виртуальных это всего лишь 4 гига, доступных одновременно машинному коду, т.е. задаваемых через операнды.

Ответить | Правка | Наверх | Cообщить модератору

181. "Arch Linux прекращает поддержку 32-разрядной архитектуры x86"  +1 +/
Сообщение от Orduemail (ok), 27-Янв-17, 23:48 
>> Почему именно 4Гб? Почему не 3? На 32-битной системе процессу доступно лишь
>> 3Gb виртуального адресного пространства. Это значит, что он максимум сможет иметь
>> 3Gb физической памяти в своём распоряжении, даже если система умеет в
>> PAE и имеет на борту 64Гб физической памяти.
> 4 гига виртуальных это всего лишь 4 гига, доступных одновременно машинному коду,
> т.е. задаваемых через операнды.

Не совсем. В смысле, в теории всё так, но практика как всегда хитрее любой теории. Верхний гигабайт виртуального адресного пространства процесса закрыт для ring3. Часть этого адресного пространства занято ядром, часть пустует, но в любом случае недоступно процессу. То есть, можно написать инструкцию, которая обратится по адресу 0xfffffffc, но результатом будет исключение процессора и segfault. Никакой mmap не поможет процессу исправить эту ситуацию и сделать 0xfffffffc валидным адресом. И там целый гигабайт таких адресов.

Ответить | Правка | Наверх | Cообщить модератору

182. "Arch Linux прекращает поддержку 32-разрядной архитектуры x86"  +/
Сообщение от Ю.Т. (?), 28-Янв-17, 00:21 
>>> Почему именно 4Гб? Почему не 3? На 32-битной системе процессу доступно лишь
>>> 3Gb виртуального адресного пространства. Это значит, что он максимум сможет иметь
>>> 3Gb физической памяти в своём распоряжении, даже если система умеет в
>>> PAE и имеет на борту 64Гб физической памяти.
>> 4 гига виртуальных это всего лишь 4 гига, доступных одновременно машинному коду,
>> т.е. задаваемых через операнды.
> Не совсем. В смысле, в теории всё так, но практика как всегда
> хитрее любой теории. Верхний гигабайт виртуального адресного пространства процесса закрыт
> для ring3. Часть этого адресного пространства занято ядром, часть пустует, но
> в любом случае недоступно процессу. То есть, можно написать инструкцию, которая

Ну так я же не о скрытом от процесса гиге (который тем не менее не пропадает), а о том что на борту есть и другие средства работы с физической памятью, и отождествлять физическую и адресуемую в операндах память -- совершенно некорректно.

Ответить | Правка | Наверх | Cообщить модератору

183. "Arch Linux прекращает поддержку 32-разрядной архитектуры x86"  +2 +/
Сообщение от Orduemail (ok), 28-Янв-17, 09:35 
>[оверквотинг удален]
>>> 4 гига виртуальных это всего лишь 4 гига, доступных одновременно машинному коду,
>>> т.е. задаваемых через операнды.
>> Не совсем. В смысле, в теории всё так, но практика как всегда
>> хитрее любой теории. Верхний гигабайт виртуального адресного пространства процесса закрыт
>> для ring3. Часть этого адресного пространства занято ядром, часть пустует, но
>> в любом случае недоступно процессу. То есть, можно написать инструкцию, которая
> Ну так я же не о скрытом от процесса гиге (который тем
> не менее не пропадает), а о том что на борту есть
> и другие средства работы с физической памятью, и отождествлять физическую и
> адресуемую в операндах память -- совершенно некорректно.

Ты хочешь намекнуть на то, что процесс пользуясь mmap и munmap может мапить себе разные кусочки физического адресного пространства и таким образом получить доступ ко всем 64Гб наличной физической памяти?

Тебе не кажется, что ты как-то совсем погряз в теории? Зачем это может быть нужно процессу? Какая ему разница, какой именно гигабайт физической памяти прячется за гигабайтом виртуальной? Но если всё-таки это нужно, то насколько это будет эффективнее, чем использование процессом 64-битного режима с 64-битной адресацией?

Ответить | Правка | Наверх | Cообщить модератору

184. "Arch Linux прекращает поддержку 32-разрядной архитектуры x86"  –1 +/
Сообщение от Ю.Т. (?), 28-Янв-17, 10:13 
> Ты хочешь намекнуть на то, что процесс пользуясь mmap и munmap может
> мапить себе разные кусочки физического адресного пространства и таким образом получить
> доступ ко всем 64Гб наличной физической памяти?

Я не хочу намекнуть, а прямо говорю, что начальное утверждение в #175:

"На 32-битной системе процессу доступно лишь 3Gb виртуального адресного пространства. Это значит, что он максимум сможет иметь 3Gb физической памяти в своём распоряжении, даже если система умеет в PAE и имеет на борту 64Гб физической памяти."

...неверно в корне и глаз режет. В распоряжении "процесса" ещё в лохматые времена физической памяти согласно конструктиву получалось иметь больше, чем адресовывалось сразу согласно машинно-кодовой (!) модели работы: DOS extenders и проч. (и это был класс ПО, действительно приносивший профит).

Ну хорошо, пусть будет "доступно одновременно", без переписывания селекторов, так всё равно неверно -- за счёт предзаписанных селекторов всё равно можно сразу больше.

Хорошо, пусть в винде и в прочих это традиционно монолит. Тогда другое твоё утверждение:

> Но если всё-таки это нужно, то насколько это будет эффективнее, чем использование процессом 64-битного режима с 64-битной адресацией?

А понятия не имею! Вот когда *ты* в последний раз работал с указателями на ассемблере 386+? Правильно, ты работаешь из высокого уровня, а значит, основной оверхед будет немного не там, где ты сейчас его ищешь. И в 2017-м ты никуда не денешься от наличия mmap.

Если же у тебя большие массивы, сравнимые с максимальным конструктивным объёмом хотя бы даже 32-разрядной арх-ры, то и так эту задачу следует решать за счёт распределённой обработки.

Ответить | Правка | Наверх | Cообщить модератору

185. "Arch Linux прекращает поддержку 32-разрядной архитектуры x86"  +2 +/
Сообщение от Orduemail (ok), 28-Янв-17, 10:59 
> Ну хорошо, пусть будет "доступно одновременно", без переписывания селекторов, так всё равно
> неверно -- за счёт предзаписанных селекторов всё равно можно сразу больше.

О, а это можно сделать из user-space в линуксе? Как?

>> Но если всё-таки это нужно, то насколько это будет эффективнее, чем использование процессом 64-битного режима с 64-битной адресацией?
> А понятия не имею! Вот когда *ты* в последний раз работал с
> указателями на ассемблере 386+? Правильно, ты работаешь из высокого уровня, а
> значит, основной оверхед будет немного не там, где ты сейчас его
> ищешь. И в 2017-м ты никуда не денешься от наличия mmap.

Слушай сюда, теоретик. Во-первых, с указателями я работаю постоянно, и gcc -S -- мой хороший друг. Я очень люблю разглядывать то, что он там накомпилировал и, отмечу, после перехода на x86_64 мне гораздо больше нравится то, что он выдаёт. Короче: не надо тут строить совершенно необоснованных гипотез о том, с чем я работаю и как я работаю. И не надо строить предположений о том, где и как я ищу оверхед.

Во-вторых. Я задал несколько вопросов, и намеренно задавал их в определённой последовательности. И первым вопросом было: скажите мне, зачем это надо? Я не собираюсь анализировать возможность и эффективность переключения банков памяти в 32-битном процессе до тех пор, пока у меня не будет конкретной задачи, которая потребует именно этого. Просто потому, что глупо было бы с моей стороны сравнивать производительность двух абстрактных систем, которые существуют только в твоей голове. Если, конечно, они действительно существуют в твоей голове: у меня есть серьёзное подозрение, что нет, что в твоей голове только куча теории, которая слабо связана с практикой.

> И в 2017-м ты никуда не денешься от наличия mmap.

Это ты к чему такое сказал вообще? То есть, какое воздействие на меня ты хотел оказать этой фразой? Что ты вообще думал о том, что думаю я, что счёл нужным произнести эти слова?

> Если же у тебя большие массивы, сравнимые с максимальным конструктивным объёмом хотя бы даже 32-разрядной арх-ры, то и так эту задачу следует решать за счёт распределённой обработки.

Ты сейчас соскакиваешь с темы. Если у меня массивы 4+Гб, то очень удобно иметь их в памяти. Распределённо ли их обрабатывать или нет -- это уже следующий вопрос, который совершенно нерелевантен данному обсуждению.

Ответить | Правка | Наверх | Cообщить модератору

186. "Arch Linux прекращает поддержку 32-разрядной архитектуры x86"  –1 +/
Сообщение от Ю.Т. (?), 28-Янв-17, 11:34 
> Слушай сюда, теоретик. Во-первых, с указателями я работаю постоянно, и gcc -S
> -- мой хороший друг. Я очень люблю разглядывать то, что он
> там накомпилировал и, отмечу, после перехода на x86_64 мне гораздо больше
> нравится то, что он выдаёт. Короче: не надо тут строить совершенно

Второй раз уже пренебрежительное "теоретик". Так вот, "практик", твой #175 был написан криво(вато); я прокомментировал; вместо кратко уточнить (мол, точнее было бы -- "в реальных современных ОС...") и закрыть вопрос, ты разводишь непонятно что.

Разумные предположения о задачах, для которых может быть хоть как-то существенен голый рост разрядности ЦПУ, ты презрительно отметаешь. Да, ты говоришь не о существенной проблеме.

Ну и так далее, кстати, почему-то чем дальше, тем грубее -- с чего это? ай-ай, усомнились в величии "сурового практика"?

Так удивись, старик -- мне совершенно безвыгодно с тобой препираться!!
Так пусть будет, что ты победил И в ЭтОм интернет-споре.
Сиди и дальше разглядывай машинный код (?!).

Ответить | Правка | Наверх | Cообщить модератору

187. "Arch Linux прекращает поддержку 32-разрядной архитектуры x86"  +/
Сообщение от Orduemail (ok), 28-Янв-17, 12:26 
>> Слушай сюда, теоретик. Во-первых, с указателями я работаю постоянно, и gcc -S
>> -- мой хороший друг. Я очень люблю разглядывать то, что он
>> там накомпилировал и, отмечу, после перехода на x86_64 мне гораздо больше
>> нравится то, что он выдаёт. Короче: не надо тут строить совершенно
> Второй раз уже пренебрежительное "теоретик". Так вот, "практик", твой #175 был написан
> криво(вато); я прокомментировал; вместо кратко уточнить (мол, точнее было бы --
> "в реальных современных ОС...") и закрыть вопрос, ты разводишь непонятно что.

О каких уточнениях может быть речь, если весь тред -- это флеймвар вокруг 32/64-битного линукса? То есть даже не "в реальных современных ОС", а ещё более конкретно: речь идёт конкретно о современном линуксе, что понятно всем кроме тебя, потому что ты цепляешься к отдельным фразам, игнорируя контекст, в которых эти фразы были произнесены.

> Так удивись, старик -- мне совершенно безвыгодно с тобой препираться!!

Я вижу. Лол.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру