>Ну например вот - kernel-PAE-2.6.18-92.1.13.el5.i686.rpm
>Т.е. RH включил, хоть и в опциональном ядре для тех у кого
>выше 4G. А при чем тут вообще редхат и его опциональные ядра?Я вроде про убунты говорил.
>Насчет того что включено везде - согласен, не прав. Возможно как и
>RH включают в опциональных ядрах.
Не видел таких ядер.Видел -openvz, -xen и т.п. - эти да, полезные весьма :).Зато вижу х64 версии, которые не только пользуются заметной популярностью но и скажем WINE под них нормально собран и прочая.
>не два с половиной человека )
Знаете, шину ISA тоже до сих пор использует не 2.5 человека.Особенно в промышленности.Мне что, тоже по этому поводу резко податься в некрофилы?Спасибо, что-то не хочется.Вот PAE - это из разряда костыльной некрофилии как раз.
>Вообще-то 10% не уж так и мало. Если на машине 16G RAM,
>теряем 1.6G.
Brain damaged logic!Или тотальное непонимание того как система и процессор работают.А у вас что, все 16Гб будут заняты исключительно *машинным кодом* из х64 команд что вы 10% от всех 16 гиг считаете????Это что ж вы туда столько набить то намерены???Обычно столько машинного кода на всем жестком диске нету, не то что в RAM!А для буферов, кэшей, данных и прочего как вы понимаете никакого распухания не происходит.Да, если система и процессы юзера заняли под себя скажем 500 Mb RAM, на х64 под систему отожрется на ~50 мегов больше.Но это все-таки не мифические 1.6Gb :-).А скажем буфер на 2Gb - он и в африке буфер на 2Gb.Ему не потребуется становиться буфером на 2.2Gb чтобы вместить 2Gb данных.Странно, да? :)
>Зачем мне такие радости если работа ведется только с
>32bit софтом?
А как вы определили "32-битность" софта?Неужели прочитали все исходники и не нашли там ни одной 64-битной переменной?В х64 системе софт нативно компиляется в 64 битный, в 32-битной - в 32 битный, а при компиле под 8-битный процессор - в команды этого 8-битного процессора, приколитесь? :).А что софту "удобнее" - можно посмотреть лишь детально просмотрев исходники.Уже полно софта который 64-битные переменные во всю использует.А как еще можно работать скажем с файлами >4Gb например?Я например пользуюсь JFS и XFS.Они нативно 64-битные ФС.Ессно они и на 32-битных системах *скомпилируются* и *будут* работать, как чисто 32-битный код.Но масса 64-битных вычислений просто сильнее нагрузит процессор потому что в 32-бит режиме их делать на порядок труднее - придется изображать 64-битные числа из 32-битных регистров, которых к тому же у 32-битного уродца х86 совсем не дофига и в которых уже скорее всего и так что-то было.В результате в 32-битном режиме будет куча бесполезных перетрясок регистров между стэком и\или RAM для того что 64-битный процессор делает 1 командой без каких-то там левых действий.Соответственно на 64-битных вычислениях 32-битные программы резонно сольют с треском.
Безусловно 64-битную арифметику можно хоть на 8-битном процессоре изобразить, если изъ...ться.А компилеру пофигу - он железный, его дело сгенерить то что попросили.Только работает потом медленно и печально, потому что бОльшую часть времени займут не нужные полезные вычисления а масса левых "служебных" действий по перетасовке регистров чтобы изобразить из 8-битных регистров и АЛУ 64-битное число.
>Вряд ли где-то можно найти подобную статитистика, к сожалению.
>Я не знаю как с поддержкой РАЕ в ядре freebsd,
Судя по их сайту - там все как обычно, то есть не ахти.Да впрочем фиг с ними, мне это неинтересно.
> но в линуксе с этим нет проблем.
Ну да, если говорить про линукс как про какого-то там абстрактного сферического коня в вакууме - вы бесспорно правы.Где-то там, в теории, когда сферический конь в вакууме - все так.А если говорить про конкретную десктопную убунту и на практике - вот тут то вы и познакомитесь с птицей обломинго а также с тем что теория и практика немного разные вещи ;)
>Ну вот тот же RH наверное все-таки потестил,
Ну, я RH с этим сердечно поздравляю.Насколько и со всеми ли драйверами которые могут засунуть на десктоп - вопрос интересный.Но только не в этом месте.Потому что тут редхат как-то мимо кассы:разговор был про убунты.
>Потом, механизм работы ядра с памятью выше 4G такой же как в
>области 1G-4G,
А куда лишняя трансляция адресов за границей 4Gb делась?Или все-таки не такой же?
И кстати у меня есть интересный вопросик по части адресации и ядра: а дисковый кэш в случае PAE ограничен 4(?) Гб или нет?
>Глючить там нечему.
Что-то я не уверен в этом.Особенно насчет разнообразных драйверов которым порой надо работать в частности с памятью.
>Потери в скорости работы RAM крайне малы, чтобы об
>этом задумываться.
Потери оперативки на 64-битный режим тоже крайне малы чтобы об этом задумываться.Говоря вашим языком.
>Ваше право. Я лишь хочу сказать что РАЕ востребовано, и это не
>удел извращенцев :)
В основном все-таки извращенцев.Или обладателей чисто 32-битных раритетов без х64 режима где каким-то чудом оказалось >4Gb RAM (на серверах такое наверное даже возможно).
>Не от того ли, что ли x64 систем пока еще маловато? ;)
Скорее, дело в том что ассемблер там заметно изменился и тех кто его освоил пока не так уж много.Хаксоры за десятилетия привыкли крушить классический х86.Посмотрите сами: пока макось была на PowerPC - хоть бы кто дыру нашел.А как только перешли на интель - сразу множество дыр посыпались как из рога изобилия.Наверное не потому что эппл резко слил качество кода по сравнению с тем что было раньше, а?Просто хаксоры тупо не умели с PowerPC работать в плане поиска дыр:).Понятно что уязвимость от этого никуда не пропадет но времени на ее апдейт будет больше а шансов получить проблемы не в теории а на практике - сильно меньше.Просто потому что хаксоры, особенно наиболее назойливые и опасные кульхацкеры качающие готовые скомпиленые сплойты и потом глушащие ими все что шевелится и попалось под руку будут немного в пролете.
Вариант для распечатки
(??), 02-Окт-08, 23:14 
