Комментарии 75
Ладно Питон, но почему C++ медленней?
Судя по всему, за счет мультитрединга и принципов работы с массивами. Незначительно, впрочем. Нагуглил статейку, там графики есть. Насколько можно доверять сайту и автору - не знаю.
https://engiware.com/benchmark/llama2-ports-extensive-benchmarks-mac-m1-max.html
Незначительно, впрочем.
А у автора то отличие в 10 раз получается.
Не совсем понял почему в 10 раз? Если вы про Go vs Mojo/C, то да. Я сам был удивлен что Go очень плох в сугубо вычислительных задачах.
Я что то не то увидел?
Как я полагаю это бенчмарк на алгоритме Mandelbrot причём на CPU Intel Xeon у которого 88 vCPU. Сам не проверял, но думаю что вполне может быть правдой, по причинам описанным в комантах -- меньший оверхед за счёт LLVM/MLIR трансляции, который обеспечивает улучшенную компиляцию под конкретные процессоры. MLIR имеет контекст более высокого уровня поэтому по словам создателей Mojo - это помогает с оптимизацией.
Тоже не понял, как C++ может быть медленнее. Параллелизм и в C++ есть. Да та же numba в питоне может циклы параллелить по ядрам процессора.
Паралелизм паралелизму рознь. Многое зависит от оптимизатора. Проблема с современными C++ компиляторами в том что им приходится поддерживать 100500 различных платформ и архитектур, из за этого код под конкретную архитектуру может оказаться суб-оптимальным. А также с другой стороны general оптимизация компилятором проигрывает более правильно организованному коду высокого уровня. Т.е. грубо говоря если программист явно пишет какой цикл нужно векторизовать и какие нужно использовать параметры для SIMD операций -- код оказывается эфективнее чем оптимизатор будет делать предположения в жадном режиме.
Латтнер на подкасте Фридмана еще рассказывал про «autotuning» https://youtu.be/pdJQ8iVTwj8?t=1264&si=NyMFBGc_-Hd0FPdl, суть в том, что программа самомтоятельно подгоняется (методом перебора) под железо, на котором ее запускают. Чтобы больший КПД на этом сетапе получить
А супер оптимизированные вычислительные библиотеки такие как BLAS -- оказываются что супер раздуты там сотни тысяч строк кода, поддерживать это хозяйство да еще и под разные архитектуры тот еще челендж
? -- автор на связи!
Это бенчмарк от Октября 2023, уже не актуален. Тем не менее на устаревшей версии Mojo бенчмарк показал лучшую производительность Mojo против C на CPU вычислениях Apple Silicon в многопоточном режиме. Почему так? Как я понимаю отчасти потому что gcc/clang компилятор плохо справляется с оптимизацией под современные процессоры, особенно если это general оптимизатор который не знает какая логика/алгоритм исполняется в коде. При этом в Mojo можно задействовать низкоуровневые примитивы прямо из коробки, такие как SIMD.
А более новый бенчмарк (см. рисунок 1 из статьи) вообще показал что код на 1000 строк на Mojo написанный под конкретный алгоритм с помощью SIMD, Vectorze и Unroll сработал на некоторых кейсах быстрее чем супер оптимизированный c++ .
Основные вычисления происходят в matmul, но что примечательно в Mojo не используется никаких ассемблерных вставок.
Ps. На текущий день вышло несколько глобальных обновлений в Mojo которые ломают обратную совместимость, но интересно было бы сделать бенчмарк на последних версиях.. Возможно найду время и займусь этим в ближайшие дни..
На данный момент Mojo поддерживается на Ubuntu Linux и macOS, но вскоре обещают добавить поддержку и на Windows.
Как правило это означает: через пару лут будет работать и на Windows. Ну не так чтобы прямо совсем работать. Ну по крайней мере что-то запустится. Даже некоторые библиотеки будут работать. Ну те, которые не зависят от других библиотек, которые не будут работать.
Ну, а BSD, конечно, в пролёте.
И откуда проблема со скоростью? Как я себе представлял Питон в части DS и ML это же просто обёртка для запуска быстрого Сишного и Фортрановского кода. Разве нет?
И откуда проблема со скоростью? Как я себе представлял Питон в части DS и ML это же просто обёртка для запуска быстрого Сишного и Фортрановского кода. Разве нет?
вероятно в том и проблема что запуск одиночной функции дешевая штука, а вот работа с памятью - передача данных между функциями уже медленное место.
Вообще было бы интересно на эту тему увидеть авторитетное мнение.
передача данных между функциями уже медленное место.
Я думаю вы совершенно правы. Как минимум это одна из проблем.
Когда мы пишем на питоне (или любом медленном скриптовом языке) в стиле "скрипт" -> готовый быстрый фреймворк -> результат, то все нормально. А если фреймворк должен вызывать нашу функцию, которая что-то там считает внутри процесса в самом фреймворке, и которая написана на медленном языке - начинается передача данных туда-сюда, много раз в цикле, преобразования, и прочая и прочая. Это помимо того, что медленный кусок сам выполняется не быстро.
Это вполне типичная проблема, она например в Apache Spark имеет место - просто PySpark дает приемлемую производительность, но стоит на питоне написать UDF (ту самую функцию, которая каждую строку данных будет обрабатывать) - вот это вот все и начинается, с тормозами как следствие.
Просто передача между функциями - быстро. Передается просто указатель (адрес) на объекты в памяти. Например, если создать numpy.ndarray и вызывать методы numpy для обработки - это быстро. Ну как быстро... Если данные огромны, то затраты на вызовы функций малы по сравнению с временем на их обработку - это типичная ситуация для ML.
Другое дело, если данные маленькие - например, работать с массивчиком 100 чисел. Уже на вызовы будет затрачено значительное время.
Ну не знаю. У меня вот вся программа это обёртка, чтобы вызвать одну единственную строку - инференс YOLO. От того, что я её напишу на C++ или Mojo - что у меня ускорится?
По личным ощущениям (которые не врут) медленность вездесущего (и неизбежного) Python в многоязычном DataScience-стеке приводит к том что "всё медленнее чем у крутых пацанов на С++/Julia/Rust итд" примерно в... 4 раза. Слишком много чтобы не заметить, но слишком мало чтобы ~выйти в окно~ броситься всё переписывать (на самом деле переучиваться самому и миллионам на планете).
Вот это 4:1 и является объективной мерой, а не 100 и 63k раз. Mojo может благотворно сказаться на всех нас, и даже на самом Python. Поэтому успехов проекту.
Вот это 4:1 и является объективной мерой
Это значит что вам необходимо не 200 серверов, а 800, чтобы выполнить тот же объем вычислений. Когда речь идёт о 2 или 8 серверах, то может и не хочется ~выйти в окно~. А если сравнить 800 и 200, да ещё и перевести это в деньги, то картина меняется.
DS не про скорость расчетов вообще. А больше про скорость кодинга. Серверы, кстати, тоже не проблема. Вот выше написано что Python медленнее в 60000 раз чем С++. Так вот, никто не продаст 59999 серверов. Да и 3/4 никто не продаст. Потому что реальная разница 4:1 наблюдается вместе с проигрышем по времени кодинга. Его я оценить не могу, ну м.б. 1:2. А значит разница "всего в два раза", неосязаемо.
Даже если "всего в два раза": сейчас нас десятки тысяч VM. Могло бы быть в два раза больше. Представляете сколько это стоит?
Вы поднимаете важный и интересный вопрос: стоимость разработки VS стоимость эксплуатации. Так вот на больших скейлах стоимость разработки ничтожна по сравнению со стоимостью эксплуатации. Там есть прямой смысл вкладываться в разработку: искать спецов по C, а то и оптимизировать критичный код на более низком уровне.
А вот если это разовый проект (расчет), то можно и на интерпретируемом языке запустить - один раз можно и подождать, заплатив в 10-20 раз больше за инстанс.
Ну так сишный код тоже не идеален. Быстрый код писать сложно. А mojo старается сделать всю сложную оптимизационную работу под капотом. Когда его анонсировали была хорошая статья с описанием как им удалось этого достичь. https://www.modular.com/blog/mojo-vs-rust-is-mojo-faster-than-rust
Я думаю у 99% программистов такое же впечатление (как и было у меня до того как я разработал llama2.mojo)
Хинт: Проблема современных вычислительных библиотек - это оверхед. Если в случае простых задач как обработка / передача http это норм, то уже для сложных вычислений оверхед связанный с абстракциями и удобством делает вот это
Чуть больше деталей в твиттере у Карпатого -- https://twitter.com/karpathy/status/1778841713605525889
Что-то я не понял.
Разве это не под windows?
Это для visual studio code, причём тут windows?
Это расширение VS Code для того, чтобы VS Code мог видеть синтаксис языка, но не сам компилятор/интерпретатор, вроде так :)
Это просто плагин для поддержки синтаксиса, т.е. ты можешь хоть в блокноте набирать код для Mojo, но запускать пока только на Ubuntu и Mac
Эти и другие области ML объединяет то, что большинство библиотек для машинного обучения написано на Python.
Ну начнем с того, что большинство библиотек для машинного обучения для питона написано не на питоне)
А ещё питон активно развивается, в том числе и в сторону увеличения быстродействия. Не защищаю питон, я всегда за прогресс)
Но, если честно, не совсем понимаю смысл создания прямо таки специализированного языка для ML. Как я понял, его основная фишка - умение хорошо дергать питоновые либы. Ну и быстрее. Посмотрим. Есть шансы, что питон станет быстрее раньше, чем новый язык покорит мир ML.
Есть шансы, что питон станет быстрее раньше, чем новый язык покорит мир ML.
Нет, шансов нет без создания ещё одной, несовместимой с предыдущими версии питона с встроенной жёсткой типизацией, компиляцией до машиных кодов с тяжёлой оптимизацией и компактными объектами и массивами (как минимум).
А про медленные библиотеки для ML, это автор смешно написал)
Пожалуйста: встроенный тип array - компактный (типизированный) массив чисел. Типы любые числовые - int, long, signed/unsigned, double, float, все размеры от 1 до 8 байт. Но array крайне редко используют, так как используют библиотеки. Потому что медленный код.
Потом еще можно рассмотреть типы данных numpy. Это по типам данных, они есть. Вот с кодом сложнее. numba умеет использовать статические типы и делает компиляцию в машинный код. Да, весьма костыльно, куча ограничений, проблема с отладкой и др. Ее нельзя применить ко всему проекту. Но сделать одну-две функции, или даже целый модуль - вполне реально. Можно закрыть точечно потребность в каких-то вещах, которых нет в библиотеках. Причем закрыть весьма эффективно - статическая типизация, весьма эффективный, скомпилированный машинный код, распараллеливание циклов как OpenMP в C++. Можно сделать все то, для чего нужно было бы писать библиотечку на C/С++. Но писать при этом на питоне, с некоторыми нюансами.
Но в целом я согласен, для быстрого языка с компиляцией без нормальной, родной статической типизации не обойтись. Сделать еще одну, несовместимую с предыдущими версию питона? Ну а почему нет, переходили же с 2 на 3))
Вот эту новую версию и сделали. Называется Mojo. :)
Сделать еще одну, несовместимую с предыдущими версию питона? Ну а почему нет, переходили же с 2 на 3))
Каков был объем написанного питоновского кода тогда и каков он сейчас? А к запуску Python 4 ситуация еще больше усугубится в этом плане. Логичнее уж тогда не забрасывая развитие третьей версии сделать форк, и... тут мы снова внезапно вернулись к Mojo)
Питон садится в лужу по быстродействию в ML, если нужно написать какой+то свой алгоритм, для которого нет подходящей библиотеки. Но для этого случая в питоне есть numba. С ней код работает на уровне лучших компилирующих языков - C/C++/Rust. То есть, быстрее уже некуда.
Да, там куча ограничений, но большую часть задач она покрывает.
Open Source Mojo. С недавних пор этот проект является открытым и находится под лицензией Apache 2.0.
От опенсорса там только репозиторий с документацией, примерами и стандартной библиотекой. Сам же Mojo, как был закрытым проектом, так и остается. По крайней мере ни лицензии, ни новости об открытии ихсодников я не нашел.
По сути под "Open Source" авторы имели в виду возможность контребьюта в их проект, в частности, в стандартную библиотеку. Об этом можно почитать их блогпост здесь.
Не очень понимаю какой смысл делать новый ЯП не опенсорсным.
Какие из современных взелетвших языков не опенсорсные?
go, rust, swift все опенсорсные же.
Скоро будет видно, как пойдёт дело дальше. Похоже что все основные компоненты будут действительно открыты. Пока что же есть такая инфа:
https://docs.modular.com/mojo/faq#open-source
Why not develop Mojo in the open from the beginning?
Mojo is a big project and has several architectural differences from previous languages. We believe a tight-knit group of engineers with a common vision can move faster than a community effort. This development approach is also well-established from other projects that are now open source (such as LLVM, Clang, Swift, MLIR, etc.).
Статью, конечно, плюсанул, все это очень интересно)
Но в такой статье очень не помешали бы примеры кода.
очень интересно
Ну, допустим, уговорили, хочу переехать с Питон на Можо. И что мне делать? У меня есть программка, которая использует Пандас, Нампи, Ультралитикс.Йоло, ОпенСиВи и ещё по мелочи. Как мне с этим добром перебраться на Можо и получить ускорение в 68000 раз?
На данный момент говорить о переезде с Python на Mojo ещё рано. Проект ещё достаточно молодой и не поддерживает многие фишки и мелочи, которые вы имеете в виду. Список стандартных библиотек Mojo можно найти здесь.
Если вы хотите начать работу с Mojo, к примеру, чтобы провести свои исследования, то инструкцию по установке можно почитать здесь.
Мало что понятно, но очень интересно. Захотелось придраться к ошибкам. Вроде и статья умная, и человек её писал осознанно. Прогнать бы через ИИ хотя бы на ошибки.
производительность, а так же включает в себя возможность работы над моделями ... тут ТАКЖЕ пишется слитно.
проект, который написан с использование библиотеки Infermo (также написана на чистом Mojo)
Тут вообще букву потеряли (с использованиеМ).
Думаю, если поискать, можно найти ещё ошибки.
Спасибо вам за отзыв. Впредь постараюсь быть более внимательным при написании статей.
Ваш текст читается хуже, чем у автора.
Цитирование форматируется символом > в начале строки:
Мало что понятно, но очень интересно.
Для выделения слов больше подходит курсив или жирный текст, а капс выглядит так, будто вы кричите :)
Захотелось придраться к ошибкам.
Я бы поспорил с корректностью термина в данном случае. Более подходящий термин - опечатки.
Не очень понял по тексту, поэтому спрошу:
Можно ли в лоб копировать код на питоне и вставить его в интерпретатор моджо? Он будет работать? И если будет, то будет ли хоть какая-то разница?
Mojo загружает интерпретатор Python и его модули во время выполнения, поэтому, где бы вы ни запускали программу Mojo, она должна иметь доступ к совместимому Python интерпретатору и находить любые импортированные модули Python.
Учитывая ещё и это. Я до этой статьи в детали не вдавался и думал, что это ещё один язык, похожий на питон. А так получается, что это какой-то .NET и различные #, грубо говоря)
Придётся почитать доки повнимательнее...
Просто взять код с Python и вставить его в Mojo не получится, но вы можете интегрировать его интегрировать. О том, как это сделать можно почитать здесь.
Я только не понял, почему это называется искусственным интеллектом. Задачи по геометрии решать умеет? Нет. Такой бред генерирует. Сразу понятно, что интеллекта там никогда не было ни в каком виде. Какая-то бессмысленная генерация больших текстов "решений".
Python сейчас тоже ускорять взялись. GIL выпиливают, JIT запиливают...
Когда можно будет запустить Django на Mojo? :)
Mojo поддерживает только несколько типов данных: Int, Float, String, Bool, Uint. Т
А кортежи, списки, словари - все то, что так упрощает работу в Python и ООП (классы etc.) в нем есть?
Сдается мне, что с развитием языка он замедлится, т.к. станет сложнее и появится больше зависимостей. Конечно в синтетических тестах мы этого не увидим, но в реальных приложениях будет не такая скорость
Очередной пересказ буклета от отдела маркетинга mojo и копирование результатов синтетических тестов... Никто не показывает решения реальных задач на mojo и сопоставление с аналогичными решениями на python. В текущие проекты mojo c разбегу не затащить вообще, поддержка синтаксиса питона это просто маркетинг, а если проект и запустится, то никакой обещанной производительности там и не будет и близко. Чтобы выжать максимум из mojo нужно переписывать все "производительный" синтаксис с использованием fn функций, let объявления переменных и поддерживаемых типов данных и т.д. и т.п. В итоге код, который может дать максиму от моджо больше похож на rust и очень далек от питона, так может и взять сразу раст (ну или RustPython)))? Причем даже в случае переписывания кода на "производительны" синтаксис не будет обещанной производительности. Короче все это материалы для менеджеров, которые будут потом ходить и говорить "хочу моджо!".
А что случилось с julia? Пару лет назад она была убийцей питона.
По факту статья больше похожа на маркетинговую агитку
Mojo: убийца Python и будущее AI