Ганс Питер Анвин (Hans Peter Anvin), один из ключевых разработчиков Linux-ядра в компании Intel и создатель таких проектов как syslinux (http://www.syslinux.org), klibc (http://en.wikipedia.org/wiki/Klibc) и LANANA (http://www.lanana.org/), опубликовал (https://lkml.org/lkml/2012/2/19/124) в списке рассылки разработчиков ядра Linux серию патчей, реализованных в рамках проекта X32 (https://sites.google.com/site/x32abi/), нацеленного на создание гибридного x86_64 ABI с 32-х битной адресацией памяти.X32 представляет собой прослойку поверх стандартного x86_64 ABI ядра, эмулирующую на 64-разрядных системах 32-х битную модель адресации памяти. Как следствие, приложения могут использовать все преимущества архитектуры x86_64, такие как дополнительные регистры, более быстрые инструкции, PIC ABI, но в то же время смогут работать с 32-х битными указателями памяти, что положительно скажется на потреблении памяти, кэша и общей скорости исполнения кода.
Замеры производительности, сделанны...URL: https://lkml.org/lkml/2012/2/19/124
Новость: https://www.opennet.ru/opennews/art.shtml?num=33142
О, отличная вещь. Как раз ушёл с amd64 из-за потребления памяти.
Проще добавить памяти - она сегодня настолько дешевая, что можно не заморачиваться.
> Проще добавить памяти - она сегодня настолько дешевая, что можно не заморачиваться.А также сменить мать, системник ну и проц до кучи. Когда свободных посадочных мест под планки памяти уже нет.
Хм, а что делать с нетбуками?
4-Гб планка - хорошо, но её энергопотребление больше, чем у 2-Гб...
Для начала посчитай количество нетбуков с amd64 и c x86. А ноуты не просто так под amd64, там уже 3+GiB, а PAX еще больший костыль был.
Пардон? Все нетбучные Интел Атомы, начиная с 300-й серии (330 и далее, т.е. как минимум с 2010 года) поддерживают x86-64.
Читать умеем?
> А ноуты не просто так под amd64, там уже 3+GiB
из атомов только самый первый (N270) не умеет х86_64
Знаем-знаем, Athlon64 (K8) c 2 слотами ДДР1 =)
Проще сменить архитектуру - а главное, бесплатно! Хотя есть ли вообще смысл использовать амд64 на <4гиг, тоже вопрос. Разве что понты?
> Знаем-знаем, Athlon64 (K8) c 2 слотами ДДР1 =)
> Проще сменить архитектуру - а главное, бесплатно! Хотя есть ли вообще смысл
> использовать амд64 на <4гиг, тоже вопрос. Разве что понты?Быстрая обработка чисел за раз, SSE, SSE2 в стандарте, доп. регистры и т.д.
Всмысле более быстрая обработка бОльших чисел.
Есть: можно делать mmap больших файлов в большом количестве не боясь вычерпать адресное пространство процесса.
>> Проще добавить памяти - она сегодня настолько дешевая, что можно не заморачиваться.
> А также сменить мать, системник ну и проц до кучи. Когда свободных
> посадочных мест под планки памяти уже нет.Вам мало 16 гиг на десктопе? :)
>>> Проще добавить памяти - она сегодня настолько дешевая, что можно не заморачиваться.
>> А также сменить мать, системник ну и проц до кучи. Когда свободных
>> посадочных мест под планки памяти уже нет.
> Вам мало 16 гиг на десктопе? :)Им масла в рогах мало. Длину и качество члена они заменяют длиной и количеством планок памяти. А потом стонут - "Мне тысячу закладок в файрфоксе открыть не хватает!" :D:D:D:D
87 вкладок в опере. )
$ free -m
total used free shared buffers cached
Mem: 16083 2461 13621 0 62 520
-/+ buffers/cache: 1878 14204
Swap: 0 0 0
> 87 вкладок в опере. )90 вкладок в хроме съедают 8 гиг рамы - пример мега прожорливости. При этом процессов хрома под 100. С другой стороны, в отличии от фф он не течет и выжирает свои 8 гиг где-то через 2-3 дня после открытия, без существенного роста и через месяц. В отличии от фф...Плюс отзывчивость хрома не в пример лучше.
покажите скрин где в хроме умещаются все 90 вкладок и можно работать!?Это единственный недостаток из за чего я не могу перейти на хром (нет многострочных вкладок)
> покажите скрин где в хроме умещаются все 90 вкладок и можно работать!?Окон при этом конечно не 1 - по окну на задачу, и не больше 15 табов на окно. Тогда нет проблем с поиском нужного + с выбором конкретного таба.
> О, отличная вещь. Как раз ушёл с amd64 из-за потребления памяти.Отличается процентов на 20 в большинстве программ, не более. И как-то на машине с 8 Гб 32 бита просто не могут заадресовать мне всю мою память...
> И как-то на машине с 8 Гб 32 бита просто не могут заадресовать мне всю мою память...Совсем никак?
ОС может до 64 Гб, приложения совсем никак.
Вот смотрю на самое жрущее после BOINC приложение - firefox - и вижу +50% потребления как минимум, после перехода на х64.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5527 frank 20 0 2465m 1.5g 24m S 41 27.4 882:49.39 firefox
Вкладок всего лишь пару десятков, да.
> Вот смотрю на самое жрущее после BOINC приложение - firefox - и
> вижу +50% потребления как минимум, после перехода на х64.
> PID USER PR NI
> VIRT RES SHR S %CPU %MEM
> TIME+ COMMAND
> 5527 frank 20 0 2465m
> 1.5g 24m S 41 27.4 882:49.39 firefox
> Вкладок всего лишь пару десятков, да.VIRT RES SHR CPU %MEM
1826m 1.3g 25m 25 8.2Opera
Версия: 11.61
Сборка: 1250
Платформа: Linux
Система: x86_64, 3.2.187 вкладок.
Это не просто костыль, а как-то особо в космических масштабах с отягчающими обстоятельствами костыль.
А, ядро все стерпит.
> Это не просто костыль, а как-то особо в космических масштабахПочему? Если памяти много процессам не требуется, а вот появившиеся в этом веке регистры с командами не помешают -- вполне занятный хак, о котором было слышно ещё осенью, что ли.
>Если памяти много процессам не требуется,Сейчас? А через год? Два? Или 4gb хватит всем?
>>Если памяти много процессам не требуется
> Сейчас? А через год? Два? Или 4gb хватит всем?Вы так пишете, как если бы собственно x86_64 собирались выкинуть... Добавляется _возможность_, для многих типов задач -- действительно полезная, но вовсе не обязательная к применению любой ценой.
Намекаю: перекомпиляция приложений. А иметь в системы два варианта программы под разные архитектуры удовольствие маленькое.
запуск в контейнерах/виртуалках под ограниченный круг задач, например, dns-сервер, веб-сервер и т.п
Не говоря уже о том что они собираются под свои нужды патчить libc, что, мягко говоря, требует длительного тестирования, чем, судя по их сайту, они заниматься не собираются.
> Намекаю: перекомпиляция приложений.Само собой.
> Не говоря уже о том что они собираются под свои нужды патчить libc
Что-то мне подсказывает, что hpa справится.
> не собираются.
Видите ли, это не те люди, у которых на сайтЕ сплошное жонглирование подробными планами. Это те, благодаря которым на моих и Ваших линуксах всё вообще в принципе загружается и работает.
>Что-то мне подсказывает, что hpa справится.А SELINUX мне подсказывает что если и справится то проблем будет больше чем пользы.
>Видите ли, это не те люди, у которых на сайтЕ сплошное жонглирование подробными планами.Да, планов на сайте у них мало. Зато сообщений о багах много.
>> hpa
> SELINUX?
syslinux конечно.
> syslinux конечно.И какие у Вас претензии к syslinux, о путающий его с SELINUX? :)
> И какие у Вас претензии к syslinux, о путающий его с SELINUX? :)Нормально так перепутал :)
видимо нет даёт ему... удовлетворения...
не радует
И много у тебя в системе процессов, потребляющих более 4gb памяти?
Не думаю, что через 2 года их количество увеличится хотя бы на 5%
>И много у тебя в системе процессов, потребляющих более 4gb памяти?3. Догадаешься каких?
>>И много у тебя в системе процессов, потребляющих более 4gb памяти?
> 3. Догадаешься каких?для всех остальных можно использовать прослойку X32
> для всех остальных можно использовать прослойку X32А что, она позволяет _выборочное_ применение к процессам?
В новости написано, что она требует специального ядра и окружения, т.е. отдельного хоста (физического или виртуального).
> А что, она позволяет _выборочное_ применение к процессам?
> В новости написано, что она требует специального ядра и окружения, т.е. отдельного
> хоста (физического или виртуального).под отдельным окружением имеется ввиду поддержка X32 в glibc, gcc, binutils, и ядро, позволяющее X32-вызовы.
На данный момент x86_64-ядро позволяет запуск 32-битных приложений (скомпиленных для старой IA32 архитектуры).
Почему бы не впилить поддержку X32, не вырубая поддержки x86_64?
> В новости написано, что она требует специального ядра и окружения, т.е. отдельного
> хоста (физического или виртуального).IA32-архитектура требует отдельного окружения, и что? для запуска 32-битных приложений использовать отдельный комп?
Что "и что"? Читай по слогам.
>> физического или виртуального
> Что "и что"? Читай по слогам.
>>> физического или виртуальногоПро отдельный хост в новости ничего не говорится (ни про физический, ни про виртуальный)
А вот на VDS-ках было бы актуально.
>приложения могут использовать все преимущества архитектуры x86_64, такие как дополнительные регистры, более быстрые инструкции, PIC ABI, но в то же время смогут работать с 32-х битными указателями памятиА как дополнительные регистры сохранить с 32-х битными указателями памяти?
Читаю про MOV:
>Opcodes A0–A3, in 64-bit mode, are the only cases that support a 64-bit offset value.
>А как дополнительные регистры сохранить с 32-х битными указателями памяти?По abi - указатель (всегда 32-х битный) загоняется в регистр (%rbx, %rbp, %r10 и т.д.). Биты с 32 по 63 - нули.
Кто то вспомнил про то что в 90х на mips было n32 ABI и решил её реинкарнировать но на ia32 =D
Чудесно. И приделать адресацию больших объемов памяти через PAE
Да есть куча случаев, когда адресация больших объемов не нужна. Ну то есть вообще. И подозреваю, что средний десктоп - это как раз тот самый случай.
както я написал скрипт (да да, для десктопа!) который обрабатывает инфу..и впринцепе его работа укладывается в 1~3 GB памяти .... но както один раз [не ради экспериента, а для дела!] я задал такие [редкие] входные параметры которые заставили его жрать памяти на пару лшних гигабайт больше!
...после чего я на следущий день -- купил себе Intel(R)64-комп и установил туда 64-битную операционную систему... потомучто НЕ нужны мне такие "сюрпризы", когда нистого ниссего я вдруг получаю FAIL всеголишь изза того что программе понадобилось чуток побольше памяти чем ей способна дать 32-битная архитектура!
......и надеюсь что разработчики других программ тоже не будут создавать для меня "сюрпризы", когда работая внутри 64-битной операционной системы вдруг окажется что сторонняя программа использует 32-битный-говнокостыль, который не позваляет экстремально задействовать эту программу на большие данные!
Писание скриптов (увы) никак не укладывается в "средний десктоп". А для стандартного набора - браузер/плеер/офис/картинки/игры 4-х гиг на программу явно хватает - графический редактор один черт свой свап использует.Ну и насчет смого скрипта - тут есть вопросы/сомнения, но информации маловато. Если не секрет - что за область применения? Никак не могу представить что-то подобное, что нужно на десктопе и при этом работает не с потоком и не с базой.
>[оверквотинг удален]
> [редкие] входные параметры которые заставили его жрать памяти на пару лшних
> гигабайт больше!
> ...после чего я на следущий день -- купил себе Intel(R)64-комп и установил
> туда 64-битную операционную систему... потомучто НЕ нужны мне такие "сюрпризы", когда
> нистого ниссего я вдруг получаю FAIL всеголишь изза того что программе
> понадобилось чуток побольше памяти чем ей способна дать 32-битная архитектура!
> ......и надеюсь что разработчики других программ тоже не будут создавать для меня
> "сюрпризы", когда работая внутри 64-битной операционной системы вдруг окажется что сторонняя
> программа использует 32-битный-говнокостыль, который не позваляет экстремально задействовать
> эту программу на большие данные!Или если ответить по-другому - лучше пусть оно сломается в экзотическом случае и придется костылить, но будет чуть быстрее работать в норме.
Помню читал в lkml, что Линусу такой подход (или его предложенная реализация) не понравился.Вот бы иметь статистику, как часто одно приложение на десктопе/сервере потребляет более 4 ГБ памяти. Я так понимаю, что 4 ГБ - ограничение лишь на каждую прогу по отдельности, а не на все в целом, т.к. хост - 64битный.
Да и такие исключения можно запускать чистыми x86_64.
> Вот бы иметь статистику, как часто одно приложение на десктопе/сервере потребляет более 4 ГБ памяти.vmware а лучше сразу несколько копий. в т.ч. на десктопе.
> vmware а лучше сразу несколько копий. в т.ч. на десктопе.Сабж нужен для скорости, а на хостах с вмварью про скорость никто никогда не слышал.
> Сабж нужен для скорости, а на хостах с вмварью про скорость никто
> никогда не слышал."виртуализация на серверах? не, не слышал"
>> Вот бы иметь статистику, как часто одно приложение на десктопе/сервере потребляет более 4 ГБ памяти.
> vmware а лучше сразу несколько копий. в т.ч. на десктопе.Так вам и не нужно vmware запускать в данном режиме. Это было бы верх долбоебизма. А вот внутри виртуалок процессы запускать - вполне нормально будет.
> Вот бы иметь статистику, как часто одно приложение на десктопе/сервере потребляет более 4 ГБ памяти.при чём тут "как часто"? если это случилось у человека хотябы один раз -- то нужно понимать что человек получил сбой (или получил БЫ еслибы был на 32)! сбой которого ВПРИНЦЕПЕ не должно было быть!
...по вашему это нормально кагда програмы УМЫШЛЕННО сбоят, в случаях если эти сбои редкие????
переход 64=>32 это заведомо УМЫШЛЕННОЕ обрекание программ на редкие сбои!
Странная логика, если честно. Эдак дойдем до того, что покупка компьютера с 8 ГБ памяти это заведомо обрекание программ на редкие сбои, надо не меньше 64 ГБ...
Отличная идея, давно пора. Как минимум у себя на десктопе я не знаю приложения, которое способно было бы сожрать 4 гига.
> Отличная идея, давно пора. Как минимум у себя на десктопе я не
> знаю приложения, которое способно было бы сожрать 4 гига.Запустите что-нибудь на яве, vuze например. Или firefox свежий.
Да в файрфоксе я всё время сижу, пока больше двух гиг не было, хотя вкладок и за две сотни переваливает. А яве на десктопе делать нечего, тем более в виде vuze. Лично у меня rtorrent прижился даже без морд, но и всяких гуёвин со вменяемым потреблением ресурсов хватает.
может просто поставить 32 битную систему с PAE ядром?
Это не то, в новости так и написано, что программы смогут использовать все плюшки x86_64, однако будут оперировать 32-битными указателями, что повысит производитьельность и уменьшит потребление памяти
регистры
Что регистры? Вот что есть в 64 битном режиме. Кажется, ровно то же самое что и в 32 битном режиме - основные регистры, сопроцессор, ммх и ссе.Архитектура x86-64 имеет:
16 целочисленных 64-битных регистра общего назначения (RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, R8 — R15);
8 80-битных регистров с плавающей точкой (ST0 — ST7);
8 64-битных регистров Multimedia Extensions (MM0 — MM7, имеют общее пространство с регистрами ST0 — ST7);
16 128-битных регистров SSE (XMM0 — XMM15);
64-битный указатель RIP и 64-битный регистр флагов RFLAGS.
кажись, как минимум, целочисленных общего назначения в два раза меньше было. Наверное доступ к тем R8-R15 только в 64-битном режиме. Соответственно, если использовать "понимающий" компилятор и перекомпилировать программы, то большее число вызовов функций теперь параметры будут передавать через эти регистры общего назначения, а не через стек. Что значительно быстрее.
х86:
EAX, EBX, ECX, EDX, EBP, ESI, EDI, ESP - 8 регистров общего назначения, а не 16
регистров много не бывает.
> 16 128-битных регистров SSE (XMM0 — XMM15);А в IA32 их 8 (XMM0 - XMM7).
Это железо появилось ещё полгода назад, а поддержкап в Linux только что. На чём же оно работало?
Железо? Ядро не железное. Это заблуждение.
А смысл? 32 бита сейчас актуальны в основном для поддержки старого железа, которое в обозримом будущем окончательно устареет. Экономия памяти? При ее современных объемах и стоимости нет смысла делать что-то новое - кому позарез нужно, есть PAE.
Я согласен, однако если подумать, то тут возможно помимо экономии памяти и на производительность как-то повлияет.
> Я согласен, однако если подумать, то тут возможно помимо экономии памяти и
> на производительность как-то повлияет.hint: L1/L2 cache -- тоже память.
> hint: L1/L2 cache -- тоже память.Префиксы. Не забывайте, что изменение размера операнда - тоже не особо ценный мех, и в ряде случаев сожрет все плюсы от мелких указателей.
>> hint: L1/L2 cache -- тоже память.
> Префиксы. Не забывайте, что изменение размера операнда - тоже не особо ценный
> мех, и в ряде случаев сожрет все плюсы от мелких указателей.размеры новых операндов выровнены для быстрого prefetch
А смысл использовать 64-битные указатели, если достаточно 32-битных? :)
Ваш вопрос похож на вопрос автомобилиста в США в 70-х: "Если бензин такой дешёвый, нафига нужны маленькие машины и дизельные двигатели?"
А смысл тогда в булевых переменных? sizeof(bool) = 1 байт, хотя по факту используем лишь 1 бит. Жутко неэффективно, батенька, коэффициент эффективности лишь 1/8 = 12,5%. В то время как в ситуации с указателями = 1/2 = 50%.
Булевы переменные нужны исключительно для удобства и этим компенсируют свою неэффективность. Если тебе нужна эффективность — используй битовые поля и << move it, move it >>.
Все почемуто забыли о встраиваемых системах, роутерах, телефонах на ядре.. там ведь нет потребления более 4гб памяти. Если этот патч ускорит производительность работы с памяти на подобных системах то это конечно будет здорово.
> Все почемуто забыли о встраиваемых системах, роутерах, телефонах на ядре..Это всё-таки не x86 в подавляющем большинстве, так что именно эта новость их прямщас скорее не затрагивает (хотя понятно, что интелу такое положение дел покоя не даёт).
Есть вагон встроенных систем на x86 - но вот 64 бит там обычно нет и близко. Зато может 386 оказаться :-)
> Есть вагон встроенных систем на x86 - но вот 64 бит там
> обычно нет и близко. Зато может 386 оказаться :-)Современные аццкие одмины обычно не знают или не помнят о такой вещи, как промэлектроника.
>что внедрение нового ABI в некоторых случаях позволяет добиться прироста скорости исполнения кода до 32%За счет чего так?
За счет локальности, вестимо. В отдельных (редких) случаях от попадания или не попадания в кэш всего алгоритма производитлеьность может меняться на порядки, не то что на 30%.
Здесь стоит добавить что в новых поколениях процессоров оптимизированные под старые поколения процессоров программы зачастую работают медленнее вообще неоптимизированных. Халявы не будет.
В опенсорс-мире в большинстве случаев это решается простой перекомпиляцией :-) В оставшихся -вроде кодирования/декодирования видео - да, надо добавлять ручные оптимизации, что и делается.
>>что внедрение нового ABI в некоторых случаях позволяет добиться прироста скорости исполнения кода до 32%
> За счет чего так?Некоторые области данных в кеш поместились, видимо... При едвашном изменении входных условий рухнет, как карточный домик, до нескольких десятых процента за счет уменьшения размера кода.
Ну тесты они там на вид стандартные гоняют.
>За счет чего так?Команды прямой адресации короче => больше команд помещается на конвейере, за один цикл чтения из области кода излекается больше команд, декодирование более коротких команд быстрее.
> Команды прямой адресации короче => больше команд помещается на конвейере, за один
> цикл чтения из области кода излекается больше команд, декодирование более коротких
> команд быстрее.Ага, зато у каждой команды, работающей с широкими операндами, появляется префикс смены размера операнда.
> Замеры производительности, сделанные разработчиками, показали, что внедрение
> нового ABI в некоторых случаях позволяет добиться прироста скорости исполнения
> кода до 32% в сравнении с классическим x86_64 ABI, хотя не исключены ситуации,
> в которых наблюдается небольшое падение производительности на 0.5-6%.Что должно означать что 64 битный код на 32% медленнее 32-битного на том же железе в тех же условиях. Поскольку такого в реальности не наблюдается то делаем вывод - автор чего-то темнит.
>Что должно означать что 64 битный код на 32% медленнее 32-битного на том же железе в тех же условиях.Не просто 32-битного, а 32-битного, использующего 16 регистров общего назначения
Скорость выполнения кода на современных процессорах настолько высока, что зачастую ограничивается не столько вычислительными блоками процессора, сколько системой памяти.
Уменьшение размеров указателей в два раза позволяет значительно сократить обьемы пересылаемых данных, а также поместить больше данных в кеш, так что прирост 32% выглядит абсолютно адекватно.
> Уменьшение размеров указателей в два раза позволяет значительно сократить обьемы
> пересылаемых данных, а также поместить больше данных в кеш, так что прирост 32% выглядит
> абсолютно адекватно.Ну так этот прирост должен и в чистом 32-битном режиме быть. Потому что "Уменьшение размеров указателей в два раза позволяет значительно сократить обьемы пересылаемых данных, а также поместить больше данных в кеш".
> Не просто 32-битного, а 32-битного, использующего 16 регистров общего назначения
Собственно говоря, этот прирост в чистом 32-х битном режиме и обнаруживается (для тех типов приложений, которые оперируют данными, состоящими значительной частью из указателей). Проявляется в виде соответствующего падения производительности при работе такой программы в 64-х битном режиме.Как бы то ни было, работа с указателями, старшие 32 бита которых константные - содержит оверхед, и поскольку обсуждаемый патч этот оверхед устраняет (привнося свой, который в большинстве случаем меньший), то его можно только приветствовать.
Подробнее можно?Кто мешает в начале программы обнулить все 64-разрядные регистры, дальше оперируя исключительно 32-разрядными регистрами?
64-х битный указатель нельзя просто так обнулить и использовать его 32-х битную младшую половину.
Это кто тебе такую глупость то сказал?; обнуляем 64-разрядные регистры
xor rsi,rsi
xor rdi,rdi
xor rcx,rcx; дальше используем только 32-разрядный код
mov esi,src ; 32-разрядный указатель
mov edi,dest ; 32-разрядный указатель
mov ecx,cnt
rep movsd
> Собственно говоря, этот прирост в чистом 32-х битном режиме и обнаруживается (для тех
> типов приложений, которые оперируют данными, состоящими значительной частью из
> указателей). Проявляется в виде соответствующего падения производительности при работе
> такой программы в 64-х битном режиме.Из чего и делаем вывод, что данная фишка имеет смысл только если 64-битная программа медленней 32-битной. И много таких встречалось?
>> Собственно говоря, этот прирост в чистом 32-х битном режиме и обнаруживается (для тех
>> типов приложений, которые оперируют данными, состоящими значительной частью из
>> указателей). Проявляется в виде соответствующего падения производительности при работе
>> такой программы в 64-х битном режиме.
> Из чего и делаем вывод, что данная фишка имеет смысл только если
> 64-битная программа медленней 32-битной. И много таких встречалось?Согласен, данный патч не имеет особенного смысла на десктопах и большинстве веб-серверов.
Возможно базы данных, специфическая математика, ну и ембед-системы с жесткими лимитами на память..
Никто и не призывает его пользовать везде и повсюду. Но сама идея вовсе не так абсолютно бесполезна, как некоторые пытаются заявить.
>ембед-системы с жесткими лимитами на памятьНафига в "ембед-системе" x86(64)? Нормальных архитектур хватает
1. для десктопа эта (new X32) архитектура не нужна
2. для embedded -- есть архитектуры намного лучшетоесть делаем в итоге следущий вывод: new X32 -- не нужна :)
>Согласен, данный патч не имеет особенного смысла на десктопах и большинстве веб-серверов.глупости какие "спецы" несут.
именно для десктопа и сервисов с малым потреблением памяти это и нужно.этот патч - это создание 64-разрядных приложений, но с 32-х битной адресацией памяти.
т.е. всё работает как в 64 битах - а это sse, 64-битная логика (в 1 тик),... да даже таймер hpet.
куча вещей не доступна для 32-бит в современном компе.
а 64-бита - перерасход озу. порой в 2-а раза.
а потом нистого ниссего оказывается что <некая-программа> не может работать с файлами размером-которых больше чем 3G, потомучто <автору-программы> никогда в голову не приходила мысль что <ктото> захочет обработать большой файл :D :D [и поэтому в правилах компиляции указана опция "на AMD64 -- компилировать как X32"]
Какой ужОснах.
Т.е. эта программа не работала бы и в 32-битном режиме вообще?
Онли 64?
Экзотический пример.
Тем более что у неё в правилах сборки х32 должна быть указана валидной платформой.
Другими словами должена пройти целый ряд и дЭбилов - разраб, мэнтейнер,... прослойка.Зыж
Не комптлируйте её в x32.:D
> а потом нистого ниссего оказывается что <некая-программа> не может работать с файлами
> размером-которых больше чем 3G, потомучто <автору-программы> никогда в голову не приходила
> мысль что <ктото> захочет обработать большой файл :D :D [и поэтому
> в правилах компиляции указана опция "на AMD64 -- компилировать как X32"]Нее, это потому что в одной убогой системе off_t по умолчанию 32-битный.
То есть загрузка в память для обработки всего файла это по-вашему нормально? Может вам хоть на начальные курсы программирования пойти или учебник какой почитать. Там расскажут про обработку больших файлов потоком и/или блоками.
> То есть загрузка в память для обработки всего файла это по-вашему нормально?
> Может вам хоть на начальные курсы программирования пойти или учебник какой
> почитать. Там расскажут про обработку больших файлов потоком и/или блоками.Бугага, учите матчасть. memory mapping != загрузка файла
>>всего файла это по-вашему нормально?
>>про обработку больших файлов потоком и/или блоками.
> Бугага, учите матчасть. memory mapping != загрузка файлаНу, и, __конечно__ же, не _всего файла. Ога-ога.
Пиковые значение именно такие, правда бывает это редко. Особенно выражено на атомах и других процессорах с (очень) маленьким кэшем.
> Что должно означать что 64 битный код на 32% медленнее 32-битного на
> том же железе в тех же условиях. Поскольку такого в реальности
> не наблюдается то делаем вывод - автор чего-то темнит.Linux с переходом на 64 теряет очень много \к сожалению в том числе скорость\
> Linux с переходом на 64 теряет очень много \к сожалению в том
> числе скорость\OMGWTF?
Кому это на ноуте понадобилось больше чем 4 гига памяти?! Под какие такие нужды?! Наверное сервер с ноута хотите сделать?! Пусть ноуты будут x86, тут вам и лишнего потребления памяти не будет, и энергии батареи. Хотите мощность садитесь за десктоп, нужно еще мощности садитесь за сервер. Производительности без потерь не бывает.Хотите видеть больше 4гб память на x86 то PAE вам в руки.
> Кому это на ноуте понадобилось больше чем 4 гига памяти?! Под какие такие нужды?! Наверное сервер с ноута хотите сделать?!Пользователи Chrome/Chromium смотрят на вас с недоумением.
использую на работе хром на 4-гиговом ноуте, смотрю на коммент с недоумением.
> использую на работе хром на 4-гиговом ноуте, смотрю на коммент с недоумением.Знаем, знаем, с 3 вкладками.
>> использую на работе хром на 4-гиговом ноуте, смотрю на коммент с недоумением.
> Знаем, знаем, с 3 вкладками.зачем? 10-15 вкладок.
Знаем, знаем. Вам печатная машинка нужна, а тут компьютеры обсуждают. Проходите мимо.
> Знаем, знаем. Вам печатная машинка нужна, а тут компьютеры обсуждают. Проходите мимо.Поиграть на нем тоже можно. Oil Rush, например, на ура идет. хром закрывать не приходится.
> Поиграть на нем тоже можно. Oil Rush, например, на ура идет. хром
> закрывать не приходится.А у меня хромиум может запросто спровоцировать oom killer на машине с 8Г оперативы. По поводу чего я сильно симпатизирую лисе :)
ну так не используйте бета-версию
> ну так не используйте бета-версиюЕщё не хватало. Разумеется от версии это не зависит.
> зачем? 10-15 вкладок.помимо этого еще запущен netbeans или eclipse (в зависимости от проекта)
в виртуалке постоянно крутится pl/sql-developer.
тормозов не замечаю.
Хром порождает несколько процессов, каждый из них сможет использовать 4 гигабайта памяти, насколько я понимаю.
Вот уж кому не стоит беспокоиться, так это пользователям Chrome/Chromium. С такой архитектурой браузера переход обратно на 32-битную адресацию памяти это чистейший WIN. Много раз вы видели, чтоб один (и я подчёркиваю ОДИН) процесс хрома занимал 4 Гб?
больше памяти - жирнее дисковый кэш, меньше дискового IO, экономим электроэнергию на запусках диска/перемещениях головки.
Даже если использовать твердотельный накопитель, то меньше телодвижений с 32-битным IO по шине SATA
> Кому это на ноуте понадобилось больше чем 4 гига памяти?! Под какие такие нужды?! Наверное сервер с ноута хотите сделать?!Запомни, пионер - нет никакой разницы между "ноутом" и "сервером". Это тебе микрософт мозги промыл, потому что им выгодно втюхать тебе "домашнюю" винду с ограничением в 3 окна, потом "рабочую" когда ты поймёшь что на этом работать невозможно, а потом и "серверную". А если ты не знаешь зачем нужна память, мне тебя просто жаль.
Я смотрю, для вас напрочь отсутствует классификация оборудования исходя из сферы применения. Как бы вы не пытались, ноут не даст, вам той же мощности что и сервер без жертв потребления энергии. Хорошо представим, что у вас на ноуте больше 4гб памяти, что дальше?! Это вызывает дополнительное потребление батареи. Из-за большого количества памяти стал жирнее кэш, получили прирост дисковой системы, и понижение потребления энергии. Дальше что?Ноут, десктоп, сервер, каждый из этих классов оборудования может выполнять те задачи, для которых они и были разработаны. Ах, нуда для вас запуск серверной программульки на ноуте это эволюция класса.
Так что представитель пионерского отряда, хочу вам напомнить, что носить ноуты с той же вычислительной мощностью, что и десктоп системы например, и при этом автономные станет возможным через 5-15 лет. Когда придумают более энерго-эффективные источники питания для ноутбуков. А пока этого не случилось, почитайте о том, чем оборудование ноутбуков отличается от десктоп систем и самое главное в сторону чего и за счет чего происходят эти изменения.
> Я смотрю, для вас напрочь отсутствует классификация оборудования исходя из сферы применения.Она отсутствует не для меня, а объективно. Я уже написал про промытые мозги, подумайте об этом.
> Как бы вы не пытались, ноут не даст, вам той же мощности что и сервер без жертв потребления энергии.
И зачем мне на ноуте мощность сервера? Мне нужна базовая функциональность, как-то за'mmap'ить файл произвольного размера, не лазить на каждое обращение к БД к диску и, боже упаси, не своппиться.
> Хорошо представим, что у вас на ноуте больше 4гб памяти, что дальше?! Это вызывает
> дополнительное потребление батареи. Из-за большого количества памяти стал жирнее кэш,
> получили прирост дисковой системы, и понижение потребления энергии. Дальше что?А что, понижения потребления вам мало? Ноуты на то и ноуты, вообще-то.
> Ноут, десктоп, сервер, каждый из этих классов оборудования может выполнять те задачи,
> для которых они и были разработаны. Ах, нуда для вас запуск
> серверной программульки на ноуте это эволюция класса.Ложь и ещё раз ложь тех кто промыл вам мозги. А с вашей стороны - тупость и невежество.
> Так что представитель пионерского отряда, хочу вам напомнить, что носить ноуты с
> той же вычислительной мощностью, что и десктоп системы например, и при
> этом автономные станет возможным через 5-15 лет.Вообще-то сейчас ноутбуки и десктоп системы по производительности совпадают. А за 10 лет производительность меняется на порядок, думайте хоть головой иногда какую хрень пишете.
> А пока этого не случилось, почитайте о том, чем оборудование ноутбуков
> отличается от десктоп систем и самое главное в сторону чего и за счет чего
> происходят эти изменения.Я же уже сказал - ничем. Хоть стойки ноутами забивайте - это только лишь дорого и неудобно.
> Вообще-то сейчас ноутбуки и десктоп системы по производительности совпадают.А покажи мне ноут который по производительности натянет вот это?
http://ck.kolivas.org/pictures/Mining/IMG_1048.JPGДа, там 4 штуки толи HD5970, толи HD6990. Одна такая видяшка в среднем делает на криптографии мой проц раз в 70 наверное. Ну а 4 - сам понимаешь. Да. Оно кушает. И требует мощный БП и хорошее охлаждение, никаких батареек не хватит. Любая ноутбучная пукалка совершенно без шансов уделать этого числокрушильного монстра. Ну хотя-бы потому что 4х6990 туда ну никак.
> А за 10 лет производительность меняется на порядок, думайте хоть головой
> иногда какую хрень пишете.Ноутбуки - маломощные пукалки, где в угоду компактности пожертвовано всем. Туда не воткнешь 4 топовых GPU. И 4 винча по 2Тб - тоже. И клава мелкая. И экран. Потому что таскать 24" и полноразмерный PC-104 keyboard на своем горбу регулярно - несколько утомительно. В лучшем случае там проц похож на десктопный. Правда если более менее приличным процом в ноуте пользоваться как на десктопе - мизерный вентиль начинает паскудно верещать, из ноута прет горячий воздух, от аккумов так долго не протянешь. Вот и получается что числокрушилка из ноута - не ахти.
> Я же уже сказал - ничем. Хоть стойки ноутами забивайте - это
> только лишь дорого и неудобно.Ага. Забей мне стойку ноутами с 6990 приаттачеными по 4-6 карточек на девайс, как это некоторые господа делают.
Когда вы видите слово "сервер" у вас в воображении возникают исключительно монструозные мейнфреймы и осбуживающие их техники в белых халатах ? Датацентры значительной частью забиты серверами более слабыми чем средний современный ноут и они не перестают быть серверами как это ни странно.
У серверов зато есть пачка быстрых сетевых карт с аппаратным ускорением, scsi и raid и т.д. и где всё это у ноутбука?
> Хотите видеть больше 4гб память на x86 то PAE вам в руки.Спасибо, дружище. Только вот не "больше 4", а "больше трёх с небольшим"; а тот же Линус рекомендовал применение x86_64 для систем от 1Gb RAM: http://www.realworldtech.com/forums/index.cfm?action=detail&... (и лично у меня ядро с PAE гораздо чаще не просыпается по сравнению с нормальным).
Так что для очень специфических случаев -- как вот когда корень на SSD должен быть совместим с core/core2 -- PAE применять приходится, но радости эти игрушки и впрямь не приносят.
PS: и да, это мой мобильный сборочный сервер -- когда нет доступа к быстрому хосту, зато есть время, настроение и ещё несколько часов батареи.
Вы хотите мощность и производительность без потерь. То есть хотите оперировать большим объемом информации и при этом ничем не жертвовать. Вы можете запускать на том же ноуте что угодно это ваше право, я с этим не спорю. Я лишь говорю о том, что получить все сразу и без жертв не получится.Арифметика проста:
Если вы хотите оперировать большим объемом памяти, то вам нужна x86_64 но платой за это будут дополнительные расходы ресурсов системы которые уходят на обеспечение реализации ее работы.
> Вы хотите мощность и производительность без потерь.Отнюдь, трейдоффы вполне ясны.
>> Хотите видеть больше 4гб память на x86 то PAE вам в руки.
> Спасибо, дружище. Только вот не "больше 4", а "больше трёх с
> небольшим"; а тот же Линус рекомендовал применение x86_64 для систем от
> 1Gb RAM: http://www.realworldtech.com/forums/index.cfm?action=detail&...Линус, как известный коммунист, ругается crap'ами и политическими проститутками примерно с такой же частотой, как Ленин. И неудивительно - им сам Белый Доктор так повелел. Но я так и не увидел ни у него, ни у оппонентов доказательства осмысленности границы тут именно в 1GB. У большинства более внятных комментаторов граница пробегает на 4GB, причины очевидны.
> У большинства более внятных комментаторов граница пробегает на 4GB, причины очевидны.Не смешно, поскольку если бы они вообще понимали, о чём говорят -- то цифра была бы в районе 3.2..3.5 (ну 3.6, не помню особо точно, но там зазор в несколько сот метров). Проверено на куче всякого разного, от старых xeon'ов до не очень старых ноутов.
PS: подозреваю/смутно припоминаю, что CONFIG_HIGHMEM4G уже таит костыли для проброса данных окошками, только и всего. По крайней мере не всё железо физически умело DMA настолько высоко.
>> У большинства более внятных комментаторов граница пробегает на 4GB, причины очевидны.
> Не смешно, поскольку если бы они вообще понимали, о чём говорят --
> то цифра была бы в районе 3.2..3.5 (ну 3.6, не помню
> особо точно, но там зазор в несколько сот метров).Не домысливай. Память обычно ставят или 3, или уже 4, так 3 ещё нет, 4 уже да. Твои 3.6 по любому в этом диапазоне. Так что они понимают, о чём говорят, это ты читаешь справа налево.
Так на исходный вопрос будет ответ? В чём магичность цифры 1GB, или Торвальдсу приглючилось?
> Не домысливай. Память обычно ставят или 3, или уже 4
$ free -m | head -2
total used free shared buffers cached
Mem: 3017 1731 1286 0 71 780Две планки по два гига (ради синхронного двухканального режима), i945. Три с половиной и другими хвостиками (в зависимости от BIOS и, помнится, чипсета/железа) сейчас не покажу, уже давно живых таких под рукой не осталось. Бутни 32-битную livecd-шку у себя и глянь.
> Так на исходный вопрос будет ответ? В чём магичность цифры 1GB, или
> Торвальдсу приглючилось?Я несколько удивился и начались припоминаться циферки что-то в районе 960M; лучше sr@ спроси при случае, что там не так с работой с памятью начинается.
Вот навскидку (см. по "bounce buffers"):
http://lwn.net/2001/0607/kernel.php3
http://lwn.net/2001/0614/a/lt-zones.php3
>> Не домысливай. Память обычно ставят или 3, или уже 4
> Две планки по два гига (ради синхронного двухканального режима), i945. Три
> с половиной и другими хвостиками (в зависимости от BIOS и, помнится,
> чипсета/железа) сейчас не покажу, уже давно живых таких под рукой не
> осталось. Бутни 32-битную livecd-шку у себя и глянь.Что глянуть? Что там будет доступно меньше чем 3.5? Спасибо, кэп.
>> Так на исходный вопрос будет ответ? В чём магичность цифры 1GB, или
>> Торвальдсу приглючилось?
> Я несколько удивился и начались припоминаться циферки что-то в районе 960M; лучше
> sr@ спроси при случае, что там не так с работой с
> памятью начинается.
> Вот навскидку (см. по "bounce buffers"):
> http://lwn.net/2001/0607/kernel.php3
> http://lwn.net/2001/0614/a/lt-zones.php3Муть зелёная. Слоистость адресного пространства из-за ограничений древних устройств (кому 1M, кому 16M, кому 4G) имеет место быть, но собственно буфера для вопроса о виртуальном пространстве ни при чём. Более-менее нормальная формулировка требований получается такой: кому-то хочется иметь в одном виртуальном пространстве и всю VM ядра, и всю физическую память, и VM текущего процесса; и всё это - ради экономии 100 строк кода и пары сотен тактов на маргинальные применения из-за специфичных костылей архитектуры (кроме тех буферов, /dev/mem и ещё нескольких аналогичных применений - такой маппинг нафиг не сдался).
> Кому это на ноуте понадобилось больше чем 4 гига памяти?! Под какие
> такие нужды?! Наверное сервер с ноута хотите сделать?! Пусть ноуты будут
> x86, тут вам и лишнего потребления памяти не будет, и энергии
> батареи. Хотите мощность садитесь за десктоп, нужно еще мощности садитесь за
> сервер. Производительности без потерь не бывает.
> Хотите видеть больше 4гб память на x86 то PAE вам в руки.Не поверишь, чувак. Для некоторых профессионалов ноут - не консьюмерский продукт посейчас. А рабочий инструмент. Из которого нужен именно что МОБИЛЬНЫЙ СЕРВЕР. Вдумайся. И там, случается, приходится и Oracle EE гонять. И одновременно пару-тройку активных виртуалок. А иногда и более тяжкие приложения.
РАЕ - это для другого. РАЕ позволяет операционной системе (и только ей) видеть до 64 Гб ОП (вместо 4 Гб) за счёт увеличения размера страницы с 4 кб до 32 кб. 32-разрядное приложение с PAE получит макс. 4 Гб, без него макс. 3 Гб, а без доп.настроек Windows и вовсе лишь 2 Гб. Чтобы одно приложение использовало больше 4 Гб нужна 64-разрядная адресация. Приложений, использующих больше 4 Гб предостаточно: игры, Photoshop, 3d max, MathLab, ..
Причем тут Шindoшs? Оно не нужно. Вообще разговор про Linux.
Буду ждать в ваниле (ведра,гцц,..), тогда и позмотрю.
Ваглядит заманчиво, особенно для всяких мплэйер, ффмпег и тд, где памяти много не нужно, а всякие фичи цпу очень даже.
Меня что-то смешит резон "снижается потребление памяти". Если взять все указатели программы, очевидно, что их объём стократ меньше самих указываемых данных. Обработка 64 битов тоже ведётся одновременно, т.е. выйгрыш ну настолько смехотворный, что смахивает на лапшу.
Да и если подумать, ну вот кому нужны громады больше 4 гигабайт?! (речь про десктоп) Если это обработка видео, всё спокойно делается при помощи memory mapped files (под винду). Других файлов больше даже 1 гига вообще не видел. Блюрэй? Мёртворождённый отстой. Так что даже и не знаю, имел ли вообще смысл прыгать с 64 битами.
> Да и если подумать, ну вот кому нужны громады больше 4 гигабайт?Есть приложения (игры в основном, также Photoshop, 3D max, MathLab, ..), использующие больше 4 Гб ОП одновременно. Для использования одним приложением больше 4 Гб (точнее больше 3 Гб) нужны 64 бита.
> снижается потребление памяти
Забавно, но факт. Напр. у нас L2-список вида {next, prev, parent_ptr, child_ptr, data_ptr}. Размер для х86 = 20, для х64 = 40. Если у нас в списке 100 элементов, экономия ~2 кб. Вроде немного, но в приложениях списков и массивов много, и можно получить экономию в десятки и сотни мегабайт. Немного, согласен, но ведь и мы над этой "оптимизацией" не сильно заморачивались. :)
> Так что даже и не знаю, имел ли вообще смысл прыгать с 64 битами.
Если по-крестьянски, то размер адресации соразмерен количеству записей, используемых в промышленных базах данных. Сегодняшие базы перешагнули предел в 4 млрд. записей и им нужно больше.
>> Да и если подумать, ну вот кому нужны громады больше 4 гигабайт?
> Есть приложения (игры в основном, также Photoshop, 3D max, MathLab, ..), использующие
> больше 4 Гб ОП одновременно. Для использования одним приложением больше 4
> Гб (точнее больше 3 Гб) нужны 64 бита.Это проблемы Шindoшs. У нас всё ОК!
> Меня что-то смешит резон "снижается потребление памяти". Если взять все указатели программы, очевидно, что их объём стократ меньше самих указываемых данныхДумаешь часто получается хранить данные одним куском лежат? Связные список интов - вот уже указатели занимают в 2 раза больше чем данные. Двусвязный - уже в 4.
> Да и если подумать, ну вот кому нужны громады больше 4 гигабайт?! (речь про десктоп) Если это обработка видео, всё спокойно делается при помощи memory mapped files (под винду).
Ещё один позорный неуч. Ничего что с 32битными указателями ты 4 гига никуда не замаппишь? И что видео вообще-то поточные данные которые не нужно никуда маппить.
> Других файлов больше даже 1 гига вообще не видел.
Ну тут даже продолжать нет смысла. Ты, друг мой, компьютера наверное не видел. Только однозадачную пишущую машинку и игровую приставку...
Посмотрите как-нибудь сколько памяти потребляет, скажем, rb-tree, хранящее map int->int (т.е. что-то вроде разреженного массива). Сложные структуры данных тратят на указатели в разы больше памяти, чем на сами данные. А учитывая нынешнюю любовь к куче уровней абстракции - такого счастья становится много. Если есть ООП - считай, любой объект - это минимум два указателя: указатель на объект и указатель на таблицу виртуальных функций. В общем, много их.
А в чём суть проекта? В long mode никто не запрещает использовать 32-разрядные регистры и указатели, и даже команды с ними [32-разрядными регистрами] будут на 1 байт меньше. Берём и тупо пишем 32-разрядный код. В чём проблема то?
суть в том, чтоб не писать 32-разрядный-only код, там где возможно, нахяляву иметь преимущества x86_64, просто пересобрав уже существующие. проект отлично подойдёт для задачеориентированных virtual appliances, vds и т.п..
А сейчас кто мешает? В 64-разрядном окружении возможно исполнение 32-разрядного кода.
перечитай новость. для чего: экономия памяти (очевидное), повышение производительности (менее очевидное, даже наоборот); сейчас: на i586 нельзя воспользовать преимуществами регистров x86_64 и прочими оптимизациями, на x86_64 для запуска 32-разрядных приходится деражить 32-разрядные версиии софта (как правило дублируя родные), у которых тоже, неясно, что там с оптимизацией и использованием регистров; предлагают: создать архитектуру, где всё как x86_64, только 32. для запуска контейнера vds/виртуалки достаточно подготовить шаблон для сборки/установки или запустить debootstrap/zypper/нужное_подставить
1.
На i586 (Pentium 10-летней давности) не было 64-разрядных регистров и только поэтому "нельзя воспользовать преимуществами регистров x86_64 и прочими оптимизациями".2. "предлагают: создать архитектуру"
Дальше можно не читать. Вы ВООБЩЕ не понимаете о чём говорите.
> 1.
> На i586 (Pentium 10-летней давности) не было 64-разрядных регистров и только поэтому
> "нельзя воспользовать преимуществами регистров x86_64 и прочими оптимизациями".
> 2. "предлагают: создать архитектуру"
> Дальше можно не читать. Вы ВООБЩЕ не понимаете о чём говорите.то, что можно будет указать при сборке (архитектура/abi). понятие инфраструктура - для тебя, видимо, из области гуманитарных наук, если приходится объяснять по 5 раз то, что написано в новости, и спецификациям по ссылкам, по которым ты даже не удосужился сходить
1. не внося в исходники исправлений вообще
2. то, что можно будет указать при сборке (архитектура/abi)Ваши высказывания не согласуются друг с другом. Из-за этого, а также обилия оскорблений и перевирания терминологии крайне сложно понять что именно вы имеете в виду.
> 1. не внося в исходники исправлений вообще
> 2. то, что можно будет указать при сборке (архитектура/abi)
> Ваши высказывания не согласуются друг с другом. Из-за этого, а также обилия
> оскорблений и перевирания терминологии крайне сложно понять что именно вы имеете
> в виду.это исправления на уровене двух-трёх ifdef'ов, которые хорошо автоматизируются и централизирутся (скипты сборки пакетов deb, rpm, obs-подобные системы и т.п.)
На, держи пример:; обнуляем 64-разрядные регистры
xor rsi,rsi
xor rdi,rdi
xor rcx,rcx; дальше используем только 32-разрядный код
mov esi,src ; 32-разрядный указатель
mov edi,dest ; 32-разрядный указатель
mov ecx,cnt
rep movsd
> На, держи пример:
> ; обнуляем 64-разрядные регистры
> xor rsi,rsi
> xor rdi,rdi
> xor rcx,rcx
> ; дальше используем только 32-разрядный код
> mov esi,src ; 32-разрядный указатель
> mov edi,dest ; 32-разрядный указатель
> mov ecx,cnt
> rep movsdмне что переписывать весь софт для этого?
"X32 представляет собой прослойку поверх стандартного x86_64 ABI ядра, эмулирующую на 64-разрядных системах 32-х битную модель адресации памяти"Ещё раз: "32-х битную модель адресации памяти" можно использовать в "64-разрядных системах" безо всяких ухищерений. Сути проекта всё ещё не понимаю.
> "X32 представляет собой прослойку поверх стандартного x86_64 ABI ядра, эмулирующую на 64-разрядных
> системах 32-х битную модель адресации памяти"
> Ещё раз: "32-х битную модель адресации памяти" можно использовать в "64-разрядных системах"
> безо всяких ухищерений. Сути проекта всё ещё не понимаю.суть в том, чтоб взять debootstrap, имеющийся софт, указать архитектуру/abi x32 и создать шаблон для chroot/openvz/xen/kvm, не внося в исходники исправлений вообще
>Ещё раз: "32-х битную модель адресации памяти" можно использовать в "64-разрядных системах" безо всяких ухищерений.Это если на ASM'е фигачить. А как насчёт существующих компиляторов C/C++ (нас в данном случае интересует GCC, ну и может clang/llvm). Они так могут? Для того может и создают отдельный ABI. Или ты предлагаешь расширить существующий x86_64 ABI?
Это всё объясняет. Спасибо. Но по мне так сами придумали геморрой, сами себе его героически лечат.
>Это если на ASM'е фигачить. А как насчёт существующих компиляторов C/C++ (нас в данном случае интересует GCC, ну и может clang/llvm). Они так могут?да. могут. и всегда могли! :D
просто делают 32-битный код и всё.
а вот как его выполнить в 64-битной системе - это уже думает ядро+бинутилс+32-битные-либы.
>Для того может и создают отдельный ABI. Или ты предлагаешь расширить существующий x86_64 ABI?нет. не для этого.
идея сабжа такова - создавать 64-х битные (!!!!) приложения, но в которых указатели 32-битные.
что уменьшает размер кода, инструкций, адресной логики, уменьшает использования памяти, кэша.
но при этом все плюшки x86-64 остаются.
>да. могут. и всегда могли! :DЧто они могли? Генерировать код который использует 64-х битные плюшки и 32-х битные указатели? И для этого был адекватный ABI? Научи меня как собрать toolchain под это дело.
Тогда нафига нужно:
>а также интегрировать поддержку новой "архитектуры" в пакеты binutils, libc и GCC
>просто делают 32-битный код и всё.Т.е. смешивать не умели?
>нет. не для этого.
Следи за мыслью. GCC + binutils + сотоварищи умеют либо одно, либо другое. Захотелось смесь => запиливают новый ABI (соглашение о том как и что будет в конечном бинарнике) => обеспечивают поддержку для toolchain и ядра. Все рады, ну окромя тех кто будет это дело поддерживать.
Не нужно неуклюжих оправдований. Вы с ваней скатились на 32 в 64 окружении. Что уже давно работает. И это любой компилятор мог.
>>а также интегрировать поддержку новой "архитектуры" в пакеты binutils, libc и GCC>просто делают 32-битный код и всё.
>Т.е. смешивать не умели?Что не понятно в "новой архитектуры"?
> Следи за мыслью. GCC + binutils + сотоварищи умеют либо одно, либо другое.Они умели только те архитектуры, которым их научили.
>Захотелось смесь => запиливают новый ABI (соглашение о том как и что будет в конечном бинарнике) => обеспечивают поддержку для toolchain и ядра. Все рады, ну окромя тех кто будет это дело поддерживать.Да. И что? :D
gcc нужно научить генерить для "новой" архитектуры.
Ядро, лдд и прочий бинутилс - для правильного разворачивания и выполнения.
Профит стоит того, чтобы этим заморочиться.
>Что не понятно в "новой архитектуры"?Единственное что мне тут не понятно, так это как ты научился писать не умея читать.
>"X32 представляет собой прослойку поверх стандартного x86_64 ABI ядра, эмулирующую на 64-разрядных системах 32-х битную модель адресации памяти"
>Ещё раз: "32-х битную модель адресации памяти" можно использовать в "64-разрядных системах" безо всяких ухищерений. Сути проекта всё ещё не понимаю.чего тут не понятного?
грубо x32 - это 64-битное приложение (да-да! со всеми вытекающими), но с 32-битной адресацией памяти.
Снимаю шапку перед Анвином, молодец !!! Ему только за SYSLINUX памятник поставить надо, остальные пусть подавятся асcемблерным кодом :)
