> Понятно, что Хабр – не то место, где нужно разжевывать нюансы работы с GLIBC.
За всех пользователей Хабра говорить не могу, но мне кажется, что на Хабре достаточно много людей, которые ожидают увидеть в статьях скорее описание нюансов glibc, а не смешные картинки с мемами. Подобную техническую направленность Хабра подтверждает недавний переезд статей по ряду нетехнических и не относящихся напрямую к IT-сфере тем на отделившиеся ресурсы.
Я совершенно не против, если вы в статьях здесь будете пытаться объяснять сложные вещи простыми словами, но, учитывая тематику ресурса, с процитированным предложением не согласен.
Согласен с вами. Без экскурса в историю о том, что C++ появился из Си, обычно не так просто объяснить, почему, например, scanf не работает с std::string.
Теперь можно применять декоратор строкой @cpmoptimize(verbose=sys.stderr), тогда он будет логгировать, в каких функциях какие циклы он оптимизировал, что пропустил из-за iters_limit, а что оптимизировать не смог. В последнем случае выводятся достаточно подробные сообщения о причинах того, что оптимизация не удалась.
Оптимизация не ускоряет программу в определённое количество раз, а вообще изменяет сложность алгоритма, используемого в ней. Таким образом, меняется вид зависимости времени работы от входных данных (обратите внимание, линия на графике после оптимизации имеет другой вид, соответствующий функции, растущей более медленно).
Понятие «асимптоты» тут, грубо говоря, ни при чём, речь только про сложность алгоритма. Вот ещё статья с хабра на эту тему.
Если написать тот же самый код, что и на картинке, для n = 10^5 скрипт с тривиальным алгоритмом у меня работает за 0,2 с, а скрипт с оптимизацией — за 0,05 с. То есть, оптимизация ускоряет программу в 4 раза.
Вы уверены, что правильно измеряли время выполнения? В вашем случае разница между временем так мала (в пределах погрешности), что вы могли, например, случайно запускать один и тот же файл.
Вычислительную сложность алгоритма нередко коротко называют «асимптотика». В словосочетании «изменяется асимптотически» я имел в виду то, что в результате оптимизации изменяется эта самая сложность алгоритма (далее идут рассуждения про асимптотику O(n) в одном случае и асимптотику O(log n) в другом).
По ссылке можно найти презентации с подробным описанием изменений, которые они сделали в интерпретаторе: 1, 2. Там же сравнивается эффективность WPython по сравнению с классическим интерпретатором CPython.
Мне кажется, что в основной код CPython это не внесли, так как было сделано очень много внутренних изменений в интерпретаторе, которые его значительно усложнили. Возможно, это привело к каким-то проблемам, из-за которого слиять проекты было затруднительно.
Нет, моя библиотека, к сожалению, не умеет оптимизировать рекурсивные функции. Однако, в Интернете я видел проекты по написанию других декораторов, которые, также анализируя байт-код, оптимизируют конкретно случай хвостовой рекурсии. Можно поискать по словам «python tail recursion decorator»: goo.gl/CHhkZh
Модель, которая сейчас занимает первое место в лидерборде, есть в открытом доступе (вот статья про неё на Хабре).
Для этого nc не подойдёт?
На одном компьютере можно запустить:
На другом:
За всех пользователей Хабра говорить не могу, но мне кажется, что на Хабре достаточно много людей, которые ожидают увидеть в статьях скорее описание нюансов glibc, а не смешные картинки с мемами. Подобную техническую направленность Хабра подтверждает недавний переезд статей по ряду нетехнических и не относящихся напрямую к IT-сфере тем на отделившиеся ресурсы.
Я совершенно не против, если вы в статьях здесь будете пытаться объяснять сложные вещи простыми словами, но, учитывая тематику ресурса, с процитированным предложением не согласен.
Теперь можно применять декоратор строкой @cpmoptimize(verbose=sys.stderr), тогда он будет логгировать, в каких функциях какие циклы он оптимизировал, что пропустил из-за iters_limit, а что оптимизировать не смог. В последнем случае выводятся достаточно подробные сообщения о причинах того, что оптимизация не удалась.
Новую версию можно установить с github'а.
Понятие «асимптоты» тут, грубо говоря, ни при чём, речь только про сложность алгоритма. Вот ещё статья с хабра на эту тему.
Вы уверены, что правильно измеряли время выполнения? В вашем случае разница между временем так мала (в пределах погрешности), что вы могли, например, случайно запускать один и тот же файл.
Мне кажется, что в основной код CPython это не внесли, так как было сделано очень много внутренних изменений в интерпретаторе, которые его значительно усложнили. Возможно, это привело к каким-то проблемам, из-за которого слиять проекты было затруднительно.