>Хе.  Сам всё не добирался синхронизировать на буке (gvy) и дома
>(Michael Shigorin).
>Ладно, тогда остаётся только про министерство. :)
Ну вот, сам оказывается такой же :)

>Перечитайте -- я как раз о том, что даже не ">", а "=" -- не выйдет.  Впрочем, это как раз мелочи и Вы и так знали вроде:
Угу.Кой-какие основы х86 я знаю.Хотя и не шибко сильно.Однако при нужде как и вы найду через непродолжительное время поисков.

>>Самое интересное что я с этим и не спорил вроде.Я про дефолты.
>Я тоже.
Я там кстати похоже нагнал на линукс незаслуженно.Вроде, на х86 по дефолту наоборот - процесс может отожрать 3 гига или около того а системе остается около гига.

>Нет, конечно.  Просто если оппонент решает сместиться в ту сторону, то
>до точки "в морг" может иметь маленький смысл наехать по существу.
Это да, возможно вполне правильно :) просто перегибать тоже не надо - а то возникает стойкое и не очень конструктивное желание наехать в ответ.

>с тем, чтобы по возможности чего интересного подсказать и заодно дать
>повод задуматься, а стоило ли начинать бузу.
Думаю что эта цель была в чем-то достигнута, во всяком случае я очень кстати наткнулся на интересную статью как раз про объем доступной в i386 линуксным программам памяти.

>Возвращаясь к нашим баранам -- объёмы и характер организации памяти я упоминал
>к тому, чтобы разницу (критичную, а не "ну чуть медленней/быстрей") между
>32/64-битными архитектурами подчеркнуть на _типичных_ задачах.
Типичность задач - понятие относительное.Хотя да, пока еще - 4 гига памяти типичные задачи редко кушают.Но скоро будут.Лично я видел как программы (правда, в винде) вылетают когда 2Gb виртуального пространства закончились, хотя физической памяти при этом может жраться кстати вполне адекватно.Кстати эта проблема освещена на страничке посвященной проблеме C10K (10 000 соединений на 1 сервер) и серверам http использующим треды.Там меткое замечание что каждый тред жрет заметно виртуальной памяти (нечто типа 2 Мб на тред - под стек), итого после запуска заметного числа тредов процесс на 32-битной платформе может сурово обломаться из-за окончания адресного пространства (не окончании системной памяти!).Реально столько памяти конечно же процессом не используется (тред вовсе не обязан немедленно забить стек на 2 мега) - все это не представляло бы никаких проблем ... если б не ограниченность диапазона адресов.

>Так вот на сейчас тезис вида "ааа! на декстопе-32 нельзя выделить много
>байтов одному процессу!" -- несостоятелен при "много" порядка 2^32 по той
>простой причине, что /пока/ таких десктопных задач с аппетитами корпоративных СУБД
>-- скорее нет.  /Завтра/ ими будут, ессно, игрушки -- такой
Да ладно вам, просто задача с множественными тредами.См.выше про C10K.Задача с множеством тредов жрала бы не шибко то и много *физической* памяти и *свопа* (я так понимаю линукс выделяет страницы только когда они реально начинают юзаться?) но зато такая задача может налететь на тот факт что ее адресное пространство даденое процессу просто кончается(хотя ни своп ни физическая память не забиты).Итого получается бестолковое ограничение на число тредов на процесс, ничем особо не обоснованное кроме ограничений 32-битной архитектуры.

>Поэтому не было смысла орать о проблеме, которой нет:
См.выше - иногда проблемы бывают там где не ждали - скажем окончание адресного пространства при том что реально память не закончилась это довольно забавно, а? :)

> достаточно (и зачастую оптимально) использовать 32-битный режим
Ну, я использую в 64-битном :).Мне и так неплохо :).Как (временный?) бонус - некоторая устойчивость к фокусам скрипткиддей (у них сплойтов для х64 как-то не замечено тоннами).

>Так помню, где/как её искать ;)
Если мне приспичит я тоже найду, а вы что подумали?:)