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

[Andrey Savchenko <bircoph@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 5168 bytes --]

On Wed, 8 Nov 2017 15:30:08 +0300 Alexey Tourbin wrote:
> 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
> deb4b4bc890fc675311c5a311fc9d23cb36a5598c7eb5e42dd9934303c3bc775f5df2ce2ac1e6ee48c76c74b7bb43e29592d118e3e7448f6b533103265383f60
>  -
> 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
> deb4b4bc890fc675311c5a311fc9d23cb36a5598c7eb5e42dd9934303c3bc775f5df2ce2ac1e6ee48c76c74b7bb43e29592d118e3e7448f6b533103265383f60
>  -
> 1.95s user 0.04s system
> 
> Кагбе если вы хотите всё замедлить в 4 раза, то рецепт написан на
> стене.  В общем, я пока не принимаю аргумента о том, что 32-битность
> не является узким местом в плане производительности.  Является!

Задержка в 1 секунду не критична. Я не говорю, что её нет, я
говорю, что это не повод блокировать изменение хеша, если оно нужно
по иным соображениям.

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

Для каждой задачи есть свои инструменты. Есть задачи, где 32-битных
систем достаточно. Если у Вас десктоп с Intel ME, то под капотом
там тоже есть 32-битный Minix в Ring -2, но это уже отдельная
история...

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]