Комментарии 4
Главное чтобы не получилось как с языком Julia: когда в экосистеме появляется слишком много багов корректности и сочетаемости
последний флаг означает, что наша наивная реализация автоматически становится векторизованной
-march=native означает, что код будет оптимизироваться под процессор, на котором собирается.
Для gcc есть флаг -fvect-cost-model=unlimited, который делает это.
Последний пункт особенно важен. Почему? А потому что OpenBLAS - это монстр, состоящий из ассемблерного кода, который годами оптимизировали красноглазые гении в подвалах под каждую существующую микроархитектуру Intel, в то время как программа на Mojo - это пара сотен строк условно-платформонезависимого питоноподобного кода, что очень впечатляет.
А кто тогда MKL оптимизировал? Он то побыстрей будет.
Плюс OpenBLAS в том, что вендор его может замокать (например как это делает Apple).
Так что пока, Mojo смешно смотрится.
В целом согласен, но MKL - это библиотека от самого вендора CPU, то есть, например, на процессорах AMD картина для описанных бенчмарков может быть качественно другой, не говоря уже про совсем отличное от x64 железо. С OpenBLAS же такого быть не должно.
Следование спецификации BLAS действительно много где развязывает руки в плане использования более быстрых реализаций от вендоров железа (Accelerate от Apple, BLIS от AMD, ArmPL от Arm и т.д.), но, как разобрано в этом посте от Modular, подход с платформо-специфичными реализациями, которые тюнились руками, очень плохо масштабируется, особенно для нейронок. В это собственно и заключается основной вывод статьи и, собственно, главная мотивация разработчиков языка: Mojo может и отстает в моменте, но потенционально он предоставляет намного более гибкий и масштабируемый подход для реализации вычислений.
Первый взгляд на производительность реализации floating-point GEMM для CPU на языке Mojo