32 vs 64

Тянуть 32х ради «не падения производительности на дохлом железе»? Можно. В критичных случаях. Но не на массовых десктопах и рабочих станциях. И это стоит бабла. Тащить костыли.

Аксиома - фундаментальная истина, не требующая проверки

...аксиомы и проверяются особенно тщательно, ибо лежат в основе.

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

лечи селективное зрение, и научись цитировать.

только он медленнее получается. Подумай о том, как в такой список вставлять.

Нормально там все вставляется, т.к. массивы (чанки) берутся небольшого размера. И скорость произвольного доступа действительно выше, чем у простого списка.

Тянуть 32х ради «не падения производительности на дохлом железе»?

не. Я не об этом. ИМХО нужно переходить на 64 бита. Даже ценой апгрейда памяти или замены дохлого железа.

И это стоит бабла

угу. Как раз тот случай, когда скупой платит дважды. Не будут разработчики ориентироваться на 32 бита, если это не кофемолка без интернета и одной кнопки.

это надо тем кому надо

теперь просто понятнее что именно это надо

слишком много сложных слов в одном посте )

не уловил

Нормально там все вставляется, т.к. массивы (чанки) берутся небольшого размера.

они у тебя получаться разные, что усилит фрагментацию памяти. Будет очень много дыр в твоей памяти. Причём всё это ещё и усугубляется тем, что памяти мало. Её мало просто из-за маленькой шины в 32 бита, и с этим ты ничего не сделаешь. Кроме того, ломается последовательный доступ, т.е. ты уже не можешь выделять блоки 9001, 9002, 9003... После 9001 тебе придётся прыгнуть в 1234, а потом в 5343. Это ломает напрочь кеширование и упреждающее чтение, которое всё равно работает(т.е. пока ты обрабатываешь 9001й блок, процессор параллельно читает 9002й, но тебе нужен будет не он, а 1234й).

В итоге, приложения требующие хотя-бы 500 метров(e.g. браузер), работают заметно быстрее на 64х битах, хотя и жрут намного меньше 4х Гб.

И с этим ничего не поделать — браузер жрёт так много потому, что в этом вашем интернете web2.0 во все поля, и сайты пишут криворукие говнокодеры, вставляющие тонны жабоскриптов куда надо и не надо. Увы. В 2001ом такого не было. Да и с другими приложениями та же беда.

не уловил

ты процитировал неправильно. На самом деле, KRoN73 как раз и спорил с тем, что ты ему приписываешь. Но ты его аргументов не заметил.

ну я процитировал не его слова, а те которые процитировал он в своём посте

я ответил на его пост с целью поддержать

наверное я не доходчиво выразил свою мысль

ну я процитировал не его слова, а те которые процитировал он в своём посте

ну и нахрена так делать?

да согласен

Целый год по привычке на 32 сижу - траву не могу порендерить толком в блендере...

завязывай с травой

они у тебя получаться разные, что усилит фрагментацию памяти. Будет очень много дыр в твоей памяти.

Не обязательно. Можно перемещать/уплотнять чанки на лету. А можно и не на лету, а по запросу. В любом случае оверхэд сильно меньше, чем при вставке в сплошной массив.

Её мало просто из-за маленькой шины в 32 бита, и с этим ты ничего не сделаешь

Про это я ничего не говорил.

Это ломает напрочь кеширование и упреждающее чтение, которое всё равно работает(т.е. пока ты обрабатываешь 9001й блок, процессор параллельно читает 9002й, но тебе нужен будет не он, а 1234й).

Ничего это не ломает. Для управления предвыборкой есть специальные инструкции процессора, но, даже если это не учитывать, кэш работает не так тупо, как ты написал.

Не обязательно. Можно перемещать/уплотнять чанки на лету. А можно и не на лету, а по запросу. В любом случае оверхэд сильно меньше, чем при вставке в сплошной массив.

а если сравнить с простым списком, в котором всего два поля — значение, и указатель на следующий?

Её мало просто из-за маленькой шины в 32 бита, и с этим ты ничего не сделаешь

Про это я ничего не говорил.

не говорил, но IRL такой эффект наблюдается.

Это ломает напрочь кеширование и упреждающее чтение, которое всё равно работает(т.е. пока ты обрабатываешь 9001й блок, процессор параллельно читает 9002й, но тебе нужен будет не он, а 1234й).

Ничего это не ломает. Для управления предвыборкой есть специальные инструкции процессора, но, даже если это не учитывать, кэш работает не так тупо, как ты написал.

не, ну понятно, что я утрировал и преувеличивал, что-бы разъяснить суть явления. Но такое есть IRL. Конечно разница не очень большая, но всё же некоторый эффект есть начиная даже с 512Мб используемой памяти. И с каждым годом это всё сильнее и сильнее. Потому, для десктопов и лаптопов 32х битная архитектура подходит с каждым днём всё хуже и хуже.

Догма —

А она там, вдруг, при чём?

И, да, с разморозкой!

что за разморозка

что за разморозка

«Ответ на: комментарий от KRoN73 19.03.2012 23:00:53»

Ага Читал тред не обращая внимания на даты

А по сабжевой теме — я завёл на выходных две абсолютно идентичных виртуалки с Lubuntu, одна — 32бит, другая — 64 бит. Но руки не доходят исследовать софт.

Могу только сказать, что на свежеуствновленной и голой системе Firefox занимает после первого старта в 32 битной 87Мб RSS и 461Мб VIRT, а в 64 бит — 118Мб и 778Мб, соответственно.

http://i.imgur.com/l3pqUWE.jpg

http://i.imgur.com/OFjaDhf.png

VIRT в Хроме просто жжёт:
http://i.imgur.com/D4ubbqF.png

Ещё немного LibreOffice:
http://i.imgur.com/RV1MfFG.png

Это тот самый softice?

Это тот самый softice?

угу

он есть в линуксе?

оказывается soffice

он есть в линуксе?

apt-get install libreoffice
emerge app-office/libreoffice
emerge app-office/libreoffice-bin

и т.п. :)

оказывается soffice

Много лет назад это был http://ru.wikipedia.org/wiki/StarOffice

Он путает с http://en.wikipedia.org/wiki/SoftICE

Ну незнай, попробуй без мультилиба чоли.

Ну незнай, попробуй без мультилиба чоли.

Так, как раз, 64-х битный софт и жрёт-то больше. Хочешь экономии — как раз нужен мультилиб и 32 бита.

Кстати, это может быть ответом, почему Хром под Linux жрёт настолько больше ресурсов, чем под Windows. Под Win x64 он 32-х битный.

Слишком сложные непонятные программы. Запусти какой-нибудь gzip и посмотри сколько он жрат.

Слишком сложные непонятные программы

Это Firefox и Хром непонятные? :D Это один из основных инструментов большинства ЛОРовцев сегодня.

Запусти какой-нибудь gzip и посмотри сколько он жрат.

А вот gzip'ом пользуются редко. Тем не менее даже с ним:
http://i.imgur.com/pFX8BKo.png

748k vs 820k.

а если сравнить с простым списком, в котором всего два поля — значение, и указатель на следующий?

Возьмём список в котором 3 поля: 2 значения и указатель на следующий чанк. Произвольный доступ в 2 раза быстрее чем по простому списку, памяти жрёт меньше чем простой список (меньше указателей). При вставке перемещать что-либо нужно только в половине случаев, да и то только один элемент.

Потому, для десктопов и лаптопов 32х битная архитектура подходит с каждым днём всё хуже и хуже.

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

Firefox занимает после первого старта в 32 битной 87Мб RSS и 461Мб VIRT, а в 64 бит — 118Мб и 778Мб, соответственно.

что в лоб, что полбу.

VIRT в Хроме просто жжёт:

какая разница до VIRT'а?

Так, как раз, 64-х битный софт и жрёт-то больше. Хочешь экономии — как раз нужен мультилиб и 32 бита.

экономия на спичках получается. 118-87=31. Когда ты в последний раз видел DRAM на 32Мб?

запусти уж xz -9, хватит онанизма.

Возьмём список в котором 3 поля: 2 значения и указатель на следующий чанк. Произвольный доступ в 2 раза быстрее чем по простому списку, памяти жрёт меньше чем простой список (меньше указателей). При вставке перемещать что-либо нужно только в половине случаев, да и то только один элемент.

ок. Есть список ({1,2},{3,4},{5,7},{8,9},{10,11}), как вставить 6?

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

с этим согласен.

({1,2},{3,4},{5,7},{8,9},{10,11}), как вставить 6?

Тут есть два варианта:

({1,2},{3,4},{5,6},{7},{8,9},{10,11}) или ({1,2},{3,4},{5,6},{7,notused},{8,9},{10,11}) notused выделяется но не используется пока не понадобится вставить что-нибудь между 7 и 8.

они у тебя получаться разные, что усилит фрагментацию памяти. Будет очень много дыр в твоей памяти

В итоге, приложения требующие хотя-бы 500 метров(e.g. браузер), работают заметно быстрее на 64х битах, хотя и жрут намного меньше 4х Гб.

В теории - да, на практике часто - нет.

Firefox 32 работает значительно быстрее, чем Firefox 64. Я про официальную сборку на mozilla.org

Who are you?

KRoN73, винда, не стыдно?

На удалённые offtopic сообщения не отвечаю ;-)

Вообще, я тот, кто я есть.

Кстати, ответ на вопрос простой.

Если у вас HDD, используете PAE + 32bit.

Если у вас SSD, используете 64bit + 32bit библы для 32bit приложений.

Нет, не стыдно, некоторым работать надо, а не идолопоклонничествовать.

Неправильный ответ, на HDD тоже уже давно многие используют amd64.