Я изначально сказал, что не буду писать статьи в этом году, но этот редактор намного проще в использовании, чем Zhihu! Формула тоже отличная! Я не хочу больше писать Zhihu в будущем.Будет ли кто-нибудь читать меня здесь, чтобы писать о квантовых вычислениях? ! Такой ароматный! Хотите добавить куриную ножку своим программистам, которые пишут редакторы! ок, вернемся к теме
Этот вопрос задают многие люди.
Мне всегда казалось, что я себя не понимаю. Это все codegen.Почему Джулия работает быстро?Джулия может использовать LLVM, а Python может использовать и другие вещи? Чем хороша Юля? Недавно из-за 1.0 я обсуждал это с некоторыми людьми (такими как Honghong), а затем погуглил.Большая часть контента в этой статье основана на тех мнениях, которые я слышал и видел.
Потом меня тоже поправили: Джулия годится только для научных вычислений. Выслушав эти мнения, я думаю, что если Юля хорошо поработает над экологией, это может привлечь разработчиков с техническими способностями на этом этапе, чтобы опробовать много хороших вещей.
Из первой статьи Юлии
Вернемся к первой статье Юлии (я лишь примерно перевела часть, если интересно, читайте исходный текст):
В начале статьи видно, что то, что пытались решить в начале Джефф Безансон, Стефан Карпински, Вирал Б. Шах, Алан Эдельман, было общей проблемой двуязычия, а двуязычные проблемы часто проявлялись в простоте использования (Удобство ) и компромисс производительности (производительности), программисты используют простые в использовании динамические языки, когда им нужно описать высокоуровневую и сложную логику алгоритмов, и часто используют C и Fortran в чувствительных к производительности местах. Этот подход хорошо работает для некоторых приложений, но он также имеет недостатки. При написании некоторого параллельного кода сложность алгоритма станет очень большой. Написание векторизованного кода, с другой стороны, очень неестественно для многих задач и может создавать промежуточные переменные, которых можно избежать с помощью явного цикла for.
Написание кода на обоих языках может быть более сложным, чем написание кода на любом из языков из-за необходимости учитывать преобразования типов и управление памятью между двумя языками. Если интерфейс между двумя уровнями кода не обрабатывается должным образом, это может значительно увеличить сложность оптимизации.
Другое решение — повысить производительность наших существующих динамических языков, таких как Python. Такие проекты, как PyPy, на самом деле оказались очень успешными [1]. Эти существующие проекты являются попытками оптимизировать существующий язык, что очень полезно, поскольку существующий код может принести непосредственную пользу. Но ни одно из этих решений не может по-настоящему решить проблему двуязычия.Решения по проектированию языка, предполагающие наличие языка-интерпретатора, подрывают его способность генерировать эффективный код.. Как заметил Генри Бейкер на Common Lisp:
...the polymorphic type complexity of the Common LISP library functions is mostly gratuitous, and both the efficiency of compiled code and the efficiency of the programmer could be increased by rationalizing this complexity. [2][3][4]
В начале разработки Джулия обдумывала, как использовать современные технологии для эффективного ускорения динамических языков. По результатам Джулия обеспечивает интерактивное программирование и динамизм Python, Lisp, Ruby, а также производительность статически скомпилированных языков.
Производительность Юлии в основном достигается этими тремя характеристиками:
- Достаточная информация о типе, полученная естественным образом за счет многократной отправки
- Агрессивная специализация кода для динамических типов (например, шаблон C++, примечание)
- Компиляция с помощью JIT LLVM
На самом деле, здесь мы увидели, что скорость Джулии заключается не просто в генерации LLVM, а в дизайне самого языка.
В прошлых попытках оптимизировать динамические языки исследователи заметили, что программы на самом деле могут быть не такими динамичными, как представляли себе программисты [5].
We found that dynamic features are pervasive throughout the benchmarks and the libraries they include, but that most uses of these features are highly constrained...
С этой точки зрения существующий дизайн языка программирования может не найти хорошего баланса. Существует много кода, который на самом деле может быть статически типизирован и выполнен более эффективно. Но это невозможно из-за конструкции самого языка. Мы предполагаем, что следующая «динамика» более полезна:
- Возможность запуска кода во время загрузки и компиляции, что может упростить сборку систем и файлов конфигурации.
- Сделать общий тип Any единственным истинным статическим типом, что позволяет игнорировать статические типы при необходимости.
- Не отвергайте хорошо сформированный код
- Поведение программы определяется только типом среды выполнения (например, отсутствие статической перегрузки)
Джулия, с другой стороны, отказывается от некоторых функций, мешающих оптимизации (таких как CLOS [6]), со следующими ограничениями:
- Сами типы неизменяемы
- Тип значения неизменен в течение всего времени его жизни.
- Окружение локальных переменных не овеществлено
- Программный код неизменяем (обратите внимание, но новый код может быть сгенерирован и выполнен, что, вероятно, отражается в мире макросов)
- Не все привязки изменяемы (позволяет определять константы)
Эти ограничения позволяют компилятору видеть все определенные локальные переменные, а затем анализировать их только на основе локальной информации.
Статью полностью переводить не буду, поэтому Штефан подытожил в рассылке.Выступление Юлии в основном подводят следующие моменты:
- an expressive parametric type system, allowing optional type annotation
- multiple dispatch using type annotations to select implementations
- dataflow type inference, allowing most expressions to be concretely typed
- careful design of the language and standard library to allow analysis
- aggressive code specialization on run-time types
- just-in-time compilation (using LLVM).
Видно, что система типов параметров и множественная диспетчеризация как особенности самого языка (которые даже напрямую влияют на дизайн кода Julia при его написании) очень важны.
В то же время Стефан также прокомментировал:
LLVM великолепен, но это не волшебство. Его использование не делает реализацию языка автоматически быстрой. Что дает LLVM, так это свобода от создания собственного нативного кода, а также ряд стандартных низкоуровневых оптимизаций. Вам все равно нужно генерировать хорошие Код LLVM Виртуальная машина LLVM — это типизированная регистровая машина с бесконечным числом однократно записываемых регистров — с ней проще работать, чем с реальным машинным кодом, но не так далеко (в этом и вся суть).
На самом деле, мы видим, что очень поверхностно говорить, что codegen сейчас прогнил. И заявление о том, что у Джулии нет инноваций, это просто смесь C++, R и Python, тоже (неописуемо).
Подводя итог, Julia на самом деле является результатом некоторых ограничений некоторых исходных динамических языков и пытается найти лучший баланс. Говорить, что он наследует простоту Python, неправильно, также неправильно говорить, что он наследует R, а Julia не наследует C++. Что Джулия хочет выразить, так это то,Мы могли бы пожертвовать менее важной динамикой в обмен на очень впечатляющую скорость.
Что касается того, является ли этот баланс оптимальным, то благожелательный видит благожелательный, а мудрый видит мудрость.
некоторые попытки
На самом деле, есть некоторые попытки бросить вызов C/Fortran:
Чистая реализация Julia для BLAS:
дискурс.удаленность от alang.org/he/major-miserable-десять тысяч человек…
Чистая реализация Джулии HDF5:
JSON, реализованный на чистом Julia (по красной оценке, это он умеет лучше):
С этой точки зрения мое понимание было не верным раньше, помимо более однородных многомерных массивов (это очень важно для физиков, а то не многие до сих пор пользуются Фортраном), возможно у нас могут быть и более обширные приложения, которыми не ограничиваются для научных вычислений и машинного обучения, но больше мест, где в прошлом требовалось решать двуязычные проблемы.
Но, напротив, проблемы, которые можно было решить на одном языке в прошлом, могут быть непростыми в использовании с таким большим убийцей. Думаю, этого, наверное, достаточно, чтобы объективно описать Юлю, а также можно понять, для каких сценариев она подходит, а для каких не подходит.
Наконец, я лично считаю, что Джулия в настоящее время не подходит для Сяобая. Не для тех, кто ищет работу. Но он больше подходит для тех, кого в прошлом мучило двуязычие.
[1]: К. Ф. Больц, А. Куни, М. Фиялковски и А. Риго, Трассировка метауровня: JIT-компилятор трассировки Pypy, Материалы 4-го семинара по реализации, компиляции, оптимизации объектно-ориентированных языков и системы программирования, ICOOOLPS '09, страницы 18–25, Нью-Йорк, штат Нью-Йорк, США, 2009 г. ACM.
[2]: H. G. Baker. The nimble type inferencer for common lisp-84. Technical report, Tech. Rept., Nimble Comp, 1990.
[3]: Брукс Р. А. и Габриэль Р. П. Критика общего шепелявости, В материалах симпозиума ACM 1984 г. по LISP и функциональному программированию, LFP ’84, страницы 1–8, Нью-Йорк, США, 1984. ACM.
[4]: Морандат Ф., Хилл Б., Освальд Л. и Витек Дж. Оценка дизайна языка R. В Дж. Нобл, редактор, ECOOP 2012 Object-Oriented Programming, Volume 7313 of Lecture Notes in Computer. Наука, стр. 104–131, Springer Berlin/Heidelberg, 2012.
[5]: Ферр М., Ан Дж.-Х.Д., Фостер Дж. С. Статическая типизация с учетом профиля для динамических языков сценариев, SIGPLAN Not., 44:283–300, октябрь 2009 г.
[6]: Х. Г. Бейкер, Клострофобия: ее этиология и лечение, SIGPLAN OOPS Mess., 2(4): 4–15, октябрь 1991 г.