Один из разработчиков Gentoo опубликовал (http://blog.flameeyes.eu/2012/06/debunking-x32-myths) заметку, в которой попытался разобраться с мифами, витающими вокруг x32 ABI, позволяющего использовать на 64-разрядных системах 32-разрядную модель адресации памяти. Diego Elio "Flameeyes" Pettenò не уверен, что использование x32 ABI оправдывает себя и считает многие из достоинств x32 ABI раздутыми.
Например, в процессе оценки работы сборки (http://www.opennet.me/opennews/art.shtml?num=34065) Gentoo для x32 ABI автор статьи пришёл к выводу, что выигрыш в производительности не столь велик, как показывают некоторые синтетические тесты от создателей x32 ABI. В частности, значительный прогресс отмечается при сравнении с x86 ABI, но при сравнении с x86-64 выигрыш несущественный. В заметке также разбираются вопросы сокращения размера кода и данных (выигрыш незначительный), эффективности кэширования, необходимости адресации более 4 Гб (в качестве аргументов упоминаются ASLR (Address Space Layout Randomization и prelink).URL: http://blog.flameeyes.eu/2012/06/debunking-x32-myths
Новость: http://www.opennet.me/opennews/art.shtml?num=34188
Насчет "небольшого" выигрыша в размере данных - это, вероятно, шутка такая.
В типичной сколько-нибудь сложной 32-битной программе на C или C++ процентов от 30 до 50 процентов оперативной памяти занимают указатели. Удвойте их размер - и пропорция еще ухудшится.
Да хрен с ней, с памятью, она нынче дешевая. Интереснее то, что 32-битных указателей больше влезает в кэш процессора. Но если на деле выхлоп от этого не так высок, то стоит ли городить огород?
Оптимизация из ничего.
Да даже если съекономить 1% памяти и 1% производительности простой перекомпиляцией — адназначна стоит.
Не такое уж ничего - перекомпилировать целый дистрибутив, починить вылезшие из-за этого баги, полностью отказаться от проприетарного софта, который наверняка не будет заморачиваться компиляцией под ещё одну архитектуру.
>полностью отказаться от проприетарного софтано зачем? x32, x64 и x86 смогут сосуществовать в одном дистре
Не переживайте, дистр за вас компилят другие.
А блобы будут работать также, как и сейчас.
> Да даже если съекономить 1% памяти и 1% производительности простой перекомпиляцией — адназначна стоит.про негативные стороны то X32 -- наверно забыли да?!
хреновы оптимизаторы. ненавижу вас!
как пользоваться отражением файла в память на X32 (и на x86) ? опять возвращаемся в каменный век с глупыми ограничениями?
Для дэбилов, в 100 раз, повторяю:
В системе работают сразу 3-и платформы:
x86/x32/amd64.
Напомнить дэбилам какие объёмы файлов можно отобразить в amd64?
Отображальщик, млин. Что не файло, так террабайтное.
Из каменного века вы выйдете только тогда, когда научитесь сображать лучше. И не раньше.
Поймите: в системе придётся держать сразу ТРИ набора системных библиотек. Когда появились CentOS'ы под x86_64, первой командой после развертывания системы было yum remove \*.i?86\*Вот так и с x32. В бою нужна чистая система под конкретную платформу, а не сборная солянка из ужа с ежом.
В бою? Как на счёт ноута?
Когда у себя воюете, то у себя и там и пишите.
А то все фломастеры разные.Зыж
Вот к примеру недвно вполне себе боевой сервер.
А хасп блоб для 1ц под x86.
В вашем, специфичном случае винду поставите, если вдруг припрёт?Если 99% по никогда не нуждаются в >4гб озу, то x32 — отличный выход.
Что делает ваш сервер конкретно? Без сферических коней?
> Если 99% по никогда не нуждаются в >4гб озу, то x32 —
> отличный выход.
> Что делает ваш сервер конкретно? Без сферических коней?Какой из? Конкретно? Без сферических коней? У меня их пачка.
любой.
ведь вы озу для 64 бита не жалеете, но пожалели место на диске для лежащего мёртвым грузом с мултилиб32
> ведь вы озу для 64 бита не жалеете, но пожалели место на
> диске для лежащего мёртвым грузом с мултилиб32Ага, я жалею ОЗУ для двух копий (x64 и x32) всех библиотек в памяти.
если не запускается 32-битное ПО, то только дэбил будет думать, что оно загружается в ОЗУ.но вопрос в силе:
Что делает ваш сервер конкретно, без сферических коней, которым нужно больше 4Гб ОЗУ?
> В вашем, специфичном случае винду поставите, если вдруг припрёт?ESXi никто не отменял.
для управления виртуалками как рах 32-бит достаточно.
лол
xcp и его цатриксовый большой брат поставляются с 32=битгым дом0.
и да, виртуальные машины никогда не мапируют образы витуалок в память:D
> для управления виртуалками как рах 32-бит достаточно.Для управления виртуалками достаточно bare hypervisor и миниатюрного dom0. В целом в dom0 едино, что x32, что x64, что x86.
угу.
одним аргументом в пользу избыточности 64-битных поинторов меньше (чего не скажешь об инструкциях цпу, доступных в amd64 и x32, т.к. дом0 может управлять довольно сложными комбинациями желено/софтверных хранилишь и даже с крипто)
> Да даже если съекономить 1% памяти и 1% производительности простой перекомпиляцией —
> адназначна стоит.Чертовы гентушники. Долбутся 2 недели ради 1% с перекомпилом всего и вся. Потом приходит некто более вменяемый и показывает как можно 1 махом 5% откусить за в 100 раз более короткий срок. Ну там убив пару значков на питоне в трее например, или еще какой жирной и бесполезной фигни.
Чертовы убунтушники. Думают что убрав/добавив пару значков сделали охренненый вклад в оптимизацию системы. А скомпилённые дебы им из космоса завезли.
Потом удивляются, почему хром с 50 вкладками ubuntu.com на x86_64 занимает 4Гб, а на x86 только 2. И опять начинают убирать/добавлять "значки на питоне".
Когда они узнают что значки можно делать в гимпе/инскейпе, коллапс мозга обеспечен.зыж
более тупого коммента тут даже ваня не оставлял.
мои поздравления.
может она и дешевая, зато не быстрая. ЦП может 20/120 тактов тупо нупить, пока КП отработает при промахах кеша на чтении/записи - компиляторы - не боги :)
Особенно в С++.
Объект, таблица указателей на виртуальные функции и тд, и тп. На всём этом тратится память.
А если учесть, что в x32 могут жить все 3 платформы одновременно, то это выход даже не только для ноутов/планшетов/ультрабуков/впс, но и для полноценных серверов.
> но и для полноценных серверов.Что, что? Где вы сейчас увидите сервера с менее 4GiB оперативки?
P.S. Домашние выхлопы не в счет.
1. даже 32-разрядная архитектура позволяет использовать до 64 Гб ОП.
2. 4 Гб выделяется на одно приложение. Т.е. 5 приложений смогут использовать 20 Гб ОП.
3. самое главное: какой смысл заочно спорить с разработчиком Gentoo даже не прочитав его аргументы и ни черта ни соображая в системном программировании?????
верни аккаунт ване!!!
Теоретически можно отмеривать по 4 гб на каждую нитку (если дать каждой нитке свою LDT и каталог страниц). Но среди разработчиков ОС этим делом никто особенно не заморочился, и нитка выполняется в контексте процесса. Это дешевле по ресурсожоркости и проще по мемори шарингу.
в linux потоки/процессы создаются вызовом clone2, у которого куча параметров, позволяющая создавать различные вариации для параллельного выполнения.
тот же fork всего лишь вызывает clone2 с предопределёнными параметрами.
> Теоретически можно отмеривать по 4 гб на каждую нитку (если дать каждой
> нитке свою LDT и каталог страниц). Но среди разработчиков ОС этим
> делом никто особенно не заморочился, и нитка выполняется в контексте процесса.
> Это дешевле по ресурсожоркости и проще по мемори шарингу.от LDT в линуксе же давно отказались, а в винде никогда и не использовали
и у 64бтных процов есть какие то весёлости с отсутствием LDT в 64битном режиме
> 1. даже 32-разрядная архитектура позволяет использовать до 64 Гб ОП.А теперь покажи мне как ты адресуешь 64Гб 32-разрядным указателем...
он сказал правду — 32-разрядная архитектура, а не 32-разрядное приложение позволяет использовать до 64 Гб.
так что вы либо сознательно передёргиваете, либо безсознательно не понимаете.
и я даже затрудняюсь сказать что из этого хуже.
http://ru.wikipedia.org/wiki/PAEВообще address space для приложения остается 4 гб , но общий объем физически адресуемой памяти 64Гб
Ограничение в 4гб для процесса, не для системы...
1. А кто сказал что x32 только для систем с <4гб озу?
2. Как часто обычные приложения (ls, rm, grep, bash, …) требуют для своей работы >4Гб?
Или их полтора килобайта обязательно нужно адресовать 64-битными указателями?
> 2. Как часто обычные приложения (ls, rm, grep, bash, …) требуют для
> своей работы >4Гб?Вы полагаете, что функционирование сервера ограничивается только этими программами?
повторяю (для альтернативно одарённых):
>А если учесть, что в x32 могут жить все 3 платформы одновременно,разъясняю (для альтернативно одарённых):
1. ядро в окружении x32 — 64-битное.
2. в окружении x32 можно устанавливать/компилировать/использовать все 3 платформы одновременно.
например - ls, rm, grep, bash,… скомпилированы в x32; блобы аля flash/skype/… идут в x86; сервер субд (оракл, постгри,…) в amd64.
в платформе x32 нет специфичных каталогов с дублированием для каждой платформы аля /lib, /lib64, /usr/lib, /usr/lib64.
где платформы (x32, x86, amd64) указаны в терминах целевой платформы, тобиш gentoo.
>в платформе x32 нет специфичных каталогов с дублированием для каждой платформы аля /lib, /lib64, /usr/lib, /usr/lib64.А как оно тогда запускает x86 и x86_64?
Слушайте, я вам что ли транслэйт.ру?
Сходите уже по ссылкам в новости и по ссылкам ниже новости.
Там всё это есть.
зыж
http://archives.gentoo.org/gentoo-dev/msg_f0cdf209196aa629d2...
>ive converted my system over to x86/amd64/x32 multilib for funs. but i cansee how some people wont want all three all the time. so the question is how
we want to make this available to users at the release/profile level.>release wise, we could ship a single multilib stage (x86/amd64/x32) and make
it easy to convert to a subset.
сойдёт за ответ?
Таких программистов надо бить. Потом учить алгоритмам и структурам данных.
> Таких программистов надо бить. Потом учить алгоритмам и структурам данных.Он не программист.
Что не мешает ему нравоучительно рассуждать о программировании.
Впрочем, в среде "разработчиков" Gentoo это считается нормальным.
не надо гнать на гентешников, ок?
стэйдж с x32 кстати только они и создали.
Абсолютно с ним согласен - UEFI - 64 бита, ядро может стартовать напрямую из UEFI, 32битная среда используется только для инициализации памяти, на самых ранних стадиях загрузки. Пора выдавить 32битные приложения (и выбросить поддержку 16 бит). Для тех кому надо запускать 32бита - пусть используют виртуализацию.
Правильно глаголишь.
Пора.
Даёшь x32! Ведь это 64-битное приложение с укороченными указателями! :D
> Даёшь x32! Ведь это 64-битное приложение с укороченными указателями! :DДаешь костыли и ходули. Ведь если отпилить вам половину ноги - кой-как ходить вы сможете. Зато экономия места очевидна. При массовом внедрении технологии можно даже сэкономить на материалах. Ведь здания и транспорт можно делать намного компактнее!
ну если у тебя ноги по 4-е метра каждая, то я бы на твоём месте их укоротил.
то что ты можешь проходить террабайт километров каждое утро — ещё не повод так далеко бегать в сортир и сбивать люстры.
> террабайт километров//прочёл, много думал...
хм, вроде в школе преподают.
http://ru.wikipedia.org/wiki/%D0%91%D0%B...
>Байт (англ. byte) — единица хранения и обработки цифровой информации. В современных вычислительных системах байт считается равным восьми битам, в этом случае он может принимать одно из 256.1 терабайт это 2 в степени 40.
так вот терабайт километров означает, что в данном случае каждое утро он проходит столько километров, что для хранения этого числа необходим терабайт.
Проще купить железо на ARM и не париться с кучей устаревшего хлама, жрущего электроэнергию.
> В частности, значительный прогресс отмечается при
> сравнении с x86 ABI, но при сравнении с x86-64
> выигрыш несущественный.Он что - тупой? В этом то и суть - чтобы улучшить производительность до уровня 64бит, при этом оставив все 32битным.
нет же. речь повысить работу с памятью до скорости 32 при остальных фичах 64
Он один из разработчиков Gentoo, это многое объясняет.
Разработчики Gentoo первые и, видимо, пока единственные кто запилил x32 ABI в дистрибутив. Вот это действительно многое объясняет)
И что с того ?Зато вот эта фраза "I honestly wonder how’s it possible for the C library to have so many pointers in its own structures" замечательно показывает что гражданин хреновастенько разбирается в том о чем пишет.
Поясните для неспециалистов, рассуждая каким образом вы пришли к такому заключению?
TROLL MODE ON"honey" - это мёд, а "STL" - майкрософтовский блок, видимо honeSTLy - это что-то "мёдо-майкрософт", а какое отношение это имеет к языку Си?
>TROLL MODE ONМог бы и не писать, ты его не выключаешь.
Серьёзное общение на ресурсе, где отсев комментариев превышает 50%, и шанс выживания у "гы-гы" выше чем у "Торвальдс повёл себя по-хамски", физически невозможно. Администрация создаёт условия и правила игры, люди наполняют содержание. web 2.0 во всей красе.
> где отсев комментариев превышает 50%,Во первых где отсев лживых(!!!) комментариев превышает 50%.
Во вторых да, низкий процент. Надо бы побольше.Зыж
> "Торвальдс повёл себя по-хамски"Ну я считаю, что все эти годы по хамски со своими потребителями ведут себя компании аля нвидиа и мс.
20 лет и один средний палец… ассиметричный ответ и не более.
> Ну я считаюИз серии "Дайте мне одну белую ворону и я докажу что чёрных не существует"
Именно под этим лозунгом ты всё время и выступаешь.
Только не "я", а "я и кардинал". А так всё верно.
Ну а если я всё говорю верно, то чего ты возмущаешься?
Я не возмущаюсь. Тебе показалось.
Брезгую чуть-чуть. Это да. Что наверное отражается в стиле моих комментов.
Но так же осознаю, что холуи полезны.
вантузятники в сторону линукса не могут говорить "верно" - иначе у них мозг коагулирует
ваня, ты гы-гы-гы! физически с тобой невозможно общаться. веб два ноль стеклянный и летит не ровно.
Ещё не запилили, пока рк.
Ждут глибс и гцц.
> Ждут глибс и гцц.А я жду llvm и clang.
А вообще я томат.
Пестицидов кушай меньше, томат.
> А вообще я томат.Овощи на опеннете!
> Разработчики Gentoo первые и, видимо, пока единственные кто запилил x32 ABI в дистрибутив. Вот это действительно многое объясняет)Грег КХ отмечал, что генту разрабатывают очень тупые люди. Имхо, вполне авторитетный источник.
> Грег КХ отмечал, что генту разрабатывают очень тупые люди. Имхо, вполне авторитетный
> источник.Точнее, не сколько тупые, сколько неадекватные.
И чего он тогда на ней сидит?
> И чего он тогда на ней сидит?потому что он разраб генту
> потому что он разраб гентуВидимо, "коллеги"-ламеры (вроде автора сабжа) ему уже плешь проели своими "ценными замечаниями".
тоже неадекват?))
> Разработчики Gentoo первые и, видимо, пока единственные кто запилил x32 ABI в дистрибутив. Вот это действительно многое объясняет)Быть первым - не значит обязательно быть умным и пряморуким.
(осторожно так) товарищ, вы часом не аптгетчик?
> (осторожно так) товарищ, вы часом не аптгетчик?А вы видимо очередной любитель компилить все и вся. Не глядя в сорц...
>> (осторожно так) товарищ, вы часом не аптгетчик?
> А вы видимо очередной любитель компилить все и вся. Не глядя в сорц...Ну вы-то точно бинари в хексредакторе проверяете.
А кто, кроме Gentoo, уже умеет x32 ABI?
умеет апстрим ядра, бинутилс, глибс, гцц. весь стэек для платформы в общем.
если интересует кто уже собрал дистр под эту платформу? пока только стэдж генты есть из полуфабрикатов.
Простите, но разработчик Gentoo - это не авторитет.
Они там до сих пор считают, что линукс должен грузиться без /usr. Это уже диагноз.
Программа разметки диска всех популярных дистрибутивов Linux предлагает назначить новый раздел как /, /home/, /usr, /var. Все предлагают отдельный /usr по желанию.
>Они там до сих пор считают, что линукс должен грузиться без /usr. Это уже диагноз.единственные здравомыслящие люди остались, остальные уже поклоняются потерингу с его бредовыми идеями.
> единственные здравомыслящие люди остались, остальные уже поклоняются потерингу с его бредовыми идеями.Только почему-то их "здравомыслие" сильно конфликтует с объективной реальностью.
Проще говоря, они, как и вы, не в курсе, как грузится Linux. Поэтому вы и порете фигню.
разумеется linux не может загрузится, не включая /usr, системд, пульсаудио и офлайновых обновлений.
пиндец.
> и ещё куча тупейших троллей с 4-я метровыми ногами.а также гости из иной реальности прошедшие террабайты километров
это ж они же, 4-х метрово-ногие и есть.
что-то с логикой у вас слабовато.
> Они там до сих пор считают, что линукс должен грузиться без /usr. Это уже диагноз.Обязан.
Не следует превращать систему сделанную профессионалами в систему сделанную студентами.
> Обязан.
> Не следует превращать систему сделанную профессионалами в систему сделанную студентами.Разумеется. Надо делать наоборот.
Linux - ядро, написанное 20 лет назад студентом Торвальдсом.
Solaris - система, сделанная профессионалами. Уже сто лет в обед /bin, /sbin и /lib там являются симлинками на подкаталоги в /usr.
> Solaris - система, сделанная профессионалами.:)
Да мне как-то всё равно как там оно.> Уже сто лет в обед /bin, /sbin
> и /lib там являются симлинками на подкаталоги в /usr.А давайте устроим разбор полетов по-дистрибутивно с выводами копипастом?
Как снег растает, увидим кто где побывал.
:)
> Да мне как-то всё равно как там оно.Предлагаете не делать разницы между профессионалами и студентами? Парой комментов выше вы придерживались обратной точки зрения.
>> Да мне как-то всё равно как там оно.
> Предлагаете не делать разницы между профессионалами и студентами? Парой комментов выше
> вы придерживались обратной точки зрения.Десктоп и тачевые мобильные и носимые устройства разный класс.
И для планшета systemd с обязательно приколоченным к корню /usr идеальное решение. Да и третьегном сюда отлично вписывается.
Но это уже _не_ десктоп.> Парой комментов выше
> вы придерживались обратной точки зрения.Пинок под седалище понят и принят
Моя сильная ачепятка смахивающая на ляп.
>> Да мне как-то всё равно как там оно.
> Предлагаете не делать разницы между профессионалами и студентами? Парой комментов выше
> вы придерживались обратной точки зрения.Ну и где эта ваша команда профессионалов? Хотя Оракул кажется слегка одумался и уже не так гонит как поначалу. Куча коммерческих Unix уже исчезла, развивается только AIX. HP-UX почти сдохло, т.к. PA-RISC закопали, а итаники нафиг ни кому не сдались. Солярка кажется развивается, посмотрим, будет лет через 10. Linux точно живее всех живых. А уж на тему как правильно разбить ФС - нужно исходить из задачи и применения. То, что хорошо на эмбедовке, вовсе не обязательно должно быть хорошо на нагруженной сервере БД. Мое личное мнение - прибитый гвоздями в корень /usr не нужен
>> Solaris - система, сделанная профессионалами.
> :)
> Да мне как-то всё равно как там оно.Не хотите учиться у людей, которые явно умнее и опытнее вас? Ну-ну.
> Не хотите учиться у людей, которые явно умнее и опытнее вас? Ну-ну.Приколачивая /usr к корню?
Где-то systemd уже не создаёт этих проблем (по грубым беглым прикидкам).В микрософт тоже кто-то умнее меня. Предлагаете учиться у мастдая прикололотив всё в C:?
>Linux - ядро, написанное 20 лет назад студентом Торвальдсом.
>Solaris - система, сделанная профессионалами. Уже сто лет в обед /bin, /sbin и /lib там являются симлинками на подкаталоги в /usr.дешёвый трёп.
> Простите, но разработчик Gentoo - это не авторитет.
> Они там до сих пор считают, что линукс должен грузиться без /usr.
> Это уже диагноз.GNU/Linux, да и любой Unix, должен грузиться без /usr
Если тебе непонятно почему, попробуй сначала разобраться в этом детально. Впрочем, твоя категоричность - это уже диагноз.
Для меня дистрибутивов, которые это не умеют, просто не существует. Как класс.
ps. Да, я использую это. Очень часто. Я хочу на флешке полноценную систему, а не live, но при этом не хочу тратить место. И /usr у меня всегда в squashfs, и монтируется уже из fstab.
Так, пиплы ...ДОЛЖНЫ СУЩЕСТВОВАТЬ /, /tmp, /dev/, /dev/tty, /dev/null, /dev/console
дальше начинается у каждого "свой POSIX".
> Простите, но разработчик Gentoo - это не авторитет.
> Они там до сих пор считают, что линукс должен грузиться без /usr.
> Это уже диагноз.Ага, следующим шагом поттеризации долен быть запрет на загрузку линукса без /home, ага.
Пользовался 64-битной системой с 512 Мб памяти, и чего? Нагружал его браузерами, играми (64-битными) и прикладным ПО - и чего? Где до 50% большее потребление памяти?
Я пробовал загрузить нечаянно убунту 64-битную в лайв режиме в виртуалке с 512 МБ. Не дождался, надоело :) В общем-то да, примерно как 32-битная на 256 МБ.
> Я пробовал загрузить нечаянно убунту 64-битную в лайв режиме в виртуалке с
> 512 МБ. Не дождался, надоело :) В общем-то да, примерно как
> 32-битная на 256 МБ.Так это ж убунта. Нормальные линуксы можно и на 128 загрузить, причем с гуем.
В livecd да?
Оно просто не сможет загрузится и притом 32битная тоже...
> Я пробовал загрузить нечаянно убунту 64-битную в лайв режимеА в чем пойнт запуска 64-битной системы на 512Мб? Обычно оно начинает иметь смысл когда памяти более 2Гб.
А почему должен быть понт? А вообще, ответ на Ваш вопрос очень большой - проще Вам самим почитать про разницу между 32 и 64-битными системами, т.к. не все упирается в "2ГБ" и не так однозначно. В целом можно сделать практически любую программу и для 32 и для 64-битной системы (если смотреть в пределах максимального размера ОЗУ, поддерживаемого самой ОС), но для обработки больших объемов информации несколько проще это сделать на 64-битной системе.В контексте же здесь обсуждаемого лайвсиди это ИМХО не суть важно т.к. не вижу особого смысла делать "числодробилку" с запуском с лайвсиди, а для задачь обслуживания такие объемы ОЗУ в 99,99% не нужны.
>> Я пробовал загрузить нечаянно убунту 64-битную в лайв режиме
> А в чем пойнт запуска 64-битной системы на 512Мб? Обычно оно начинает
> иметь смысл когда памяти более 2Гб.Проверял дырку с mysql, который соглашался с паролем "Маодзедун" с какого-то раза (кстати, так и не согласился). Оно зявлено как работающее на Убунту 12.04 64-бит, поэтому в существующую виртуалку с 512 метрами мозгов сунул образ 64-битки (лайвСД).
> Я пробовал загрузить нечаянно убунту 64-битную в лайв режиме в виртуалке с
> 512 МБ. Не дождался, надоело :) В общем-то да, примерно как
> 32-битная на 256 МБ.Не знаю че там с Livecd в виртуалке, а на живой машине 512 озу убунту 64 приемлемо работает уже несколько лет - вплоть до 11.10. 12.04 не проверял - что-то автоапгрэйд впервые за столько лет обломался :)
Вместо адаптации существующего ПО, под то, что уже есть, придумали еще один огород и под него начнут все адаптировать. Иллюзия прогресса
хм. как и критика чужого труда иллюзия конструктивной критики.
ничего нового в этом плане.
в этом мире все иллюзорно
> Вместо адаптации существующего ПО, под то, что уже есть, придумали еще один
> огород и под него начнут все адаптировать. Иллюзия прогрессаБла-бла-бла. А по делу есть что сказать?
Ну автор практик и как бы в курсе, что что «молитвами/мифами» особо ничего не изменишь.
На серверах, оно не очень то и интересною, а на десктоп системах таки да, особо сэкономить памяти не удастся. Так как там если деббагером/анализатором памяти пробежаться получается что основная память под char[] забита, или под всякие картинки, кеши этих самых картинок. В лучшем случае около 10-5 % оперативной памяти в целом у нагруженной работающими приложениями системы сэкономить удастся. Хотя в сферических условиях, всякие системные либы могут до 30-40% меньше памяти использовать, но их общее потребление памяти затмевается, например тем же браузером в процентном соотношении. На "синтетических" тестах за счет кеша скорость может взлететь, а вот на практике, для чего-то типа перекодирования аудио/видео это все дает тысячные процента увеличения производительности.
> автор статьи пришёл к выводу, что выигрыш в производительности не столь велик, как показывают некоторые синтетические тесты от создателей x32 ABIУРА! неужеле здравый смысл наконец-то восторжествовал??!!!
...ведь ,блин, этоже очевидно что кому какая разница насколько выигрывает X32 по сравнению с x86.
x86 уже давно есть мёртвое, и вспоминается оно только как срашный сон..важно щаз только x86_64! а минусов у X32 (по сравнению с x86_64) больше чем плюсов
(это мой предыдущий комментарий)Спасибо добрый человек, об отражении файла в память я как-то и не упомнил, хотя буквально вчера так считывание из большого файла и реализовал, там критично важной была скорость считывания больших блоков. Так давно ориентируюсь на 64-битную систему, что и забыл о 32-х битных подходах.
Конечно менее продвинутый школьник не поймет вообще о чем идет речь, более продвинутый решит что использование 64 битной адресации, как защиту от переполнения при отражении большого файла в память это быдлокод. Но это действительно делает код очень простым, ясным и быстрым. Собственно, при любых ценах на память, теоретический выигрыш от данной архитиктуры больший за x86_64 в очень специфичных ситуациях.
>> автор статьи пришёл к выводу, что выигрыш в производительности не столь велик, как показывают некоторые синтетические тесты от создателей x32 ABI
> УРА! неужеле здравый смысл наконец-то восторжествовал??!!!Здравый смысл и справочник по системе команд подсказывает, что 64битный код в среднем толще 32-битного на 30% просто за счет вдвое большей толщины указателей. Это означает что используя 32битную адресацию на фкусной и прыткой 64битной системе команд можно нахаляву получить 30% кэша сверху (ну какое-то пенальти на префиксах конечно будет но тем не менее). На структурах данных получается обычно сэкономить заметно меньше, ибо и фрагментация, и странички, и выравнивание и проч (а код один хрен весь смаплен в адресное пространство всех процессов и физической памяти жрет ровно один раз), поэтому здравый смысл гентушника ставившего эксперимент помноженый на незнание матчасти вызывает у него когнитивный диссонанс.
>Здравый смысл и справочник по системе команд подсказывает, что 64битный код в среднем толще 32-битного на 30% просто за счет вдвое большей толщины указателей.Вот только код в x32 64-битный. Точнее amd64 instruction set. Те в коде никакой разницы не будет.
код — да, а указатели (за счёт которых короче) — нет.
прочтите процитированное вами предложение до конца.
> код — да, а указатели (за счёт которых короче) — нет.
> прочтите процитированное вами предложение до конца.Какой смысл заморачиваться с размером программ если основную часть памяти занимают данные, которые они обрабатывают? Ну уменьшите вы прогу со 100КБ до 10 и что изменится? Можно конечно сказать про увеличение скорости запуска т.к. с диска читаться быстрее будет, но опять же реального выигрыша на таких масштабах оптимизации практически нет.
> Какой смысл заморачиваться с размером программ если основную часть памяти занимают данные, которые они обрабатывают? Ну уменьшите вы прогу со 100КБ до 10 и что изменится?В кэш без промахов в общем случае влезет в 10 раз больше программ. Что дает весьма неплохой профит.
Допустим обработка данных занимает 90% времени, допустим что в остальные 10% входит запуск приложения (пусть даже многократный), обрабатывающего эти данные. Допустим вы получили выигрыш в 30% на запуске этого приложения, но реальный выигрыш, с учетом реальной работы программы, а не тупого ее запуска, составит 30% от 10%, что даст 3% в абсолюте, что даже при таких маловероятных значениях как вышеприведенные не более чем погрешность их измерения. О каком профите вы говорите? Чисто теоретически оно конечно так, но мы живем и не на листе бумаги.
бред сивой кобылы.
Как аргументированно с Вашей стороны. Мне Вас жаль.
что можно аргументировать для сивой кобылы?
> код — да, а указатели (за счёт которых короче) — нет.
> прочтите процитированное вами предложение до конца.А префикс изменения размера указателя?
>Один из разработчиков Gentoo
>Diego Elio "Flameeyes" Pettenò не уверен, что использование x32 ABI оправдывает себя и считает многие из достоинств x32 ABI раздутыми.Gentoo уже не торт? Ищут отмазки чтоб не поддерживать x32?
ну, поддерживают одни, критикуют другие.
собака лает, караван идёт.