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

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

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

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

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

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

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

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

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

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

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

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

Что касается Result, заметил интересную особенность: если никогда не делать unwrap, код очень выигрывает в качестве, так как приходится явно продумать как Result дойдёт до верхушки стека. Это привело к тому, что код на Rust для меня теперь является эталонным в проекте, все протоколы описаны в нём и я получаю подробнейшее указание, где была ошибка в одном лаконичном сообщении. Скорость решения любой проблемы удивительно высокая. Да, и больше не требуется пугать системных администраторов трассировкой исключений.
0
Тут от специфики программы зависит. Я вот, например, игру пытаюсь писать и меня полностью устраивает во многих случаях при возникновении ошибки просто сразу грохнуть все приложение. Ну и о причине написать в консоль, для чего expect и нужен.
0
Игра — это интересно! Пока не удалось опробовать пласт графических и звуковых библиотек. Какие библиотеки используете? Быстро ли работают? Какие есть недостатки в их реализации?
+1
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. Вроде, терпимо работает.
0
Походил по ссылкам, честное слово, узнал много нового. Проект получился не маленький совсем. Есть, что скомпилировать на выходных )

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