>Приложения будут кушать чуть меньше памяти.

Нет, жрать они будут почти столько же, но пайку им урежут.

Имхо, это сделано специально чтобы подсадить пользователей на несовместимый велосипед и вынудить конкурентов тратить средства на поддержку и разработку этой дряни. Сколько сейчас стоят 4Gb DDR2? А потом будут стоить ещё дешевле. Ради экономии нескольких сотен метров оперативы нет смысла плодить новую неперспективную архитектуру. А потом на 64 битную систему портируют kernel PAE и наступит счастье.

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

Да - фотошопы, всякие АЕ, 3Д редакторы.

Единственное, для чего оно реально может быть интелу - это искусственное сегментирование рынка.
Но тогда это чистый подарок для AMD. Один раз они такой подарок уже получали, результатом была amd64 и самозакапывание P4.

>Сколько сейчас стоят 4Gb DDR2? А потом будут стоить ещё дешевле.

Этой мантре уже минимум пять лет. До гига догнали быстро, штеуд итаниум замутил, рамбас прикупил в ожидании прибылей, а вот дальше случилась засада. Как раз на рубеже 32-64 бита адресного пространства, что-то типа, завод у самсунга навернулся или еще чего-то в этом роде, короче, 4 гига до сих пор на уровень 1 гига по цене не упали.

Итаниум совсем не выдержал, АМД еле выполз, а теперь вообще вон какая фигня. Опять штеуд неадекватен.

Нуб в треде

Объясните, как в 32 бита можно вместить адресное пространство приложения, используещего, например, 10ГБ памяти.

> Что же используется вместо стека, прямой доступ к Христу за пазуху?

Не знаешь матчасть - так нечего иронизировать попусту. На примере IA-64: в соответствии с рекомендуемыми Intel и наиболее натуральными calling conventions стек вообще не используется для вызова функций. Аргументы функции укладываются в заранее выделенные инструкцией alloc регистры out0, out1, ..., outN (их может быть до 96-ти), которые инструкциями br.call.* (вызов функции) переименовываются в in0, in1, ..., inN. Вместо стека на памяти используется стек из 96 регистров с плавающим регистровым окном. Return pointer сохраняется обычно в одном из локальных (loc0, loc1, etc.) регистров, которые при переименовывании скрываются от вызываемой функции, тем самым избавляя от необходимости класть его на стек. Результат: минимум (вплоть до нуля) работы с памятью в стандартной рутине по вызову функций, что в сотни раз быстрее аналогичных процедур на x86.

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

Фееричная чушь. Каким это образом 64-битные указатели влияют на скорость обхода связных структур?

не, немного не так ))
в вашем высказывании :
----------
И x32 бинарники вполне могут исполнятся параллельно и с нормальными 64битными бинарниками и со старыми i386 полностью 32битными бинарниками.
----------
фрагмент о нормальных 64битных бинарниках, строго говоря, надо бы удалить.

Почему? Вот есть архитектура ядра x86-64 (она же amd64). Под этим ядром можно [будет] запускать бинарники в 3-х разных ABI: нормальный amd64 (он же LP64), x32, и обычный старый i386. Что вам в этом утверждении не нравится?

>Этой мантре уже минимум пять лет. До гига догнали быстро, штеуд итаниум замутил, рамбас прикупил в ожидании прибылей, а вот дальше случилась засада. Как раз на рубеже 32-64 бита адресного пространства, что-то типа, завод у самсунга навернулся или еще чего-то в этом роде, короче, 4 гига до сих пор на уровень 1 гига по цене не упали.

Так я и не говорю про 4 гига одной планкой. В стандартной материнке ПК 2-4 слота, итого можно воткнуть 4-8 гектар. Больше 4 нужно далеко не всем, но вдруг послезавтра приспичит запустить что-то тяжёлое или попользоваться свопом? Приделать к ноуту лишнее гнездо проще изобретения новой архитектуры. Нет же, теперь они станут всех дрючить поддержкой неведомой хрени экономящей чуть-чуть ресурсов. Хотя похожего эффекта можно было бы добиться оптимизацией компилятора и системных либ.

> Объясните, как в 32 бита можно вместить адресное пространство приложения, используещего, например, 10ГБ памяти.

Как-как... Завести по сегменту на каждые 4 GiB памяти и переключать сегменты при работе. При необходимости можно и paging разнести на разные вторичные хранилища.

>Единственное, для чего оно реально может быть интелу - это искусственное сегментирование рынка.

Сие не может быть целью. Интел реально боица, что его имперскому правлению на рынке десктопов и серверов придет конец.

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

> новое ABI для линукс, _программную_ архитектуру с 32 битными указателями памяти

Как я это понимаю, это даже не новая *архитектура ядра* (типа i386 или x86-64 или alpha etc), а просто (несколько упрощая) поддержка нового типа бинарников под *обычными* amd64 ядрами.

> Сына, кабы ты паял к565ру5 (или ещё более ранние) и знал бы, сколько они стоили, ты бы лужицу не газифицировал. Память им видите ли дорогая.

Я даже больше скажу, когда чип тупо невозможно достать, цена – это уже дело десятое...

Не «не надо», а скорее «компилятор не даст». Для этого gcc -mx32 этот целый Лю и пилит. Ну то есть процессору ничего не мешает эти инструкции выполнять, но, похоже, gcc в этом режиме их не будет «видеть» и генерировать, да и ассемблеру видеть запретит (если кто-то асмовыми вставками захочет обойти).

Не, ну можно же напрямую на асме в машинных кодах вставить. Но в общем да, gcc видимо не будет сам такие инструкции генерировать, и, возможно, gas будет на них ругаться.

> Одно мне во всей этой истории не нравится.

Ну, допустим, доделают они тулчейн, дебиан соберут, потом редхэт, и все такое.

А потом интел радостно выкатит процессоров, которые только такое куцое подмножество инструкций и будут использовать, превратив программное решение в аппаратное. В результате у нас будут дешевые «десктопные» 64-битные процессоры с кастрированной 32-битной адресацией и SIGILL на long pointer instructions, а альтернативой будут заоблачно дорогие зеончики с 64-битной.

А смысл? Ядро-то все равно обычное amd64, и для него нужна полная поддержка amd64, так что в проце ничего сократить не получится.

На примере IA-64:

Но речь не о ней.

Каким это образом 64-битные указатели влияют на скорость обхода

связных структур?

Больше кеша требуется... но это, думаю, погоды не сделает.
При этом, если шина данных 64битная, то может и быстрее получиться. :)

>Так я и не говорю про 4 гига одной планкой.

ага. и плати за каждую планку. здесь вообще линейный рост стоимости.

В стандартной материнке ПК 2-4 слота, итого можно воткнуть 4-8 гектар.

большой вопрос.

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

А во вторых, слоты ставят, только гарантии нет. Недавно взяли сервер - ставим три банка - работают только два. Оказалось, в три банка можно поставить только двусторонние планки. Еще чаще банально не хватает напряжения при всех заполненных банках. Кто об этих нюансах догадывется в момент покупки?

Больше 4 нужно далеко не всем,

Если бы люди покупали только то, что реально нужно - до сих пор были бы 386 компы с 4 мегабайтами памяти.

Искуство интела и мекрософта - запаривать подешевле, но всем. Размазывать ниокр по рынку, а значит в основном на тех, кому оно нафиг не нужно.

Объясните, как в 32 бита можно вместить адресное пространство

приложения, используещего, например, 10ГБ памяти.

Как-как... Завести по сегменту на каждые 4 GiB памяти и переключать

сегменты при работе.

Не занимайся ерундой: это уже не «вместить», а «портировать».
Разные вещи. Вместить нельзя никак, а портировать и под риалмод
можно много чего. :)

>> К их счастью, такой режим совместимости уже давным-давно сделан (CONFIG_IA32_EMULATION) для запуска старых 32битных i386 бинарников, надо только чуть-чуть подпилить, чтоб кроме одного ABI (IA-32) повесить на него еще и второй (x32).

Какое ещё нафиг счастье?

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

То раньше в режиме совместимости запускался один кривой ископаемый бинарник, а теперь весь юзерспейс будет так работать.

Ну, во-первых, сейчас в i386 дебиане есть amd64 ядра, и, предпололжительно, есть странные(*) люди, гоняющие обычный 32битный юзерспейс поверх 64битного ядра.

Ну нафига оно такое счастье? Любители усложнять и городить костыли пусть делают вдоль.

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

-------------

(*) На самом деле, может и не такие уж странные. 32битный юзерспейс поверх 64битного ядра однозначно лучше 32битного юзерспейса поверх 32битного ядра с PAE. Весь вопрос тут только в одном: действительно ли 64битный юзерспейс так уж и расточителен по памяти, по сравнению с 32битным. И появление сабжа (с последующими бенчмарками) возможно поможет расставить точки над ы.

> Таким образом, похоже, это и есть реализация x32 ABI for x86_64, или я не прав?

Если вы считаете, что x32 ABI и старый i386 ABI – это одно и то же, то вы не правы.

Тем не менее, я не вижу и повода устраивать из этого драму: никому

хуже от этого быть вроде не должно.

А маинтеинерам поддерживать всякий хлам? :)
Не только маинтейнерам ядра и тулчайнов, а ещё и маинтейнерам
пакетов. Ведь уже сейчас во все практически 64битный дистры входят
и 32битные варианты либ. А тут ещё и это появится... Так что может
запросто и хуже стать. :)

> И таки он будет с обычным x32 совместим

Нету такой вещи, как «обычный x32». То, что вы предположительно имеете в виду, называется обычный x86 или ia-32. Не надо путать терминологию, и без того полно каши в головах у общественности.

>>Так я и не говорю про 4 гига одной планкой.

ага. и плати за каждую планку. здесь вообще линейный рост стоимости.

А как же два каких-то там канала в материнке с 4 слотами? Если воткнёшь все 4 гига в один слот, то задействуешь только 1 канал, а от 8 пока толку мало.

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

DDR2 так резко в DDR3 не мутировала, просто вдруг осознал что 4 гектара самое оно, а покупать про запас резона нет. Оперативка может быть быстрее необходимого, всё упирается в тормоза материнки. У самого DDR2 на 1000Мгц а материнка только на 800, обломно но никуда не прыгнешь.

Еще чаще банально не хватает напряжения при всех заполненных банках.

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

Если бы люди покупали только то, что реально нужно - до сих пор были бы 386 компы с 4 мегабайтами памяти.

И все бы шпиляли в интернете в дум с бензопилами... Лепота. И кодили на _восьмом_ Болланд паскале;) Хорошо но фпц жалко.

>> Объясните, как в 32 бита можно вместить адресное пространство приложения, используещего, например, 10ГБ памяти.

Как-как... Завести по сегменту на каждые 4 GiB памяти и переключать сегменты при работе. При необходимости можно и paging разнести на разные вторичные хранилища.

«Вы были бы правы, если бы не ошибались»©. Проблема в том, что в 64битном режиме сегменты почти полностью выпилили. Остались только fs и gs, если я правильно помню, но и их можно использовать фактически только как лишние^Wдополнительные базовые регистры, и то, они остались только в из-за горячих просьб MS.

>> На примере IA-64:

Но речь не о ней.

В amd64 ABI таки тоже calling convention предусматривает использование регистров для передачи (по крайней мере некоторых) параметров. Подробности см. в спеках.

Каким это образом 64-битные указатели влияют на скорость обхода связных структур?

Больше кеша требуется... но это, думаю, погоды не сделает.

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

При этом, если шина данных 64битная, то может и быстрее получиться. :)

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

Объясните, как в 32 бита можно вместить адресное пространство

приложения, используещего, например, 10ГБ памяти.

Как-как... Завести по сегменту на каждые 4 GiB памяти и переключать

сегменты при работе. При необходимости можно и paging разнести на

разные вторичные хранилища.

«Вы были бы правы, если бы не ошибались»©. Проблема в том, что в

64битном режиме сегменты почти полностью выпилили.

Я хоть и другой анонимус, но ошибаетесь здесь вы.
Их выпили ли в 64битном режиме _для 64битных сегментов_.
А тут люди обсуждали 32битные сегменты. Для них, даже в 64битном
режиме, отлично работает и база, и всё остальное.
С другой стороны, непонятно, как анонимус планировал 64битные
базовые смещения в 32битных сегментах использовать, ну да не суть...
На счёт x32 - вы правы, ia32 имел ввиду, сори. После попыток чтения
драфта от этого Лю, полная каша в голове образовалась с названиями. :))

Но речь не о ней.

В amd64 ABI таки тоже calling convention предусматривает

использование регистров для передачи (по крайней мере некоторых)

параметров.

Но анонимус говорил про стек, а не про параметры...
Короче, ночь на дворе, и все всё путают (включая и меня), да и
новость отстойная от начала и до конца. :)

> Весь вопрос тут только в одном: действительно ли 64битный юзерспейс так уж и расточителен по памяти, по сравнению с 32битным. И появление сабжа (с последующими бенчмарками) возможно поможет расставить точки над ы.

Реальные бенчмарки действительно должны снять все вопросы насчёт нужности/ненужности X32. Но целесообразность хотя бы проведения такого эксперимента видна на примере ppc64 vs. ppc32: http://lixom.net/~olof/lca.pdf

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

> А во вторых, слоты ставят, только гарантии нет. Недавно взяли сервер - ставим три банка - работают только два. Оказалось, в три банка можно поставить только двусторонние планки. Еще чаще банально не хватает напряжения при всех заполненных банках. Кто об этих нюансах догадывется в момент покупки?

Ну, если в инструкции на плату не написано точно, что она поддерживает, то стоит ли покупать такие мамы? На моем десктопе например замечательно работают 8 гигов в 4 DDR2 слотах.

Велосипеды, велосипеды, только сегодня распродажа! Велосипеды, велосипеды!

>> Тем не менее, я не вижу и повода устраивать из этого драму: никому хуже от этого быть вроде не должно.

А маинтеинерам поддерживать всякий хлам? :) Не только маинтейнерам ядра и тулчайнов, а ещё и маинтейнерам пакетов. Ведь уже сейчас во все практически 64битный дистры входят и 32битные варианты либ. А тут ещё и это появится... Так что может запросто и хуже стать. :)

Ну их же никто не заставляет это использовать. Если это кому-то это окажется настолько полезно, что превысит затраты на поддержку, то они будут это использовать, а если нет – не будут. В чем проблема?

>>>> Объясните, как в 32 бита можно вместить адресное пространство приложения, используещего, например, 10ГБ памяти.

Как-как... Завести по сегменту на каждые 4 GiB памяти и переключать сегменты при работе. При необходимости можно и paging разнести на разные вторичные хранилища.

«Вы были бы правы, если бы не ошибались»©. Проблема в том, что в 64битном режиме сегменты почти полностью выпилили.

Я хоть и другой анонимус, но ошибаетесь здесь вы. Их выпилили в 64битном режиме _для 64битных сегментов_. А тут люди обсуждали 32битные сегменты.

Это спорный вопрос. Если речь шла о предлагаемом x32, то тут обсуждали именно 64битные сегменты кода и нормальный 64-bit mode, а не compatibility mode. Потому что x32 бинарники будут работать как раз в 64битном режиме, в котором сегменты таки почти полностью выпилены.

Для них, даже в 64битном режиме, отлично работает и база, и всё остальное.

Если это 32битный сегмент, то это уже не 64битный режим, а compatibility. Давайте таки не путать термины, и тумана станет меньше.

С другой стороны, непонятно, как анонимус планировал 64битные базовые смещения в 32битных сегментах использовать, ну да не суть...

Ну вообще говоря в long mode ядро всегда работает в 64битном режиме, и даже дескрипторы 32битных сегментов для compatibility mode имеют 64битные базы, насколько я помню.

>> Весь вопрос тут только в одном: действительно ли 64битный юзерспейс так уж и расточителен по памяти, по сравнению с 32битным. И появление сабжа (с последующими бенчмарками) возможно поможет расставить точки над ы.

Реальные бенчмарки действительно должны снять все вопросы насчёт нужности/ненужности X32. Но целесообразность хотя бы проведения такого эксперимента видна на примере ppc64 vs. ppc32: http://lixom.net/~olof/lca.pdf

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

Дыг в том то и дело: просто расширение разрядности с 32 до 64 дает обычно только проигрыш, это видно на примере почти всех RISC архитектур, где такой переход был. Теоретически, можно предположить, что и в случае amd64 удлиннение адресов само по себе несет какие-то издержки, которые компенсируются другими бонусами. И вопрос именно в том, стоят ли эти издержки того, чтоб пытаться от них избавиться. И эксперимент с x32 как раз это и покажет в чистом виде: 64битные адреса они выпилят, а все остальные фичи amd64, которые дают выигрыши, оставят.

Это спорный вопрос.

Да. Я про 32битные сегменты подумал именно по тому, что база
упоминалась (которой в 64битных нет).

Если это 32битный сегмент, то это уже не 64битный режим, а

compatibility. Давайте таки не путать термины, и тумана станет

меньше.

Это не совсем путаница - есть long mode, и есть legacy mode.
А compatibility mode - это не совсем отдельный режим, не такой,
как legacy mode. Можно подрежимом long'а считать, но по сути
это long mode.

Ну вообще говоря в long mode ядро всегда работает в 64битном режиме,

и даже дескрипторы 32битных сегментов для compatibility mode имеют

64битные базы, насколько я помню.

Ошибаетесь.
Пруф:
http://support.amd.com/us/Processor_TechDocs/24593.pdf
страница 72, пункт 4.6.2

> Вот он и пытается любым способом снизить потребление ресурсов и повысить быстродействие, чтобы не допустить вход на десктопы конкурентам.

Я не понимаю простую вещь - почему нельзя просто выпилить 32-битный режим.

Кроилово на указателях отвечает только за кеш. Но ведь не в два же раза буст. Можно поискать тесты камней с кешем 4 и 6 мегабайт. Разница будет небольшая совсем.

> Дыг в том то и дело: просто расширение разрядности с 32 до 64 дает обычно только проигрыш, это видно на примере почти всех RISC архитектур, где такой переход был. Теоретически, можно предположить, что и в случае amd64 удлиннение адресов само по себе несет какие-то издержки, которые компенсируются другими бонусами.

У нас как бы разногласий по этому вопросу и нет :) IMHO у AMD просто не было другого выхода. Если бы новая 64-битная архитектура всего лишь увеличивала разрядность и не исправляла старые косяки x86, то, получив ухудшение производительности, пользователи бы ревели белугой и обвиняли AMD во всех смертных грехах.

И вопрос именно в том, стоят ли эти издержки того, чтоб пытаться от них избавиться. И эксперимент с x32 как раз это и покажет в чистом виде: 64битные адреса они выпилят, а все остальные фичи amd64, которые дают выигрыши, оставят.

Уже были упоминания о JVM и luajit, которые используют подобные трюки в 64-битном режиме. Есть предположение, что если бы это было совсем бесполезно, то никто бы и не заморачивался :)

А Intel'у с его Atom'ом еще предстоит ожесточенная борьба против ARM Cortex-A9 за планшеты и смартфоны. И похоже, что они хватаются за любую возможность хоть чуть чуть улучшить производительность и уменьшить потребление ресурсов.

>> это исключительно программное решение

Пока.

так так говоришь, как-будто это что-то плохое

>> Если это 32битный сегмент, то это уже не 64битный режим, а compatibility. Давайте таки не путать термины, и тумана станет меньше.

Это не совсем путаница - есть long mode, и есть legacy mode. А compatibility mode - это не совсем отдельный режим, не такой, как legacy mode. Можно подрежимом long'а считать, но по сути это long mode.

Естественно, compatibility mode это подрежим long mode. Мой пойнт был в том, что compatibility mode – это не 64-bit mode.

Ну вообще говоря в long mode ядро всегда работает в 64битном режиме, и даже дескрипторы 32битных сегментов для compatibility mode имеют 64битные базы, насколько я помню.

Ошибаетесь.
Пруф: http://support.amd.com/us/Processor_TechDocs/24593.pdf страница 72, пункт 4.6.2

На самом деле, в п. 4.6.2 описан GDTR, а дескрипторы описаны в 4.8. Но по сути вы таки правы, да, это я сглючил, 24593 я давно последний раз читал. :) И, да, таки непонятно, как первоначальный анонимус планировал переключать сегменты.

> И эксперимент с x32 как раз это и покажет в чистом виде: 64битные адреса они выпилят, а все остальные фичи amd64, которые дают выигрыши, оставят.

Отказ от лишних битов в адресах не повлияет на упаковку команд. Плотность кода и суперскалярность останутся без изменений.

Ну а чего будет от легкого кроилова на кеше, можно без экспериментов посмотреть. Поищите бенчмарки камней с кешем на 4 и 6 мегабайт. Чуда там нет.

> У нас как бы разногласий по этому вопросу и нет :)

Таки да, нет. :)

IMHO у AMD просто не было другого выхода. Если бы новая 64-битная архитектура всего лишь увеличивала разрядность и не исправляла старые косяки x86, то, получив ухудшение производительности, пользователи бы ревели белугой и обвиняли AMD во всех смертных грехах.

Ну естественно. Я бы это только чуть-чуть в другом ракурсе сформулировал: amd'шники решили, что раз уж нарушать совместимость, (а без нарушения совместимости на 64бита не перейти), то уж выжать из нарушения максимум возможного. Количество регистров давно все мечтали увеличить (пруф – register renaming начиная с PPro), но это одно из тех изменений, которое невозможно было сделать совместимо.

Уже были упоминания о JVM и luajit, которые используют подобные трюки в 64-битном режиме. Есть предположение, что если бы это было совсем бесполезно, то никто бы и не заморачивался :)

Ну вот и будем посмотреть, что это даст (или не даст) в случае с x32.

> Поищите бенчмарки камней с кешем на 4 и 6 мегабайт. Чуда там нет.

Потому что не L1

Ну вы разверните мысль, не стесняйтесь. Наверное у вас имеются секретные данные, что интел делает линукс размером 128 килобайт. И в новых процессорах полностью выпилят котроллер памяти за ненадобностью.

> Ну вы разверните мысль, не стесняйтесь. Наверное у вас имеются секретные данные, что интел делает линукс размером 128 килобайт.

Нет, просто я понимаю, что L1 быстрее и меньше L2, и оказывает на быстродействие больше влияния.

И в новых процессорах полностью выпилят котроллер памяти за ненадобностью.

Подай заявление в Смехопанораму.

> Нет, просто я понимаю, что L1 быстрее и меньше L2, и оказывает на быстродействие больше влияния.

Ага. То есть, вылезли поумничать и подавить авторитетом без конкретных примеров, в своей обычной манере. Бывает.

>> Нет, просто я понимаю, что L1 быстрее и меньше L2, и оказывает на быстродействие больше влияния.

Ага. То есть, вылезли поумничать

Гг. Ну, если для тебя напоминание о важности именно L1 - это «умничание», то у тебя проблемы %)

>> И эксперимент с x32 как раз это и покажет в чистом виде: 64битные адреса они выпилят, а все остальные фичи amd64, которые дают выигрыши, оставят.

Отказ от лишних битов в адресах не повлияет на упаковку команд. Плотность кода и суперскалярность останутся без изменений.

Да, на упаковку команд отказ от 64битных адресов скорее всего практически не повлияет, потому что там и так все упаковано максимально плотно: в amd64 в отличие от рисков длина команды переменная. И, например, там где достаточно 8битного displacement, обычно оно и используется. Не говоря уже о том, что ISA в принципе не предусматривает 64битного displacement или immediate в командах, кроме нескольких ограниченных форм MOV.

Но сократятся размеры всяческих структур данных, использующих указатели, вроде деревьев etc.

Ну а чего будет от легкого кроилова на кеше, можно без экспериментов посмотреть. Поищите бенчмарки камней с кешем на 4 и 6 мегабайт. Чуда там нет.

4 и 6 мегабайт – это кэши третьего уровня, довольно медленные, а сокращение структур данных (возможно) даст выгоду и для более низкоуровневых и более быстрых кэшей.

Хотя, как я уже неоднократно говорил, я сомневаюсь, что выгода будет существенной.

>На моем десктопе например замечательно работают 8 гигов в 4 DDR2 слотах.

это два банка. а проблемы обычно в третьем банке начинаются.

>Потому что не L1

потому кеш, это пластырь на переломе.

>Я не понимаю простую вещь - почему нельзя просто выпилить 32-битный режим.

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

А с другой стороны, есть тонны софта, который никто не будет переписывать под 64 бита. Не нужно это никому.

>>>> В стандартной материнке ПК 2-4 слота, итого можно воткнуть 4-8 гектар.

А во вторых, слоты ставят, только гарантии нет. Недавно взяли сервер - ставим три банка - работают только два. Оказалось, в три банка можно поставить только двусторонние планки. Еще чаще банально не хватает напряжения при всех заполненных банках. Кто об этих нюансах догадывется в момент покупки?

На моем десктопе например замечательно работают 8 гигов в 4 DDR2 слотах.

это два банка. а проблемы обычно в третьем банке начинаются.

Возможно. Но Napilnik таки был прав в первоначальном утверждении.