Проект CentOS объявил (https://lists.centos.org/pipermail/centos-announce/2017-Janu... о доступности редакции дистрибутива CentOS Linux 7.1611 на базе RHEL 7.3 для 32-разрядной архитектуры i386. Сборки сформированы на основе исходных текстов пакетной базы CentOS 7 для архитектуры x86_64 и включают все имеющиеся в основной ветке обновления. Для загрузки подготовлены iso-образы (http://mirror.centos.org/altarch/7/isos/i386/) размером 6.5Гб (Everything), 4Гб (DVD), Live KDE (1.6Гб), Live GNOME (1.1Гб), 648Мб (Minimal) и 354Мб (Netinstall), работоспособные на оборудовании, поддерживающем режим PAE (https://ru.wikipedia.org/wiki/PAE), в том числе на IOT-платах, таких как Intel Edison. Из специфичных для 32-разрядных x86-систем изменений (https://wiki.centos.org/SpecialInterestGroup/AltArch/i386) отмечается удаление поддержки UEFI Secure boot в пакетах efibootmgr, efivar и kexec-tools, модификация syslinux и ядра Linux для сборки на архитектуре i686.Напомним, что дистрибутив RHEL 7.3, используемый в качестве основы CentOS 7.1611, выпускается только для 64-разрядых систем. Адаптация пакетной базы для 32-разрядных систем выполнена благодаря деятельности группы CentOS Linux AltArch SIG (https://wiki.centos.org/SpecialInterestGroup/AltArch) (Special Interest Group), в которую вошли лица, заинтересованные в портировании CentOS на платформы и архитектуры, отличные от x86_64 и официально не поддерживаемые в базовой редакции. В настоящее время развиваются инициативы по созданию сборок CentOS 7 для i386, ARM64/AArch64, ARMv7, PPC little-endian и PPC big-endian (Power8).
URL: https://lists.centos.org/pipermail/centos-announce/2017-Janu...
Новость: http://www.opennet.dev/opennews/art.shtml?num=45945
А по существу что даёт 64 бита? 4-5% компенсируются меньшим потреблением памяти. В общем т*пой маркетинг, только и всего. Лучше бы X32 допилили.
ЗЫЖ Это с каких пор слово т*пой стало ненормативной лексикой? А "острый" почему тогда не внесли?
> А по существу что даёт 64 бита?Больше байт в некоторых типах переменных.
откуда лезут диванные эксперды, а?Тебе - ничего не даёт, радуйся.
по существу - не спотыкаться о длину указателей, не лазить к файлам больше 4G через анальный интерфейс, целочисленную арифметику, пригодную для практического использования...собственно, на сегодня единственный минус - это uefi/32, на котором 64битную систему можно загрузить только совсем уж через задницу.
К сожалению это таки да, каждый второй планшет или ноут, сделанный в китае.
Или может даже два из трех, если отсеять макойопов (которым все равно, они линукс в здравом уме ставить не будут).
>не лазить к файлам больше 4G через анальный интерфейс, целочисленную арифметику, пригодную для практического использования...Это софистика всё. Конкретный прирост производительности есть? p7zip даёт у меня прирост в единицы %. Это на i5. Зато потребление памяти раза в полтора возрастает и вылезает куча других странных глюков. Оно мне надо?
вы из какой криокамеры вылезли? Прироста хотите - да ради б-га, баферпул мискла более 4 гигов. Банальный Redis или любой другой nosql на всю память. Да просто все, что упирается в лимиты
> вы из какой криокамеры вылезли? Прироста хотите - да ради б-га, баферпул
> мискла более 4 гигов. Банальный Redis или любой другой nosql напоэтому центосники и собрали свою версию с PAE ;-)
x86 в принципе позволяет обойти лимит в 4G - проблема, что для этого нужны нетривиальные ручные телодвижения (при неправильных - потеря производительности не в проценты, а в разы) авторам софта. А они их просто скоро перестанут делать вообще, забив на всякие *(long long) и lllllllseek (а то еще и семантику сменят, сделав ll признаком >64T), и при этом не проверяя размеры - "на нормальной системе все работает".(поэтому я немного нечестен в том что это "пара крыжиков в сборочной ферме" - это еще далеко не пара дурацких багрепортов, с которыми непонятно, что делать, и которых со временем будет все больше. Впрочем, на самом деле, понятно - оставлять висеть в статусе 'new, unassigned', пока проект не закроют. А вот RH себе этого позволить не может ;-)
Но _пока_ у многих все же будет работать. Мне, к примеру, нужно для дешевых виртуалок на неспособной тянуть 64битных гостей системе. Оно сколько-то еще трудами центосников поживет, а потом на матери раздует кондюки (и хостер мне ее на халяву проапгрейдит на правильную, если повезет ;-)
> p7zip даёт у меня прирост в единицы %у меня процентов 30-40
>у меня процентов 30-40Зря не 146. Убедительнее бы смотрелось.
> Конкретный прирост производительности есть?есть: если программист не делает специальных телодвижений - ты просто не можешь работать с файлом больше определенной длины. Вот твоя производительность при этом - равна нулю.
А программисты все больше и больше перестают делать эти самые телодвижения - у них хватает бабла на x64 систему, ага. Завтра выйдет несовместимая версия этого p7zip, которая у тебя либо не будет собираться вовсе, либо не будет работать правильно, либо будет только с архивами меньше 4G.
Та же целочисленная арифметика - все, кто ей пользуется всерьез, вынуждены вставлять cpu detection код, и подменять ее плавающей для таких как ты. Очень скоро они либо вообще перестанут это делать (производительность, ага - труда человека), либо сделают с ошибкой и никто ее не заметит (а заметившие ниасилят исправить).
другое дело, что для того же центоса вопрос сборки под x86 _пока_ - это всего лишь вопрос пары крыжиков в настройке сборочной фермы (хотя, как видим, уже не совсем - secure boot пришлось ручками отламывать. А он на, как минимум, моем uefi32 - вполне себе есть, просто нет никого, кто написал бы работающий код), и очень неплохо, что они не поленились их нажать и выделить немного мощности и для этого.
Но, предвижу, это щастье нам ненадолго, и в следующей major поддержки x86 просто не будет.
С другой стороны - ну сижу я на системе где и этот центос не заведется (они зачем-то собрали его с PAE - кому вот это нахрен надо, для меня полная загадка) - что-то пятилетней давности, что-то - руками собрано как надо. Еще лет на пять ее хватит, хотя уже не для всего, а там либо конденсаторы поплывут, либо вообще начнутся диффузные процессы в кристаллах. Не вижу, что тебе мешает идти тем же путем. Для _массовой_ устарновки (для чего и нужен дистрибутив) все равно уже нет смысла выбирать x86.
Глючный софт это не аргумент вообще. Если задаться целью, то можно накопать гору софта, который не будет работать на x64 и наоборот. И там и там, будут вполне очевидные ошибки. А то, что появляются проблемы из-за каких-то кривых уефи, так то маркетологи небось химичат. Архитектура тут не при чём вообще. Что-то из разряда насильно выключенного PAE в венде. Конечно, рано или поздно на 64 бита загонят всех, но это будет исключительно искусственное решение, вроде uefi, DRM и каких-то там непонятных чипов в материнках.
> Глючный софт это не аргумент вообще.с чего он глючный? Тебя может еще смущает, что он на твоем советском калькуляторе MK не работает, даже если б в теории могло?
> И там и там, будут вполне очевидные ошибки.
там нет никаких "ошибок", ну кроме той, что не вбита #pragma error "whis should not work on anything less than x64 arch"
> А то, что появляются проблемы из-за каких-то кривых уефи, так то маркетологи небось
> химичат.а, понял тебя - uefi происки проклятых маркетологов, ну надо же.
phoenix bios forever, and 640k should be enough for all.> Конечно, рано или поздно на 64 бита загонят всех, но это будет исключительно
> искусственное решениеда, а так-то, без сраных маркетологов, сидели бы по сей день на прекрасной восьмибитной архитектуре. Или даже на 2x4битной, привет 8008
> phoenix bios forever^ Это.
И при этом x64. Нафиг мне лишний гемморой с EFI?
>> phoenix bios forever
>
> ^ Это.
>
> И при этом x64. Нафиг мне лишний гемморой с EFI?Не, это у вас какой-то неправильный феникс. Или с памятью проблемы. Правильный - только x86 и только 16-битный. А вот как из этого 16-битного переключали проц в "x64"(точнее - x86_64) - читайте в документации :)
> Не, это у вас какой-то неправильный феникс. Или с памятью проблемы. Правильный
> - только x86 и только 16-битный. А вот как из этого
> 16-битного переключали проц в "x64"(точнее - x86_64) - читайте в документации
> :)Не смешно, потому что феникс до 2008 года разрабатывали. А x86_64 процы появились хрен знает когда.
Ну я таки имелл ввиду, что у меня нет EFI, обычный American Megatrends BIOS.
>> Конечно, рано или поздно на 64 бита загонят всех, но это будет исключительно
>> искусственное решение
> да, а так-то, без маркетологов, сидели бы по сей день на
> прекрасной восьмибитной архитектуре. Или даже на 2x4битной, привет 8008Или мотороловской, или ещё какой. Да мало ли кого ещё .
Сам по себе рост разрядности в шинах не так ценен, как кажется. Просто мы крутимся в замкнутом круге - раздувание массивов данных <-> набрасывание железа. И этот круг создан не реальными потребностями преобразования данных, а, да-да, маркетологами. Сколько там сейчас порядков в мировом объёме составляют все эти ролики и носимая медия?
Сам круг реален, конечно, и эти разговоры по большому счету бессмысленны. Ну, кроме ум показать.
> Просто мы крутимся в замкнутом круге - раздувание массивов данных <-> набрасывание железа.просто мы можем, наконец-то, делать вещи, которые раньше были либо вовсе недоступны, либо делались через жопу и при этом очень подорого.
Не хотите ли вернуться, к примеру, к линейному видеомонтажу - два видака, ручные крутилки, ручное выравнивание кадров - а потом еще отдельно аудиотрек положить, все теплое-ламповое, и каждая операция поэтому портит качество (а для "взрослых" - спецоборудование, ценой в миллиард, и тоже, все равно, портит - но, хотя бы, быстро).Меня сейчас вполне устраивает, что я могу совершенно спокойно швыряться 4k роликами с экшн-камер, и операция "подрезать хвосты, склеить и вывалить на диск" не требует всей жизни и еще пару лет впридачу, и не требует сооружать для этой цели специальный компьютер за дохрена денег со специальным оборудованием, годится мой офисный ноут.
А любителям теплого-лампового с удовольствием продам кинокамеру Спорт. 8mm*2, шикарная вещь. У меня даже эта чудо-пленка для нее есть, только за двадцать лет, боюсь, шансы получить на ней хоть какую-то картинку равны нулю (даже если б было чем и в чем ее обработать).
> Сам по себе рост разрядности в шинах не так ценен, как кажется.
если ты готов ограничить свои компьютерные потребности возможностями 8-битных процессоров - то да. Но про интернеты эти ваши - сразу же забывай. Они в 16-то были не айс - что ka9q, что trumpet. Про кино, понятно, тоже. Музыка - ну, восьмибитный синтезатор, да, вперед. Какой еще такой mp3?
>> Просто мы крутимся в замкнутом круге - раздувание массивов данных <-> набрасывание железа.
> просто мы можем, наконец-то, делать вещи, которые раньше были либо вовсе недоступны,
> либо делались через жопу и при этом очень подорого....
> если ты готов ограничить свои компьютерные потребности возможностями 8-битных процессоровНу, это уж поехало в духе: "что не тыща, то и мильён". А можно и так посмотреть, что за, скажем, минувшие 20 лет ни у кого из человечества не выросли новые органы чувств, и не изменились качественно диапазоны восприятия, и осталась прежней ёмкость подкорки; тот же суточный цикл и т.д.
Так почему за всё те же потребляемые нами интернеты мы должны покупать и покупать и покупать, и делать то же самое в рабочей памяти, выросшей на 6-7 порядков, с исполнительными устр-вами, выросшими в мощн-ти соответственно?? Покупка обесценивается чуть ли не в два-три года постоянной (нужной ли?) сменой ассортимента.
Кто кому голову морочит?
> Меня сейчас вполне устраивает, что я могу совершенно спокойно швыряться 4k роликами
> с экшн-камер, и операция "подрезать хвосты, склеить и вывалить на диск"
> не требует всей жизни и еще пару лет впридачу, и не
> требует сооружать для этой цели специальный компьютер за дохрена денег со
> специальным оборудованием, годится мой офисный ноут.Ах-ах, неотвратимая поступь прогресса. Ещё бы узнать, как формируется спрос на плоды этого монтажа.
Что касается собственно верхнего слоя задач, то он будет всегда, и соответствующие тех. средства должны расти. Это так называемый "средний" слой, который вызывает сомнения.
Новый набор инструкция на CPU? Не, не слышал, я слышал только о RAM > 4Гб
> Новый набор инструкция на CPU? Не, не слышал, я слышал только о
> RAM > 4ГбДля памяти > 4Гб есть PAE. Работает как часы. Это в венде его опять-таки маркетоиды порезали.
>> Новый набор инструкция на CPU? Не, не слышал, я слышал только о
>> RAM > 4Гб
> Для памяти > 4Гб есть PAE. Работает как часы. Это в венде
> его опять-таки маркетоиды порезали.Как г-но он работает, там процесс все равно не получает больше 4.
>>> Новый набор инструкция на CPU? Не, не слышал, я слышал только о
>>> RAM > 4Гб
>> Для памяти > 4Гб есть PAE. Работает как часы. Это в венде
>> его опять-таки маркетоиды порезали.
> Как г-но он работает, там процесс все равно не получает больше 4.Ваше мнение об 32-b. user-space-е на amd64 ядре?
http://www.opennet.dev/openforum/vsluhforumID3/110263.html#117
(Да, я там написал про "знаю, для чего там x86_64" -- *ровно* _два_ приложения (не считая файл-кеша ядра) имеют "буфера" >=4ГБ.)О прогрессе https://wiki.debian.org/Multiarch что думаете, уважаемый коллега?
>процесс все равно не получает больше 4Актуально только для обработки более 4-х гигов данных за один заход. А если данных будет на 8 Тб? Неужели без 8 Тб RAM и соответствующей адресации нельзя будет их обработать? Почему бы не обрабатывать эти 8 Тб данных порциями по 4 гига? А если оперативки всего 2 гига? Её может быть разное кол-во. Как меньше так и больше. Так почему бы тогда и не обрабатывать универсально, используя буфер динамических размеров (а размер будет определяться исходя из доступной оперативки и настроек юзера)?
Что эффективнее при наборе данных в 8 Тб - mysql с буфером InnoDB в 2 гига или в 8-16?
Это уже другой вопрос, который не имеет смысла если оперативки всего от 512-ти Мб до 4-х Гб.
Да, действительно уже некоторое время как столько оперативки не имеет смысла.
Скоро - даже на телефонах.;-)
> Что эффективнее при наборе данных в 8 Тб - mysql с буфером
> InnoDB в 2 гига или в 8-16?Опять какое-то серверное применение. Там наверное и проц особый нужен.
> Опять какое-то серверное применение. Там наверное и проц особый нужен.AMD 965/1090 или Core2 даже пищебродам вполне хватало :)
>> Опять какое-то серверное применение. Там наверное и проц особый нужен.
> AMD 965/1090 или Core2 даже пищебродам вполне хватало :)Покажи мне материнку на 775 сокете, которая бы поддерживала больше 4-8ми Гб RAM. DDR2 умер, даже для "нищeбродов", как ты выражаешься. На самом деле, видно, никогда не работал в конторах, в которых "устаревшие" компьютеры аккуратненько отправляются на склад, а потом используются в разных других задачах :)
>>> На самом деле, видно, никогда не работал в конторах, в которых "устаревшие" компьютеры аккуратненько отправляются на склад, а потом используются в разных других задачах :)К счастью.
> Что эффективнее при наборе данных в 8 Тб - mysql с буфером
> InnoDB в 2 гига или в 8-16?При соотношении обрабатываемых данных и массива рабочей памяти в тысячи, т.е. второе о() от первого, наращивание памяти это далеко не первая задача, которую следует решать.
Однако заставить чудика купить не нужные ему апп. ресурсы -- первая задача, которую решают производители АО (в содружестве с произв-ми ПО).
> При соотношении обрабатываемых данных и массива рабочей памяти в тысячи, т.е. второе
> о() от первого, наращивание памяти это далеко не первая задача, которую
> следует решать.Конечно. Лучше пилить медленными ротационными дисками или протереть насквозь SSD, но индексы в памяти не держать, да, и аппресурсы не покупать.
>> При соотношении обрабатываемых данных и массива рабочей памяти в тысячи, т.е. второе
>> о() от первого, наращивание памяти это далеко не первая задача, которую
>> следует решать.
> Конечно. Лучше пилить медленными ротационными дисками или протереть насквозь SSD, но индексы
> в памяти не держать, да, и аппресурсы не покупать.Массовый отечественный информатик, чем дальше, тем больше, характеризуется диковатым сочетанием осведомлённостью о самом передовом-мировом и неспособностью охватывать проблемы в масштабе крупнее его серверной/студии/etc.
Ну так озвучь нам, о гений земли руськой, ту самую первую задачу, которая не дает отечественному ойти вперде.
> Ну так озвучь нам, о гений земли руськой, ту самую первую задачу,
> которая не дает отечественному ойти вперде.Для начала изъяснись ты по-руськи. Да ладно.
Если ты это не он, то он не понимает или ленится понять, что задача больших данных даже 10 лет назад НЕ решалась наращением мощности одиночного счётного узла. Ещё бы можно выяснить, видел ли он терабайтную базу близко, а то за индексы в памяти он беспокоится. Плоды "практико-орентированного образования", понимаешь.
И к чему издевательское "гений"? Просто поинтересовался в своё время более развёрнуто, как это делают на западе. Разве я говорю, что сам это всё придумал?
> Актуально только для обработки более 4-х гигов данных за один заходнет(c).
Актуально для _любой_ работы с данными больше 4G - в том числе банально прочитать один байт со смещением 4G+1
(а учитывая помянутые любителями XP особенности плоской модели памяти - на самом деле 3 или 2 - в линуксе это, сюрприз, настраивается, но системе все равно сколько-то нужно оставить)> Почему бы не обрабатывать эти 8 Тб данных порциями по 4 гига?
а если там перекрестная ссылка из третьей порции в первую? Как она должна быть записана, и как мы это будем засовывать в код, уже написанный и отлаженный на архитектуре без ненужных ограничителей? Правильно - читать по пол-ссылки за раз, потом вручную манипулировать "склеенным" указателем, вручную же обрабатывая ошибку переполнения, потом снова раскладывать получившееся на адрес "страницы" + адрес внутри нее. Очень удобно, приятно, и позволяет потратить много времени на увлекательный поиск ошибок. Все ради того, чтоб тебе подольше не менять давно снятый с производства процессор.
> А если оперативки всего 2 гига?
размер адресного пространства в общем не имеет никакой связи с наличием физической памяти. Если я mmap'ну шестигиговый файл - программа отнюдь не сожрет 6 гиг физической памяти, пока я не прочитаю все шесть (то есть не сделаю какую-то операцию с данными хотя бы через каждый 4k при стандартной странице - а если это на самом деле пришлось делать, и страницы не освобождаются, то есть к ним снова нужно обращаться - поздравляю, дорогой друг, но у тебя все ж таки слишком сложная обработка слишком больших данных для такой дряхлой машинки, пора апгрейдиться)
Но вообще-то твой компьютер безнадежно устарел, в любом случае.
Железо для 32-х битных систем с парой гигов оперативы лежит на полках магазинов _сегодня_. Да, процы там 64-х битные, но 32-х битный UEFI неотключаем. Но, и оперативки 2 гига.
> Железо для 32-х битных систем с парой гигов оперативы лежит на полках магазинов _сегодня_.ну не ходи в такой плохой магазин, зачем ты так с собой?
В моем китайском планшете, купленном чтоб не жалко когда сопрут, не в этом и даже не прошлом году, и именно что насквозь китайском, и то четыре.
uefi32 (и еще без fallback на легаси запросто, или с неработающим, ибо забыли проверить) это да, китайцы они такие китайцы. Поэтому и спасибо центоси, что они еще годик-два нам отыграли.
Но это очень скоро пройдет, а живут эти поделки обычно недолго, моя уже явно дольше, чем китайский производитель наивно рассчитывал. (придется ему таки выпустить восьмигиговую, чтобы заставить меня снова дать ему денег. И ведь выпустит же...)
>>> Новый набор инструкция на CPU? Не, не слышал, я слышал только о
>>> RAM > 4Гб
>> Для памяти > 4Гб есть PAE. Работает как часы. Это в венде
>> его опять-таки маркетоиды порезали.
> Как г-но он работает, там процесс все равно не получает больше 4.А тебе на что больше 4? Даже браузеры давно умеют многопроцессность.
> Даже браузеры давно умеют многопроцессность.К слову, по сравнению с тем, сколько кипят холиворы 32vs64 - не так уж и давно научились.
А стабилизировали всю эту радость так и вовсе только-только.
>Для памяти > 4Гб есть PAE. Работает как часыслова не мальчика, но иксперта!
назови хоть одну программу, которая умеет адресовать >4гб через PAE.
>>Для памяти > 4Гб есть PAE. Работает как часы
> слова не мальчика, но иксперта!
> назови хоть одну программу, которая умеет адресовать >4гб через PAE.А с чего ты взял, что кто-то должен опровергать твой бред? Это ограничение есть, но у нас многозадачная система. запустил несколько сотен процессов и утилизируй хоть 64 гига оперативы. Браузеры давно это умеют, хотя им и полгига уже много.
Несколько сотен i?86-процессоров - это суровый садомазохизм.
Поправка: как ручные механические часы. Со всеми их срывами, отставаниями-опережениями и (тада!) необходимостью заводить каждые полсуток.А как насчёт смапить в адресное пространство процесса файлик >4Гб сложной структуры? Или опять будем изобретать велосипеды, кэш, эвикшн-стратегию и т.п., считая, что сделаем это лучше, чем ядро?
К счастью, с адресным пространством даже в 48 бит необходимость работать с файлами поблочно отпала чуть более, чем совсем. Мапим и работаем так, как нам надо.
На практике эти инструкции ничего ощутимого не дают. А вот работать часть приложений начинает медленнее, т.к. гонять из памяти приходится в 1,5 - 2 раза больше данных. И на той же системе, с 4 гб, swap всё время загружен, в то время как на 32 бит в нем не было необходимости.
> На практике эти инструкции ничего ощутимого не дают. А вот работать часть
> приложений начинает медленнее, т.к. гонять из памяти приходится в 1,5 -
> 2 раза больше данных. И на той же системе, с 4
> гб, swap всё время загружен, в то время как на 32
> бит в нем не было необходимости.Давай список этих приложений. А то вон у нас итаниум так и не взлетел. Я понимаю, что есть такие задачи, где 64 бита очень хороши, но вот на типичном десктопе я пока их не встречал. Даже на сервере, судя по тому же итаниуму, они нафиг не нужны.
Даёт приятное теплое чувство, что у тебя не отсталые 32, а передовые 64.
> Даёт приятное теплое чувство, что у тебя не отсталые 32, а передовые
> 64.Приятное тёплое чувство, что тот же пых, собранный на x64, исполняет одни и те же скрипты % на 5-10-15 шустрее. Про gcc вообще молчу. Впрочем, желающие погреть воздух могут его греть дальше.
Речь не о ницшеброд-VPS с 256мб памяти, да.
>> Даёт приятное теплое чувство, что у тебя не отсталые 32, а передовые
>> 64.
>пых, собранный на x64, исполняет одни
> и те же скрипты % на 5-10-15 шустрее.Откуда дровишки?
Вон они на unboxing [или как там его] в 5.6=>7.0 _два_раза_ [и более~] под фанфары рапортовали.
>Про gcc вообще
> молчу.Не сдерживайтесь, расскажите, откуда и эти дровишки.
//Неужели бенчмарки таки есть, но мне никто их не дал, когда я просил там наверху?
>Впрочем, желающие погреть воздух могут его греть дальше.
Кстати, одни и те ж задачи, собранные на 64бита вместо 32ух [при условии, что "помещаются" в те 2-3-4гига], и запущенные на одном и том же интел64+32 железе!!, по логике, занимая, скажем на 30% больше памяти, также и пересылают ["чуть"] больше данных, и, соответственно, _расходуют_ [чуть?] _больше_ электричества и больше греют полярные шапки!?
//Ларабель [у нас же тут больше никто ничего не меряет, да-а-а??!] не меряет потребление электричества в своих пузомерках -- ему счета за луц актуальны? ...но поперёк маркетинговой линии Интела он не ходит?
> А по существу что даёт 64 бита? 4-5% компенсируются меньшим потреблением памяти.На самом деле, иногда разница есть -- если используешь что-то вроде BLAS. Для массового юзера, понятно, ничем не отличье.
> На самом деле, иногда разница есть -- если используешь что-то вроде BLAS.
> Для массового юзера, понятно, ничем не отличье.Для массового юзера отличье начнётся там, где начнутся операции с длинными числами. Декод-энкод видео/аудио, крипта (ага, любой браузер), сжатие данных и т.п.
Учитывая, что память нынче дешева, как грязь (~30$/4G), смысла ретроградить даже массовому юзеру особо не видно.
>> А по существу что даёт 64 бита? 4-5% компенсируются меньшим потреблением памяти.
> На самом деле, иногда разница есть -- если используешь что-то вроде BLAS.Во-во. Как раз собирался написать, что для газодинамических расчётов выигрыш очень даже неплохой, потому как единовременная обработка float-ов в 64 бита значительно повышает точность вычислений. Выигрыш в производительности на порядок, прикидочно. Точнее, увы, не скажу. Давно я сетки не считал.
Были кстати отдельные инициативы адаптировать солверы для расчётов на видеокартах. Идея была в том, чтобы увеличить скорость расчётов и их точность за счёт повышенной разрядности GPU. Увы, как-то не задалось дело. Данные в этих расчётах исчисляются десятками (а иногда даже сотнями) Гб. На их пересылку карте, уходит куда больше времени, нежели выигрывается на вычислениях.
> Для массового юзера, понятно, ничем не отличье.
Истина. На интах мы тут вряд ли получим большой прирост.
>[оверквотинг удален]
>> На самом деле, иногда разница есть -- если используешь что-то вроде BLAS.
> Во-во. Как раз собирался написать, что для газодинамических расчётов выигрыш очень даже
> неплохой, потому как единовременная обработка float-ов в 64 бита значительно повышает
> точность вычислений. Выигрыш в производительности на порядок, прикидочно. Точнее, увы,
> не скажу. Давно я сетки не считал.
> Были кстати отдельные инициативы адаптировать солверы для расчётов на видеокартах. Идея
> была в том, чтобы увеличить скорость расчётов и их точность за
> счёт повышенной разрядности GPU. Увы, как-то не задалось дело. Данные в
> этих расчётах исчисляются десятками (а иногда даже сотнями) Гб. На их
> пересылку карте, уходит куда больше времени, нежели выигрывается на вычислениях.Ну да. Это и есть 1) фундаментальная проблема и 2) проблема её решения с помощью распределённых вычислений.
Видеокарты воплощают параллелизм с общей памятью, что годится не для всех задач. Большая (разреженная) матрица, если алгоритм позволяет разделить её на части, более выигрывает от раздачи её на счётные модули с (небольшой) памятью независимого доступа. Но... стоимость пересылки. Оптимизации принятия этого решения посвящены, пожалуй, тома.
почему кому то надо допиливать то что нужно вам?
В мире больше половины компов с менее 4 Гб на борту. Разработчики операционных систем и разжиревших браузеров забыли это и успешно промыли мозги своим пользователям.
Наверно разработчики ценят своё время и не хотят заниматься архитектурой которая уходит в прошлое так же как ушли в прошлое архитектуры 8 и 16 бит в сегменте рынка офисного или домашнего использования компьютеров
> Наверно разработчики ценят своё время и не хотят заниматься архитектурой которая уходит
> в прошлое так же как ушли в прошлое архитектуры 8 и
> 16 бит в сегменте рынка офисного или домашнего использования компьютеровРазработчики чего? Большинство так вообще пишут на си, т.е. на более высоком уровне, чем уровень инструкций определённого процессора.
> Разработчики чего? Большинство так вообще пишут на си, т.е. на более высоком
> уровне, чем уровень инструкций определённого процессора.Ядра и драйверов, не?
i386 из ядра выпилили, со временем по той же причине будет выпилен и i686.
> В мире больше половины компов с менее 4 Гб на борту.но большая их часть лежит на свалке в Гане (google for it)
> Разработчики операционных систем и разжиревших браузеров забыли это
как страшный сон, да.
> и успешно промыли мозги своим пользователям.
пользователи в мире опенотсоса не интересуют вообще никого.
Впрочем, судьба x86 архитектуры и в мире коммерческого софта довольно предсказуема - учитывая что у интела, по-моему, уже только atom'ы остались не-64бита, и те устаревшие и скорее всего их через год снимут.Кстати, еще и по этой причине обидно вкладывать усилия в поддержку того, что все равно очень скоро сдохнет, от естественных причин.
> А по существу что даёт 64 бита? 4-5% компенсируются меньшим потреблением памяти.
> В общем т*пой маркетинг, только и всего. Лучше бы X32 допилили.Вот мы с тобой думали, что Интель продаёт нам 64-b., да? Нет! Эти [///вырезано/самоцензурой///] продадут эскимосам и снег в заполярье:
"[...]that might work better with newer IoT type boards like minnowboard, edison, jaguarboard, etc."
Brace your, bros, Intel over[priced] Things is coming.
> ЗЫЖ Это с каких пор слово т*пой стало ненормативной лексикой? А "острый"
> почему тогда не внесли?//В правилах -- "оскорбляющих или неуважительных выражений. Приветствуется уважение к собеседнику, корректное обращение с окружающими, терпимость, вежливость, дружелюбие;" Уважай маркетинг -- матb тBою.
> "[...]that might work better with newer IoT type boards like minnowboard, edison,
> jaguarboard, etc."только вот нахрена там центось и вообще система общего назначения - для удобства создания iot-ботнетов, разьве что? Да вроде и так как-то справляются...
Для моргания светодиодиком это совершенно лишнее.
ничего не дает. Как и 32 битная архитектура.
Всем пересаживаемся на 8088. 64 кбайта хватит всем.
>А по существу что даёт 64 бита?Ну, программам оно дает возможность выделить больше 2х гб памяти. Конечно нормальным людям это не нужна, им и 64 кб хватает.
> ничего не дает. Как и 32 битная архитектура.
> Всем пересаживаемся на 8088. 64 кбайта хватит всем.
>>А по существу что даёт 64 бита?
> Ну, программам оно дает возможность выделить больше 2х гб памяти. Конечно нормальным
> людям это не нужна, им и 64 кб хватает.Больше 2х или 4x? Ты определись, а то выше про 4 говорили. И давай список этих программ, которые по 8 гигов за раз выделяют.
Под XPюшей два гига, под линуксом четыре.
> под линуксом четыреТри
$ ps ux | grep perl
angra 5127 21.1 26.4 4053676 4051504 pts/4 S+ 01:10 0:01 perl -E $s="a"x1024000;push @a,$s for 1..4030;say 1; <>
$ which perl
/usr/bin/perl
$ file /usr/bin/perl
/usr/bin/perl: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.26, BuildID[sha1]=ff3d3e8ea1c50813a8d4ba9f8591b229c7299d73, stripped
Что за плата/чипсет?
Ну и uname -a неплохо бы
Это ты правильно смекнул. Да, дело в ядре. В данном случае это amd64 ядро на 32-битной системе. Линукс подобный фокус позволяет сделать безболезненно, винда - нет. На стандартном PAE ядре предел будет в 3 гига. Однако когда то были патчи и к 32-битным ядрам, что позволяли получить почти 4 гига на процесс.
> Лучше бы X32 допилилиПлюсую - для десктопа идеально, хотя и с оговоркой про требования современных браузеров.
>> Лучше бы X32 допилили
> Плюсую - для десктопа идеально, хотя и с оговоркой про требования современных
> браузеров.Многопроцессность спокойно решают эту проблему. 1 вкладка - 1 процесс. Это же как надо умудриться накодить, чтобы страничка хотя бы 2 гига оперативы умудрилась пожрать.
> Это же как надо умудриться накодить, чтобы страничка хотя бы 2 гига оперативы умудрилась пожратьНе знаю, это не я кодил...
К сожалению, большинство дополнительных реп, например epel, не поддерживают 32-разрядную архитектуру. Так что подойдет только тем, кто использует только голенький Centos
без epel совсем хреновенько, согласен
Copr@FedoraProject будет поддерживать сборку el7 для i686? А то проблема с мультилибом там
а какой нить guix умеет часть пакетов х64, часть х32, а часть х86 ? (и чтоб в конфиге указать какие пакеты какой архитектуры брать)
> а какой нить guix умеет часть пакетов х64, часть х32, а часть
> х86 ? (и чтоб в конфиге указать какие пакеты какой архитектуры
> брать)По впечатлению, возможно необоснованному и ошибочному,
* эти всякие multiarch-и/multilib-ы пилят, и перепиливают!, модные редхейтистые ребята из федор https://lwn.net/Articles/711199/ . У остальных, арчей https://wiki.archlinux.org/index.php/Multilib / гент https://wiki.gentoo.org/wiki/Multilib и пр., и пр. https://wiki.debian.org/Multiarch#Current_Status , оно находится в разной степени обсуждения, развала, раздрая -- в попытках "тащить ентерпрайсное".
* в Guix-е этого нет, вроде. Как и x32 ABI. //Опять -- может, и ошибаюсь.
.
.
.
"As for guix, that project looks interesting to me but looks to be very much in its infancy [...]" --https://www.reddit.com/r/linux/comments/357rkz/exherbo_the_f.../Опять, по впечатлению, они активно занимаются бутстратпом дистрибутива без (ну, с минимумом - пока получается) бинарных пред-зависимостей и кросс-компиляцией (в какой-то части пакетов и само-бутсртапа).
Соляра может
> Соляра можетx32 linux ABI? Верю.
Гикс умеет создавать окружения x86 на системе x64. Например, так можно получить 32-битный GCC:$ guix environment --system=i686-linux --ad-hoc gcc-toolchain
$ gcc -dumpmachine
i686-unknown-linux-gnu$ file -bL `which gcc`
ELF 32-bit LSB executable, Intel 80386...