Уже PAE не нужен? А как попрекали лет 10 назад микрософт за то, что создавали 64-битное ПО и 64-битную архитектуру.

Это, скорее всего, был Banias, где PAE поддерживается, но не отражается в cpuid, поэтому система считала, что проц не поддерживает pae. В линуксе помогает параметр ядра forcepae.

Покажите-ка мне RHEL 7.4 для i386

Лол, а что сразу не поддержку ЕС ЭВМ показать? RHEL поддерживает все актуальные архитектуры своей энтерпрайзной продуктовой ниши — AMD64, Power, System z. И это несколько архитектур.

Лол, а что сразу не поддержку ЕС ЭВМ показать? RHEL поддерживает все актуальные архитектуры своей энтерпрайзной продуктовой ниши — AMD64, Power, System z. И это несколько архитектур.

Это же он утверждал, что красношляпа не такая. Такая же, точно также выбросила i386 на свалку. И причем выбросила не только из флагманских серверных продуктов, но и из всех продуктов этой линейки.

Это же он утверждал, что красношляпа не такая

И он абсолютно прав — шляпа поддерживает разные архитектуры.

Такая же

А ты нагло врёшь.

точно также выбросила i386 на свалку

Нет, не также. Арч поддерживал две архитектуры, что минус один и даёт утверждаемую тобой поддержку одной архитектуры, рхел же выкинул только одну из нескольких поддерживаемых и продолжает поддерживать несколько архитектур. Не понимать этого может либо идиот, либо демагог. Кто ты из этих двух типов?

PAE - это гнилющий костыль, типа EMS. Не взлетел - и чудненько.

Зачем на железе с менее чем 64 гб оперативной памяти 64-битный пингвин? Чтобы софт жрал больше?

На самом деле, PAE не панацея даже при объёме ОЗУ <= 64 Гб, т. к. один процесс всё равно получает не больше 2 Гб в Линуксе или 3 Гб в Windows.

Что касается 2007 года, то тогда PAE была ещё актуальна, хотя 64-битные процы уже появились. И о какой Windows идёт речь? Если о 64-битной хрюшке, то они её так и не допилили: поддержка железа и прикладного ПО на ней была минимальна.

т. к. один процесс всё равно получает не больше 2 Гб в Линуксе или 3 Гб в Windows.

Кто-то наоборот, этому рад. А оперативку в таком количестве держит для многозадачности.

Ты понимаешь, зачем вообще нужны указатели?

win_vista_x64 8-)) RTM 8/11/2006; GA - 30JAN2007

Вы тут с катушек послетали? 2003 - первые Атлоны х64 ваапсче. ОСи не готовы, все смотрят на это с немалым недоумением, а чо пускать то? Линуксоиды, конечно, молодцы, быстро смогли скомпилироваться, еще и ХРя какая-то типа 64 битная вышла.

2006й - сокет АМ2 и ДДР2, куча новых Атлонов х2.

А в тут РАЕ вспоминаете. хнык хнык,
Загнал висту х64 году так в середине 2007, на своем семпроне для сокета АМ2, вот кстати, проц валяется никому не нужный. Офигел от скорости загрузки, по сравнению с ХР. почти в два раза быстрее.

т. к. один процесс всё равно получает не больше 2 Гб в Линуксе или 3 Гб в Windows.

Кто-то наоборот, этому рад. А оперативку в таком количестве держит для многозадачности.

Кто-то — да. А кто-то — нет. И те, кому память нужна для одного процесса (а это обычно те, кто активно работает с 3d-графикой, САПР'ами, растровой графикой с высоким разрешением, анимацией и т. д.), на самом деле нуждаются в ней куда больше, чем те, кому надо запустить 100 экземпляров браузера одновременно. В конце концов, если мне не хватит памяти на запуск 100 экз., — запущу 10, если не хватит на запуск 10, то запущу 2. И всё, что мне надо, посмотрю, хотя, м. б., это будет не так удобно, как хотелось бы. А вот если 3d-сцена не помещается в оперативку, то с такой сценой уже ничего не сделать, ну разве что обрабатывать её вместо 10 минут 10 месяцев.

Когда нибудь, мы расскажем тебе про списки, хеш-таблицы, деревья и прочие структуры данных, которых нет в стандартной библиотеке C.

Этож сколько надо экземпляров структур, чтобы стал актуален вес именно их, а не данных...

С PAE?

Pae на WinXP заблокировали еще во втором сервис-паке.

Кто-то использует объёмные массивы указателей?

Сишечка же. Как там иначе реализовать многомерные массивы?

Через одномерные массивы и формулы преобразования координат в этих многомерных массивах в конкретный индекс этого одномерного массива.

Например, 2-х мерный массив получается так:

a[y*w+x];

Этож сколько надо экземпляров структур, чтобы стал актуален вес именно их, а не данных...

Эээ... Роутинг подсетей IPv4, например. Адрес подсети — 4 байта. Размер указателя — 8 байт. Или k-v база данных с большим количеством маленьких пар. Или аллокатор памяти. Короче, почти любая задача за пределами твоего кругозора.

Это если у тебя матрица. В общем случае длина вложенного массива может быть переменной.

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

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

А потом кто-то решит расширить какое-то значение и... Короче, как только в дело вступают изменяемые данные, одномерный массив не работает.

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

А потом кто-то решит расширить какое-то значение и...

И придётся синхронизировать оба массива. Передвинуть содержимое первого массива и обновить информацию во втором.

Бгг. Передвинуть там ничего нельзя, там будет копирование всего массива, если удлиннить значение в начале.

Линус задвигал когда-то со всеми выкладками, почему PAE не нужен.

Да там особо нет никаких выкладок, просто его жопоболь. Вполне себе инженерный подход: 1) получили возможность распоряжаться более чем 4GB RAM; 2) не поломали бинарную совместимость с существующим ПО. Какие там проблемы были у разработчиков ядра белых господ и производителей железа вполне ожидаемо не волнует.

Что значит «нельзя»? Какое ещё «копирование всего массива»?

Допустим, у нас есть массив, который содержит многомерные подмассивы A, B, C и D.

ABCD

0123

AABCD

0234

Другой вопрос, что передвигать может быть, да, много. Но, не вручную же. Машина не устаёт.

Лол. Еще раз — ты не можешь ничего передвинуть, это массив. Ты можешь только расширить массив и скопировать ячейки со смещением. Чаще всего это слишком дорого, потому что делать приходится часто.

По-ходу, да, мы называем одно и тоже разными словами.

Что, кстати, не отменяет того, что разные изменяющиеся по размеру многомерные массивы можно держать в разных одномерных массивах. А в один одномерный массив складывать только те многомерные массивы, которые никогда не изменяются по размеру.

Теперь к сложности расширения добавилась сложность поиска.

Какие там проблемы были у разработчиков ядра

Ты читать тот пост не пробовал? Там нет ни слова о проблемах ядра. Там, хотя достаточно эмоционально, в своём стиле, он рассказывает о том, почему те, кто думает, что для использования больше 4GB использовать PAE — вполне здравая идея, не совсем правы. Я, кстати, в своё время совершенно независимо от него убедился в том, что уже при 2Gb оперативы на 32-х битах начинает не хватать виртуального адресного пространства.

Вполне себе инженерный подход

Угу. Только нежизнеспособный. Просто в 95м году ещё никто даже не догадывался, как оно будет в реале работать на объёмах оперативки в районе 4GB, ведь в следующем, 1996м, за новенькую Sun Ultra 1 200 с 256Мб надо было выложить почти $30000. И до AGP, которая протянула шаловливые ручки в виртуальное адресное пространство, было ещё два года. И с многозадачностью ещё было довольно плохо.

Всё-таки ты идиот.

У нас на инфе на i3 Skylake 32 бит винда 7, лол.

Речь про экономию памяти или что? Есть 2 пути: «обработка данных порциями» и «обработка данных в один проход».

Второй путь, конечно, быстрее, но требователен к памяти, и подразумевает, что её у юзера куры не клюют. Первый путь как раз таки применялся на машинах со считанными килобайтами оперативками, куда все данные, чтобы их обработать за один проход, просто не влезут.

И если грузить весь большой объём данных в оперативку, то расход на структуры и указатели тут уже не так существенен. Он существенен если нужно экономить память, и для этого данные грузятся в оперативку порциями.

не так существенен

Гонево. Даже если на сервере памяти дохрена, ее лучше экономить и пускать на более полезные вещи. Разумеется, если экономия существенная.

что уже при 2Gb оперативы на 32-х битах начинает не хватать виртуального адресного пространства.

А теперь притормози на секундочку и подумай, что если бы у тебя не было 2Gb оперативы, то и проблемы такой не было бы. В те времена отдельные приложения вполне себе укладывались в 1-2 гигабайта, однако запускать десяток таких приложений на одной машине — это была неплохая экономия места в серверной датацентре. PAE решал определенную задачу, и решал неплохо.

Только нежизнеспособный

А кто ж виноват, что народ кругом так полюбил страницную организацию памяти? Могли бы себе спокойненько, как во времена 286-х жить на сегментах до 4 гигабайт и использовать ds, es, fg, gs — аж до 16 гигабайт из одного приложения.

полную маркировку процессора?

поди какая-нибудь экзотика, типа трансметы?

т. к. один процесс всё равно получает не больше 2 Гб в Линуксе

тогда для кого настройку memory split сделали в menuconfig? или она не работает?

PAE взлетел и своё дело сделал: в переходный период между 32 и 64 битами помог эффективнее распоряжаться памятью.

Грубо говоря, адресация памяти длиннее выходит на 64 битах.

Это будут дикие костыли с дичайше неэффективным использованием ресурсов. С таким подходом лучше сразу поставить systemd и wayland.

Первый путь как раз таки применялся на машинах со считанными килобайтами оперативками

Вот только на домашних ПК не считанные килобайты оперативной памяти.

тут такое дело, что PAE это действительно костыль. тебе фактически приходится поддерживать три набора кода - для х86-32, x86-32-PAE и х86-64. процы уже новые все х64, кроме атома, но атом не проц, и проживет на <=4gb. если ты лично хочешь, тащи код PAE сам.

Наборов-то плашек из 8 нет, а ведь очень важно ставить плашки даже не то что из одного производителя, а даже из одной партии/одной упаковки.

даже из одной партии/одной упаковки.

а за это скажи спасибо JEDEC. есть такая штука как on-die-termination. реализовано это так: у тебя есть PHY DDR3, по сути - трансивер. Вот тебе пример такого трансивера:

https://caslab.e-ce.uth.gr/journals/J16-CAEE_2012.pdf

Он имеет следующие режимы:

Z - это когда он отключается от линии, и наружу торчит только сопротивление блока ESD + ёмкость трасивера через R=~10ом. это R тоже элемент ESD, он сделан для того, чтоб лютый разряд ушел через входные lvscr -элементы, после резистора еще такие же стоят, но резак не дает потенциалу прорваться к затворам.

прием: это когда верхние и нижние «ножки»(см пример) дают одинаковое сопротивление до Vio и GND. т.е. там есть транзисторы которые стоят в режиме усиления, и выполняющие роль резистора, калибруемые на Rtt, и транзисторы в режиме ключа. К Vio и GND дают по 2Rtt, что по переменному току приводит к общему импедансу вдвое меньше - Rtt ровно.

передача: это когда ножка подключается чисто к Vio или GND. то есть если на прием было 3 на плюс и 3 на ноль, то теперь будет 6 на плюс или 6 на ноль.

когда у тебя много планок, то для улучшения приема адресуемая планка поднимает свой импеданс. это называется dynamic on-die-termination(dynamic ODT). но, по постоянному току все остальные планки будут тянуть уровень к Vio/2+небольшая дельта. проблема возникает от того, что они неодинаково тянут. в разных партия микросхем параметры транзисторов гуляют. Есть «углы» так называемые. быстрый-nmos/медленный-nmos/быстрый pmos/медленный-pmos и вот эта дельта она действует и на входные компараторы, и на трансивер. может оказаться так, что 5 планок опускают «Vio/2» вниз по постоянному току, а у 3х планок «Vio/2» поднят вверх на входе компараторов.

Тут чистая электрика плюс длинные линии. никакая мамка этого не исправит, т.к. максимум что она может сделать - это обеспечить постоянное волновое сопротивление линии. А отражения идут с микросхем, и выглядят они как завалы фронтов. Если ты подключил до хера планок в параллель, то извини - JEDEC тебе лично ничего не гарантирует. это UB в чистом виде

И ловить феерические глюки с вендорскими дровами.

А ещё для второго пути есть mmap. Но тс-с-с.

Нуу... mmap так себе решение, если мы про file-based операции и совсем невозможное, если мы про network-based.

Нет, штеуд. Я его выкниул, жаль.

http://nbexpert.com/notebooks/hp/hp-pavilion-zt3000.html Ноут во, мне его двоюродная сестра из Канады подарила.

Почему невозможное? Речь идёт об обработке, причём если обработка кратковременная - то вы в общем случае не наберёте network-based данных больше, чем доступный объём памяти. Если же речь о длительной обработке больших блоков - значит network-based пишутся в mmap'ed storage, и далее обрабатываются, угу.

Да. Сейчас PAE не нужен.

И да, лет 15 назад от офтопика был 2003 сервер 32 битный, который так вполне выходил за 4 гига по общей памяти, но для каждого процесса только 2 гига :( ;)

https://ark.intel.com/products/27576/Intel-Pentium-M-Processor-1_50-GHz-1M-Ca...

пае на месте, как видишь.

64 бита имеет смысл юзать начиная со значений более 1 ГБ.

RHEL платный, а зачем ориентироваться на тех, кто не может более-менее новый компьютер купить?

Тем более я вообще не знаю, кто покупает RHEL Desktop, который, кстати, даже без поддержки.