LINUX.ORG.RU

Гвидо ван Россум хочет ускорить Питон вдвое

 ,


1

2

На онлайн-конференции Python Language Summit 2021 автор языка и сотрудник Майкрософт Гвидо ван Россум рассказал о запланированном на версию 3.11 увеличении скорости CPython.

За проект Ван Россум благодарит пандемию и Майкрософт. Ему стало скучно на пенсии, он попробовал наняться в Майкрософт, его взяли и разрешили самому выбрать, чем заняться. Таким образом Майкрософт «возвращает долги» Питону.

В прошлом году уже предлагался 4-летний «план Шеннона», обещавший ускорение на 50% в год в течении 4 лет за 2 миллиона долларов (500 тысяч в год). Одним из условий было, чтобы направление разработки определяло сообщество, а не корпорации.

Сейчас разработкой на деньги Майкрософт занимаются Марк Шеннон, Эрик Сноу и Гвидо Ван Россум, могут привлечь и других программистов. Обещают прозрачное сотрудничество с ядром разработчиков основной ветки и плавное накопление изменений. Не будет ни долгосрочных параллельных форков, ни внезапных патчей из 6000 строк. Все изменения будут доступны для обсуждения на Гитхабе.

Разработчики приняли следующие ограничения:

  • Не ломать совместимость со стабильным ABI.
  • Не ломать частичную совместимость API.
  • Не ломать и не замедлять граничные случаи (например, не кидать миллион объектов в стек eval).
  • Не делать код несопровождаемым.

Поэтому нельзя менять базовые вещи: объекты, типы, счёт ссылок; байткод, стековый фрейм; компилятор, интерпретатор; внутреннее устройство большинства объектов…

Для ускорения версии 3.11 планируют:

  • Адаптивный интерпретатор байткода.
  • Множество сравнительно небольших оптимизаций:
    фрейм стека;
    ускорение вызовов;
    аллокация.
  • Обработка исключений «без накладных расходов». (кавычки Ван Россума)

Гарантии успеха не дают.

Также хотят:

  • Ускорить запуск.
  • Изменить формат файлов .pyc.
  • Ускорить операции с целыми.
  • Фиксированное смещение для __dict__.
  • «Скрытые классы».
  • «Tagged numbers».

В последующих версиях хотят добиться 5-кратного ускорения. Вероятно, будут генерировать машинный код (iOS в пролёте). Могут что-то сделать с ABI и API.

Кто выиграет — очевидно. Не будет особой разницы для библиотек на Си (numpy, tensorflow), программ, тормозящихся вводом-выводом, многопоточного кода. И для неэффективных алгоритмов.

PEP 659: https://www.python.org/dev/peps/pep-0659/
Гитхаб: https://github.com/faster-cpython/

>>> Презентация

★★★★★

Проверено: Shaman007 ()
Последнее исправление: commagray (всего исправлений: 3)
Ответ на: комментарий от Reset

это точно. Страшно подумать, что за нагрузка на процессор будет в таком случае

anonymous
()
Ответ на: комментарий от Reset

Чтобы помочь питону его надо минимум в 10 раз ускорять.

Увы, но это на данный момент единственный интерпретируемый язык, который можно без особой боли использовать.

IPR ★★★★★
()
Ответ на: комментарий от IPR

Скорее, дело не в языке, а в «сахаре» и «включенных батарейках». И то и другое - наркотики. :)

dataman ★★★★★
()
Ответ на: комментарий от Reset

Это было бы правдой, если бы от питона требовалась скорость.

evgeny_aa ★★☆
()
Ответ на: комментарий от th3m3

Помочь занять первенство, скорее всего.

anonymous
()
Ответ на: комментарий от anonymous

звучит как оправдание использования php вместо остальных яп

Джаваскриптом тебе по губам.

IPR ★★★★★
()
Ответ на: комментарий от IPR

а зачем нужна интерпретируемость?

ну и руби так-то поинтереснее будет, но там сильно меньше либ. Даже свой быстрый компилятор есть - mruby.

Ford_Focus ★★★★★
()
Последнее исправление: Ford_Focus (всего исправлений: 1)
Ответ на: комментарий от IPR

Увы, но это на данный момент единственный интерпретируемый язык, который можно без особой боли использовать.

О как. А я-то думал это Lua и фабрисовский QuickJS.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

О как. А я-то думал это Lua и фабрисовский QuickJS.

Неправильно думал. Луа на говно больше похоже, нежели на ЯП.

IPR ★★★★★
()
Ответ на: комментарий от IPR

а как интерпретируемость ускоряет прототипирование?

питон, конечно, нашёл свою нишу в клепании прототипов из говна и палок большого количества готовых решений, но причём тут интерпритируемость?

время компиляции? у голанга, например, оно минимально. да и у шарпа в debug-режиме тоже.

Ford_Focus ★★★★★
()
Ответ на: комментарий от IPR

Неправильно думал. Луа на говно больше похоже, нежели на ЯП.

Боюсь даже предположить на что тогда похож питон.

Stanson ★★★★★
()
Ответ на: комментарий от IPR

луа ближе к bash скрипту, чем к ЯП.

anonymous
()
Ответ на: комментарий от Ford_Focus

время компиляции? у голанга, например, оно минимально. да и у шарпа в debug-режиме тоже.

Ну так конпеляй, я ж не против ¯_(ツ)_/¯

IPR ★★★★★
()
Ответ на: комментарий от Stanson

Боюсь даже предположить на что тогда похож питон.

Там только за комментарии – нужно гнать ссаными тряпками из почётного списка ЯП.

IPR ★★★★★
()
Ответ на: комментарий от IPR

SQL наверно тоже на говно похож. Там комментарии такие же.

То ли дело пистон! Это же признак качества - собезьянничать комменты из unix shell / perl’а.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

SQL наверно тоже на говно похож. Там комментарии такие же.

SQL не совсем ЯП.

То ли дело пистон! Это же признак качества - собезьянничать комменты из unix shell / perl’а.

Ну да, ну да, гораздо логичнее выдумать свою фигню. Неудобная, говёная, зато своя!

// Можно комментарии пилить типа xxxПыщ-ПыщxxxОлоло. Тогда вообще оригинально будет.

IPR ★★★★★
()
Ответ на: комментарий от IPR

lua

Просто для питона дофига либ. Выше вон другой аноним про lua говорит - он проще питона, по мощности не уступает (но всё надо самому писать), по скорости сильно превосходит, даже если многократно вызываемые функции в низкоуровневые .c модули не загонять.

anonymous
()
Ответ на: lua от anonymous

По скорости он кроет питон как бык корову. Во много раз. Он проще. Разумеется есть и недостатки. Самый главный - он откровенно рассчитан на плотную интеграцию с С, тогда его преимущества максимальны, а питономакаки не для того питоном балуются чтобы С учить.

anonymous
()
Ответ на: комментарий от anonymous

Самый главный недостаток lua это индексация с 1. Столько с этим неинтуитивных ошибок возникало, вы себе таки не представляете

anonymous
()
Ответ на: lua от anonymous

всё надо самому писать

Недавно обсуждали статью, что из-за этого Лисп сошёл. Для любой задачи там найдётся до десятка библиотек, покрывающих около 90% функционала. И чем дописывать их, проще написать с нуля для себя ещё одну полусырую. Потому что всё просто. В итоге все мигрировали на более сложные языки, где библиотеки были на 100%.

question4 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Проблема такого рода не в ЯП. Проблема в ДНК программиста. Не ту профессию выбрал.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.