> в amd64 в отличие от рисков длина команды переменная

У современных рисков (хотя можно ли их ещё называть рисками?) тоже переменная:

ARM Thumb-2: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344b/BEIIEGAF...

microMIPS: http://www.mips.com/products/architectures/micromips/

>> в amd64 в отличие от рисков длина команды переменная

У современных рисков (хотя можно ли их ещё называть рисками?) тоже переменная:

Ну хорошо, пусть будет так: «в amd64 в отличие от классических рисков, с которыми и связаны все истории про распухание кода при переходе к 64битности, длина команды переменная».

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

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

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

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

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

> В итоге результат сильно зависит от размера кода и данных, которые надо обработать.

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

Например, интуиция подсказывает, что во всяких интерпретируемых языках/виртуальных машинах аццкие деревья/списочные структуры/хеши возможно могут получить выгоду от x32. Не связано ли это с андроедом, интересно.

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

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

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

Надо вернуться к изначальному вопросу - «нафига все это затеяно». Если ради борьбы с ARM, то про совместимость софта говорить смысла мало.

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

> идиоты из штеуда не догадались удвоить L1 и разом решить все проблемы

При увеличении размера кэша, неизбежно ухудшается его скорость. Поэтому L1 приходится делать относительно маленьким. Более подробную информацию найдёте в сети элементарным поиском. Я даже вам первую попавшуюся ссылку подкину - http://forum.ixbt.com/topic.cgi?id=8:19534

> Я готов поверить, что Штеуду хочется выкатить новую архитектуру

А как вы себе это представляете? В чем будет новость архитектуры? Я хочу обратить внимание, что с ядерной стороны сабж не предполагает существенных изменений, x32 работает на обычном x86-64 ядре, и соответственно, требует полной реализации amd64 архитектуры. А если внезапно кто-то выкатит проц, с урезанной реализацией amd64, то это потребует глобальной переделки всего йадра, и на этом месте Линус взбрыкнет и пошлет таких инноваторов.

> При увеличении размера кэша, неизбежно ухудшается его скорость. Поэтому L1 приходится делать относительно маленьким.

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

> Я хочу обратить внимание, что с ядерной стороны сабж не предполагает существенных изменений, x32 работает на обычном x86-64 ядре, и соответственно, требует полной реализации amd64 архитектуры.

Это какая-то магия про частичную девственность. Будет новая платформа сборки. А если проталкивать новую платформу - дык на нормальных железках и с нормальным профитом. Иначе смысла не вижу.

первый камент человека прочитавшего все 6 страниц других каментов

прочитал все 6 страниц каментов, убив примерно 2.5 часа. Из прочтённого могу сказать что(уже трудно отделить собственные мысли от ваших, но самые ценные каменты далии анонимусы и vadic): 1. это затевается для увеличения быстродействия и экономии памяти. 2. для излечения профита из этой фичи достаточно будет с помошью модифицированного компилятора пересобрать уже заточенную под х64 программу, которую можно будет запускать под ядром с новым x32 ABI, точно также как сейчас можно запускать х86 под х64. Сам х32 ABI является дополнением(модификацией) к существующему х86(ia32) ABI 3. предполагаю что это можно будет ощутить на скриптовых языках.(например сейчас php или perl скрипты под запущенные на х64 интерпретаторе жрут в 2 раза больше памяти чем на х86 интерпретаторе, если кому-то не лень перепроверить и уточнить, с удовольствием посмотрю ваши результаты, т.к. тестил сам один раз и на скорую руку, и всё не соберусь проверить досконально). в комментариях также упоминали что это присуще и java приложениям и в jvm даже есть флаг -xx:+UseCompressedOOps для сокращения расхода памяти. Может кто-нибудь знает такой флаг для php? 4. под виндовс мы этого врядли дождёмся(разве что с апдейтом). 5. выгоду из этого извлекут а)юзеры с специфическими требованиями и манией к оптимизациям б)производители мобильных устройств в) владельцы больших количеств серверов исполняющих поподающий под оптимизацию код(например google с ихним pythonовым app engine, если сказанное мною выше про скриптовые языки относится и к питону)

З.Ы. моск реально опух, еле выдавил из себя этот камент, пора спать.

> просто несколько другая вариация ABI, с устранением наверное наиболее часто упоминаемого недостатка amd64 - аппетитов к памяти, в среднем конечно оно 15-20% , но кое где может и за 100% переваливать, лично видела как java-приложение использующее 512Мб памяти в 32 битном режиме стало кушать 1.4Гб при смене явы на 64-битную

А Вам не пришло в голову, что «используемая» память это просто тот кусок, которых JVM отхватывает по умолчанию. И это самое «по умолчанию» зависит от много чего, в том числе и от битности. Вообще-то в свое время Sun рекомендовала использовать 64 битный режим только если приложению надо более 2х гигабайт. Так что я даже несколько удивлен, что оно отхватило только 1.4.

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

Брал планку на 4 гига Patriot DDR3-1333 за 1700 рублей? От Kingmax и некоторых производителей есть дешевле. А двуканальный набор 2x2 стоит ещё дешевле. Не вижу смысла в процессорах, которые адресуют только до 4 гигов. А если нужно съекономить память, то почему бы не запустить 32-разрядное приложение в 64-разрядной среде. Процессор просто переключится в 32-разрядный режим.

Я хочу обратить внимание, что с ядерной стороны сабж не предполагает существенных изменений, x32 работает на обычном x86-64 ядре, и соответственно, требует полной реализации amd64 архитектуры.

Это какая-то магия про частичную девственность. Будет новая платформа сборки. А если проталкивать новую платформу - дык на нормальных железках и с нормальным профитом. Иначе смысла не вижу.

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

Вот кстати Энвин отвечает Коксу практически то же, что и я говорил много раз:

> It's a simple question - why do we care, why do we want the overhead and the hassle, what do users get in return ?

The target applications are an embedded (closed or mostly closed) environment, and the question is if the performance gain is worth it. It is an open question at this stage and we'll see what the numbers look like and, if it turns out to be worthwhile, what exactly the final implementation will look like."

Типа они и сами еще не знают, стоит ли оно того, и нужно ли им.

6 страниц флуда ради sizeof(void*)=4 ? :))

[H.J. Lu] в мире Линукс человек номер 1 от Intel, автор libc5 (той самой что была до Glibc, многие наверное и не помнят) и один из ведущих разработчиков binutils и GCC

Строго говоря, libc5 была основана на libc4 (разница в том, что libc5 поддерживала ELF, а четвертая была a.out'ной), и так далее, а изначальная линуксная libc была таки основана на glibc 1.x. Хотя, изменений по сравнению с glibc там было дофига, так что это наверное правильнее назвать форком. И, да, несмотря на все вышесказанное вклад Лю и других (IIRC и Дреппер успел над более ранними libc поработать) действительно был огромен и от изначального glibc там оставалось вроде довольно немного.

И если я правильно помню, Лю до интела успел поработать в Cygnus(*) Support (не путать с Cygnus Spaceworks), конторе, которая была (и остается и сейчас, но в составе Red Hat) мэйнтейнером binutils и egcs (кроме прочего).

--------

(*) CYGNUS – Your GNU Support

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

H Peter Anvin там уже есть... может и Линус чего напишет ) посмотрим...

там для приложения требуется явное указание этого куска -Xms -Xmx

и если для 32 бит это -Xms524m -Xmx524m
и все работает, то для 64 бит приходится задавать 1.4 Гб, иначе ничего просто не загрузится с сообщением о надостатке памяти.

>Downside этого в том, что для таких особо скомпиленных программ нужен особый ABI

Ну как-то получается что-то типа мультилиб системы, принципиальной разницы нет.

>> При увеличении размера кэша, неизбежно ухудшается его скорость. Поэтому L1 приходится делать относительно маленьким.

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

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

> Было бы на что

Обратите внимание: он уже не пытается убедить общество в том, что 30% от стоимости ПК - это совсем уж дешево.

> совсем уж дешево.

*совсем уж даром

>сейчас в рассылке вступил в дискуссию Алан Кокс, с (типичным лоровским «ненужен») вопросом, а зачем все это надо , что от этого будет иметь конечный пользователь и стоит ли на себя вообще брать труды по поддержанию лишнего ABI

И Алан как всегда прав :)

Подозреваю что для «особых случаев» профита от 32-битных указателей на 64-битной архитектуре будет достаточно лишнего флага оптимизации компилятора (для СЗЗБ разумеется). А вот лишнее ABI не нужно :)

>Результат: минимум (вплоть до нуля) работы с памятью в стандартной рутине по вызову функций, что в сотни раз быстрее аналогичных процедур на x86.

Разве это не сглаживается L1-кэшем? А вершина стека всегда будет в кэше.

Ну черт его знает. Я вот посмотрел новость и у меня закралась надежда, что Штеуд обрежет текущий x86, оставив только x86_64 (то есть удешевит процессор, избавившись от части мусора) и потом прикрути этот самый ABI на 32 бита. В результате мы получим более простой и дешёвый процессор без всякого 16битного и 32хбитного говна.

>Ну черт его знает. Я вот посмотрел новость и у меня закралась надежда, что Штеуд обрежет текущий x86, оставив только x86_64 (то есть удешевит процессор, избавившись от части мусора) и потом прикрути этот самый ABI на 32 бита. В результате мы получим более простой и дешёвый процессор без всякого 16битного и 32хбитного говна.


То есть выкинет архитектуру с доминирующей (пока) кодовой базой ради
нулевой кодовой базы ? :) Чего только не услышишь на ЛОР :))

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

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

Посмотрел LKML :) Это разве обсуждение :)
Лор по страннице выдал на каждое сообщение в LKML

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

Сверхлинейное ускорение, обусловленное кеш-эффектами таки никто не отменял :)

> Подозреваю что для «особых случаев» профита от 32-битных указателей на 64-битной архитектуре будет достаточно лишнего флага оптимизации компилятора (для СЗЗБ разумеется). А вот лишнее ABI не нужно :)

Только изменений в gcc недостаточно. Нужны еще изменения в libc (например, чтоб malloc(3) ни при каких обстоятельствах не выделял области выше 4 гигов). Нужны и изменения в ядре (например, чтоб mmap(2) не мэпал ничего выше 4 гигов). В результате де факто получаем либо новый API, либо новый ABI. Новый ABI лучше.

> разницы ни в два ни в полтора раза там не будет.

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

IMHO если вдруг X32 покажет (в среднем по больнице) прирост производительности 3-5%, то это будет уже достаточным агрументом для его использования. А 5-10% было бы вообще замечательно.

>Только изменений в gcc недостаточно. Нужны еще изменения в libc (например, чтоб malloc(3) ни при каких обстоятельствах не выделял области выше 4 гигов)

Это всё легко делается (точнее не делается) на этапе оптимизации.

Новый ABI лучше.

Новый ABI _всегда_ хуже :))

На магию тоже официального запрета не было. Только с примерами из жизни напряги.

>> Только изменений в gcc недостаточно. Нужны еще изменения в libc (например, чтоб malloc(3) ни при каких обстоятельствах не выделял области выше 4 гигов)

Это всё легко делается (точнее не делается) на этапе оптимизации.

Это каким же образом интересно? Как вы на этапе оптимизации можете предвидеть, в каком месте malloc захочет выделить область? И, тем более, mmap (или, например, shmat(2)).

Новый ABI лучше.

Новый ABI _всегда_ хуже :))

Новый ABI лучше, чем новый API.

Кстати Алан в LKML коснулся и вопросов безопасности :)

Переполнения на урезанных указателях могут быть весьма фееричны :)

> Как вы на этапе оптимизации можете предвидеть, в каком месте malloc захочет выделить область

А никак. Запрет на внешние короткие указатели

> Переполнения на урезанных указателях могут быть весьма фееричны :)

Каким образом? Ядро должно просто игнорировать старшие биты в тех значениях, которые должны быть 32битными.

> Только с примерами из жизни напряги.

Вас в гугле забанили ? :)

>Каким образом? Ядро должно просто игнорировать старшие биты в тех значениях, которые должны быть 32битными.

Цитирую Алана по слогам:

whats the justification for
everyone having more crud dumping their kernels, more syscall paths
(which are one of the most security critical areas) and the like.

Примеры в студию или не было :) . Реальные примеры, а не лабораторные 5+7 в цикле миллион раз сложить.

Как вы на этапе оптимизации можете предвидеть, в каком месте malloc захочет выделить область

А никак. Запрет на внешние короткие указатели

И как конкретно вы это реализуете в gcc? Вот например у вас есть код:

void *ptr = mmap(NULL, 424242, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);

И ядро вам раз, и возвращает, например, 0x42ffffffff. Если компилятор тупо обрежет до 32бит, то вы будете обращаться совсем в другое место, и получите SIGSEGV.

>Примеры в студию или не было :)

У меня сейчас реально на кластере вертится пример 200 воркеров в 6Мб кешах. Ну и в гугле их вагон и маленькая тележка.

И где там написано про переполнения? Аффтары x32 хотят сохранить семантику 32битного API. Соответственно, (почти) все получаемые ядром значения будут рассматриваться как 32битные, и старшие биты регистров, в которых принимаются соответсвующие параметры будут просто игнорироваться.

Попробуйте написать вот так :)

char ptr = malloc();

;)

Вы смешали в одну кучу каменты Алана с моими :)

Раз уж зашёл такой разговор. Скажите, есть ли смысл (какие плюшки можно получить или гемор подцепить...) ставить ядро для x86_64 на 32х битный пингвин? Памяти 8г, перегнать саму ОС на x86_64 пока нет возможности.

Попробуйте написать вот так :)
char ptr = malloc();

А вдруг мне нужен именно mmap? Хорошо, пусть будет

void *ptr = mmap(NULL, 424242, PROT_READ|PROT_WRITE, MAP_SHARED, STDIN_FILENO, 42*4096);

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

А ядро ты соберешь с -mx32 тоже и оно будет такое же, как эти бинарники.

>планки SO-DIMM серьезных объемов все еще неприятно дорогие

4Gb - 50$. Ну просто о-о-очень дорого.

Вы смешали в одну кучу каменты Алана с моими :)

Ну это же вы попытались использовать слова Кокса в подтверждение вашего тезиса о переполнении:

Переполнения на урезанных указателях могут быть весьма фееричны :)

Каким образом? Ядро должно просто игнорировать старшие биты в тех значениях, которые должны быть 32битными.

Цитирую Алана по слогам:

whats the justification for everyone having more crud dumping their kernels, more syscall paths (which are one of the most security critical areas) and the like.