Да, это навязывается уловное выражение - когда условие может выступать(можно переписать) как выражение и возвращать, что-то. В более старых языках это будет как выше сказали - тернатный оператор.
В этом и прикол машинного обучения, что LLM при обучении, выучивает обобщающие знания(как программировать), а не то как именно программировать на том или ином языке. Достаточно относительно небольшой кодовой базы с фишками языка программирования, которые до селе не у кого не было.
Компиляторы консервативно не делают векторизацию операций с плавающей точкой, так-как это может сломать устойчивые численные алгоритмы. Поэтому нужно вручную подсказывать/указывать где можно делать автовекторизацию.
Но пока в Rust нет хорошего(по мнению большинства) способа это делать. Поэтому пока пляшем вокруг std::SIMD, std::intrinsic и дизайном кода, который склоняет к векторизации.
Пример “хорошего” api как раз и показывает компромиссность связанную с производительностью Python:
for batch in dataloader:
logits = classifier(batch.features)
loss = cross_entropy(logits, batch.labels)
loss.backward()
optimizer.step()
Где градиент? Какие параметры оптимизирует оптимизатор? Как эти параметры попадают в целевую функцию? Совершенно не видно потока данных. Всё это скрыто не потому, что это удобно - это не удобно, а потому, что мы не хотим, чтобы выполнение вываливалось в python-код и тормозило библиотечный код.
Всё же Python это альтернатива Matlab/Maple итд, а не С++/Rust . Python в мире ML это язык скриптования тулбоксов: PyTorch, JAX, итд. А С++/Rust это технологи на которых реализуют эти тулбоксы.
Это конечно интересно читать, про локальный опыт LLM-оводства. Но сомнение взывает целесообразность всех этих приседания для 35B модели, причём сильно квантифицированной.
Когда за копейки можно получить DeepSeek-V4-Flash на 284B c потоком токенов под 100/сек.
Ну я бы другую аналогию привёл - представьте себе какого-нибудь строителя, которому вместо перфоратора дают дрель с ударным механизмом со словами, что это тоже самое.
Это какие-то ужасные условия для работы. Я без 27+ моника и удобного кресла с подголовниками/подлоконтниками и стола нужной высоты даже работать не сяду, а не то, чтобы сколько-нибудь продолжительно работать.
Да сколько угодно насоздавай УЦ и сертификатов, всё решают компании из США - Google/Apple/Mozilla/Microsoft/CISCO итд, захотят они не класть твой сертификат к хранилище рутовых сертификатов своего ПО, ты там и не окажешся.
Да, это навязывается уловное выражение - когда условие может выступать(можно переписать) как выражение и возвращать, что-то. В более старых языках это будет как выше сказали - тернатный оператор.
В этом и прикол машинного обучения, что LLM при обучении, выучивает обобщающие знания(как программировать), а не то как именно программировать на том или ином языке. Достаточно относительно небольшой кодовой базы с фишками языка программирования, которые до селе не у кого не было.
Вот код на Rust:
А это как будет выглядеть на Mojo:
Как по мне - вполне неплохо.
Так там же управление памяти как в swift (на счётчиках ссылок), а в Mojo как в Rust на системе владения/заимствования. Это концептуально разные языки.
Компиляторы консервативно не делают векторизацию операций с плавающей точкой, так-как это может сломать устойчивые численные алгоритмы. Поэтому нужно вручную подсказывать/указывать где можно делать автовекторизацию.
Но пока в Rust нет хорошего(по мнению большинства) способа это делать. Поэтому пока пляшем вокруг
std::SIMD,std::intrinsicи дизайном кода, который склоняет к векторизации.Пример “хорошего” api как раз и показывает компромиссность связанную с производительностью Python:
Где градиент? Какие параметры оптимизирует оптимизатор? Как эти параметры попадают в целевую функцию? Совершенно не видно потока данных. Всё это скрыто не потому, что это удобно - это не удобно, а потому, что мы не хотим, чтобы выполнение вываливалось в python-код и тормозило библиотечный код.
Всё же Python это альтернатива Matlab/Maple итд, а не С++/Rust . Python в мире ML это язык скриптования тулбоксов: PyTorch, JAX, итд. А С++/Rust это технологи на которых реализуют эти тулбоксы.
Зачем IDE чтобы читать код, кода это можно делать в редакторе кода, типо Zed в 120 фпс, а не на java-блоатваре?
Основное время уходит на LLVM - я проверял. Но тут нужно уточнить, что LLVM долго работает из-за того rustc генерирует много LLVM IR.
Не знаю, был ли это сарказм, но уж лучше так, чем кожевенные мешки.
Но это же не альтернатива.
Это конечно интересно читать, про локальный опыт LLM-оводства. Но сомнение взывает целесообразность всех этих приседания для 35B модели, причём сильно квантифицированной.
Когда за копейки можно получить DeepSeek-V4-Flash на 284B c потоком токенов под 100/сек.
Плюсую. Статьи плюсанут не могу - маководы минуснули карму =)
Ну я бы другую аналогию привёл - представьте себе какого-нибудь строителя, которому вместо перфоратора дают дрель с ударным механизмом со словами, что это тоже самое.
Плюсую
Это какие-то ужасные условия для работы. Я без 27+ моника и удобного кресла с подголовниками/подлоконтниками и стола нужной высоты даже работать не сяду, а не то, чтобы сколько-нибудь продолжительно работать.
Да ладно вам, это для менеджмента ну или дизайнерам там каким-нибудь. Зачем нормальным прогерам Apple MacBook ?)
Да сколько угодно насоздавай УЦ и сертификатов, всё решают компании из США - Google/Apple/Mozilla/Microsoft/CISCO итд, захотят они не класть твой сертификат к хранилище рутовых сертификатов своего ПО, ты там и не окажешся.
Вы правильно написали это утвердительно. Всем надо будет разбираться с сертификатами.