Как стать автором
Обновить

Комментарии 33

Из других новостей: на 1.3 racer собирался 4:45 на моей машине, на 1.4 — 3:57. Один мой проект собирается теперь за 1:00 вместо 1:14. Примерно 20% ускорения в обоих случаях.

Что радует, ускорения компиляции примерно такого масштаба происходят в каждом релизе.
вы уже в продакшне его?
В продакшене можно и нужно, но пока не всё, например, веб-сервер hyper болеет этим: github.com/hyperium/hyper/issues/368
Проблема вроде бы решена, но просто таймаутом, который и то, добавили недавно в стандартную библиотеку, 10К так не решить. Для последнего есть MIO, который весьма хорош. Драйверы БД тоже иногда болеют багами, но в целом всё можно исправить самому, честное слово, git clone && cargo build и у вас все готово к отладке внешнего проекта. Код всегда строгий и простой, так что проблем разобраться в чужом коде точно не будет.
очень завораживает, если честно.

Хотим заюзать раст внутри эрланга, пока вокруг да около ходим.
Мы начинали как раз с того, что написали несколько расширений для проекта на Erlang + С. Постепенно проект на Rust поглотил проект на Erlang (на последнем кусок был небольшим). В результате получилась такая штука: чтобы написать хорошее расширение на Rust нужно погрузиться в unsafe, что-то хорошо сделать в unsafe совсем не просто, это не самая комфортная зона языка, придётся много колдовать с Box, Cell, Rc. Rust очень многое хранит в стеке, и тут легко что-нибудь перепутать и потерять данные (язык без GC, всё мгновенно режет, да и в стеке ничего надолго не сохранишь). В зоне unsafe язык просто промолчит и разрешит всё уничтожить.
Другими словами, чтобы хорошо написать расширение пришлось основательно изучить Rust, но изучив захотели попробовать его для всего проекта.

В итоге: в проекте есть прирост по скорости в целых 16 раз. Задача — имитационное моделирование. Много CPU-bound, не так много IO. Может потому и такой прирост. Программа просто стала монолитом на системном языке. На C++ по скорости был бы тот же результат. Но с блэкджеком хотелось…
ну ёлки, на C++ вы бы по пути повесились от сегфолтов и стектрейсов =)

Очень интересный результат, спасибо.

Судя по вашему описанию, действительно у вас не про эрланг была задача.
мы хотим кусочек кода попробовать перевести на раст, но не уверены в результате.

Сейчас есть медленная и работающая реализация на эрланге, есть побыстрее в полтора раза и в 4 раза лучше по памяти реализация на С.

Смущает малое ускорение куска на С (я ожидал раз в 5) и не очень понятно, что в нём медленного, но самое главное: на С переползать страшно, потому что это сегфолты. Поэтому хочется пощупать раст.
Прирост скорости, действительно, спрогнозировать сложно. Но если он был маленький на C, то возможно просто упёрлись в возможности ОС, а прослойка над ней была довольно маленькая. Например, отдавать видео-поток, по скорости примерно все одинаково: nginx = go = python = rust = erlang = с, так как во всех случаях будет использоваться sendfile, и в нём программа будет находиться 70-80% времени. Тут ускорить не получится, к сожалению. С другой стороны в Rust полный контроль над памятью и реально без сегфолтов, это на случай транскодера.
про sendfile неверно. Это старый миф про его крутость, который не хотят проверять.

Разница, безусловно, есть, потому что при раздаче видео происходит куча другой работы по перепаковке контейнеров, учету сессий и т.п. Это и отличает примитивные реализации видеостриминговых серверов от более фичастых.
Если, действительно, прокачать фишками, то работы для языка побольше, конечно. Тут точно Rust хорошо ляжет. Сам язык/компилятор к продакшн точно готов, а вот во внешних библиотеках слегка будет дефицит функционала, иногда ошибки. До полной практической прокачки лэнда осталось всего месяцев 6-10. Спустя этот период писать будет чуть полегче, но я думаю сейчас самое время испытать все это добро на опережение. На изучение самого языка уходит не мало времени, месяца 2 минимум, при опыте в С, Java, Erlang, хотя поначалу он кажется очень простым, прочитать учебник без перерывов на еду мне удалось ровно за день. Потом долго будет ощущение, что вроде пишите и много пишете, но будто топчитесь на месте. Потом приходит озарение как всё правильно сделано и желание выкинуть всё остальное с GC.

Кстати, а как конфигурируется сервер? Скриптом на мини-языке или конфигом?
у нас конфигурация была вольная, но выкинули и перешли на строгий валидируемый конфиг. Я могу немало рассказать, почему это правильно и полезно, но это будет неприятно читать, потому что аргументы сведутся к «люди не читают документацию, а нас задолбало отвечать на одни и те же вопросы»

Ну как это. sendfile крут когда файл уже в кэше. Насколько я помню линуксовская реализация sendfile не умеет SF_NODISKIO, поэтому senfile может перестать быть крутым.
невозможность внятно определить наличие файла в кеше делает sendfile непредсказуемым, а следовательно непригодным для контроля за высокими нагрузками.
Просто надо выбирать правильную ОС для нужной задачи. Netflix например использует sendfile, а все потому, что в ОС которую они используют есть AIO и SF_NODISKIO.
И зачем менять ОС с поддерживаемой и популярной на фрибсд, под которую осталось три админа в нашем полушарии?
Чтобы использовать правильный инструмент для задачи. Впрочем мой комментарий был только о том, что senfile унылый только в некоторых ситуациях и только на Linux. Другая проблема с sendfile вне FreeBSD еще с использованием TLS.
а во фре tls в ядре для sendfile?
bulk encryption ядерный в 11-CURRENT (ветка которую netflix в продакшене использует). Сессия устаналивается в user space, ядро только шифрует данные. https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf
Я с вами не спорю, но хочется уточнить один момент: проверки Rust в unsafe не отключаются. Есть ровно три вещи, которые разрешаются дополнительно только в unsafe: разыменование сырых указателей, вызов опасных функций, и доступ к изменяемым статическим данным. Есть довольно большой класс поведения, которое считается не определенным и которое недопустимо даже в unsafe, но есть и поведение, которое явно не считается небезопасным и называется вместо этого «нежелательным» (например, утечка памяти).
Полностью согласен. В unsafe очень помогло заходить под GDB. Некоторые абстракции работы с кучей довольно хитрые и не всегда очевидно, что под ними лежит. Часто исходный код Rust очень помогает.
А вы не могли бы ваш опыт оформить в виде статьи? Очень интересно почитать про реальное применение языка и особенно про проблемы, с которыми столкнулись по пути.
В действительности, пока дошли до релиза по ряду вопросов сформировалось мнение, которое иногда отличалось от первого впечатления. Я думаю написание статьи — это хорошая идея, постараюсь найти время.
Я гоняю в продакшене на одном проекте, но там на расте только кусок, который как библиотека подключен в остальное приложение. Кусок просто перерабатывает данные и делает по ним статистику определенного рода. Работает хорошо, нареканий нет, добились снижения по потреблению памяти без проседания производительности, хотя это не было какой-то целью.

Делать сервер целиком на Расте я бы не стал, а вот на уровне extensions для Node, Python, Ruby он заходит очень хорошо.
Нет, пока ещё нет.
О! Result::expect наконец-то стабилизировали, это приятно.
Согласен! Некоторые другие возможности тоже хочется видеть стабильными (плагины компилятора, например, но это пока всё ещё довольно сырое).

Что касается Result, заметил интересную особенность: если никогда не делать unwrap, код очень выигрывает в качестве, так как приходится явно продумать как Result дойдёт до верхушки стека. Это привело к тому, что код на Rust для меня теперь является эталонным в проекте, все протоколы описаны в нём и я получаю подробнейшее указание, где была ошибка в одном лаконичном сообщении. Скорость решения любой проблемы удивительно высокая. Да, и больше не требуется пугать системных администраторов трассировкой исключений.
Тут от специфики программы зависит. Я вот, например, игру пытаюсь писать и меня полностью устраивает во многих случаях при возникновении ошибки просто сразу грохнуть все приложение. Ну и о причине написать в консоль, для чего expect и нужен.
Игра — это интересно! Пока не удалось опробовать пласт графических и звуковых библиотек. Какие библиотеки используете? Быстро ли работают? Какие есть недостатки в их реализации?
https://github.com/ozkriff/zoc — вот, прототипчик, давненько уже ковыряю черепашьими темпами.

Звук пока не трогал совсем.

Для создания окна и получения ввода использую glutin (https://github.com/tomaka/glutin) — отличная библиотека, работает даже на андроиде, к ней претензий не возникало никаких.

Для вывода графики использую свои обертки (https://github.com/ozkriff/zoc/tree/f874c9e/src/zgl/src) над голым gl-rs. Обертки кривые, сто лет назад их еще написал). Думаю переписать все на glium (https://github.com/tomaka/glium) — тоже отличная библиотека, только уж очень долго компилируется и сильно увеличивает время линковки проекта, на скорости рендеринга особо не должна сказываться.

Для 3д математики использую cgmath-rs (https://github.com/bjz/cgmath-rs), вроде как он немного для игр лучше подходит, чем nalgebra (https://github.com/sebcrozet/nalgebra), хотя последняя тоже неплоха.

Для вывода текста накидал небольшую обертку над stb_truetype — https://github.com/ozkriff/stb-tt-rs и сделал простенький кэш глифов — https://github.com/ozkriff/zoc/blob/f874c9/src/zgl/src/font_stash.rs. Вроде, терпимо работает.
Походил по ссылкам, честное слово, узнал много нового. Проект получился не маленький совсем. Есть, что скомпилировать на выходных )

Есть статистика, сколько FPS удаётся выжать?
Не знаю, если честно, сколько оно там сейчас кадров выдает — мне до оптимизации отрисовки еще далеко, сначала бы сделать это все играбельным.
Если интересно состояние ржавчины для написания игр, то вот еще хорошая и относительно свежая ссылка с мнением Tomaka (автором нескольких вышеупомянутых библиотек) — https://users.rust-lang.org/t/my-gamedever-wishlist-for-rust/2859.
Спасибо. Фронт работ в направлении игр, конечно, ещё большой, хотя базовые вещи, действительно закрыты.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории