Насчёт ML хочу заметить, что тут как раз всё очень хорошо оптимизировано и написано на достаточно низкоуровневых языках. Питон - просто удобный интерфейс.
Согласно Википедии, PyTorch является интерфейсом библиотеки Torch, которая написана на Lua, LuaJIT, C, C++ и CUDA.
Возможно, существуют более подходящие примеры для использования статически типизированного Питона.
Единственное оправдание, которое я могу придумать, насчёт неиспользования Go, это, пожалуй, его незнание)
Язык модный, стильный, молодёжный. Правда, в академической среде его пока не так активно преподают. Постараюсь выучить самостоятельно.
Насчёт полной компиляции Питона - вопрос спорный. Питон во многом популярен из-за интерпретации и динамической компиляции, свобода действий над кодом во многом отличает его от компилируемых языков. Если есть желание скомпилировать Питон, то я вижу три варианта, и все не очень:
Компилировать виртуальную машину Питона целиком с конкретной программой (таким занимается библиотека pyinstaller) (это не выглядит очень эффективно)
Сделать компилируемую версию Питона с поддержкой динамической типизации (сомневаюсь, что такие вещи просто пишутся)
Отобрать у пользователя все динамические возможности Питона и сделать более эффективную реализацию на этих ограничениях (но тогда чем Питон будет лучше других компилируемых языков, таких как C/C++ или golang)
Может быть, я просто что-то неправильно воспроизвёл. Но всё что я сделал, это поменял интерпретатор на PyPy и выполнил прогоны с теми начальными данными, записав результат в файл.
По небольшому опыту написания контестов, где предлагают на выбор Питон или PyPy, скажу, что зачастую PyPy может проигрывать Питону по памяти, а иногда и по времени. Наверное, это зависит от конкретной задачи.
Я помучился с установкой PyPy (matplotlib не установился из-за Pillow, который не смог найти zlib, о чём я и писал в статье, но считать было можно) и вот что получил. Никакой значимой оптимизации PyPy не дал, поэтому я не хочу перегружать графики повторяющейся с Питоном линией.
Я поправил текст статьи, под другими языками подразумевались только C++ и Java. Rust я не хотел обижать.
Про то, что все примитивы в Питоне обернуты в объект я попытался сказать в статье, но может недостаточно явно. Согласен, что это тоже замедляет работу Питона.
Проверки входных типов тоже не были реализованы, и их наличие упростило бы потенциальную отладку.
Отладка стороннего модуля на другом языке - дело занятное :)
У меня был опыт работы с PyQt, где любая ошибка внутри самого Qt просто приводила к аварийному завершению программы без выяснения причин. Дебаг внутрь исходников не входил. Так что это проблема более глобальная, чем jit-компиляторы.
Согласен, что применимость jit-компиляции ограничена. Из моего исследования стало ясно, что она хорошо себя показывает на алгоритмах с глубоким перебором и вложенными циклами и на разветвлённой рекурсии. В остальных случаях применение под вопросом.
Для проверки эффективности на реальной программе проекту явно не хватает функционала, но аналогичные замеры можно провести, используя @numba.jit(nopython=False)
Мне кажется, по ссылке находится статический компилятор. Там используется другой подход - Ahead of time, который конкурирует с Just in time. Так как оба эти подхода до сих пор существуют, выделить однозначного лидера не получается.
Автоувеличение, или длинная арифметика, действительно не были реализованы, но программисты на C++, как правило, обходятся без неё. Обычно тип данных определяется задачей. Например, число дней в году рациональнее было бы кодировать типом short. Чтобы не происходило переполнения типов, необходимо правильно выбрать тип на этапе проектирования.
C++ я выбрал с заделом на будущее, так как там присутствует готовое понятие класса. Также там реализованы некоторые коллекции - прямые аналоги коллекций Питона. Конкретно в моей реализации до их использования не дошло, но в большом проекте выбор C привёл бы к тех. долгу и реализации этих фичей (классы, коллекции) вручную.
Учитывая GIL в стандартной реализации Питона, перевод асинхронности в настоящую был бы очень уместен. Однако, готовых решений по реализации многопоточности с интерфейсом как в Питоне, насколько я знаю, в C++ нет. Async присутствует в стандарте C++20, но я не уверен, что это то, что нужно.
Любое сишное расширение может быть интегрировано в jit-компилятор, если имеет прямой аналог в Питоне, например, модуль cmath. В более сложных случаях поддержка модулей заключается в ручном переводе в сишные эквиваленты. Именно поэтому даже такие большие проекты, как RPython и PyPy не поддерживают всего разнообразия пакетов. Если в библиотеках встречаются вставки на других ЯП, то всё опять же усложняется, так как придётся делать целую цепочку вызовов динамических библиотек.
С оптимизацией библиотеки и так неплохо справляются, когда включают в себя модули на более производительных языках. Например Numpy содержит код на Фортране, потому что так быстрее. Ускорять Numpy с помощью jit не представляется необходимым.
В моём решении не реализовано преобразование объектов и структур данных, а без этого реализовывать многопоточность было бы проблематично. Заниматься преобразованием прикладных библиотек, таких как asyncpg, имеющих свойство менять API при каждой новой значительной версии, можно заниматься на свой страх и риск никогда не закончить.
Спасибо. На самом деле, это примерное время разработки. У студентов рабочий день не нормированный, поэтому я руководствовался при подсчёте датами своих коммитов. Для предмета на зачёт больше времени не нашлось)
Насчёт ML хочу заметить, что тут как раз всё очень хорошо оптимизировано и написано на достаточно низкоуровневых языках. Питон - просто удобный интерфейс.
Согласно Википедии, PyTorch является интерфейсом библиотеки Torch, которая написана на Lua, LuaJIT, C, C++ и CUDA.
Возможно, существуют более подходящие примеры для использования статически типизированного Питона.
Единственное оправдание, которое я могу придумать, насчёт неиспользования Go, это, пожалуй, его незнание)
Язык модный, стильный, молодёжный. Правда, в академической среде его пока не так активно преподают. Постараюсь выучить самостоятельно.
Насчёт полной компиляции Питона - вопрос спорный. Питон во многом популярен из-за интерпретации и динамической компиляции, свобода действий над кодом во многом отличает его от компилируемых языков. Если есть желание скомпилировать Питон, то я вижу три варианта, и все не очень:
Компилировать виртуальную машину Питона целиком с конкретной программой (таким занимается библиотека pyinstaller) (это не выглядит очень эффективно)
Сделать компилируемую версию Питона с поддержкой динамической типизации (сомневаюсь, что такие вещи просто пишутся)
Отобрать у пользователя все динамические возможности Питона и сделать более эффективную реализацию на этих ограничениях (но тогда чем Питон будет лучше других компилируемых языков, таких как C/C++ или golang)
Вы были правы, что PyPy ускоряет вычисления. Я добавил его рассмотрение в раздел с графиками. Теперь статья будет иметь большую ценность.
Стоило запустить код вне Jupyter-блокнота, как PyPy стал работать быстрее. Однако, на числах Фибоначчи он меня так и не перегнал.
Может быть, я просто что-то неправильно воспроизвёл. Но всё что я сделал, это поменял интерпретатор на PyPy и выполнил прогоны с теми начальными данными, записав результат в файл.
По небольшому опыту написания контестов, где предлагают на выбор Питон или PyPy, скажу, что зачастую PyPy может проигрывать Питону по памяти, а иногда и по времени. Наверное, это зависит от конкретной задачи.
Я помучился с установкой PyPy (matplotlib не установился из-за Pillow, который не смог найти zlib, о чём я и писал в статье, но считать было можно) и вот что получил. Никакой значимой оптимизации PyPy не дал, поэтому я не хочу перегружать графики повторяющейся с Питоном линией.
Тогда простите, неправильно вас понял)
Я поправил текст статьи, под другими языками подразумевались только C++ и Java. Rust я не хотел обижать.
Про то, что все примитивы в Питоне обернуты в объект я попытался сказать в статье, но может недостаточно явно. Согласен, что это тоже замедляет работу Питона.
Проверки входных типов тоже не были реализованы, и их наличие упростило бы потенциальную отладку.
Отладка стороннего модуля на другом языке - дело занятное :)
У меня был опыт работы с PyQt, где любая ошибка внутри самого Qt просто приводила к аварийному завершению программы без выяснения причин. Дебаг внутрь исходников не входил. Так что это проблема более глобальная, чем jit-компиляторы.
Функция print после каждой строчки в помощь
Согласен, что применимость jit-компиляции ограничена. Из моего исследования стало ясно, что она хорошо себя показывает на алгоритмах с глубоким перебором и вложенными циклами и на разветвлённой рекурсии. В остальных случаях применение под вопросом.
Для проверки эффективности на реальной программе проекту явно не хватает функционала, но аналогичные замеры можно провести, используя @numba.jit(nopython=False)
Мне кажется, по ссылке находится статический компилятор. Там используется другой подход - Ahead of time, который конкурирует с Just in time. Так как оба эти подхода до сих пор существуют, выделить однозначного лидера не получается.
Автоувеличение, или длинная арифметика, действительно не были реализованы, но программисты на C++, как правило, обходятся без неё. Обычно тип данных определяется задачей. Например, число дней в году рациональнее было бы кодировать типом short. Чтобы не происходило переполнения типов, необходимо правильно выбрать тип на этапе проектирования.
C++ я выбрал с заделом на будущее, так как там присутствует готовое понятие класса. Также там реализованы некоторые коллекции - прямые аналоги коллекций Питона. Конкретно в моей реализации до их использования не дошло, но в большом проекте выбор C привёл бы к тех. долгу и реализации этих фичей (классы, коллекции) вручную.
Учитывая GIL в стандартной реализации Питона, перевод асинхронности в настоящую был бы очень уместен. Однако, готовых решений по реализации многопоточности с интерфейсом как в Питоне, насколько я знаю, в C++ нет. Async присутствует в стандарте C++20, но я не уверен, что это то, что нужно.
Любое сишное расширение может быть интегрировано в jit-компилятор, если имеет прямой аналог в Питоне, например, модуль cmath. В более сложных случаях поддержка модулей заключается в ручном переводе в сишные эквиваленты. Именно поэтому даже такие большие проекты, как RPython и PyPy не поддерживают всего разнообразия пакетов. Если в библиотеках встречаются вставки на других ЯП, то всё опять же усложняется, так как придётся делать целую цепочку вызовов динамических библиотек.
С оптимизацией библиотеки и так неплохо справляются, когда включают в себя модули на более производительных языках. Например Numpy содержит код на Фортране, потому что так быстрее. Ускорять Numpy с помощью jit не представляется необходимым.
В моём решении не реализовано преобразование объектов и структур данных, а без этого реализовывать многопоточность было бы проблематично. Заниматься преобразованием прикладных библиотек, таких как asyncpg, имеющих свойство менять API при каждой новой значительной версии, можно заниматься на свой страх и риск никогда не закончить.
Спасибо. На самом деле, это примерное время разработки. У студентов рабочий день не нормированный, поэтому я руководствовался при подсчёте датами своих коммитов. Для предмета на зачёт больше времени не нашлось)