[devel] кризис 32-битных архитектур

[Aleksey Novodvorsky]

8 нояб. 2017 г. 3:33 PM пользователь "Alexey Tourbin" <
alexey.tourbin на gmail.com> написал:

2017-11-08 13:03 GMT+03:00 Andrey Savchenko <bircoph на altlinux.org>:
> Добрый день,
>
> On Wed, 8 Nov 2017 09:26:46 +0300 Alexey Tourbin wrote:
>> Кажется, 32-битные архитектуры находятся на последнем издыхании.
>> Предлагаю обсудить в том числе и это.  Главными двумя факторами
>> издыхания мне кажутся: 1) chromium жрет слишком много памяти, и давно
>> опередил firefox по популярности; и это зависит не только от chromium,
>> но и от разжиревших сайтов; 2) память стоит сравнительно дешево, 500
>> рублей за гигабайт, DDR3 - чуть дешевле, DDR4 - чуть дороже.  Итого,
>> современный десктоп должен иметь не менее 8G RAM, иначе он сам себя
>> обрекает на вечные муки.
>>
>> Антитезой может выступать поддержка российских архитектур типа "Бойкал
>> T1". Я недавно думал и производил измерения, годится ли Blake2b в
>> качестве универсальной хеш-функции для всех архитектур.  На 32-битных
>> архитектурах Blake2b работает в 4 раза медленнее.  Следовательно, если
>> держать в уме поддержку 32-битных архитектур, то это всё меняет, нужны
>> разные хеш-функции вместо одной универсальной и т.п.
>
> hash-функции не являются узким местом в плане производительности,
> поэтому данный тест сложно рассматривать как аргумент. Потяно, что
> вся длинная арифметика на 64 битах будет ощутимо быстрее, чем на 32.
> Но нужно смотреть на конкретные задачи. На самом деле некоторые
> вещи на 32 битах могут быть быстрее за счёт меньшей нагрузки на
> память (здесь ещё можно вспомнить x32 ABI).

Почему хеш-функции не являются узким местом в плане
производительности? Вот вы сделали apt-get update, сколько секунд у
вас будет вычисляться проверка скачанных файлов, одну секунду, четыре
секунды? 10?

$ set /var/lib/apt/lists/*list.*
$ cat $@ |time b2sum
deb4b4bc890fc675311c5a311fc9d23cb36a5598c7eb5e42dd9934303c3b
c775f5df2ce2ac1e6ee48c76c74b7bb43e29592d118e3e7448f6b533103265383f60
 -
0.44s user 0.04s system

$ rpmpeek coreutils-8.27.0.23.f4570-alt1.i586.rpm cp -pv
./usr/bin/{md5,sha256,b2}sum $PWD/
$ cat $@ |time ./b2sum
deb4b4bc890fc675311c5a311fc9d23cb36a5598c7eb5e42dd9934303c3b
c775f5df2ce2ac1e6ee48c76c74b7bb43e29592d118e3e7448f6b533103265383f60
 -
1.95s user 0.04s system

Кагбе если вы хотите всё замедлить в 4 раза, то рецепт написан на
стене.  В общем, я пока не принимаю аргумента о том, что 32-битность
не является узким местом в плане производительности.  Является!

> Думаю, что пока будет спрос по тем или иным причинам, до тех пор
> и будут выпускаться 32-битные дистрибутивы. i586 уже в закате,
> а вот на mips, arm и прочей "экзотике" оно ещё очень даже нужно.

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

Специализированного -- да, насчёт узкого -- не уверен, особенно в РФ в
условиях, извините, импортозамещение железа.
Чуть подробнее.
1. i586 -- очень много старого железа, в том числе у корпоративных
заказчиков. Причем универсального назначения.
2. armv7 -- уходит, даже raspberry pi уже на armv8. Но вовсю производятся
системы на armv7 от elvees. Ранее 19 года вряд ли перейдут на armv8.
3. mipsel -- помянутый Байкал-Т. Хотя у китайцев loongson mips64el. Вот на
нем будем собирать.
4. mips64 (big endian), у нас -- Комдив64. Это отдельный разговор, но по
факту userspace там 32 bit.

Пока сборка 32 bit на всех этих платформах происходит на 64-битных серверах
и не представляет особой проблемы, если не считать тестирования.

В общем, пока спрос есть, хотя хотелось бы забыть про 32 бита в p10. Но не
в p9.


Rgrds, Алексей
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20171108/9c09cae1/attachment.html>