Железо на шаг впереди, софт делает два шага назад

Что: 543ea92f9b81c1c8adead550e7ce0cf3cc665240

Когда: 2020-11-13 10:54:06+03:00

Темы: go hard hate

Железо на шаг впереди, софт делает два шага назад

https://fabiensanglard.net/silicone/index.html
Автор пишет что, не смотря на возрастающую производительность
процессоров и железа в целом, на каждую сохранённую железячниками
инструкцию, софт умудрится сделать на две инструкции больше. Меня
впечатлило что автор говорит что раньше Photoshop на SSD грузился
за секунду, XCode запускался мгновенно. А теперь на Ryzen 5 2600 с
M.2 NVMe он уже просто не в состоянии использовать XCode и Photoshop
грузится на 13сек!

Это нормально что raytracer-ы требуют больше ресурсов потому что они
делают более качественную и лучшую картинку. Компиляторы получили всякие
LTO оптимизации, которые тоже ресурсоёмки. Но вот не нормально что
прежние такие же задачи на новом железе выполняются так же долго.

Именно в этом году я конкретно начал замечать и париться об отзывчивости
системы. Я делал это и прежде, но в этом году у меня обострение какое-то.


  Я уже не вспомню где и как именно, но он тупо просто некоторые чисто
  shell вещи умудряется делать так, что я на глаз замечаю задержку.

  мощных Mac системах (коллега проверял) "не прогретый" запуск занимает
  более секунды! Если мне надо посчитать в калькуляторе что-то, то я,
  очевидно, хочу его моментальный запуск! Это происходит не часто,
  поэтому к долгому времени запуска я привыкнуть не могу. Я перешёл на
  zcalc, а теперь вот на dc в rlwrap в tmux с кучей shell-скриптов
  обёртки -- и это работает стремглав, по сравнению с запуском python.

  он способен откомпилировать с нуля mumble-сервер, жирный irc-сервер с
  кучей зависимостей за считанные секунды!

  скорость работы (или я замечу задержку или нет) практически на первом
  месте. Возясь с LSP увидел что скорость работы Python LSP сервера
  такая, что я полностью отключил его, ибо мне проще и удобнее руками
  вызывать pylint/pyflake/whatever, а не получать с дичайшей
  асинхронностью по времени warning-и, которые уже не актуальны могут
  быть. Linting clangd для C работает вполне вполне с достаточной
  скоростью и помогает, но вот дополнение методов/функций работает очень
  медленно -- автоматику во время набора поэтому отключил. А вот в Go
  LSP работает практически со скоростью моего набора!

  процесс конфигурирования+сборки+установки стал таким быстрым (для моих
  проектов, конечно же), что мне почти физически становится плохо когда
  я вижу что на моём ноутбуке ./configure выполняется дольше чем сама
  сборка. Это проблема configure, но всё же!

  способно компилироваться. C++ -- адовейший ад. У коллеги с мощным
  компьютером видел сколько собирает Rust программу типа PyDERASN-а --
  ещё большее время ожидания, при котором можно прочитать новости успеть

  насколько много впустую тратится время *человека* ожидающего запуск
  программы

  порядок быстрее чем Python Sphinx. Не то чтобы это критично, но к
  быстрой работе команд/задач очень привыкаешь и офигеваешь как в
  некоторых проектах дока собирается по несколько минут. Давным давно
  для вырезания docstring-ов и их вставки в .texi/.rst файлы у меня был
  Python скрипт и при частой сборке программ я бОльшую часть времени мог
  ждать только факта самого его запуска. Сейчас у меня быстро написанная
  программка на Perl -- работающая просто моментально для глаза (Perl
  вообще очень и очень шустрый)

  сборка полностью всей ОС занимала меньше (на в разы более слабом
  железе) чем сборка сейчас LLVM-а. CMake собирается дольше чем GCC (не
  самый последний GCC, конечно же, где вроде как тьма C++ появилось). А
  скорость сборки всей системы важна, если бы мы максимально старались
  делать статическую линковку (c0de9bbf633b421a57a10db70d6d76b5f195546e).
  Сборка Go, начиная с 1.4, занимает суммарно (без тестов) наверное пару
  минут на ноутбуке

Отзывчивость системы это life-changing! Это не просто "ну, приятно что
быстрее запускаются", а это именно в корне меняет привычки и работу за
компьютером. Огромное количество людей уходит с жирных IDE на Emacs/Vim
только потому что на их 16GB RAM системах оно всё равно всё тормозит (с
моей точки зрения -- до неюзабельного состояния).

Буквально позавчера я устанавливал Ubuntu последнюю LTS на флешку
(обычную такую дешёвую флешку), чтобы на отдельном ноутбуке поработать с
железом и с ней. В н��й так много всего позапущено (без GUI! это server
вариант), что когда мне показали приглашение для логина, то логин занял
более чем минуту, прежде чем я увидел строку shell-а! Каждая, *КАЖДАЯ*
команда имеет видимый и ощутимый lag. На этой же флешке я помню как
запускал FreeBSD с GUI и Firefox-ом -- это была юзабельная система.
Большие лаги я наблюдают когда соединяюсь с удалённым VPS-ками по IPv6,
который идёт через третьи страны -- вот на современных Ubuntu,
запущенных на локальном железе, ощущения похожие.

Я, как программист, часто понимаю, конечно же, откуда растут ноги всего
этого, но нужно же иметь совесть! Отдельная тема это смартфоны и
броузеры (штатные, где ничего не отключено из JS-а) -- где всё медленно
и неспешно, в slow-mode-е. У папы на смартфоне я вижу задержку наверное
чуть ли не на каждый клик (не в броузере, а просто в системе), хотя
другие этого не замечают уже, ибо привыкли. Мне в фильмах всегда
бросалось что любое нажатие по любой кнопочке обязательно должно
открывать окошко/менюшку с анимированным визуальным эффектом. В Mac по
умолчанию когда показываются все текущие окна, тоже анимация их
размещения по экране. В фильмах это ладно и простительно. Но нормальный
человек рехнулся что ли за каждым частым действием ждать десятки/сотни
миллисекунд на свистоперделку, вместо того чтобы от компьютера сразу
получить ответ на свою команду? Знаю что в проприетарных системах этими
анимациями часто скрывают, на самом деле, долгое время запуска/работы,
но ведь не всегда же так.

Насколько мог бы "динамический" IPsec между host-to-host системами
(когда одна из сторон "анонимна" например) помочь с хранением
handshake/state и сократить до минимума лишние round-trip-ы до сервера,
дьявольски увеличив отзывчивость системы (HTTP/2 со всякими TLS session
resumption-ами это и пытаются добиться как-раз). Когда люди хотят чтобы
в каждой сетевой программке была поддержка TLS, то меня это бесит! IPsec
надо развивать, а не эти изолированные TLS сессии. Ведь нет же ничего
чтобы хранило state при запуске lynx, curl, wget, whatever -- наверное
только броузер одна из немногих программ которая долго живёт и может
блюсти уже установленные handshake-и. Life-changing когда я стал
использовать OpenSSH долгоживущие сессии и моментально логиниться на
сервер, а не ждать пока TCP/SSH handshake отработает и вся эта не
шустрая асимметричная криптография (пускай даже и *25519!).

Или вот на работе у нас используется OpenVPN. Под пять секунд приходится
ждать пока он подключится! А ведь ping до сервера вообще показывает чуть
больше 2мс!

На глаз видно насколько медленнее работает SSH или IKEv2 с RSA ключами.
Но это уже ладно -- это тема ни программистов, ни компьютеров. Но пора
активнее начать использовать эллиптические кривые.

Я бы на месте пользователей компьютеров и ресурсов Интернетов люто
ненавидел любого программиста, бессовестного и обнаглевшего!

оставить комментарий

Сгенерирован: SGBlog 0.34.0