PAE vs nonPAE vs 64

[Gerasats]

Господа мне сдается что прыжки вокруг PAE не есть так скажем до конца корректными, да мы имеем  (почти как факт более полное отображение объема памяти, но не использования, хоть PAE хоть non-PAE может использовать только доступные первые - 4 гБ), чем платим за правильность отображения, да всего навсего из-за увеличения количества страничных уровней, система начинает тратить больше времени при обращении к памяти, таким образом, если типичный объем используемый программой памяти незначительно больше 2GB, то работа без PAE эффективнее. Это все проверено мною, и еще как пользователь фул установок - мне редко приходилось чего либо запихивать в память более 2 гБ, и это надо еще очень постараться, тогда я не понимаю что можно такого всадить в память пользователю фругала, если самый тяжелый - офис, из того что мне попадалось.


ЗЫ: И если честно, то я в свое время тоже очень сильно ратовал за PAE, однако - обучаюсь.....

[k0l0p0k]

2 Gerasats

"хоть PAE хоть non-PAE может использовать только доступные первые - 4 гБ" - неверно

PAE — режим работы встроенного блока управления памятью x86-совместимых процессоров, в котором используются 64-битные элементы таблиц страниц (из которых для адресации используются только 36 бит), c помощью которых процессор может адресовать 64 ГБ физической памяти (вместо 4 ГБ, адресуемых при использовании 32-разрядных таблиц)

[sfs]

PAE актуально для загрузки всего дистра в память. Puppy серьезно потолстел. И это еще не предел.
Современные компы под win7-8 имеют от 4гб.
Переход на 64bit - дело только времени. PAE - это и есть плавный переход. Тормозов не замечал. В теорию не лез

[Gerasats]

PAE актуально для загрузки всего дистра в память. Puppy серьезно потолстел. И это еще не предел.
Современные компы под win7-8 имеют от 4гб.
Переход на 64bit - дело только времени. PAE - это и есть плавный переход. Тормозов не замечал. В теорию не лез

C переходом на х64 спорить не стану, потому как рано или поздно придется перебираться и на х128, только в части что это есть переход, да еще плавный не согласен категорически, это есть всего лишь индикатор загрузки памяти, и все, никакого перехода, то что он начиная с страницы 128 начинает читать последовательно до страницы 4024 в этом его и есть фокус, никакого количественного улучшения работы с памятью, никакой загрузки чего либо в память PAE не несет. Для того чтобы работать по архитектуре х64 нужно слишком многое, начиная с того что ядро должно работать с приложениями х64, кончая тем что ОС должна быть также х64.
А серъёзность поправления в массе Паппи, ответ один - придется думать как жить не только с игрушкой конструктором фругал, рано или поздно пузырь лопнет, потому как на сегодня, я уже писал мой фул Паппи Прэцейс весит 16 гБ, и если понадобится будет весить и более, и во что будем запихивать, или выход в 128 сфс или пфс, на чем все это разворачивать и как взаимодействовать в случае многозадачности?  

Насчет видоуз, есть такое наблюдение версия 8 в ОЗУ отправляет всего навсего 46 мБ (против 480 в 7, и почти 900 в Висте), остальное прищелкивается связями и билиотеками, правда на Линукс похоже?

[sfs]

никакой загрузки чего либо в память PAE не несет.

Само по небе не несет , но возможность использовать >4gb  дает. Что дает ускорение работы, экономию батареи и hdd

мой фул Паппи Прэцейс весит 16 гБ

А зачем тогда puppy? Чем не устраивает обычная ubuntu?

[Gerasats]

но возможность использовать >4gb  дает. Что дает ускорение работы, экономию батареи и hdd

Не буду спорить, Вы видите эту возможность, я нет, а есть она или нету, это очень субъективное понятие, потому как кроме как индицирование я ничего не вижу, объем в 4 гб и более запихивается как PAE, так и в non.

А зачем тогда puppy? Чем не устраивает обычная ubuntu?

Работает роскошно, а что пользователю нужно?
Ну про последнюю убунту у меня хороших слов в целом не получается, что-то в основном только матерные , ну это уже такой изыск ума команды космонавта, что я просто и не знаю. И в целом сколько я знаю пингвоводов, что-то почти все 100% сбежали с убунты, кто на минт, кто на деби, кто-то как и я на паппи.
Другое дело что я сейчас все больше понимаю, первоначальная идея Паппи - "Быстрая ОС - для старых машин" меняется на другой, судя по той же мурге "Быстрая и агрессивная ОС - для всяких машин". И отсюда и цели, и задачи. По сути ситуация такова что ограничений нету ни по производительности, ни по объему памяти, не по графике, все накладываемые ограничения очень субъективны.

[k0l0p0k]

прогам в PAE-режиме по прежнему доступно только 4G памяти
самой ОС - 64G

[sfs]

прогам в PAE-режиме по прежнему доступно только 4G памяти

Не знаю не серверных прог которые съедят больше. Разве что виртуалки...

Другое дело что я сейчас все больше понимаю, первоначальная идея Паппи - "Быстрая ОС - для старых машин" меняется на другой, судя по той же мурге "Быстрая и агрессивная ОС - для всяких машин".

Да.
Железо дешевеет и стремительно меняется
На старом если браузер нормально не запустить - уже в помойку
Телефоны легко делают старые компы. За счет массовости - ценник на них падает
Мир меняется...
А не так уж и давно у меня на первом самодельном компе было 48к памяти и я радовался...

[Gerasats]

прогам в PAE-режиме по прежнему доступно только 4G памяти
самой ОС - 64G

Я конечно очень дико извиняюсь, а что значит "самой ОС-64G", я как и sfs, наверное, родом из тех времен, когда (вдуматься в затертом 1988 когда впервые сел за ПК) наличие 64 кБ расширенной памяти считалось роскошью, а тут мне пишут 64 гектара, надо полагать ОЗУ, доступно ОС, это так? Получается что грузим всю ОС и все приложения в ОЗУ и работаем оттуда, смысл этих манипуляций, это прямая дорога к тому что проповедует Гугл, а сейчас и Убунта, загрузка всего в ОЗУ и работа оттуда. В принципе быстро, красиво, но это уже иная архитектура, больше похожая на закрытую, типа hi-end, нас туда не пустят и не особо приветствуется. Я с этим столкнулся когда начал ковыряться в проекте Android-x86, google ведет себя очень интересно: то открывает доступ к репам и исходникам, то меняет порядок доступа, то вообще может закрыть путь к исходникам на неопределенное время (вон закрыл в декабре, открыл в феврале), все очень не однозначно.
Кстати решил посмотреть на жизнь под Убунтой 13.04, аккурат сегодня вышел очередной РК, и в принципе не упал и спокойно работает с него и пишу. Ну надо наверное хорошо пригрузить, чтобы хоть что-то понять, пока ничего и не стоит, может поэтому и в адеквате.

[sfs]

Получается что грузим всю ОС и все приложения в ОЗУ и работаем оттуда, смысл этих манипуляций,

дает ускорение работы, экономию батареи и hdd

Если загрузиться по сети - бездисковая рабочая станция
А куда еще пупи-пользователю память девать на современном ПК? Хоть как-то к делу приспособить.
Попробуйте скомпилить ядро - чтобы все (дистр devx src) в памяти происходило. Впечатляет

это прямая дорога к тому что проповедует Гугл, а сейчас и Убунта, загрузка всего в ОЗУ и работа оттуда.

Про гугл и android не в курсе. Про Ubuntu знаю только про попытки монтировать /tmp в tmpfs.
Что именно Вы имели ввиду? И почему это плохо?

В принципе быстро, красиво, но это уже иная архитектура, больше похожая на закрытую, типа hi-end, нас туда не пустят и не особо приветствуется.

В 218 все эти возможности есть (PAЕ и pfsramload ) Да еще и uksm (сжатие памяти) впридачу

в проекте Android-x86, google ведет себя очень интересно: то открывает доступ к репам и исходникам, то меняет порядок доступа, то вообще может закрыть

Дык они бабло зарабатывают, а не в игрушки , как мы , играют  

[k0l0p0k]

2 Gerasats
'а что значит "самой ОС-64G" ' - зто значит операционка(32-разрядная)
с включеным PAE будет видеть не более 64Gb озу.
я кстати тоже из тех времен когда 32-64kb озу считалось нормой
,а дискета на 1.44Mb казалось огромной

[Gerasats]

Если загрузиться по сети - бездисковая рабочая станция
А куда еще пупи-пользователю память девать на современном ПК? Хоть как-то к делу приспособить.
Попробуйте скомпилить ядро - чтобы все (дистр devx src) в памяти происходило. Впечатляет

Нет! И сейчас попробую объяснить почему, не все так радужно, когда все сразу и на борту, вот уж где странно, да, я сторонник фула, и говорю что все на борту не есть гуд, и хуже, легче скомпилироваться во фругале с плюсанутым копмилятором и поддержкой устройств - получить требуемый pet (меня интересуют больше они, объяснять не надо) чем потом всю эту шнягу, а это лишний гектар таскать с собой в ядерной поддержке. Так и делаем, фругал 2 га сохраненки, компилим то что мне надо, а это: видео, виртуалка, графические пакеты для солидов и прочей лабуды, а потом формируем полную установку. После получения нужных мне дел ведь эта вся радость - тупой баласт и для ОС и для памяти. Так что я пользуюсь фругалом, потому как так проще - сделать то что надо тебе, чем пытаться подладить то что сделали другие для других сборок и других ядер.

2 Gerasats
'а что значит "самой ОС-64G" ' - зто значит операционка(32-разрядная)
с включеным PAE будет видеть не более 64Gb озу.
я кстати тоже из тех времен когда 32-64kb озу считалось нормой
,а дискета на 1.44Mb казалось огромной

Вы ведь понимаете ну будет она видить или не будет, а толку то. Нам же не посмотреть надо, а задействовать, а режиме хоть PAE хоть non мы только зрители, на 4 гБ все и закончится.
И это уже мысль вслух, вот смотрите Майкрософт долго боролся за мощные, большие ядра которые лежат в ОЗУ полностью, чем закончилось после Висты, отказались от этого, и думается мне не спроста, все таки и скорость загрузки и надежность ядра выше при меньшем объеме.
И кстати с клиентской машиной и облаком МС один из первых подпрыгивает, но что-то облачные технологии, как мне кажется выше хранилищ и игрищ таки и не подпрыгнут, да те редакторы и проги что есть в облаках, в лучшем случае что-то несерьёзное сделать. А простой пользователь все норовит чтобы у него единственного стояло и лежало что-то ценное  .ИМХО.

[sfs]

Прочитал несколько раз. Все равно не понял - чем frugal c загрузкой в память хуже FULL ...
Чем PAE хуже nonPAE тоже не понял

[k0l0p0k]

2 Gerasats
предположим у нас два компа - на 1м 1Г озу ,на 2м ну например 16Г
(PAE включено - ocь эти 16Г видит)
и предположим мы занимаемся обработкой видео - DVD(размер
4.7 - 9 Gb) перепаковываем в другой формат например.
на компе с 16Г  весь этот DVD можно целиком поместить в озу,
а на 1м компе системе постоянно придется работать с жестким диском.
Вопрос на засыпку - где скорость обработки будет выше ?  )

[Gerasats]

Прочитал несколько раз. Все равно не понял - чем frugal c загрузкой в память хуже FULL ...
Чем PAE хуже nonPAE тоже не понял

Где у меня была фраза о том что хуже, а что лучше?
Я ведь пишу что компилировать лучше под фругалом, а вот работать лучше в фуле, как хотите так и понимайте, мой резон ниже:
-  почему предпочитаю стандартную установку, а Вы согласитесь что стандартная линукс установка (не Паппи) - у нас зовется фул, потому как можно многие делать вещи не оглядываясь назад, что там у меня с сохраненкой и местом, ну или сразу отрезать сохраненку в размере 8 гБ, а такое появилось совсем не давно, а потом подвязывать, а начинаешь подвязки по 512 мБ городить, да? Да! ( а попробуйте на скорость фругал в 10гБ - мне не очень, а как Вам?).
Задачи которые приходится решать, да тот же не линейный видеомонтаж, или работа с аудиофайлами, я стандарта сжатия мп3 в аудио не признаю, есть флак, есть не сжатый аудиопоток и там на не сжатом потоке ох как нужен объем, и те 8гБ кончаются через час работы, и дай Бог чтобы втиснулось, вот тут фул, не заменим. Это раз, второе фругал убирает осторожность пользователя, ну подумаешь убил сохраненку, у меня есть запасная, что там перезагрузка лишние 10 минут и все сначала.

2 Gerasats
предположим у нас два компа - на 1м 1Г озу ,на 2м ну например 16Г
(PAE включено - ocь эти 16Г видит)
и предположим мы занимаемся обработкой видео - DVD(размер
4.7 - 9 Gb) перепаковываем в другой формат например.
на компе с 16Г  весь этот DVD можно целиком поместить в озу,
а на 1м компе системе постоянно придется работать с жестким диском.
Вопрос на засыпку - где скорость обработки будет выше ?  )

Ну хорошо видит и что вы в видимую часть можете вгрузить? Честно во-первых в любой ОС очень сложно найти программу которая требует 100% загрузки в память, в нашей архитектуре, во-вторых прочитывание и работа со всем массивом ОЗУ не одно и то же. Для того первого компа в Вашем примере с 1 гБ ОЗУ гораздо эффективнее наличие свопа (в 2 гБ), чем у второго с 16 гБ ОЗУ, ну там не нужен будет своп, почти на 100%, хотя если даже дать ему 32 мБ он не откажется. И пример с перкодированием ДВД не корректен, потому как даже в этом случае любой кодировщик будет скорее опираться не на ОЗУ, тем паче весь объем, а именно на своп, и знаете почему, мне сдается что настроить кодировщик будет сложнее для работы с ОЗУ, чем просто отрезать ему для свопа часть харда. Ведь память в целом не работает статично, там если конвейера запустились они должны работать, посему все равно придется молотить и с 1 гБ  диску, и с 16 тоже придется молотить диску, не будет ваш 9гБ ДВД покоится в памяти, у нее задача не хранить, а проталкивать, а если хранить, то это уже скорее нанд память и риск процессоры или армы.

ЗЫ: Ох и понесло нас то.....