Почему Моджо — читаем объяснения разработчиков.

Пламенный привет посетителям этой страницы, пришедшим из социальных сетей, да и всем остальным тоже!

В апреле 2021-го года наблюдал удивительное явление: обильный поток посетителей из 4-х социальных сетей. В связи с этим настоятельно рекомендую всем неоднократно и регулярно посещать сайт rtbsm.ru — там в общих чертах изложена Российская Теннисная Балльная Система Марии (Шараповой).

Приглашаю всех полюбоваться на Фото и Видео красавицы Марии — надеюсь, что Вы поделитесь адресом сайта rtbsm.ru с друзьями и знакомыми.

Главная проблема — известить Марию, чтобы она лично как можно скорее заявила на весь мир о РТБСМ.

Почему Моджо — ниже представлен весьма длинный текст с подробными объяснениями разработчиков, позволяющий многое понять о создании и развитии Моджо.

Привожу информацию со страницы https://docs.modular.com/mojo/why-mojo :

Почему Моджо

Когда мы запускали Modular, у нас не было намерения создавать новый язык программирования. Но когда мы создавали нашу платформу для унификации мировой инфраструктуры ML/AI , мы поняли, что программирование всего стека слишком сложно. Плюс мы писали много MLIR от руки и не очень хорошо проводили время.

Нам нужна была инновационная и масштабируемая модель программирования, которая могла бы быть ориентирована на ускорители и другие гетерогенные системы, широко распространенные в области искусственного интеллекта.

Это означало язык программирования с мощным мета-программированием во время компиляции, интеграцией методов адаптивной компиляции, кэшированием на протяжении всего процесса компиляции и другими функциями, которые не поддерживаются существующими языками.

И хотя ускорители важны, одним из наиболее распространенных и иногда упускаемых из виду «ускорителей» является центральный процессор. В настоящее время процессоры имеют множество блоков ускорителей, подобных тензорным ядрам, и других блоков ускорения искусственного интеллекта, но они также служат «запасным вариантом» для операций, которые не обрабатываются специализированными ускорителями, таких как загрузка данных, предварительная и постобработка и т. д. и интеграция с зарубежными системами. Итак, стало ясно, что мы не сможем поднять ИИ только с помощью «языка-ускорителя», который работает только с определенными процессорами.

Прикладные системы искусственного интеллекта должны решать все эти проблемы, и мы решили, что нет причин, по которым это нельзя было бы сделать с помощью всего лишь одного языка. Так родился Моджо.

Язык для технологии

Когда мы поняли, что ни один существующий язык не может решить проблемы вычислений ИИ, мы приступили к переосмыслению основных принципов того, как следует проектировать и реализовывать язык программирования для решения наших проблем.

Поскольку нам требуется высокопроизводительная поддержка широкого спектра ускорителей, традиционные технологии компилятора, такие как LLVM и GCC, не подходят (и любые языки и инструменты на их основе не подходят). Хотя они поддерживают широкий спектр процессоров и некоторые часто используемые графические процессоры, эти технологии компилятора были разработаны десятилетия назад и не могут полностью поддерживать современные архитектуры чипов.

В настоящее время стандартной технологией для специализированных ускорителей машинного обучения является MLIR.

MLIR — это относительно новая инфраструктура компиляторов с открытым исходным кодом, созданная в Google (чьи руководители перешли на Modular), которая получила широкое распространение в сообществе ускорителей машинного обучения.

Сильной стороной MLIR является его способность создавать компиляторы для конкретной предметной области, особенно для странных областей, которые не являются традиционными процессорами и графическими процессорами, таких как AI ASICS, системы квантовых вычислений , FPGA и специальные микросхемы .

Учитывая наши цели в Modular по созданию платформы искусственного интеллекта следующего поколения, мы уже использовали MLIR для некоторой части нашей инфраструктуры, но у нас не было языка программирования, который мог бы раскрыть весь потенциал MLIR в нашем стеке. Хотя многие другие проекты теперь используют MLIR, Mojo — это первый основной язык, разработанный специально для MLIR , что делает Mojo уникально эффективным при написании кода системного уровня для рабочих нагрузок ИИ.

Член семейства

Наша основная миссия Mojo включает инновации во внутреннем устройстве компиляторов и поддержку существующих и новых ускорителей, но мы не видим необходимости в инновациях в синтаксисе языка или сообществе . Поэтому мы решили использовать экосистему Python, потому что она широко используется, ее любит экосистема искусственного интеллекта и потому что мы считаем, что это действительно хороший язык.

У языка Mojo высокие цели: мы хотим полной совместимости с экосистемой Python, нам нужна предсказуемая низкоуровневая производительность и низкоуровневый контроль, и нам нужна возможность развертывать подмножества кода в ускорителях. Кроме того, мы не хотим создавать фрагментированную экосистему программного обеспечения — мы не хотим, чтобы пользователи Python, которые используют Mojo, сравнивали их с болезненным переходом с Python 2 на Python 3. Это немалые цели!

К счастью, хотя Mojo — это совершенно новая кодовая база, концептуально мы не начинаем с нуля. Использование Python значительно упрощает наши усилия по проектированию, поскольку большая часть синтаксиса уже определена. Вместо этого мы можем сосредоточить наши усилия на создании модели компиляции Mojo и функций системного программирования. Мы также извлекаем пользу из огромных уроков, извлеченных из других языков (таких как Rust, Swift, Julia, Zig, Nim и т. д.), из нашего предыдущего опыта миграции разработчиков на новые компиляторы и языки, а также используем существующую экосистему компиляторов MLIR.

Кроме того, мы решили, что правильная долгосрочная цель Mojo — предоставить расширенный набор Python (то есть сделать Mojo совместимым с существующими программами Python) и использовать реализацию CPython для поддержки экосистемы с длинным хвостом. Если вы программист Python, мы надеемся, что Mojo вам сразу знаком, а также предоставит новые инструменты для разработки безопасного и производительного кода системного уровня, для которого в противном случае потребовались бы C и C++ ниже Python.

Мы не пытаемся убедить мир, что «статика лучше» или «динамика лучше». Скорее, мы считаем, что оба хороши, когда используются в правильных приложениях, поэтому мы разработали Mojo, чтобы позволить вам, программисту, решать, когда использовать статический или динамический.

Почему мы выбрали Python

Python является доминирующей силой в машинном обучении и бесчисленном множестве других областей. Его легко освоить, он известен важным группам программистов, имеет замечательное сообщество, множество ценных пакетов и широкий выбор хороших инструментов. Python поддерживает разработку красивых и выразительных API-интерфейсов благодаря своим функциям динамического программирования, что привело к тому, что такие платформы машинного обучения, как TensorFlow и PyTorch, стали использовать Python в качестве интерфейса для своих высокопроизводительных сред выполнения, реализованных на C++.

Сегодня для Modular Python является неотъемлемой частью нашего поверхностного стека API — это диктуется нашими клиентами. Учитывая, что все остальное в нашем стеке является предметом переговоров, само собой разумеется, что мы должны начать с подхода «сначала Python».

Если говорить более субъективно, мы считаем, что Python — красивый язык. Он разработан с использованием простых и компонуемых абстракций, избегает ненужной пунктуации, которая на практике является избыточной при отступах, и оснащен мощными (динамическими) функциями мета-программирования. Все это даёт нам возможность расширить язык до того, что нам нужно в Modular. Мы надеемся, что люди в экосистеме Python увидят, что наше направление развития Mojo заключается в том, чтобы вывести Python на новый уровень — завершить его — вместо того, чтобы конкурировать с ним.

Совместимость с Питоном

Мы планируем обеспечить полную совместимость с экосистемой Python, но на самом деле существует два типа совместимости, поэтому мы сейчас придерживаемся обоих типов:

• Что касается вашей возможности импортировать существующие модули Python и использовать их в программе Mojo, Mojo на 100% совместим, поскольку мы используем CPython для обеспечения совместимости.
• Что касается возможности переноса любого кода Python в Mojo, он пока не полностью совместим. Mojo уже поддерживает многие основные функции Python, включая асинхронность/ожидание, обработку ошибок, вариативность и т. д. Однако Mojo еще молод, и ему не хватает многих других функций Python. Mojo пока даже не поддерживает классы!

Предстоит проделать много работы, но мы уверены, что доберемся до цели, и руководствуемся опытом нашей команды в создании других крупных технологий с их собственными путями обеспечения совместимости:

• Путь к компилятору Clang (компилятору для C, C++, Objective-C, CUDA, OpenCL и других), который является «совместимой заменой» GCC, MSVC и других существующих компиляторов. Трудно провести прямое сравнение, но сложность проблемы Clang оказывается на порядок выше, чем реализация совместимой замены Python.
• Путь к языку программирования Swift , который охватывал среду выполнения Objective-C и языковую экосистему и постепенно перенес миллионы программистов (и огромные объемы кода). Благодаря Swift мы усвоили уроки о том, как быть «совместимыми во время выполнения» и взаимодействовать с устаревшей средой выполнения.

В ситуациях, когда вы хотите смешать код Python и Mojo, мы ожидаем, что Mojo будет напрямую взаимодействовать со средой выполнения CPython и иметь аналогичную поддержку интеграции с классами и объектами CPython без необходимости компиляции самого кода. Это обеспечивает совместимость подключаемых модулей с обширной экосистемой существующего кода и позволяет использовать подход постепенной миграции, при котором постепенный переход на Mojo дает дополнительные преимущества.

В целом мы считаем, что, сосредоточив внимание на разработке языка и постепенно продвигаясь к полной совместимости с Python, мы вовремя добьемся того, чего нам нужно.

Однако важно понимать, что когда вы пишете чистый код Mojo, в реализации, компиляции или среде выполнения нет ничего, что использовало бы существующие технологии Python. Сам по себе это совершенно новый язык с совершенно новой системой компиляции и выполнения.

Преднамеренные отличия от Python

Хотя совместимость и возможность миграции Python являются ключом к успеху Mojo, мы также хотим, чтобы Mojo был первоклассным языком (это означает, что это автономный язык, а не зависящий от другого языка). Его возможности по вводу новых ключевых слов или грамматических формулировок не должны быть ограничены только для обеспечения совместимости. Таким образом, наш подход к совместимости двоякий:

1. Мы используем CPython для запуска всего существующего кода Python 3 без изменений и используем его среду выполнения без изменений для полной совместимости со всей экосистемой. Выполнение кода таким способом не дает никаких преимуществ от Mojo, но само существование и доступность этой экосистемы быстро ускорит появление Mojo и воспользуется тем фактом, что Python уже действительно отлично подходит для программирования высокого уровня.
2. Мы предоставим инструмент механической миграции, который обеспечит очень хорошую совместимость для людей, желающих перенести код с Python на Mojo. Например, чтобы избежать ошибок миграции с кодом Python, который использует имена идентификаторов, соответствующие ключевым словам Mojo, Mojo предоставляет функцию обратной апострофы, которая позволяет любому ключевому слову вести себя как идентификатор.

В совокупности это позволяет Mojo хорошо интегрироваться в мир, в котором преобладает CPython, но позволяет программистам Mojo постепенно перемещать код (модуль или файл за раз) в Mojo. Это проверенный подход при переходе с Objective-C на Swift, реализованный Apple.

Потребуется некоторое время, чтобы создать остальную часть Mojo и поддержку миграции, но мы уверены, что эта стратегия позволит нам сосредоточить наши силы и не отвлекаться. Мы также считаем, что отношения с CPython могут строиться в обоих направлениях — разве не было бы здорово, если бы команда CPython в конечном итоге переопределила интерпретатор в Mojo вместо C?

Проблемы Python

Стремясь сделать Mojo расширенной версией Python, мы считаем, что сможем решить многие существующие проблемы Python.

У Python есть некоторые хорошо известные проблемы — наиболее очевидные из них — низкая производительность на низком уровне и детали реализации CPython, такие как глобальная блокировка интерпретатора (GIL), которая делает Python однопоточным. Несмотря на то, что существует множество активных проектов по решению этих проблем, проблемы, возникающие при использовании Python, гораздо глубже и особенно эффективны в области искусственного интеллекта. Вместо того, чтобы подробно говорить об этих технических ограничениях, мы поговорим об их последствиях здесь, в 2023 году .

Обратите внимание: везде, где мы ссылаемся на Python в этом разделе, имеется в виду реализация CPython. О других реализациях мы поговорим позже.

Проблема двух миров

По ряду причин Python не подходит для системного программирования. К счастью, Python обладает удивительными преимуществами в качестве связующего слоя, а низкоуровневые привязки к C и C++ позволяют создавать библиотеки на C, C++ и многих других языках с лучшими характеристиками производительности. Именно это позволило реализовать в экосистеме такие вещи, как NumPy, TensorFlow, PyTorch и огромное количество других библиотек.

К сожалению, хотя этот подход является эффективным способом создания высокопроизводительных библиотек Python, он имеет свою цену: создание таких гибридных библиотек очень сложно. Это требует низкоуровневого понимания внутреннего устройства CPython, требует знания программирования на C/C++ (или другом) (подрывая в первую очередь одну из первоначальных целей использования Python), затрудняет разработку больших фреймворков и (в первую очередь) в случае с ML) подталкивает мир к моделям программирования, основанным на графах, которые имеют худшее фундаментальное удобство использования, чем системы «активного режима». И TensorFlow, и PyTorch столкнулись в этом отношении с серьезными проблемами.

Помимо фундаментальной природы того, как проблема двух миров создает сложность системы, она усложняет все остальное в экосистеме. Отладчики обычно не могут работать с кодом Python и C, а те, которые могут, не получили широкого распространения. Прискорбно, что экосистеме пакетов Python приходится иметь дело не только с Python, но и с кодом C/C++. Такие проекты, как PyTorch, со значительными инвестициями в C++, намеренно пытаются перенести большую часть своей кодовой базы на Python, потому что они знают, что это повышает удобство использования.

Проблема трех миров и N-миров

Проблема двух миров обычно ощущается во всей экосистеме Python, но у разработчиков фреймворков машинного обучения дела обстоят еще хуже. Искусственный интеллект повсеместно ускоряется, и эти ускорители используют специальные языки программирования, такие как CUDA. Хотя CUDA является родственником C++, у него есть свои особые проблемы и ограничения, и у него нет согласованных инструментов, таких как отладчики или профилировщики. Он также фактически привязан к одному производителю оборудования.

В мире искусственного интеллекта невероятное количество инноваций в области аппаратного обеспечения, и, как следствие, сложность выходит из-под контроля. Сейчас предпринимается несколько попыток построить ограниченные системы программирования для ускорителей (OpenCL, Sycl, OneAPI и другие). Этот взрыв сложности продолжает нарастать, и ни одна из этих систем не решает фундаментальную фрагментацию инструментов и экосистемы, которая так сильно вредит отрасли — они лишь усиливают фрагментацию .

Развертывание мобильных устройств и серверов

Еще одна проблема для экосистемы Python — развертывание. У этого есть много аспектов, в том числе, как управлять зависимостями, как развертывать герметично скомпилированные файлы «a.out» и как улучшить многопоточность и производительность. Это области, в которых мы хотели бы, чтобы экосистема Python сделала значительные шаги вперед.

Связанная работа

Нам известно о многих других попытках улучшить Python, но они не решают фундаментальную проблему, которую мы стремимся решить с помощью Mojo.

Некоторые постоянные усилия по улучшению Python включают работу по ускорению Python и замене GIL, созданию языков, которые выглядят как Python, но являются его подмножествами, а также по созданию встроенных предметно-ориентированных языков (DSL), которые интегрируются с Python, но не являются первыми. -классовые языки. Хотя мы не можем предоставить исчерпывающий список всех усилий, мы можем рассказать о некоторых проблемах, с которыми сталкиваются эти проекты, и о том, почему они не решают проблемы, которые решает Mojo.

Улучшение CPython и JIT-компиляции Python

В последнее время сообщество потратило значительные усилия на улучшение производительности CPython и решение других вопросов реализации, и это показывает огромные результаты. Эта работа просто фантастическая, поскольку она постепенно улучшает текущую реализацию CPython. Например, Python 3.11 увеличил производительность на 10–60 % по сравнению с Python 3.10 за счет внутренних улучшений, а Python 3.12 стремится пойти дальше благодаря оптимизатору трассировки. Многие другие проекты пытаются приручить GIL, а такие проекты, как PyPy (среди многих других), используют подходы JIT-компиляции и трассировки для ускорения Python.

Хотя мы являемся поклонниками этих великих усилий и чувствуем, что они ценны и интересны для сообщества, они, к сожалению, не удовлетворяют наши потребности в Modular, поскольку не помогают обеспечить единый язык для акселератора. Многие ускорители в наши дни поддерживают очень ограниченные динамические функции или делают это с ужасной производительностью. Более того, системные программисты стремятся не только к «производительности», но они также обычно хотят большей предсказуемости и контроля над тем, как происходят вычисления.

Мы стремимся устранить необходимость использования C или C++ в библиотеках Python, мы стремимся к максимально возможной производительности, а в некоторых случаях мы вообще не можем использовать динамические функции. Поэтому эти подходы не помогают.

Подмножества Python и другие Python-подобные языки

Существует множество попыток создать «развертываемый» Python, например TorchScript из проекта PyTorch. Они полезны, поскольку часто предоставляют решения для развертывания с низким уровнем зависимостей и иногда обладают высокой производительностью. Поскольку они используют синтаксис, подобный Python, их легче изучить, чем новый язык.

С другой стороны, эти языки не получили широкого распространения — поскольку они являются подмножеством Python, они обычно не взаимодействуют с экосистемой Python, не имеют фантастических инструментов (таких как отладчики) и часто неудобны для замены. поведение в Python в одностороннем порядке, что нарушает совместимость и еще больше фрагментирует экосистему. Например, многие из них изменяют поведение простых целых чисел для переноса вместо создания математических вычислений, совместимых с Python.

Проблема с этими подходами заключается в том, что они пытаются решить слабое место Python, но не так хороши в сильных сторонах Python. В лучшем случае они могут стать новой альтернативой C и C++, но без решения динамических вариантов использования Python они не смогут решить «проблему двух миров». Такой подход приводит к фрагментации, а несовместимость делает миграцию трудной или невозможной — вспомните, насколько сложно было перейти с Python 2 на Python 3.

Расширения Python с совместимостью

Поскольку Mojo разработан как надмножество Python с улучшенными возможностями системного программирования, оно разделяет некоторые общие идеи с другими надмножествами Python, такими как Pyrex и Cython . Как и Mojo, эти проекты определяют свой собственный язык, который также поддерживает язык Python. Они позволяют вам писать более производительные расширения для Python, которые взаимодействуют как с библиотеками Python, так и с C.

Эти расширенные наборы Python отлично подходят для некоторых типов приложений, и они с большим успехом применяются в некоторых популярных библиотеках Python. Однако они не решают проблему двух миров Python , и, поскольку они полагаются на CPython в своей основной семантике, они не могут работать без него, тогда как Mojo использует CPython только тогда, когда это необходимо для обеспечения совместимости с существующим кодом Python . Код Pure Mojo не использует какие-либо ранее существовавшие технологии среды выполнения или компилятора, вместо этого он использует инфраструктуру на основе MLIR , обеспечивающую высокопроизводительное выполнение на широком спектре оборудования.

Встроенные DSL в Python

Другой распространенный подход — создание встроенных предметно-ориентированных языков (DSL) в Python, которые обычно устанавливаются с помощью декоратора Python. Примеров этому множество ( @tf.functionдекоратор в TensorFlow, @triton.jitмодель программирования Triton от OpenAI и т. д.). Основным преимуществом этих систем является то, что они поддерживают совместимость с экосистемой инструментов Python и естественным образом интегрируются в логику Python, позволяя встроенному мини-языку сосуществовать с сильными сторонами Python для динамических сценариев использования.

К сожалению, встроенные мини-языки, предоставляемые этими системами, часто имеют неожиданные ограничения, плохо интегрируются с отладчиками и другими инструментами рабочего процесса и не поддерживают тот уровень интеграции родного языка, который мы ищем для языка, который объединяет разнородные вычисления и основной способ написания крупномасштабных ядер и систем.

С помощью Mojo мы надеемся повысить удобство использования всей системы, упростив ее и сделав ее более последовательной. Встроенные DSL — это удобный способ запустить демо-версии, но мы готовы приложить дополнительные усилия и работать над тем, чтобы обеспечить лучшее удобство использования и предсказуемость для нашего сценария использования.

Чтобы узнать о том, что мы уже создали с помощью Mojo, см. Руководство по Mojo - https://docs.modular.com/mojo/manual/

По моему мнению, важно запомнить, что для создания компиляторов MOJO использована MLIR.

!…

Приглашаю всех высказываться в Комментариях. Критику и обмен опытом одобряю и приветствую. В особо хороших комментариях сохраняю ссылку на сайт автора!

И не забывайте, пожалуйста, нажимать на кнопки социальных сетей, которые расположены под текстом каждой страницы сайта.
Продолжение тут…