LINUX.ORG.RU
ФорумTalks

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

 , ,


1

2

Цитата из тех времен:

Windows — отстой, поскольку разработчики забили в несерверных версиях на такую фичу, как PAE, придуманную инженерами Intel еще в дремучем 1995 году, в результате чего, когда размеры памяти стали достигать 4Gb, система Windows XP (32-разрядная) смогла видеть только ~3.25 гигабайт ОЗУ. Воистину, 640K должно хватить всем.

А сейчас первее микрософта готовы выкинуть 32 бита на мороз. Как времена меняются. Хотя до сих пор мамок с поддержкой более 64 гб около 20 шт и то реализована эта поддержка с помощью расширения слотов до 8 - топорно-костыльно. Наборов-то плашек из 8 нет, а ведь очень важно ставить плашки даже не то что из одного производителя, а даже из одной партии/одной упаковки.

★★

Последнее исправление: Lowes (всего исправлений: 3)

Ответ на: комментарий от watashinoshi

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

redgremlin ★★★★★
()
Ответ на: комментарий от Lowes

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

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

redgremlin ★★★★★
()
Ответ на: комментарий от redgremlin

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

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

Lowes ★★
() автор топика
Ответ на: комментарий от Lowes

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

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

Такая же

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

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

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

redgremlin ★★★★★
()
Ответ на: комментарий от Lowes

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

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

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

aureliano15 ★★
()
Ответ на: комментарий от aureliano15

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

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

Lowes ★★
() автор топика
Ответ на: комментарий от saahriktu

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

h31 ★★★★
()

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

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

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

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

Deleted
()
Ответ на: комментарий от Lowes

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

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

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

aureliano15 ★★
()
Ответ на: комментарий от saahriktu

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

kirk_johnson ★☆
()
Ответ на: комментарий от Lowes

С PAE?

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

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от saahriktu

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

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

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от DNA_Seq

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

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

a[y*w+x];
где, w - ширина 2-х мерного массива.

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 4)
Ответ на: комментарий от saahriktu

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

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

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

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

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

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

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

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от Lowes

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

mandala ★★★★★
()
Ответ на: комментарий от kirk_johnson

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

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

saahriktu ★★★★★
()
Ответ на: комментарий от Gonzo

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

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

kawaii_neko ★★★★
()
Ответ на: комментарий от kirk_johnson

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

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

ABCD
Второй массив пусть условно содержит
0123
Теперь пусть условно нужно расширить многомерный подмассив A. Схематично это так:
AABCD
Синхронизируем второй массив. Условно так:
0234
Всё работает.

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

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 2)
Ответ на: комментарий от saahriktu

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

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

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

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

saahriktu ★★★★★
()
Ответ на: комментарий от kawaii_neko

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

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

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

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

redgremlin ★★★★★
()
Ответ на: комментарий от kirk_johnson

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

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

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

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

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

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

kirk_johnson ★☆
()
Ответ на: комментарий от redgremlin

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

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

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

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

kawaii_neko ★★★★
()
Ответ на: комментарий от aureliano15

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

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

n_play
()
Ответ на: комментарий от AlexAT

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

Quasar ★★★★★
()
Ответ на: комментарий от saahriktu

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

Quasar ★★★★★
()
Ответ на: комментарий от saahriktu

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

Quasar ★★★★★
()
Ответ на: комментарий от saahriktu

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

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

Quasar ★★★★★
()

тут такое дело, что 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 в чистом виде

ckotinko ☆☆☆
()
Ответ на: комментарий от Quasar

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

AlexAT
()
Ответ на: комментарий от kirk_johnson

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

AlexAT
()

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

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

Serg_HIS
()
Ответ на: комментарий от next_time

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

utf8nowhere ★★★
()
Ответ на: комментарий от Lowes

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

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

te111011010
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.