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

твоя версия, почему тот же софт под 64битами жрёт больше?

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

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

Могу расшифровать I32LP64. Все равно будешь тролить?

А теперь разверни свою логику ответа.

так, только папочки в дельфине открываться быстрее будут.

а если не нужен крузис и домашнее видео на Over9000Mb?

моим домашним например не нужно ни то, ни другое. А вот SSD им пришёлся по нраву.

оптимизация этого находится в самом конце списка

ну да. Эникейщик детектед. А вот твои клиенты целыми днями будут окошки открывать, и твои попугаи на синтетике им не нужны.

Ты меня устал. Сколько раз можно повторять? Ты ступил на счет интов, они везде 32 битные в си и с++ во всех линуксах на обеих битностях. Остальные примитивы - на 64 битах в 2 раза длиннее.

Или ты считаешь, что 80% программы - инты? Если так, то разверни сам свою логику.

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

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

ППКС

у мегабакса период просветления. Внимайте.

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

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

ты упорот, или просто белены объелся?

#include <stdio.h>

int main()
{
	int x = 17;
	printf("sizof(int) %lu, sizeof(*int) %lu\n",
			sizeof(x), sizeof(&x));
	return 0;
}

sizof(int) 4, sizeof(*int) 8

Linux ksu 3.10.17 #2 SMP Wed Oct 23 16:34:38 CDT 2013 x86_64 Intel(R) Pentium(R) CPU G2020 @ 2.90GHz GenuineIntel GNU/Linux

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

даже смотреть не буду на всякое говно нарисованное. Я сам рисовать умею. Мужика с членом например. С трёхметровым.

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

насколько? на 31 килобайт? А теперь посчитай, сколько это в рублях. Только калькулятор не сломай.

Ты ступил на счет интов, они везде 32 битные в си и с++

Вот с этого и надо было начинать. Я был уверен, что в Linux, как и в других «взрослых системах» int занимает 8 байт. Проверил — действительно, в Linux 64 int остаётся 32-х битным.

Остальные примитивы - на 64 битах в 2 раза длиннее.

Что, char == 2 байта, а short == 4 байта? o_O А какой смысл в этом на x86? Это ж не PDP.

Однако, проверил — sizeof(int) == 4, так что char == 1 байт. Также максимальное значение unsigned char == 255.

Максимальное для unsigned short == 65535. Получается, что все примитивные типы по дефолту имеют и на 32, и на 64 битах равный размер. Что и логично, так как разрядности char зависит, как правило, от байтовой гранулярности архитектуры, а short исторически именно 16 бит, а не 2×char и не 1/2×int.

Объясни, что ты имел в виду под «Все остальные примитивные типы, кроме интов».

Или ты считаешь, что 80% программы - инты?

Вот тут — да, считаю. Хотя это уже другая история выходит.

KRoN73 ★★★★★ (23.01.2014 21:34:30) почему тот же софт под 64битами жрёт в 2-4 раза больше, чем под 32?..

эти твои слова будут лучшим комментарием к тебе.

Ты ступил на счет интов

он просто верит в сказки и в цветные картинки из интернетов.

Я был уверен, что в Linux, как и в других «взрослых системах» int занимает 8 байт. Проверил — действительно, в Linux 64 int остаётся 32-х битным.

you made my day!

зайди на http://www.top500.org/statistics/list/ и удивись: 96.4% суперкомпьютеров работают на Linux (а остальные на UNIX). Ты точно сегодня белену не кушал, не? Может в скорую звонить пора? А то некроз мозга уже очевиден...

Или ты считаешь, что 80% программы - инты?

Вот тут — да, считаю. Хотя это уже другая история выходит.

ну вот тут ты и ошибаешься. Уже 20 лет как не делают индексы в память int'ами в большинстве случаев, т.к. всем ясно, что указатель может и не влезть в int. Потому используют более широкие типы, а уже лет 15 как для этого придумали ptrdiff_t. А сами int'ы нужны лишь в каких-то специальных случаях.

Вот с этого и надо было начинать.

Я так-то это раз 10 написал в виде «I32LP64».

Что, char == 2 байта, а short == 4 байта?

Про эти недомеры я даже не думал, имел в виду long, pointer, возможно также float & double (не уверен, на работе линуксов нет, проверить щас не могу).

Вот тут — да, считаю. Хотя это уже другая история выходит.

Ты упорот. Все адреса всех функций, фрейм поинтеры и прочее низкоуровневое щячло складываются в 64 битный адрес. Только это уже увеличивает расход памяти.

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

Я так-то это раз 10 написал в виде «I32LP64»

Я это расшифровывал как (int32*) :)

Про эти недомеры я даже не думал, имел в виду long, pointer, возможно также float & double (не уверен, на работе линуксов нет, проверить щас не могу).

long в I32LP64 имеет такой же размер, pointer — не примитивный тип, float и double имеют фиксированный размер по ISO, ЕМНИП.

Так какие тогда примитивы стали больше? :)

Ты упорот. Все адреса всех функций, фрейм поинтеры и прочее низкоуровневое щячло

Это же всё копейки. Функций, указателей и прочего явно не десятки миллионов, в отличие от собственно данных, == примитивов.

Только это уже увеличивает расход памяти.

Но не на гигабайты же!

float & double (не уверен, на работе линуксов нет, проверить щас не могу).

не проверяй. Float&double подчиняются IEEE 754. Т.е. в первом 32 бита, а во втором 64 бита.

Все адреса всех функций, фрейм поинтеры и прочее низкоуровневое щячло складываются в 64 битный адрес. Только это уже увеличивает расход памяти

увеличивает. Но не очень значительно. Потому что размер индексов относительно данных небольшой, и только на индексах это заметно(да и то, если индекс==указатель. Что не обязательно). IRL размер используемой памяти на 64х битах больше на ~10..20%, что не играет никакой роли (учитывая, что 64х битные приложения ровно на столько же быстрее. Или даже ещё быстрее).

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

...нужно матчасть подучить...

Твои аргументы исключили. Мои тоже. 64 битные приложения больше ПРОСТО ТАК!

Функций, указателей и прочего явно не десятки миллионов

ты точно упорот. Для каждого объекта C++ у тебя будет как минимум одна VT(а может и не одна). Ну и в _любых_ структурах данных указателей как минимум не меньше, чем самих данных. (не считая массивов, но массивы в «десятки миллионов» люто тормозят, ибо O(N)).

Но не на гигабайты же!

эти гигабайты существуют только в твоих влажных фантазиях.

64 битные приложения больше ПРОСТО ТАК!

Ладно, сойдёмся на этом варианте :D

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

У тебя не играют роли индексы и адреса

не у меня, а IRL. И дело не в том, что «не играют», а в том, что их роль незначительна.

В итоге имеем на 100-200 метров больше в памяти. Копейка рубль бережет.

вот когда начнут продавать память по 100..200Мб, тогда и поговорим за бережливость. На сегодня её только гигабайтами продают, увы.

И да, лишние 100Мб можно было-бы заюзать для ускорения, но тоже увы — 32х битная архитектура работает заметно медленнее. Намного заметнее, чем ускорение от лишних 100Мб кеша.

вот когда начнут продавать память по 100..200Мб, тогда и поговорим за бережливость.

Я и не сторонник бережливости, всеми конечностями за 64 бита и памяти мне не жалко. Крон вон спрашивал за потребление. Интересно на самом деле, откуда оно берется в деталях. Если дело не в поинтерах (которых не миллионы) и не в отступах на индексах, то в чем же?

Интересно на самом деле, откуда оно берется в деталях. Если дело не в поинтерах (которых не миллионы) и не в отступах на индексах, то в чем же?

дело как раз в поинтерах(aka индексах). Открой первый том Кнута, и почитай про основные структуры данных. Ну вот дерево к примеру: В обычном бинарном непрошитом дереве имеется 2 указателя на один ключ данных. ИЧСХ, ровно половина указателей хранит NULL. С остальными структурами не лучше. Есть правда простые массивы, но они люто тормозят на вставке/удалении. А ещё им нужен большой непрерывный кусок в памяти, а где ты его найдёшь, если у тебя её немного, всего 4Гб? Т.ч. даже простые массивы нельзя использовать в 32х битной архитектуре, даже если там всего 5% на самом деле используется места. А в 64х битной — можно.

Но данных обычно нужно много, потому процент указателей не очень большой, и 32х битные приложения потому IRL ненамного меньше.

Кто сказал x32? :-)

Кто сказал x32? :-)

8032AH? Так это реализация 8051, т.е. x51 ;)