- комментарий 0:
From: kmeaw
Date: 2020-12-09 13:38:47Z
> It’s about twice as slow as that
Где-то начиная с 1.9 стало лучше, когда появилась YARV. Сейчас ситуация
такая:
% python --version
Python 3.9.0
% time python -c $'def fib(n): return n if n < 2 else fib(n-1) + fib(n-2)\nprint(fib(35))'
9227465
python -c 2.93s user 0.01s system 99% cpu 2.938 total
% ruby --version
ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-linux]
% time ruby -e 'def fib(n); n < 2 ? n : fib(n-1) + fib(n-2); end; p fib(35)'
9227465
ruby -e 'def fib(n); n < 2 ? n : fib(n-1) + fib(n-2); end; p fib(35)' 1.22s user 0.01s system 99% cpu 1.231 total
Да и RoR тоже с тех пор обмазали всякими прокси и кешами для ускорения
всего. Как сейчас, уже не знаю, я перестал следить за происходящим
где-то после Rails 3.
Когда-то моим любимым gem был em-ssh. До того, как я начал писать на Go,
возможность обойти тысячи машин по ssh за секунды казалась удивительной.
В Ruby есть callcc, но его в последних версиях спрятали в continuation.
В 1.9.1 появились fibers. В Python callcc нет до сих пор, а async
появился только в 3.4. Возможно, это и к лучшему, но конструкция очень
уж мощная.
Ещё есть такая крутая штука, как mruby. Есть стандарт, компилируется в
байткод, легко вставлять в другие приложения, расширяется с помощью
mrbgems. Примерно как Lua, но с гораздо более (лично мне) приятным
синтаксисом.
> Ruby performance tuning really feels like trying to get the best
> miles per gallon out of a tricycle.
GC.disable
:)
- комментарий 1:
From: Sergey Matveev
Date: 2020-12-09 13:58:57Z
*** kmeaw [2020-12-09 16:33]:
>Где-то начиная с 1.9 стало лучше, когда появилась YARV.
Лично я, обо всём что вы написали не в теме. Собственно, к Ruby не
возвращался вообще ни разу, после Django/Python. Помню я когда мерил
производительность, то запомнилось так: Python на порядок медленнее
Perl, а Ruby на порядок медленнее Python. Здоровские у вас результаты
получились, прогресс огромный у них!
А async в Python мне и сейчас не нравится и я не одобряю его наличие,
ибо пока я вижу что он больше геморроя в целом добавил Python-миру. На
практике получалось что или всё должно быть с async-ом (ну, конечно, где
уместно) или всё синхронное (чтобы под каким-нибудь gevent-ом запускать).
А мешанина на практике регулярно сводилась или к полному дублированию
кода или переделыванию всё в async. Тьма библиотек что раньше отлично
работали и были проверены времени -- теперь переписываются, хотя
gevent-а было бы достаточно в преобладаюшем большинстве случаев.
- комментарий 2:
From: Sergey Matveev
Date: 2020-12-09 14:03:57Z
*** kmeaw [2020-12-09 16:33]:
>Ещё есть такая крутая штука, как mruby. Есть стандарт, компилируется в
>байткод, легко вставлять в другие приложения
Вот лично я бы уж точно предпочёл что угодно другое (ну кроме JS) чем
Ruby встраивать :-). Для меня Ruby имеет все недостатки Perl-а: огромное
количество способов сделать одно и то же действие. И если среди сотни
способов один не знаком читающему код, то он не поймёт его или будет
заблуждаться в том что видит. Ruby чересчур богат. Как и Perl, но у
Perl-а есть своя ниша где он хорош, а для Ruby не смогу её назвать.
Разве что он дал толчок MVC миру framework-ов своим RoR-ом.
- комментарий 3:
From: kmeaw
Date: 2020-12-09 15:28:16Z
> Вот лично я бы уж точно предпочёл что угодно другое (ну кроме JS) чем
> Ruby встраивать :-).
Полгода назад я использовал mruby в embedded-системе, где почти не было
бинарников, кроме busybox. Эта программа представляла собой
предзагрузочное окружение - с помощью стандартных (внешних) утилит
привязывала драйвера к устройствам, раскладывала обработчики прерываний
по cpu, инициализировала сеть, консоль на последовательном порту, LVM,
монтировала корень и так далее. Самая первая версия этой программы была
простым shell-скриптом, как и в большинстве дистрибутивов.
С shell на ruby переписал просто потому, что оказалось неудобно
восстанавливаться в случае ошибок, парсить древовидные конфиги и
создавать временные файлы там, где надо хранить бинарные данные, часть
которых ещё и при некоторых условиях являлись секретами. Также mruby ещё
дал мне возможность проверить хотя бы синтаксис перед упаковкой образа
системы. Ну и небольшой размер и уже наличие готового пакета с
интерпретатором в репозитории дистрибутива тоже сыграли свою роль в этом
выборе.
Думал про Go, но бесконечные if err != nil и неудобность вызова внешних
утилит (os/exec против `cmd`) заставили отказаться от этой идеи.
Интересно, что бы ещё подошло для решения похожей задачи?
- комментарий 4:
From: Sergey Matveev
Date: 2020-12-09 15:37:50Z
*** kmeaw [2020-12-09 18:22]:
>Думал про Go, но бесконечные if err != nil и неудобность вызова внешних
>утилит (os/exec против `cmd`) заставили отказаться от этой идеи.
Ну это holywar тема, но по мне это сравнение чрезвычайно
богатого/сложного языка (я и Python то считаю чересчур богатым) с
простым и минималистичным, значит и легче поддерживаемом. Для меня тут
ничто не может никогда компенсировать сложность.
>Интересно, что бы ещё подошло для решения похожей задачи?
Lua, Perl? Хотя к Perl наверное такие же претензии можно как и к Ruby
предъявить, касательно сложности. Tcl? Ну собственно я просто перечисляю
то, что часто используется как glue-language. Scheme не рассматриваю,
ибо функциональщина и я сегодня смотрел про callcc, но так с ходу и не
понял что это и как этим пользоваться :-). Вы уже сказали про Lua
конечно, но а мне он он нравился, опять же, простотой. Ну и достаточно
богатыми возможностями. А Ruby... это как C++ -- на них конечно можно
писать нормально, понятно, поддерживаемо, но мало кто это умеет. Но это
holywar тема с языками.
В любом случае, всё это всяко лучше JavaScript :-)