Дэниел Шеплер (Daniel Schepler (http://piuparts.debian.org/sid/maintainer/s/schepler@de...)) приступил (http://wiki.debian.org/X32Port) к созданию порта Debian GNU/Linux, собранного с использованием X32 ABI. Для реализации поддержки X32 ABI при сборке задействованы GCC 4.7, Glibc 2.16, binutils 2.22 и другие системные компоненты с патчами для обеспечения поддержки X32 ABI. В настоящее время для проведения начальных экспериментов подготовлен репозиторий (http://87.98.215.228/debian/byhand/l/linux/), включающих около 90 пакетов. Для проведения экспериментов предлагается загрузить штатную x86_64-сборку Debian с ядром, собранным с поддержкой X32, и затем использовать подготовленные X32-пакеты в chroot-окружении.X32 (https://sites.google.com/site/x32abi/) представляет собой гибридный x86_64 ABI, позволяющий использовать на 64-разрядных системах 32-разрядную модель адресации памяти. ABI X32 позволяет приложениям использовать все преимущества архитектуры x86_64, такие как дополнительные регистры и более быстрые инструкции, PIC ABI. В то же время ABI X32 даёт возможность работать с 32-разрядными указателями памяти, что позволяет экономить память, способствует более эффективному наполнению процессорного кэша и положительно сказывается на общей скорости исполнения кода. При тестировании (http://www.linuxplumbersconf.net/2011/ocw//system/presentati...) в ситуациях, связанных с интенсивной работой с указателями, новый ABI продемонстрировал ускорение исполнения кода вплоть до 30% в сравнении с классическим x86_64 ABI. Ограничением ABI X32 является невозможность адресации из приложения более 4 Гб памяти. Поддержка X32 была добавлена в ядре Linux 3.4.
URL: http://www.phoronix.com/scan.php?page=news_item&px=MTI0MzE
Новость: http://www.opennet.me/opennews/art.shtml?num=35519
Хоть на debian переходи :)
В генте это давно есть. Переходи туды. Заодно и линукс на зубок вызубришь и переходить куда-либо перехочешь
> В генте это давно есть. Переходи туды. Заодно и линукс на зубок
> вызубришь и переходить куда-либо перехочешьЯ предпочитаю пересобирать только те пакеты, которые на мой взгляд не правильно собраны, а не всю систему.
ну бинарники юзай, хотя нет лучше все пересобрать.
> хотя нет лучше все пересобрать.А вы тогда на гору Арарат сбегайте. И главное, пудовую гирю не забудьте. На вершине оставьте, не забудьте.
> Переходи туды"Бросай курить, вставай на лыжи. И вместо рака будет грыжа!"
>> Переходи туды
> "Бросай курить, вставай на лыжи. И вместо рака будет грыжа!"Тут скорее "бросай курить, начинай бухать!"
>>> Переходи туды
>> "Бросай курить, вставай на лыжи. И вместо рака будет грыжа!"
> Тут скорее "бросай курить, начинай бухать!"На лурке побывал? Читал я что там пишут. На современной системе время компиляции всего мира небольшое. Да и полностью весь мир я забыл когда компилил. Только обновляю. На gprs/edge. Время скачивания пакета превышает время сборки. Так что для меня не актуально время сборки того или иного пакета.
Тут скорее каждый для себя выбирает инструмент удобный для личного использования в тех или иных условиях. Гента - действительно быстрая и гибкая. Убунта так не умеет. На убунте всё хорошо, пока не появится желание собрать что-либо из исходников. Сначала устанавливаешь всяческие dev-пакеты apt-get'ом (спокуха мужики! не все гентушнеги знають!) затем руками (!) качаем source.tar.gz руками (!) распаковываем и первое на что чешутся руки - это ./configure && make && sudo make install и своими же руками превращаем систему в файлопомойку. Только Ъ-бубунтойды в курсе про дебианизацию сорца, сборкой *.deb и установкой оного пакетным менеджером. Только Ъ - ~5% остальных устраивает первый вариант. И на всяких говносайтах, бложках и на форуме убунты вываливают навоз о том как они сделали ЭТО! Те, кто начинает догадываться, что что-то здесь не так, или просто не хотят что-либо делать по причине лени, начинают ныть: товарищи Ъ дайте deb, ppa.
Я не употребляю никаких веществ, меня прёт трезвый (Жданов, ага) образ жизни и я вообще к IT-индустрии никакого отношения не имею, специальность - инженер-электрик.
А причем тут убунта? В исходном посыле был Debian, а какие там проблемы у пользователей убунты, пусть Марк волнуется.
> А причем тут убунта? В исходном посыле был Debian, а какие там
> проблемы у пользователей убунты, пусть Марк волнуется.Пакетный менеджер общий.
> На лурке побывал? Читал я что там пишут. На современной системе время
> компиляции всего мира небольшое.Осталось только придумать нафига все компилить лично. Я как-то предпочитаю собирать только программы где я поменял сорец или соизволил взять какую-то совсем тестовую версию типа версии какой-нибудь программы из VCS-системы, с пылу с жару, от программеров.
> когда компилил. Только обновляю. На gprs/edge. Время скачивания пакета превышает время сборки.
А на 30Мбит эернете - наоборот.
> так не умеет. На убунте всё хорошо, пока не появится желание
> собрать что-либо из исходников. Сначала устанавливаешь всяческие dev-пакеты apt-get'омДа, при том он может все зависимости указанному пакету укачать к тому же.
> (спокуха мужики! не все гентушнеги знають!) затем руками (!) качаем source.tar.gz
Ну конечно, про apt-get source гентушники не знают. И потому топырят пальца. Как самые "умные". Хотя проблема на самом деле лишь в том что apt-get эти "умники" видели лишь на картинке. Иначе эти чудики знали бы что при нужде получить пакет и перестроить его - несколько команд, все заавтоматизировано нафиг и прочая.
> руками превращаем систему в файлопомойку
Если нет мозгов на хотя-бы юзание checkinstall - кто же пациенту доктор?
> Я не употребляю никаких веществ,
Походу, это вас от генты так торкнуло.
> Осталось только придумать нафига все компилить лично.Например, свой уникальный набор программ. Например, кто-то на дух не переносит gtk. или жабу. или ещё что-то. или наоборот хочет систему максимально завязать на какие-то либы. Чем разбираться каждый раз что с собой тащит то или иное и искать источники, где собрано именно так, проще управлять use-флагами.
>> так не умеет. На убунте всё хорошо,ни разу не сталкивался. постоянно какие-то кривули мелкие. То в эмпатии аккаунт первый не заводится, то в нетворк менеджере пароль не сохраняется, то ещё какой мелкий неприятный косяк. При том что рядом стоит калька и тот же нетворкменежджер работает как часы.
> Да, при том он может все зависимости указанному пакету укачать к тому же.
угу. только вот зависимости прибиты гвоздями. где-то там кто-то решил, что так - хорошо. и если бы оно работало всегда без мелких и крупных недочётов, я бы согласился.
>> (спокуха мужики! не все гентушнеги знають!) затем руками (!) качаем source.tar.gz
(внимательно смотрит) а потом делаем татуировку: машинка XXX, пакет ZZZ, флаги YYYY. ну и само собой к сорока годам будешь как якудзу.
> Ну конечно, про apt-get source гентушники не знают.
не знают конечно, это сокровенное знание для избранных.
только вот не вижу преимуществ вашего аптгетчества над той же калькой. выбрал бинарный профиль, если что-то надо подправить - гибкая система конфигов в /etc/portage/*.
ну разве только бесноватое комьюнити, которое очень любит громко объяснять, что "нас много, мы победим венду".
> И потому топырят пальца. Как самые "умные". Хотя проблема на самом деле лишь в том что apt-get эти "умники" видели лишь на картинке. Иначе эти чудики знали бы что при нужде получить пакет и перестроить его - несколько команд, все заавтоматизировано нафиг и прочая.
Ой, вот не надо только. Лично я - щупал. В плане скорости есть преимущество перед emerge, в плане гибкости ровно наоборот. Я предпочитаю преимущество в гибкости. Да о чём мы говорим, о системе с отсутствующим /var/log/messages...
> А на 30Мбит эернете - наоборот.Жируете? :)
И сколько же стоит такое счастье?По ссылке тарифы одного из операторов в моём городе.
http://khabarovsk.dv.rt.ru/homeinternet/fast_internetПо моему адресу на момент подключения работал только один оператор.
Интернет подключил чуть больше года назад, но тогда цены были ещё выше!
Город Хабаровск.
>apt-get sourceкачает только то, что есть в src-репах (если подключены). А если мне нужна прога, которой нет в src-репах? Никто из разрабов не заморачивался с src.deb, ppa ибо не пользуются deb-based дистрами? Придется попотеть (по какому поводу говорил).
>И потому топырят пальца.
Это ты их сейчас оттопырил.
>Иначе эти чудики знали бы что при нужде получить пакет и перестроить его - несколько команд
которые нужно отплясать повторно после обновления.
>все заавтоматизировано нафиг и прочая.
:) :P :D оооооооо как вам торкнуло. Я пользуюсь бубном на нетбуке, хотя бы по той причине, что предлагаю её людям, которых достала вирусная возня в венде. Поэтому всю вашу _заавтоматизированую_нафик_ знаю. Вам же сравнивать сложно, ибо не юзали генту (консерваториев, так сказать не кончали, но кузькину мать показывать умеем, да). По сравнению с portage' ваш apt - глюкавая игрушка для детей дошкольного возраста. И поверьте, я знаю о чём говорю.
>юзание checkinstall
знаю. Не америку открыл. Почитай как это реализовано в генте (хотя 'читать' наверное не ваш метод).
>Походу, это вас от генты так торкнуло.
Нет. Я указал фамилию человека, за генту я тогда и знать не знал.
ЗЫЖ тут клыкастый про кальку писал, так она бинарная гента, если что.
> На современной системе время
> компиляции всего мира небольшое.Ага, на один только Firefox пара, тройка часов уйдет, а на Chromium возможно и больше.
>на один только Firefox пара, тройка часов~20 мин у меня.
Юзеры генты знают только emerge и куда вписывать make/c flags. :)
и совсем, совсем не знают apt-get. страшно жить.
> и совсем, совсем не знают apt-get. страшно жить.А ведь есть emerge apt и apt-get emerge :)
>> и совсем, совсем не знают apt-get. страшно жить.
> А ведь есть emerge apt и apt-get emerge :)Оно то есть, но мне не нужно.
> не знают apt-get. страшно жить.Я использую генту на ББ. На нетбуке - убунту.
> Я использую генту на ББ. На нетбуке - убунту.Как ни странно, это не помешало остаться вам полным кофейником в аптгете и его возможностях. Вы зачем-то как дебил качаете сорц вручную, хотя получить оный - одна команда аптгету.
>> Я использую генту на ББ. На нетбуке - убунту.
> Как ни странно, это не помешало остаться вам полным кофейником в аптгете
> и его возможностях. Вы зачем-то как дебил качаете сорц вручную, хотя
> получить оный - одна команда аптгету.аптгет знает о всех сорцах на свете? Ну нету в репах нужного сорца. В генту можно сделать свой ebuild. И вы уважаемый, выражения выбирайте, пожалуйста.
> Я использую генту на ББ.На Большом Бубне?
> В генте это давно есть. Переходи туды.На дистрибутив жуликов и воров? Нет пути!
>> В генте это давно есть. Переходи туды.
> На дистрибутив жуликов и воров? Нет пути!Вот виндавс - даже Папа одобрил. Там иконки и службы. И жуликов/воров точно нет. 100%. Да-да.
Чё только не делают, лишь бы "не x86"! Точнее так: "когда собаке делать нечего....". Есть такой "синдром нового", когда человеку неймётся, что всё работает и он начинает сходить с ума и всё модернизировать. Работал x86 режим и всё было хорошо. Нет, вылезли со своими 64 битами, перекорёжили "для совместимости" сишный код, создали какой-то flat режим - на те, вам же мало было проблем!
"... ходють тут, только мусорють ..."
Сам-то понял, чего написал и зачем?
гентушники уже собрали, протестировали и сделали вывод: очередной костыль
Так а смысл в этом костыле - перенос идеи n32 и n64 с mips на ia32? Так как бы тогда было n32 создано из за недостатка памяти (ты попробуй симами по 8-32М набрать более 4Га) это было еще в середине 90х. А тут костыль может быть полезен разве что на планшетах с атомами. И то только если там стоит меньше 3Га рамы
да хрен там. лично я на свой ноут с 16 гигами памяти и
># dmidecode -t processor
> Family: Core i7
>…
> Core Count: 4
> Core Enabled: 4
> Thread Count: 8с удовольствием поставлю.
не вижу ни одной задачи на ноуте, которой позарес нужно 64-битными указателями ворочать.
да и мемори ликс в этой ситуации куда как менее болезненны.так же vps-хостеры очень рады будут — и новые инструкции (аля ссе/крипто/этк), и памяти жрёт меньше.
2 Аноним: кстати, последняя сборка стэйджа генты для x32 была 8 сентября http://distfiles.gentoo.org/experimental/amd64/x32/
т.е. много позже «развенчания мифов» работа идёт.
так что никто ни о чём не забывал, просто glibc 2.16 пока никто плотно не юзает.
а кому ненатЪ — так хрена ли беспокоитесь? вас не заставляют.
> не вижу ни одной задачи на ноуте, которой позарес нужно 64-битными указателями ворочать.А еще гражданин утверждал что 640Кб хватит всем. 4Гб конечно чутка поболее, но...
> с удовольствием поставлю.
> не вижу ни одной задачи на ноуте, которой позарес нужно 64-битными указателями
> ворочать.
> да и мемори ликс в этой ситуации куда как менее болезненны.А сюда ты через lynx постишь?
Все остальные браузеры уже благополучно доказали, что 4Гб на процесс - это еще не предел.
и как же мы интернеты смотрели на 256 мегабайтах…
> и как же мы интернеты смотрели на 256 мегабайтах…Это было давно и неправда.
>> и как же мы интернеты смотрели на 256 мегабайтах…
> Это было давно и неправда.это было пару часов назад на n900.
> это было пару часов назад на n900.У тебя тоже есть эта вундервафля? Мое уважение к Кэпу подскочило на +1, хоть это и всем похрену :)
Если браузер отожрал 4 гига - это явный баг - или утечка или кривокод адский. Такое одинаково легко хоть 4, хоть 16 сожрёт. Говорю как человек, у которого и 300 табов бывало в файрфоксе - за 3 гига VIRT не вылезало. Хром в сумме может сожрать и больше, но у него это на два десятка процессов делится.
> это явный багили это хром
только curl и sed
эту технологию можно использовать хоть на 8Г, хоть на 16Г памяти.
1-й x32 процесс - 4Г ограничение
2-й x32 процесс - 4Г ограничениеболее того ядро тоже - x86-64, то есть оно может поддерживать как x32 так и x64 процессы одновременно.
например для домашнего компа будет достаточно ограничения на 4Г на процесс с ушами.
я даже не знаю что это должна быть за задача? Gimp с большими фотками? Firefox съел 4Г?
обработка видео? вроде нет.здесь проблема что народ не понимает смысла технологии
>более того ядро тоже - x86-64, то есть оно может поддерживать как x32 так и x64 процессы одновременно.и 32-х-битные тоже.
т.е. все 3-и архитектуры живут вместе.
захотел 64-бита — скомпилил и работаешь (например для постгри, оракла и тд)так что да, я лично жду когда всё это богатство выйдет за рамки стадии тестирования.
> захотел 64-бита — скомпилил и работаешь (например для постгри, оракла и тд)А в памяти висит 2-3 набора либ с разным ABI, да? И вся экономия памяти - псу под хвост...
не вижу ни одной задачи на ноуте, которой позарес нужно 64-битными указателями ворочать.
а если даже мне и понадобится пару задач под 64-бита, аля постгри и оракл, то они как-нибудь переживут без 64-битных опенжл/хы11/кутэ/итд
ты головой то думаешь? или все проги в тройном объёме запускаешь?
зыж
хотя конечно можешь поспорить с Дональдом Кнутом http://www-cs-faculty.stanford.edu/~uno/news08.html — A Flame About 64-bit Pointers
It is absolutely idiotic to have 64-bit pointers when I compile a program that uses less than 4 gigabytes of RAM. When such pointer values appear inside a struct, they not only waste half the memory, they effectively throw away half of the cache. The gcc manpage advertises an option "-mlong32" that sounds like what I want. Namely, I think it would compile code for my x86-64 architecture, taking advantage of the extra registers etc., but it would also know that my program is going to live inside a 32-bit virtual address space. Unfortunately, the -mlong32 option was introduced only for MIPS computers, years ago. Nobody has yet adopted such conventions for today's most popular architecture. Probably that happens because programs compiled with this convention will need to be loaded with a special version of libc. Please, somebody, make that possible.[сообщение отредактировано модератором]
Дед Кнут наверно не догадывается, что размер данных программы может быть неизвестен?
и как это коррелирует с указателями?
> и как это коррелирует с указателями?Тебе делать нефига, вот и сиди коррелируй?! :)
man lseek, и т.п.
> man lseek, и т.п.Лучше mmap() тогда уж. Ну или как с 32-битными указателями оперируют в mmap-нутых файлах крупнее 4Gb?
Многооконный интерфейс, каждое окно (открытый файл) 100 Мб, сколько файлов можно открыть для 32-разряного процесса? 40 - ответ неверный. Никто все 4 Гб 32-разрядному процессу, даже в 64-разрядной системе, не даёт, обычно дают 2 Гб (половину) или 3 Гб, так проще организовать контроль доступа.А вот вопрос "как это коррелирует с указателями" я оставляю тебе на самостоятельное изучение.
> Многооконный интерфейс, каждое окно (открытый файл) 100 Мб, сколько файлов можно открыть
> для 32-разряного процесса?Стотыщпистот, пока не заDOSишь систему!!!
Многооконный пример - хреновый пример. Обычно, у всех операционнок,
окна - это треды юзающие единую память, ресурсы пожирают только
функции отрисовки самих окошек.Хороший пример - сортировка по элементам в каждой из 10000 кв. матриц размера 1000x1000.
(расчёт математической модели крыла истребителя)
Многооконный ИНТЕРФЕЙС, пример заключается в чтении в память 41 файла размером 100 Мб каждый.Искажать слова собеседника, а затем обвинять его в "хреновости", не самый этичный способ вести спор. Но если нет аргументов...
>Многооконный ИНТЕРФЕЙС, пример заключается в чтении в память 41 файла размером 100 Мб каждый.это индусский тест на быдлокодерство?
даёшь хеловорды от 4Гб в ОЗУ и выше?
:D
>Хороший пример - сортировка по элементам в каждой из 10000 кв. матриц размера 1000x1000.(расчёт математической модели крыла истребителя)
и чё там со стэком?
> А в памяти висит 2-3 набора либ с разным ABI, да? И вся экономия памяти - псу под хвост...И чо. Они все равно равно сегментами кода ровно один раз в памяти висят для всех процессов. Это раз. Мапятся они он деманд это два. Не запущено ни одной аппликухи, не будет замаплено и экземпляра библиотеки. А 64битный код по статистике почти 30% толще просто за счет более широких оффсетов и указателей.
Откуда взята статистика? 64-разрядный код (!) настолько больше будет только из-за выравниваний. Данные занимают больше места, но даже 30% получается в синтетических случаях и в случае неверно выбранных моделей хранения данных.
> И чо. Они все равно равно сегментами кода ровно один раз в
> памяти висят для всех процессов. Это раз.Спасибо, я в курсе. Это не отменяет того что вместо 1 набора либ будет висеть 2 и весь выигрыш от экономии памяти в программах проср@тся благодаря лишним либам.
> Мапятся они он деманд это два.
Тем не менее, оных может быть довольно много. Для типовой гуйной программы будет вгружен весь тулкит, типовые сишные либы и прочая. В сумме хренадцать с гаком метров кода. Совсем не факт что x64 на столько продует по объему кода.
> экземпляра библиотеки. А 64битный код по статистике почти 30% толще просто
> за счет более широких оффсетов и указателей.Ну да, будет. Скорее правда обычно процентов на 20, но все-таки эффект есть. Но вот врядли эти 20% перевесят вгрузку 2 копий тулкита типа GTK или Qt вместо 1, например. В общем извращение. Если кто ставит 64-битную систему, у него вероятно дофига памяти и 2^32 ему просто не хватило. Экономить ему 20-30% при таком раскладе путем вгрузки +1 копии системных либ - сомнительное счастье.
> здесь проблема что народ не понимает смысла технологиину я например не понимаю. :)
объясни мне -- зачем мне делать так чтобы приложение НЕ умело пользоваться 64-битными указателями?
производительности (как написанно по ссылке, а не в тексте новости) это почти не прибавит (+5% врядли заметно на глаз) -- но при это добавит геморой...
...такой геморой как например невозможность использовать полезной функцией -- mmap() .
[на 32-битах использовать mmap() опасно, и лучше не использовать. а вот 64-бита позволяют делать комфортные mmap()]_З_А_Ч_Е_М_ _Т_А_К_А_Я_ _Ф_И_Г_Н_Я_ ?
# P.S.: никто из официальных дистрибутиво-строителей не станет делать официальные дисрибутивы с X32-программами. они не долбонутые на голову. x86_64 это УЖЕ оптимально.
а тебе не всё равно? для твоёго похапэ это не имеет значения.
не догнал..это намёк на то что PHP будет работать на 5% быстее? (PHP-X32 по сравлнению с PHP-x64)
да -- мне сёравно. ты прав :)
Опасно не думать головой. Очень мало видов данных, которые не влезут в 32-битное адресное пространство (это ж гига два файл должен быть). Так что для подавляющего количества софта это вообще ничем не грозит. Кстати, что за любовь к mmap такая? Это специально чтобы нельзя было буферизовать доступ толком, а свалить это на ОС, которая не знает, что и как вы читать будете?Вон, Хром вообще собирается под 64 бита по остаточному признаку - виндовая версия исключительно 32 бита. Но под линуксом он практически завеётся на x32 - и вы получите совершенно халявное ускорение браузера (а указателей там немерено, кстати, и для v8 известно, что 32 бита работают быстрее, чем 64) и уменьшение потребляемой памяти. Учитывая, что как раз пачка процессов Хрома весьма прожорлива - это вполне интересно.
Ещё раз. Для сколько-нибудь прилично написанного софта x32 - это совершенно дармовой прирост скорости и экономия памяти. А сколько ресурсов маинтайнеры потратят на сборку ещё одной архитектуры - это не ваша забота, вы им денег не платите. Делают - значит считают интересным для себя.
Народ не понимает, нафига это нужно, а не в чем смысл.
> гентушники уже собрали, протестировали и сделали вывод: очередной костыльа ссылку можно??
да вон 3-я ссылка под новостью.
обратите внимание на последний комментарий там — грамотно и по пунктам объяснили куда он может идти со своей критикой.
Смартфонам бы это не помешало. В Андройде топовые смарты до сих пор имеют не более 2х гигов. Правда, чую пока допилят уже будет поздно. :)
а какое это имеет отношение к физической памяти (кроме её расхода конечно)?
речь о виртуальной памяти и скорости. вот тут комент внизу http://blog.flameeyes.eu/2012/06/debunking-x32-myths
>5 – So you manage a library written in C. Are you going to disprove the fact that JAVA, Perl, PHP, Python, … will be SUBSTANTIALLY faster in X32 ABI versus X86_64 due to the smaller pointer size ? I don’t need a benchmark or profiling to know it will be faster, all virtual machines running a higher level language will use pointers like crazyтак что много кому пригодится и после 4гб мартфонов.
> Андройделучше бы ты себе рабочие мозги купил, а не смарт.
> лучше бы ты себе рабочие мозги купил, а не смарт.Ведроиде! //fixed.
> лучше бы ты себе рабочие мозги купил, а не смарт.arisu, советующий другим купить мозги - это примерно как Поттеринг, объясняющий разработчикам ядра, как правильно программировать.
а тебе и советовать не буду. неоперабельно.
> неоперабельно.Соболезную.
> Соболезную.Да уж, печально. Ибо индивид столь туп что не понял за что на него Кэп вообще ополчился.
а там что 64 бита? или каким боком там x86_64?
ну на атомах то тоже смартфоны бывают.
и если ведроид будет на таком смарте работать лучше вин8, то тоже не плохой показатель.
> гентушники уже собрали, протестировали и сделали вывод: очередной костыльЛюбая технология, оказавшись в генте, автоматически превращается в костыль.
Что поделать, судьба такая.
Учитывая то, как долго вылизывают каждый релиз дебиана, не видать нам этой сборочки, как своих ушей.
> Учитывая то, как долго вылизывают каждый релиз дебиана, не видать нам этой
> сборочки, как своих ушей.Так она неофициальная. Никто ее вылизывать не будет.
А как для программиста это выглядит? Если это просто заюзать доп. опции для компилятора, то еще ладно, технология 32битной адресации достойная. Но если это влечет за собой использование доп. синтаксиса в коде, то привет еще +100500 багов в и так существующий мир нестабильного кода. В этом случае, я не пожлоблюсь на установку доп. планки ОЗУ.И прикольно наблюдать.... тут видите ли, с одной стороны - указатели жрут 64бита, когда достаточно 32бит и это не порядок. А с другой - "Решение по использованию tmpfs для раздела /tmp в Fedora 18 не будет отменено". Т.е. как бы с ОЗУ проблем нет :-)
> А как для программиста это выглядит?операторы придётся задом наперёд писать.
>> А как для программиста это выглядит?
> операторы придётся задом наперёд писать.Самый мудрый и квалифицированный комментарий в обсуждении!
> Самый мудрый и квалифицированный комментарий в обсуждении!Какой вопрос - такой и ответ. Квалификация бсдоидов уже утомила. Откуда такие отборные дуболомы вообще берутся? Презренные убунтушники и то лучше в таких вещах разбираются! Теперь вы должны сгореть со стыда!
>А как для программиста это выглядит?как новая архитектура.
вот тут подробнее https://sites.google.com/site/x32abi/documentsзыж
>И прикольно наблюдать.... тут видите ли, с одной стороны - указатели жрут 64бита, когда достаточно 32бит и это не порядок. А с другой - "Решение по использованию tmpfs для раздела /tmp в Fedora 18 не будет отменено". Т.е. как бы с ОЗУ проблем нет :-)сравнил опу с пальцем.
tmpfs настраивается/отменяется за 3 сек, а переход на другую архитектуру порой только новой инсталяцией.
это чё, такой троллинг не умелый?
и ещё, если раздел в tmpfs пустой, то ОЗУ полностью доступна для процессов. также очевидно, что временные файлы таки временные.
путаешь организационные проблемы с технологическими.
Речь не о типе проблем, а о том зачем экономить ОП в одном месте, в ситуации когда её дефицита не наблюдается (1) и в других местах используются далеко не самые компактные по отношению к памяти решения (2)?
хм… даже и не знаю как ещё намекнуть то.подумайте вот о чём, а если комьпютер вообще не включать, то память будет экономиться вообще на все 100%.
так зачем его включать?
Не дефицита не наблюдается, а федора - это полигон RHEL - и идеально удобным он быть и не обязан.
> Не дефицита не наблюдается, а федора - это полигон RHEL - и
> идеально удобным он быть и не обязан.Debian тоже так сделал, tmpfs на /tmp http://lwn.net/Articles/499686/
удобно и проблем не испытывается.По сути, x32_ABI призван прекратить существование х32, т.к. на системах где актуальна 64битная ОС проблем с ОЗУ нет в принципе, если только только головой не думали и поставили мать с двумя слотами под RAM. Иначе 32битная ОС и ядро со взведенным PAE все решает :)
ИМХО, 64битная ОС более актуальна при озу >6Gb.
>> Не дефицита не наблюдается, а федора - это полигон RHEL - и
>> идеально удобным он быть и не обязан.
> Debian тоже так сделал, tmpfs на /tmp http://lwn.net/Articles/499686/
> удобно и проблем не испытывается.cat /etc/debian_version
wheezy/sid
mount | grep tmp
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=740009,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=599924k,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1199840k)простите гиде debian перешел??куда перешел?
Для новых инсталлов вроде бы перешли. При апгрейде остаётся как было.
> Для новых инсталлов вроде бы перешли. При апгрейде остаётся как было.этому тестовому инталу 3 недели -- сильно-ли давно перешли? или инстал через debootstrap не считается таковым?
Перешли в мае где-то. Обратно не откатывались. Имеется в виду установка штатным установщиком с автоматическим разбиением диска, созданием fstab и прочим.
Мды, не знал. Я бы не сказал, что удобно - память тратить на всякую муть и получить своп в самый неподходящий момент - невелико удовольствие. Плюс к тому - если памяти хватает, то без tmpfs в /tmp можно своп вообще убрать - а с ним не выйдет. И объяснить системе "используй своп только для /tmpfs" тоже не получится. А получить туда файлы на несколько сот метров запросто - например, mc любит это дело. В общем, лично я на новых системах буду эту глупость убирать, пусть на корневой раздел всё пишется и чистится при ребуте.А вот борьбу с x86 я не понимаю - ну живёт себе и живёт. Наверняка есть вагон legacy-софта, который на экзотике вроде x32 работать не будет. В этом плане на домашнюю или девелоперскую машину его засунуть - святое дело. А в продакшн - либо x86 (для мелких виртуалок в самый раз) либо 64 бита.
>А вот борьбу с x86 я не понимаю - ну живёт себе и живёт. Наверняка есть вагон legacy-софта, который на экзотике вроде x32 работать не будет.с чего вдруг не будет то? куда он денется.
>А в продакшн - либо x86 (для мелких виртуалок в самый раз) либо 64 бита.x32 и есть 64-бита. вот в чём прелесть.
зыж
с каких пор длина адреса битность определяла? даже в 8086 она равнялась 20. в большинстве современных 64-х-битных десктопо-ноутов:
># cat /proc/cpuinfo | grep "address sizes"
>address sizes : 36 bits physical, 48 bits virtualтак что x32 поживёт. и отлично поживёт.
Я чего-то решил,что для x32 не соблюдается sizeof(log) == sizeof(void*) - это могло повлечь проблемы. Но нет, всё нормально. Тогда вообще нет проблем - почти всё корректно работать должно.Но для продакшна - всё ранво стрёмно, сначала надо на хомячках потестировать.Я имел в виду, что в продакшн тащить софт, собранный для модели ABI, на который не расчитывал автор, чревато. И продолжаю так считать, в общем-то - рано. Но на некритичных направлениях (домашний комп хотя бы) - поживёт, конечно. Точно так же как какая-нибудь btrfs на "поиграться" готова давно, но надо совсем с головой не дружить чтобы на боевые машины её совать.
> ... софт, собранный для модели ABI, на который не расчитывал автор ...Как показывает практика, "автор" даже не знает такой аббревиатуры - ABI :-(
> с каких пор длина адреса битность определяла? даже в 8086 она равняласьНу вот с таких. Если у проца 64-битные регистры то и работает он нативно с именно 64-бит числами. Ну и адреса логично 64-битные, раз такая пьянка.
>>address sizes : 36 bits physical, 48 bits virtual
Пардон, это оно порезано уже дальше, на внешних интерфейсах и прочая. А глубоко внутрях предполагается именно 64 бита. Просто кой-где сэкономили слегонца. Это вообще так, физическая инкарнация. Софту все это никак не видно особо. Софт видит 64-битные адреса. А то что железо где-то там может какие-то биты откинуть - на совести железа.
> так что x32 поживёт. и отлично поживёт.
Хрень какая-то этот x32. Нафиг надо - малопонятно. Грабель добавит, да. А экономить память на 64-битных системах ценой установки туевой хучи костылей с непонятным результатом - затея весьма странная.
>Ну вот с таких. Если у проца 64-битные регистры то и работает он нативно с именно 64-бит числами. Ну и адреса логично 64-битные, раз такая пьянка.ха! и всё это от элементарного не знания архитектуры
># cat /proc/cpuinfo | grep "address sizes"
>address sizes : 36 bits physical, 48 bits virtualдаже в 8086 шина адреса составляла 20 бит, а не 16.
ну и где логика я вас спрашиваю? :Dзыж
>Хрень какая-то этот x32. Нафиг надо - малопонятно. Грабель добавит, даесли вам что-то не понятно, это не значит ещё, что это плохая вешь.
а вообще, чего я с вами спорю то? вон на Кнута ссылку уже давал. спорьте с ним.
x32 вещь хорошая для тех, кто в теме
> 64битная ОС более актуальна при озу >6Gb.вообще-то она (64-битная ОС) более актуально УЖЕ если хотя бы RAM >= 3G .
и количество виртуальной памяти тут вообще не причём. виртуальную память можете сразу выстаить в 20G (swap), не зависимо от того x86_32 или x86_64 .
мы говорим именно про ФИЗИЧЕСКУЮ память, когда утверждаем что нужно ставить 64-битную операционную систему, если RAM >= 3G ..
> Tmpfs уже применяется по умолчанию в ArchLinux и Ubuntu.В убунту никакие разделы и каталоги в tmpfs не монтируются.
> При тестировании в ситуациях, связанных с интенсивной работой с указателями, новый ABI продемонстрировал ускорение исполнения кода вплоть до 30% в сравнении с классическим x86_64 ABIспасибо за вбрасывание ложных-ТРОЛОЛО-данный в краткий текст новости...
...я перещёл по ссылке и (не заметив никаких 30%) -- увидил следущее -- http://i6.minus.com/ijrIvkVbpUHcW.png
а именно -- 5~8% ...
# P.S.: остальные сравнения исходят из x86_32 -- которая вообще нафиг никому не упала.
# P.P.S.: ложными данными о производительности -- вы конешно можете взбудоражить общественность, но врядли вы сможете обмануть разработчиков дистрибутивов :-) . ведь они всё проверят, а не поверят на слово :-)
Отползёте на пару шагов от веба - увидите, что сервисы могут быть разными, и многие есть смысл пихать в сравнительно мелкие виртуалки, в которых 64 бита держать - только без толку выкидывать память (хоть asterisk тот же взять). Хотя x32 я бы пока ставить туда не рискнул - вот через год-другой можно будет, когда на экстремалах и домашних пользователях обкатается.
ды хорошо! запускайте X32 на роутерах! ..я же только рад буду :) ..но нет же -- её кто-то активно хочет вдалбить именно на десктопы -- вот что меня агрит.
x32 на десктопах не менее актуально, пусть сборки браузеров сделают - будут памяти жрать меньше и чуть быстрее работать. Кому от этого плохо?
Почему бы им порты на RISC процессоры не доработать до
конкурентноспособного с родными unix состояния.Так что бы
реально бало в продакшен вместо проприетарщины.Так нет же
опять каким-то онанизмом занимаются.
наверное, потому, что они забыли тебя спросить, чем им заниматься. дураки, что ж взять-то…
Из хоть как-то живых RISC на которых у линукса есть реальные конкуренты я разве что спарки вспомню - и то их настолько мало, что, видать, морочить голову никто не хочет.
На массовых RISC (ARM, MIPS тот же) у линукса очень даже конкурентоспособное состояние.
> Из хоть как-то живых RISC на которых у линукса есть реальные конкуренты
> я разве что спарки вспомню - и то их настолько мало,
> что, видать, морочить голову никто не хочет.
> На массовых RISC (ARM, MIPS тот же) у линукса очень даже конкурентоспособное
> состояние.Да ладно вам,есть сферы применения компов в которых отказ от RISC даже не
обсуждается.Там очень серьёзные задачи и системы.Просто под вечер разыгралось воображение,
представил Linux-революцию в HIGH ENDах.
уже лет 5-7 на подобные спитчи никто не ведётся.
если нужен пример хайэнда на линухе — велком ту оракл эксадата, топ500 и тд, и тп.всё. ультраспарки3 ещё лет 5 назад из 5 серверверов 3 собирал. а сейчас всё.
как оракл на старьё забил, так и новые не особо нужны стали.
пока их колбасило линух набирал обороты.
па-риски сдулись ещё раньше. уже и их приемники титаниумы затонули.
так что про риски в хайэнде могут только щёки надувать сильно ангажированные перцы.
> уже лет 5-7 на подобные спитчи никто не ведётся.
> если нужен пример хайэнда на линухе — велком ту оракл эксадата, топ500
> и тд, и тп.
> всё. ультраспарки3 ещё лет 5 назад из 5 серверверов 3 собирал. а
> сейчас всё.
> как оракл на старьё забил, так и новые не особо нужны стали.
> пока их колбасило линух набирал обороты.
> па-риски сдулись ещё раньше. уже и их приемники титаниумы затонули.
> так что про риски в хайэнде могут только щёки надувать сильно ангажированные
> перцы.Exadata,всё из top500-это кластеры.И вот эти самые перцы,которые,кстати, и
принимают решения покупать ли что и что покупать,уверены,и небезосновательно,что
решение целого ряда задач не получится развернуть на кластере.Требуется машина класса
майнфремов.В этих классах х86 нет и не будет.Только power,sparc и всякая ibm-щина.
И Linux-революция там будет только при развитии соответствующих портов.
Эм... А с каких пор в мейнфеймах есть что-то кроме айбиэмщины? И там у них ни хрена не юникс крутится.
> ... power,sparc и всякая ibm-щинаКстати, power - это и есть ibm-щина.
> конкурентноспособного с родными unix состояния.И на каких ныне выпускаемых RISC нынче unix работает?
Глянул тут обсуждения у гентушников - говорят, что v8 БЫСТРЕЕ в 32-битном варианте чем в 64-битном. Судя по всему, на x32 будет ещё быстрее.
Пусть говорят )
> Глянул тут обсуждения у гентушников - говорят, что v8 БЫСТРЕЕ в 32-битном
> варианте чем в 64-битном. Судя по всему, на x32 будет ещё
> быстрее.у Гентушников слишком сильно развито самовнушение (по поводу производительности :))...
...ещё бы -- я их понимаю прекрасно -- полтора-дня компилировать мир -- за это время воображение ОГОГО как разыграется по поводу того что "я не просто так компилирую, а делаю это для того чтобы всё быстро работало! с самыми быстрыми флагами!!". :-)
так-что я не удивлюсь если вдруг Гентушкик какой-нибудь перекомпилирует браузер из x86_64 в X32, и после этого вдруг заявит что производительность увеличилась не менее чем на одну четверть! (а не на 5%, как это официально известно об X32)
> а не на 5%, как это официально известно об X32собрал себе мир из пустых догм
> у Гентушников слишком сильно развито самовнушение (по поводу производительности :))...во как. с Большой Буквы.
> ...ещё бы -- я их понимаю прекрасно -- полтора-дня компилировать мирА по мне так наоборот: убунтяшники чтоб хоть как-то оправдать свою космовенду с обновлением переустановками регулярно рассказывают друг другу об ужасах установки из сырцов.
> Судя по всему, на x32 будет ещё быстрее.Не, извините. Бенчи давайте. Верить гентушникам на слово? Ха-ха, лучше попробовать обыграть наперсточника в наперсток.
