необходимость в 64 на 2013

ты не в тему. при чем здесь malloc? я тебе могу сказать по-другому, но смысл от этого не изменится и компилятор будет делать тоже самое. смотри и случай: alignment увеличивает затраты памяти на 64-битных системах в среднем на 10-20%

95-я была 32-разрядной оболочкой, под которой работал всё тот же DOS.

95 — 32-разрядная ОС (не оболочка), работающая бок-о-бок с 16-битной ОС, запущенной одновременно с ней. Сделан этот (местами бажный) финт исключительно ради совместимости с 16битным софтом и драйверами. А с чем оно запускается — дело десятое.

Это костыль, который нужен при нехватке оперативной памяти. Тебе часто не хватает оперативной памяти? Тогда купи себе ещё планку, вместо того, чтобы насиловать свой диск.

Между ненужными страницами редкоюзаемого софта и актуальным дисковым кэшем я выберу кэш. Поэтому юзаю своп с 8/16 Гб RAM. К сожалению, не могу купить достаточно RAM, чтобы вместить туда весь HDD. SSD — не панацея, он на порядки медленнее RAM.

95 — 32-разрядная ОС (не оболочка), работающая бок-о-бок с 16-битной ОС

Да щас. USER32.DLL почти полностью состоял из thunk'ов к 16битной USER.EXE. GDI32.DLL - тоже более чем наполовину обертка для GDI16. Блин, до чего же реклама лехко заменяет реальность - «Первая! 32битная! Без ДОСа! Трындец-пипец какая!» А на деле так и не смогли допилить до полностью 32битной системы. Так и похоронили с Миллениумом, гибрид недоделаный.

То, что сделано оно ради совместимости - это понятно, я и так знаю. Но это таки не 32-разрядная ОС, крутите как хотите.

OS/2 была 32-разрядной, BeOS был, и даже Win NT 4.0, ЕМНИП, был 32-разрядным. А домашняя винда стала 32-разрядной только с Win XP.

Да ладно, в процессе работы 16битный код получал управление только при наличии 16битных драйверов или прикладного софта. Это — 32битная ОС.

в процессе работы 16битный код получал управление только при наличии 16битных драйверов

Еще одна жертва рекламы. Здесь речь идет о 16битном коде ДОС. Кроме него в венде 9х было еще валом 16битного кода, унаследованого от 16битных версий виндовс. Об этом скромно помалкивали.

OS/2 была 32-разрядной

16-ти разрядные драйвера

даже Win NT 4.0, ЕМНИП, был 32-разрядным

NT всегда был 32-разрядным

1. Я не спорю же. Но тем не менее, вин95 была не полностью 16-разрядной.

2. Но NT в домашний комп принести удалось только в winXP. Я говорил об этом.

вин95 была не полностью 16-разрядной.

виндовс 3.11 тоже была не полностью 16 разрядной и не запускалась на процессоре ниже, чем и386. После установки библиотеки win32s, на ней запускались 32 битные приложения.

ты не в тему. при чем здесь malloc?

это ты не в теме. Чем ты память-то выделяешь? Какой инструмент существует для этого в твоей альтернативной реальности?

смотри и случай: alignment увеличивает затраты памяти на 64-битных системах в среднем на 10-20%

это только если ты выделяешь кривые структуры, которые не ложатся на 8 char'ов. Ну да, в цифру «10%» я ещё могу поверить. Цифра «20%» это уже ближе к кривому быдлокоду, независимо от архитектуры. Ты учти, что потери на выравнивание и в 32х битных системах имеются, ну и что? Проигрываем немного в памяти, за то сильно выигрываем в быстродействии (ибо, если ты не знал, CPU ещё начиная с первопня тупо не умели читать меньше чем по 64 бита. В те времена приходилось ставить 32х битную память парами. Сейчас естественно тоже не умеют, просто 32х битные SIMM уже никто не юзает в компьютерах)

Уроки русского языка прогуливал, на математике что-то запоминал?:)

именно так. (:

SSD — не панацея, он на порядки медленнее RAM.

дык он и не должен использоваться в качестве RAM.

2. Но NT в домашний комп принести удалось только в winXP. Я говорил об этом.

ну это у тебя дома. А у меня NT4 работала. До 2001го года.

какова вероятность того, что у тебя найдётся _непрерывный_ кусок размером 512Мб, если памяти(виртуальной) 4096Мб?

100%ная, если напрячься и вспомнить, как работает механизм страничной виртуальной памяти.

кривые структуры, которые не ложатся на 8 char'ов.

это которые юзают 32битный int, да?

Проигрываем немного в памяти, за то сильно выигрываем в быстродействии (ибо, если ты не знал, CPU ещё начиная с первопня тупо не умели читать меньше чем по 64 бита.

Для справки: еще 486й делал предвыборку в 256бит. Поэтому корреляция с разрядностью памяти тут никакая - данные уже будут в кэше. А вот более длинный код и данные куда быстрее забивают кэши процессора, превращая, например, Пень в Целерон на ровном месте.

100%ная, если напрячься и вспомнить, как работает механизм страничной виртуальной памяти.

ты действительно думаешь, что фрагментация виртуальной памяти никак не замедляет работу системы? Тогда у меня для тебя плохие новости... Если внутри виртуального пространства у тебя нет достаточно большого куска, то ты всё равно будешь вынужден расчищать место для него. Как именно ты будешь делать, перезамапливать страницы или перемещая блоки — это уже другой вопрос.

кривые структуры, которые не ложатся на 8 char'ов.

это которые юзают 32битный int, да?

а у тебя разве int не 32х битный? Да, в частности и они. Только в том редком случае, если число int'ов нечётное, И при этом структура очень маленькая (если структура из Over9000 int'ов, то она занимает Over36000 байт, и лишние 4 байта ничего не меняют).

Проигрываем немного в памяти, за то сильно выигрываем в быстродействии (ибо, если ты не знал, CPU ещё начиная с первопня тупо не умели читать меньше чем по 64 бита.

Для справки: еще 486й делал предвыборку в 256бит. Поэтому корреляция с разрядностью памяти тут никакая - данные уже будут в кэше. А вот более длинный код и данные куда быстрее забивают кэши процессора, превращая, например, Пень в Целерон на ровном месте.

дык они ненамного длиннее из-за выравнивания. И какая разница, какая предвыборка? Важно не то, что она есть, а то, что она не меньше выравнивания. Если ты структуры выравниваешь по 64 битам, то предвыборка по 32char'а (256 бит), просто приведёт к тому, что ты будешь за раз считать 4 структуры. Ну и что? Пятую ты всё равно туда не запихаешь, как не старайся. Посему без выравнивания быстрее не будет. Будет либо медленнее, либо также. Медленнее будет тогда, когда одна твоя структура лежит в двух выровненных блоках памяти одновременно. Потому твоему 486ом придётся читать не 256 бит, а 512 бит, потому-что нужная структура лежит на границе.

Т.ч. когда читаешь справку, надо ещё и голову подключать. А если в голове насрано, то можно попробовать (я пробовал).

, и лишние 4 байта ничего не меняют

даже в такой структуре

struct { int x,y,z; } xyz[100500900];

Пятую ты всё равно туда не запихаешь, как не старайся.

Это на 486ом. На современых процах и 5тая влезет, и 20я, и еще пару мегабайт.

даже в такой структуре

такая структура будет занимать на 25% больше памяти, и работать где-то так вдвое быстрее(на вскидку, точные цифры даст тест). Это хорошо или плохо?

Если плохо, то объедини две структуры в одну. Код будет сложнее, работать будет медленнее чем с выравниванием и по одной, но вот на сколько именно — сказать невозможно, т.к. весь твой код мне не виден.

В любом случае, это уже та самая оптимизация, которую надо делать в последнюю очередь. Когда ясно что

1. именно этот код является бутылочным горлом

2. все оптимизации алгоритма уже сделаны, и _доказано_ что этот твой пузырёк — наибыстрейший вариант.

Это на 486ом. На современых процах и 5тая влезет, и 20я, и еще пару мегабайт.

прими разупорин. Если в выравненном виде у тебя в 256 бит лезет 4 сущности по 64 бита, то хоть на десятом пентиуме у тебя пятая не полезет в ЭТИ 256 бит.