Как я полагаю это бенчмарк на алгоритме Mandelbrot причём на CPU Intel Xeon у которого 88 vCPU. Сам не проверял, но думаю что вполне может быть правдой, по причинам описанным в комантах -- меньший оверхед за счёт LLVM/MLIR трансляции, который обеспечивает улучшенную компиляцию под конкретные процессоры. MLIR имеет контекст более высокого уровня поэтому по словам создателей Mojo - это помогает с оптимизацией.
Я думаю у 99% программистов такое же впечатление (как и было у меня до того как я разработал llama2.mojo)
Хинт: Проблема современных вычислительных библиотек - это оверхед. Если в случае простых задач как обработка / передача http это норм, то уже для сложных вычислений оверхед связанный с абстракциями и удобством делает вот это
А супер оптимизированные вычислительные библиотеки такие как BLAS -- оказываются что супер раздуты там сотни тысяч строк кода, поддерживать это хозяйство да еще и под разные архитектуры тот еще челендж
Паралелизм паралелизму рознь. Многое зависит от оптимизатора. Проблема с современными C++ компиляторами в том что им приходится поддерживать 100500 различных платформ и архитектур, из за этого код под конкретную архитектуру может оказаться суб-оптимальным. А также с другой стороны general оптимизация компилятором проигрывает более правильно организованному коду высокого уровня. Т.е. грубо говоря если программист явно пишет какой цикл нужно векторизовать и какие нужно использовать параметры для SIMD операций -- код оказывается эфективнее чем оптимизатор будет делать предположения в жадном режиме.
Это бенчмарк от Октября 2023, уже не актуален. Тем не менее на устаревшей версии Mojo бенчмарк показал лучшую производительность Mojo против C на CPU вычислениях Apple Silicon в многопоточном режиме. Почему так? Как я понимаю отчасти потому что gcc/clang компилятор плохо справляется с оптимизацией под современные процессоры, особенно если это general оптимизатор который не знает какая логика/алгоритм исполняется в коде. При этом в Mojo можно задействовать низкоуровневые примитивы прямо из коробки, такие как SIMD.
А более новый бенчмарк (см. рисунок 1 из статьи) вообще показал что код на 1000 строк на Mojo написанный под конкретный алгоритм с помощью SIMD, Vectorze и Unroll сработал на некоторых кейсах быстрее чем супер оптимизированный c++ .
Основные вычисления происходят в matmul, но что примечательно в Mojo не используется никаких ассемблерных вставок.
Ps. На текущий день вышло несколько глобальных обновлений в Mojo которые ломают обратную совместимость, но интересно было бы сделать бенчмарк на последних версиях.. Возможно найду время и займусь этим в ближайшие дни..
Возможно кому-нибудь пригодится.
Стандартно chrome и chromium не позволяют задавать прокси в настройках браузера. (Предлагается выставить системные настройки прокси)
Но есть опция командной строки через которую в chromium можно задавать прокси:
chromium-browser --proxy-server=localhost:8008
Также есть возможность запустить хромиум в чистом новом профайле
Интересный проект ). Недавно нуждался в чём-то подобном для отладки JS.
А имеется ли возможность добавить правила вида:
*.site.my => localhost:9898
Т.е. перенаправлять все поддомены на какой-нибудь другой хост: порт?
Это явная утка. Прочитайте хотябы комментарий к статье на которую дана ссылка.
Клонировать симку не так просто, а IMSI код вродебы вообще не передаётся.
Да, autotune была фичей которую нужно использовать явно, но в последних версиях убрали её. Обещают в будущем вернуть после допиливания.
Классов действительно пока нет. Списки и словари появились в недавнем релизе Mojo StdLIb -- list, dict
Как я полагаю это бенчмарк на алгоритме Mandelbrot причём на CPU Intel Xeon у которого 88 vCPU. Сам не проверял, но думаю что вполне может быть правдой, по причинам описанным в комантах -- меньший оверхед за счёт LLVM/MLIR трансляции, который обеспечивает улучшенную компиляцию под конкретные процессоры. MLIR имеет контекст более высокого уровня поэтому по словам создателей Mojo - это помогает с оптимизацией.
Чуть больше деталей в твиттере у Карпатого -- https://twitter.com/karpathy/status/1778841713605525889
Я думаю у 99% программистов такое же впечатление (как и было у меня до того как я разработал llama2.mojo)
Хинт: Проблема современных вычислительных библиотек - это оверхед. Если в случае простых задач как обработка / передача http это норм, то уже для сложных вычислений оверхед связанный с абстракциями и удобством делает вот это
А супер оптимизированные вычислительные библиотеки такие как BLAS -- оказываются что супер раздуты там сотни тысяч строк кода, поддерживать это хозяйство да еще и под разные архитектуры тот еще челендж
Паралелизм паралелизму рознь. Многое зависит от оптимизатора. Проблема с современными C++ компиляторами в том что им приходится поддерживать 100500 различных платформ и архитектур, из за этого код под конкретную архитектуру может оказаться суб-оптимальным. А также с другой стороны general оптимизация компилятором проигрывает более правильно организованному коду высокого уровня. Т.е. грубо говоря если программист явно пишет какой цикл нужно векторизовать и какие нужно использовать параметры для SIMD операций -- код оказывается эфективнее чем оптимизатор будет делать предположения в жадном режиме.
Не совсем понял почему в 10 раз? Если вы про Go vs Mojo/C, то да. Я сам был удивлен что Go очень плох в сугубо вычислительных задачах.
👋 -- автор на связи!
Это бенчмарк от Октября 2023, уже не актуален. Тем не менее на устаревшей версии Mojo бенчмарк показал лучшую производительность Mojo против C на CPU вычислениях Apple Silicon в многопоточном режиме. Почему так? Как я понимаю отчасти потому что gcc/clang компилятор плохо справляется с оптимизацией под современные процессоры, особенно если это general оптимизатор который не знает какая логика/алгоритм исполняется в коде. При этом в Mojo можно задействовать низкоуровневые примитивы прямо из коробки, такие как SIMD.
А более новый бенчмарк (см. рисунок 1 из статьи) вообще показал что код на 1000 строк на Mojo написанный под конкретный алгоритм с помощью SIMD, Vectorze и Unroll сработал на некоторых кейсах быстрее чем супер оптимизированный c++ .
Основные вычисления происходят в matmul, но что примечательно в Mojo не используется никаких ассемблерных вставок.
Ps. На текущий день вышло несколько глобальных обновлений в Mojo которые ломают обратную совместимость, но интересно было бы сделать бенчмарк на последних версиях.. Возможно найду время и займусь этим в ближайшие дни..
Стандартно chrome и chromium не позволяют задавать прокси в настройках браузера. (Предлагается выставить системные настройки прокси)
Но есть опция командной строки через которую в chromium можно задавать прокси:
Также есть возможность запустить хромиум в чистом новом профайле
А имеется ли возможность добавить правила вида:
*.site.my => localhost:9898Т.е. перенаправлять все поддомены на какой-нибудь другой хост: порт?
За это пять! :)
Клонировать симку не так просто, а IMSI код вродебы вообще не передаётся.
Вот тут у митричева можно почитать разбор: http://petr-mitrichev.blogspot.com/2009/04/icpc-2009-world-finals.html
ping g.cn
тоже гугловский домен
http://www.youtube.com/watch?v=qTd5fyfd8-U
http://www.youtube.com/watch?v=ErrewreXHwQ