H.J. Lu анонсирует x32-abi

> лично видела как java-приложение использующее 512Мб памяти в 32 битном режиме стало кушать 1.4Гб при смене явы на 64-битную

В жабке для этого есть -XX:+UseCompressedOops

>Вот например, у меня имеется нетбук с процессором Intel Atom и 1GiB RAM.

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

Сейчас уже в мобильники по гигабайту ставят, а когда эта архитектура будет более-менее допилена, найти десктоп/ноут с меньшим 4х гигов оперативки будет можно только у маргиналов. Хренью intel занимается.

спасибо, запишу куда-нибудь на будущее, сейчас 32битная гента стоит там

java

Народ здесь явно не догоняет. Ядро будет обычное amd64 с модификацией для этого abi.

Плюсы в том что:

а) По сравнению с amd64 очень многие программы будут потреблять меньше памяти и кэша. Второе ощутимо сказывается на производительности.

б) Регистров будет в 2 с небольшим раза больше чем на i386

в) По сравнению с i386 будет, наконец, человеческий ABI для PIC (код внутри библиотек) и TLS (до свидания, nosegneg для Xen).

г) long long будет таким же быстрым, как и на amd64 что хорошо для криптографии и архиваторов

Т.е. в идеале этот проект комбинирует преимущества i386 и amd64. Прирост по скорости должен быть заметным как по сравнению с i386, так и по сравнению с amd64.

>x86_64 — x32-abi (x32-psABI)

Это напоминает древний процессорный «зигзак удачи» Intel 8086 -> 8088 :)

Пример контента можно?

Ну.. pg'шные базы, OpenLDAP'ные базы на bdb.. этого мало? Есть различный декстопный софт со своими неправильными бинарными форматами и не всезде заранее узнаешь завязку формата на платформу.

Не, это понятно, как-то ...

Но, в свете сегодняшних реалий и цен на DDR3, не совсем понятен профит от сего действа.
С другой стороны, при наличии уже существующих 64-х разрядных команд и решений, роль издержек на вычисление 64-х разрядного адреса памяти как-то сомнительны и не очевидны.
Добавим еще возню с поддержкой всего этого компиляторами и средствами отладки.
И пока больше вопросов чем понимания, что это правильный шаг, а не забавы технологов и побочные эффекты конкуренции Intel самим с собой.))

> А эта балалайка ещё и монстра родит в стиле x32-ps + PAE, чтобы был доступ поверх четырёх гигов. :D

А зачем PAE? Эта штука все равно в long mode работает, и все 48 бит физической памяти ядру доступны напрямую, и оно их как хочет может мэпать в 4гига виртуальных для процесса.

> а) По сравнению с amd64 очень многие программы будут потреблять меньше памяти и кэша. Второе ощутимо сказывается на производительности.

А это далеко не факт еще.

> Пример контента можно?

Можно. VP7, который для 32бит есть в виде win32 кодека, а для amd64 нет. Хотя, можно спорить, нужен ли VP7 вообще :)

А как же указатели в 32-бит?

> А как же указатели в 32-бит?

Дыг это же в ABI для user-mode указатели 32 бит. А ядро-то внутри все равно 64битное.

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

Назовите цифру.

Мне почему-то кажется, что все разговоры про указатели тянут на <1% той самой производительности.

>> а) По сравнению с amd64 очень многие программы будут потреблять меньше памяти и кэша. Второе ощутимо сказывается на производительности.

А это далеко не факт еще.

Ещё какой факт. Доказано 64-битной жабой.

> Дыг это же в ABI для user-mode указатели 32 бит. А ядро-то внутри все равно 64битное.

То есть имеем фактически тот же PAE, вид сбоку =) Просто ведь прикладной программе больше 4Гб не дадут, а если ядро видит больше, ну так и что?

Что именно доказано ?
Что некие несуществующие команды будут что-то экономить ?

> То есть имеем фактически тот же PAE

С точки зрения usermode, в каком-то смысле да. Но главная проблема с PAE на x86 в том, что в нем и ядру не видно больше 4гигов одновременно, и приходится постоянно дергать туда-сюда таблицы страниц (даже ядерные) и соответсвенно терять время на сливании TLB. Собственно именно поэтому Линус и не любит PAE.

В случае с сабжем этого не будет, ядерные таблицы страниц будут постоянными.

> В случае с сабжем этого не будет, ядерные таблицы страниц будут постоянными.

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

>а) По сравнению с amd64 очень многие программы будут потреблять меньше памяти и кэша. Второе ощутимо сказывается на производительности.

Никто этого «ощутимого» не ощутит. Сейчас тенденция идёт к переписыванию многих приложений на скриптовые языки вроде python, которые едят памяти в разы, а то и на порядки больше, чем С-аналоги. И никого это особо не напрягает. Так что те 10-20% кеша, что освободит этот изврат никто на практике, кроме гос-на Лу, разумеется, и не заметит.

А все остальные перечисленные плюсы и так даёт чистая x86-64.

Т.е. в идеале этот проект комбинирует преимущества i386 и amd64.

Основное практическое преимущество x86-64 - это нормальная адресация 4+ Гб памяти, что здесь и убито. Все эти регистры особого прироста не дают, замерялось многократно.

Новость напоминает выход процессора i8088 с 8-и битной шиной после выхода i8086 с 16-и битной. Наверное этот недо-64 предназначен для всякого рода нетбуков и тому подобных идиотских планшетов. Надо полагать, что основное преимущество - более низкое энергопотребление.

>Что некие несуществующие команды будут что-то экономить ?

Нет, что Java - катализатор тормозов.

> Просто ведь прикладной программе больше 4Гб не дадут,

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

а если ядро видит больше, ну так и что?

Если ядро видит больше, то оно может использовать это больше под buffer/page-cache, или чтобы одновременно запустить больше 4гиговых процессов, не высвопывая их.

>Надо полагать, что основное преимущество - более низкое энергопотребление.

На энергопотреблении это вообще никак не скажется.

> На энергопотреблении это вообще никак не скажется.

Контроллер памяти упростится.

> Все эти регистры особого прироста не дают, замерялось многократно.

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

>> В случае с сабжем этого не будет, ядерные таблицы страниц будут постоянными.

Ловкий зигзуг, а x86_64 уже испарился, да ?

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

Что-то я не уследил за ходом вашей мысли. Кто говорит о новом камне или испарении amd64? «Я Пастернака не читал»©, но интуиция мне подсказывает, что речь не идет даже о новой архитектуре как таковой. Это будет просто еще одна personality для стандартного amd64 ядра, наряду с x86 и обычным amd64. По крайней мере я бы имплементил именно так, и надеюсь, что «в штабе не дураки сидят».©

Во-первых, не упростится. Во-вторых, ты думаешь он много потребляет?

> Память нынче стоит как грязь по осени.

2G планка ~ 1000 руб
MB с Атомом ~ 2000 руб
Итого: 4G RAM = MB c камнем.

Кто там говорил о дешевой RAM?

> Контроллер памяти упростится.

Какой контроллер памяти? При чем тут это? Ни о каких новых процах речи не идет.

> Во-первых, не упростится. Во-вторых, ты думаешь он много потребляет?

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

мож я чет пропустил в этой жизни но зачем изобретать велосипед ? если так важно меньше памяти использовать так оставляйте 32бита!!! имхо полный бред и лепка говна от скуки

TakeMS DIMM DDR3 2048Mb 1333MHz 23 у.е.
http://www.vilka.com.ua/hardware/ram/29031/

года два назад DDR2 на один гиг была дороже

>Как же не упростится, когда шина адреса будет урезана в два раза?

Не будет.

кулер устанавливают не только на процессоре

Контроллер памяти уже давно в проце.

Его придётся разгонять, а значит и повышать его энергозатраты.

Перейдут на NUMA.

> Как же не упростится, когда шина адреса будет урезана в два раза?

Да ? Это ты откуда взял.

Что касается потребления, обрати внимание, что кулер устанавливают не только на процессоре.

Мы уже подбираемся к блоку питания и видео ?

И вообще, с увеличением количества ядер контроллер памяти становится бутылочныи горлышком. Его придётся разгонять, а значит и повышать его энергозатраты.

)) Ну прям оверклокерский фатум какой-то.

> Что касается потребления, обрати внимание, что кулер устанавливают не только на процессоре.

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

Я отвечу в вашем же ключе:

но интуиция мне подсказывает, что речь не идет даже о новой архитектуре как таковой.

А кто говорил о новой архитектуре ?

По крайней мере я бы имплементил именно так, и надеюсь, что «в штабе не дураки сидят».©

Ну не дураки уже один раз сделали атом, а ранее проморгали x64.

> Но, в свете сегодняшних реалий и цен на DDR3, не совсем понятен профит от сего действа.

Представь ноут, в который воткнули процессор с поддержкой 64-битных инструкций, но чипсет которого больше 4 Гб так и не увидит (то, что планки SO-DIMM на 4 Гб кошмарно дорогие, мы оставим в стороне). Средняя программка, скомпилированная для x86_64, содержит не много, а очень много операций «взять по адресу X» и «положить по адресу X» (16 штук РОН хорошо, конечно, но часто все равно жиденько). В результате:

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

Это в DOS 640 килобайт хватало всем — там и запустить можно было один процесс по-человечески (пара жиденьких и тоненьких резидентов не в счет). Верхняя память воспринималась как манна небесная: ура, вот этот текст можно редактировать целиком! А сейчас лишние парусот мегабайт воспринимаются точно так же: можно запустить еще одну софтину, не шибко переживая, что она засвопит все остальное и превратит работу в ад, можно уменьшить износ НЖМД за счет больших кешей, можно создать рамдиск, чтобы на нем что-то сконпелять, а потом обратно всунуть... Кстати, 8 гиг ОЗУ, 6 из них на рамдиск — ядро с включением всего, что вообще поддерживается на этом типе машин, в виде модулей, не собралось: no space left on device.

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

Короче, учитывая, что среди ноутбучных чипсетов шлака больше, чем чего-либо стоящего, а планки SO-DIMM серьезных объемов все еще неприятно дорогие, то концепт вполне может жить.

> Я отвечу в вашем же ключе:

но интуиция мне подсказывает, что речь не идет даже о новой архитектуре как таковой.

А кто говорил о новой архитектуре ?

Изначально Sylvy неудачно выбрала слово «архитектура» вместо «ABI» или «personality» в исходном посте, чем создала у многих впечатление, что речь идет о каких-то новых процах. Возможно я вас неправильно понял, но вы сказали: «Ловкий зигзуг, а x86_64 уже испарился, да ? Вот есть надуманная проблема и решаема она теперь исключительно новым камнем.» Из этого я сделал вывод, что вы тоже предполагаете, что amd64 как архитектура будет выкинута, и заменена другой. Как еще можно трактовать слова о «нов[ом] камне» я не очень понимаю.

По крайней мере я бы имплементил именно так, и надеюсь, что «в штабе не дураки сидят».©

Ну не дураки уже один раз сделали атом, а ранее проморгали x64.

В данном случае под штабом я имел в виду Линуса, Лю и компанию. Именно они будут это имплементить.

что ж, если сделают быстро - поставлю на нетбук, там этой штукенции самое место будет.

> Ну не дураки уже один раз сделали атом,

Насчет D510 скажу, что он неплох для средней рабочей станции, которая должна жрать мало электричества, так как жрет действительно мало. Все остальные атомы — это недоразумение, конечно же. Например, N270. Особенно N270.

Все это здорово, но есть одна загвоздка :
x86_64 УЖЕ ЕСТЬ и его не надо изобретать, а стенания про дорогую память
в отделе продаж CPU Intel не оценят, так как разница в цене на новые CPU ужж явно не будет меньше стоимости задрыпанного 1 гига DDR от этой «экономии». Ыы ??))

 Средняя программка, скомпилированная для x86_64, содержит не много, а очень много операций «взять по адресу X» и «положить по адресу X» (16 штук РОН хорошо, конечно, но часто все равно жиденько). В результате: 

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

Вообще-то, если я правильно помню, amd64 ISA не разрешает 64-битных непосредственных операндов или смещений в инструкциях, только 32-битные. Так что ваш первый пункт вылетает. О существенности двух других пунктов можно дискутировать.

>— куча инструкций с адресом блабла

Ты ещё посмотри сколько компилятор лишних операций в бинарь пишет, давайте писать всё на асме. Или поддержка 16бит в Core-серии, куча транзисторов не используется! Грустьпичаль.

Короче, учитывая, что среди ноутбучных чипсетов шлака больше, чем чего-либо стоящего, а планки SO-DIMM серьезных объемов все еще неприятно дорогие, то концепт вполне может жить.

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

Да да, у многих ту проходит как основой поинт, что покаждому чиху
в коде торчат прямые 64-х разрядные адреса операндов в памяти.
Вот от них бы и надо бы избавится побыстрее ))

> а эта хрень ещё неизвестно когда будет юзабельная

Я думаю «эта хрень» будет юзабельна где-то в 2.6.39 или 2.6.40

а gcc , а либы, а все остальное ?

> а gcc , а либы, а все остальное ?

Ну, это уже более другой вопрос. :)

Если что, лично я вообще не уверен в ценности этой штуки. Но учитывая, что никаких явных негативных последствий от ее создания не предвидится, то против нее я тоже ничего не имею. Может кому-то и пригодится. Может даже окажется, что я был неправ, и пригодится даже мне.

а gcc , а либы, а все остальное ?

И, да, «ограниченно юзабельно»™ оно будет даже без gcc и либ, в конце концов Hello world можно и на асме написать, напрямую используя сисколлы:

	.text
	.code64
	.globl	_start
_start:	movq	$1, %rax
	movq	$1, %rdi
	movq	$msg, %rsi
	movq	$msg_size, %rdx
	movq	$1f, %rcx
	syscall
1:	movq	$60, %rax
	xorq	%rdi, %rdi
	syscall
	.data
msg:	.ascii	"Hello world\xa"
msg_size = . - msg

А binutils вроде уже запили.

(Пример выше – это не x32, если чо, это нормальный amd64).

>Но учитывая, что никаких явных негативных последствий от ее создания не предвидится

По мне так лучше бы этих инженеров направили допиливать intel-video драйвер.