Почему 64-битный live-usb работает быстрее?

А если 2, то почему не пофиг тогда ? :-) Профиты-то начинаются при более 4.

если 2Гб, то 32х битная таки часто лучше. Не сказать, что сильно намного, но всё же. А граница — 4Гб, +-1Гб. Там плюсы и минусы архитектур примерно одинаковы.

21% однако.

у меня в кармане сейчас 8 рублей. У тебя к примеру 4 рубля. Есть разница? ИМХО — никакой.

disk io тормозит. Дома у меня все летает и открывается в момент. А там где hdd ощущается прошлый век.

у меня в кармане сейчас 8 рублей. У тебя к примеру 4 рубля. Есть разница? ИМХО — никакой.

А если 8 миллионов и 4 миллиона ? Это только одно приложение было.

Не сказать, что сильно намного, но всё же. А граница — 4Гб, +-1Гб.
Там плюсы и минусы архитектур примерно одинаковы.

В чём же разница с 2 ? Точно так же адресоваться может вся память и с 32-разрядным ядром, а на 2Gb есть те же самые увеличенные регистры у x86_64. Вот если +1Gb, то таки да, надо 32-разрядное с PAE, и это уже дополнительные затраты. а 4(-1) - ещё не надо PAE.

disk io тормозит. Дома у меня все летает и открывается в момент. А там где hdd ощущается прошлый век.

Скорость ssd требуется только при старте системы и запуске «тяжелых» приложений и то только в первый раз, далее приложение пускается из кэша оперативки, а она быстрее любого ssd. Если сваливать машину в саспенд с открытым браузером не выключая, то проблема вообще отпадает.

А если 8 миллионов и 4 миллиона ? Это только одно приложение было.

а что, бывает 2 sysllogd на одном локалхосте? А если у бабушки был-бы х?

В чём же разница с 2 ? Точно так же адресоваться может вся память и с 32-разрядным ядром, а на 2Gb есть те же самые увеличенные регистры у x86_64. Вот если +1Gb, то таки да, надо 32-разрядное с PAE, и это уже дополнительные затраты. а 4(-1) - ещё не надо PAE.

дело не в PAE. Если у тебя 2Гб, то ты в принципе не сможешь запустить несколько жирных процессов. А вот если у тебя 4 и более — уже можешь.

Граница не является резкой, я же говорю: +- гигабайт.

И да, основной профит 64х бит относительно памяти в том, что приложениям просторнее. Т.е. пара приложений может каждое выделить себе по 10Гб например, и использовать всего 1Гб каждое. Естественно в 32х так не получится, а получится по 1Гб, и там может быть жуткая фрагментация, т.к. места очень мало — всего 1Гб, и весь забитый. А в 64х битной системе будет целых 10Гб доступно приложению. При этом в действительности в каждом случае всего 3Гб физической. Но за счёт меньшей заполненности, 64х битные приложения будут работать заметно быстрее.

Советую почитать, что думает по этому поводу Линус, если ты мне не доверяешь.

ну и да, ещё кнута почитайте. Он ещё в 60х доказал, что любой алллокатор начинает тупить при заполнении более 70%. А в 32х битных очевидно как не крути, но более 4Гб виртуальной памяти не выделить. На практике получается 1 или 2Гб. Из которых обычно используется всего половина. На практике это всё приводит к тому, что система начинает тупить даже если одно приложение реально использует всего 500Мб, и при этом есть ещё 3.5Гб физической памяти.

а что, бывает 2 sysllogd на одном локалхосте?

А что, на одном локалхосте только одно приложение ? :-) syslog - просто первое попавшееся. Сравни два любых одинаковых, в одинаковых условиях. MySQL с одинаковыми базами, например.

Граница не является резкой, я же говорю: +- гигабайт.

Отнюдь. Она именно резкая, а никак не +/-. И граничный объём равен тому, с чем может работать 32-разрядное приложение, или ядро без pae. До этого объёма одни условия, после - другие.

Советую почитать, что думает по этому поводу Линус, если ты мне не доверяешь.

Зачем ? Всё и так очевидно. :-)

А что, на одном локалхосте только одно приложение ? :-) syslog - просто первое попавшееся. Сравни два любых одинаковых, в одинаковых условиях. MySQL с одинаковыми базами, например.

а кто тебе сказал, что утилизация большего объёма это плохо? Плохо, это когда ты купил 4 кг яблок, съел одно, а остальные сгнили.

Отнюдь. Она именно резкая, а никак не +/-. И граничный объём равен тому, с чем может работать 32-разрядное приложение, или ядро без pae. До этого объёма одни условия, после - другие.

граница действительно резкая, но приложениям не всегда нужно много памяти. Однако программистам проще не обмазываться битами, а выделить Over9000 Mb, и откусывать сколько надо, применяя продвинутые GC. И быстрее получается. Чем сишный malloc(3). Впрочем, тебе этого наверное не понять...

Советую почитать, что думает по этому поводу Линус, если ты мне не доверяешь.

Зачем ? Всё и так очевидно. :-)

конечно. Маркетологи дурят простому народу голову и фтыкают пустые циклы в код, потому-что Линус с emulek'ом продались intel'у и IBM...

а кто тебе сказал, что утилизация большего объёма это плохо ?

Своп сказал. Который, вдруг (для меня-то, на самом деле, не «вдруг»), при переходе на x86_64, начал работать ровно при тех же задачах.

далее приложение пускается из кэша оперативки

да ты сказочник!

А что, не так, что ли?

неа ) точнее не совсем так.

Своп сказал. Который, вдруг (для меня-то, на самом деле, не «вдруг»), при переходе на x86_64, начал работать ровно при тех же задачах.

значит пора тебе в магазин, за памятью.

значит пора тебе в магазин, за памятью.

Зачем, если с 32-разрядной ОС хватает пока ? Дольше будешь ждать апгрейда - больше выиграешь в итоге. Цены если и не падают, то уж технические параметры-то растут. Есть, конечно, другой пусть: успевать апграйдиться раз в пол-года, продавая, что есть, по более-менее приемлемой цене, но это - не мой выбор. Вот полезет в своп 32-разрядная, тогда будет другой разговор.

твоя система, делай что хочешь. Я бы добавил памяти.

Наращивание памяти - еще большая бестолковщина, чем покупка ssd.

ты что курил?

ты что курил?

А зачем это нужно?

Скорость ssd требуется только при старте системы и запуске «тяжелых» приложений и то только в первый раз, далее приложение пускается из кэша оперативки, а она быстрее любого ssd.

чушь собачья.
на ssd холодный старт быстрей, чем горячий на hdd.
купи уже и попробуй, а то несёшь тут какую-то чушь

Наращивание памяти - еще большая бестолковщина, чем покупка ssd.

ты что курил?

А ведь вполне правда. На десктопе лучше взять проц и видео подороже, а ssd и озу не помогут в кодировании семейного видео и крузисах; так, только папочки в дельфине открываться быстрее будут.

Программу один раз открывают и работают с ней, то же самое с загрузкой системы. Тк бюджет ограничен (всегда), оптимизация этого находится в самом конце списка, пока топовые проц с видео ещё не куплены.

для самых отсталых - носители информации уже очень давно являются самым медленным компонентом компов.
да, в кодировании видео ssd и рама может и не помогут, но с ними общее впечатление от системы будет «летает», а вот от видео и проца такого не получишь.

оптимизация этого находится в самом конце списка, пока топовые проц с видео ещё не куплены.

это для лохов в конце списка.
для вкуривших что к чему, ssd на первом месте.

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

а ssd и озу не помогут в кодировании семейного видео

4.2

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

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

А зачем, по-твоему, так долго и мучительно продвигали 64 бита ?

Маркетинг.

Для эффективного маркетинга не нужно придумывать архитектуру, наращивать количество регистров и пр.

I32LP64 смотрит на тебя с непониманием

Вот и практика:

32 vs 64 (комментарий)

Но причем тут int? Ты хотел сказать поинтер?

Но причем тут int?

При том, что разработчики чаще создают массивы с размерностью int[], не заморачиваясь реально потребной разрядность. Соответственно, перекомпиляция под 64 бита автоматически удваивает потребность в памяти. Что и демонстрируется на скринах.

Указатели же, как раз, роли не играют, так как они составляют весьма малую долю затрат на память.

Сейчас все дистрибутивы линукс используют I32LP64, там int 32 бита даже на 64 битном железе на 64 битной оси. Я не понимаю о чем ты.

Сейчас все дистрибутивы линукс используют I32LP64

См. скрины выше.

Я не понимаю о чем ты.

Я о практике потребления памяти приложениями.

да ну прям, у меня бывают моменты рабочие когда 15,9 гб занято.

Ну и с чего ты взял, что там int 64 битный?

PS: КиБ в выводе top доставляет

Ну и с чего ты взял, что там int 64 битный?

А есть другие разумные объяснения, почему эквивалентный 64-х битный софт жрёт настолько больше оперативки?

Поинтеры (и лонги). Если ты думаешь, что поинтеры занимают небольшую долю памяти в программах на си (ядро?), то даже хз что тебе еще и сказать.

Еще вангую 32 битные либы в памяти 64 битной оси. Они занимают довольно много памяти.

Еще вангую 32 битные либы в памяти 64 битной оси. Они занимают довольно много памяти.

У 64-х битных нативных приложений? o_O

Там точно приточно все нативные? От убунты хоть удаленный эмулятор вертолета можно ожидать.

От убунты хоть удаленный эмулятор вертолета можно ожидать.

Ну, когда вопросы веры всплывают, медицина уже бессильна :)

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

От 64 битных интов на I32PL64 вылечись

Ок. Тогда твоя версия, почему тот же софт под 64битами жрёт в 2-4 раза больше, чем под 32. В версию десятков миллионов указателей (для гигабайта разницы), извини, не поверю.

Я уже писал. Все остальные примитивные типы, кроме интов.

+ при необходимости, загрузка 32 битных либ

Остальные примитивные типы имеют равную же разрядность.

Также, как 32 битные либы тут точно не у дел. Тот же Хром прекрасно работает и без 32 битной подсистемы. Но жрёт также много.

Обмазывайся x32abi, ну.

Остальные примитивные типы имеют равную же разрядность.

Могу расшифровать I32LP64. Int 32 bit, Long/Pointer - 64 bit. Все равно будешь тролить?