Компиляторы консервативно не делают векторизацию операций с плавающей точкой, так-как это может сломать устойчивые численные алгоритмы. Поэтому нужно вручную подсказывать/указывать где можно делать автовекторизацию.
Но пока в 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 итд, захотят они не класть твой сертификат к хранилище рутовых сертификатов своего ПО, ты там и не окажешся.
Языкам программирования с развитой семантикой очень сложно придумать простой и эффективный механизм ручного контроля алиасинга. Это пробовали делать в Fortran — консервативно, но пробовали. Это пробовали в языке C, это пробуют сейчас в C++ и в Rust.
А разве нельзя сказать, что в Rust проблема решена? Через проверку заимствования в обычном коде, и через проверки miri в ансейфе.
А разве С\С++ компилятор не умеет выкидывать инициализацию если видит, что дальше память переписывается другим значением, и на этом протяжении не читается?
Сдаётся мне, что все эти приседания с инициализацией переменных - наследие былых времён, когда оптимизация "dead store elimination" отсутствовала.
Окончательное вылизывание кода просто позволит выйти на уровень насыщения количества неустранимых ошибок, количество которых зависит от используемой технологии/языка. И то это если функционал не добавляется/убавляется, компилятор не меняется и код идеально изолирован по инвариантам от зависимостей .
Есть подозрение, что у 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 итд, захотят они не класть твой сертификат к хранилище рутовых сертификатов своего ПО, ты там и не окажешся.
Вы правильно написали это утвердительно. Всем надо будет разбираться с сертификатами.
А разве нельзя сказать, что в Rust проблема решена? Через проверку заимствования в обычном коде, и через проверки miri в ансейфе.
А разве С\С++ компилятор не умеет выкидывать инициализацию если видит, что дальше память переписывается другим значением, и на этом протяжении не читается?
Сдаётся мне, что все эти приседания с инициализацией переменных - наследие былых времён, когда оптимизация "dead store elimination" отсутствовала.
Окончательное вылизывание кода просто позволит выйти на уровень насыщения количества неустранимых ошибок, количество которых зависит от используемой технологии/языка. И то это если функционал не добавляется/убавляется, компилятор не меняется и код идеально изолирован по инвариантам от зависимостей .
Есть подозрение, что у Rust это насыщение происходит быстрее, так ещё и уровень количества неустранимых ошибок ниже чем в С/С++. Это конечно можно будет подтвердить только со временем, но по крайне мере нет доводов для противоположного утверждения.
"Лес рубят - щепки летят".