Комментарии 33
Из других новостей: на 1.3 racer собирался 4:45 на моей машине, на 1.4 — 3:57. Один мой проект собирается теперь за 1:00 вместо 1:14. Примерно 20% ускорения в обоих случаях.
Что радует, ускорения компиляции примерно такого масштаба происходят в каждом релизе.
Что радует, ускорения компиляции примерно такого масштаба происходят в каждом релизе.
+6
вы уже в продакшне его?
0
В продакшене можно и нужно, но пока не всё, например, веб-сервер hyper болеет этим: github.com/hyperium/hyper/issues/368
Проблема вроде бы решена, но просто таймаутом, который и то, добавили недавно в стандартную библиотеку, 10К так не решить. Для последнего есть MIO, который весьма хорош. Драйверы БД тоже иногда болеют багами, но в целом всё можно исправить самому, честное слово, git clone && cargo build и у вас все готово к отладке внешнего проекта. Код всегда строгий и простой, так что проблем разобраться в чужом коде точно не будет.
Проблема вроде бы решена, но просто таймаутом, который и то, добавили недавно в стандартную библиотеку, 10К так не решить. Для последнего есть MIO, который весьма хорош. Драйверы БД тоже иногда болеют багами, но в целом всё можно исправить самому, честное слово, git clone && cargo build и у вас все готово к отладке внешнего проекта. Код всегда строгий и простой, так что проблем разобраться в чужом коде точно не будет.
+1
очень завораживает, если честно.
Хотим заюзать раст внутри эрланга, пока вокруг да около ходим.
Хотим заюзать раст внутри эрланга, пока вокруг да около ходим.
0
Мы начинали как раз с того, что написали несколько расширений для проекта на Erlang + С. Постепенно проект на Rust поглотил проект на Erlang (на последнем кусок был небольшим). В результате получилась такая штука: чтобы написать хорошее расширение на Rust нужно погрузиться в unsafe, что-то хорошо сделать в unsafe совсем не просто, это не самая комфортная зона языка, придётся много колдовать с Box, Cell, Rc. Rust очень многое хранит в стеке, и тут легко что-нибудь перепутать и потерять данные (язык без GC, всё мгновенно режет, да и в стеке ничего надолго не сохранишь). В зоне unsafe язык просто промолчит и разрешит всё уничтожить.
Другими словами, чтобы хорошо написать расширение пришлось основательно изучить Rust, но изучив захотели попробовать его для всего проекта.
В итоге: в проекте есть прирост по скорости в целых 16 раз. Задача — имитационное моделирование. Много CPU-bound, не так много IO. Может потому и такой прирост. Программа просто стала монолитом на системном языке. На C++ по скорости был бы тот же результат. Но с блэкджеком хотелось…
Другими словами, чтобы хорошо написать расширение пришлось основательно изучить Rust, но изучив захотели попробовать его для всего проекта.
В итоге: в проекте есть прирост по скорости в целых 16 раз. Задача — имитационное моделирование. Много CPU-bound, не так много IO. Может потому и такой прирост. Программа просто стала монолитом на системном языке. На C++ по скорости был бы тот же результат. Но с блэкджеком хотелось…
+3
ну ёлки, на C++ вы бы по пути повесились от сегфолтов и стектрейсов =)
Очень интересный результат, спасибо.
Судя по вашему описанию, действительно у вас не про эрланг была задача.
Очень интересный результат, спасибо.
Судя по вашему описанию, действительно у вас не про эрланг была задача.
0
мы хотим кусочек кода попробовать перевести на раст, но не уверены в результате.
Сейчас есть медленная и работающая реализация на эрланге, есть побыстрее в полтора раза и в 4 раза лучше по памяти реализация на С.
Смущает малое ускорение куска на С (я ожидал раз в 5) и не очень понятно, что в нём медленного, но самое главное: на С переползать страшно, потому что это сегфолты. Поэтому хочется пощупать раст.
Сейчас есть медленная и работающая реализация на эрланге, есть побыстрее в полтора раза и в 4 раза лучше по памяти реализация на С.
Смущает малое ускорение куска на С (я ожидал раз в 5) и не очень понятно, что в нём медленного, но самое главное: на С переползать страшно, потому что это сегфолты. Поэтому хочется пощупать раст.
0
Прирост скорости, действительно, спрогнозировать сложно. Но если он был маленький на C, то возможно просто упёрлись в возможности ОС, а прослойка над ней была довольно маленькая. Например, отдавать видео-поток, по скорости примерно все одинаково: nginx = go = python = rust = erlang = с, так как во всех случаях будет использоваться sendfile, и в нём программа будет находиться 70-80% времени. Тут ускорить не получится, к сожалению. С другой стороны в Rust полный контроль над памятью и реально без сегфолтов, это на случай транскодера.
0
про sendfile неверно. Это старый миф про его крутость, который не хотят проверять.
Разница, безусловно, есть, потому что при раздаче видео происходит куча другой работы по перепаковке контейнеров, учету сессий и т.п. Это и отличает примитивные реализации видеостриминговых серверов от более фичастых.
Разница, безусловно, есть, потому что при раздаче видео происходит куча другой работы по перепаковке контейнеров, учету сессий и т.п. Это и отличает примитивные реализации видеостриминговых серверов от более фичастых.
0
Если, действительно, прокачать фишками, то работы для языка побольше, конечно. Тут точно Rust хорошо ляжет. Сам язык/компилятор к продакшн точно готов, а вот во внешних библиотеках слегка будет дефицит функционала, иногда ошибки. До полной практической прокачки лэнда осталось всего месяцев 6-10. Спустя этот период писать будет чуть полегче, но я думаю сейчас самое время испытать все это добро на опережение. На изучение самого языка уходит не мало времени, месяца 2 минимум, при опыте в С, Java, Erlang, хотя поначалу он кажется очень простым, прочитать учебник без перерывов на еду мне удалось ровно за день. Потом долго будет ощущение, что вроде пишите и много пишете, но будто топчитесь на месте. Потом приходит озарение как всё правильно сделано и желание выкинуть всё остальное с GC.
Кстати, а как конфигурируется сервер? Скриптом на мини-языке или конфигом?
Кстати, а как конфигурируется сервер? Скриптом на мини-языке или конфигом?
0
Ну как это. sendfile крут когда файл уже в кэше. Насколько я помню линуксовская реализация sendfile не умеет SF_NODISKIO, поэтому senfile может перестать быть крутым.
0
невозможность внятно определить наличие файла в кеше делает sendfile непредсказуемым, а следовательно непригодным для контроля за высокими нагрузками.
0
Просто надо выбирать правильную ОС для нужной задачи. Netflix например использует sendfile, а все потому, что в ОС которую они используют есть AIO и SF_NODISKIO.
0
И зачем менять ОС с поддерживаемой и популярной на фрибсд, под которую осталось три админа в нашем полушарии?
0
Я с вами не спорю, но хочется уточнить один момент: проверки Rust в unsafe не отключаются. Есть ровно три вещи, которые разрешаются дополнительно только в unsafe: разыменование сырых указателей, вызов опасных функций, и доступ к изменяемым статическим данным. Есть довольно большой класс поведения, которое считается не определенным и которое недопустимо даже в unsafe, но есть и поведение, которое явно не считается небезопасным и называется вместо этого «нежелательным» (например, утечка памяти).
+2
А вы не могли бы ваш опыт оформить в виде статьи? Очень интересно почитать про реальное применение языка и особенно про проблемы, с которыми столкнулись по пути.
+1
Я гоняю в продакшене на одном проекте, но там на расте только кусок, который как библиотека подключен в остальное приложение. Кусок просто перерабатывает данные и делает по ним статистику определенного рода. Работает хорошо, нареканий нет, добились снижения по потреблению памяти без проседания производительности, хотя это не было какой-то целью.
Делать сервер целиком на Расте я бы не стал, а вот на уровне extensions для Node, Python, Ruby он заходит очень хорошо.
Делать сервер целиком на Расте я бы не стал, а вот на уровне extensions для Node, Python, Ruby он заходит очень хорошо.
0
Нет, пока ещё нет.
0
О! Result::expect наконец-то стабилизировали, это приятно.
+1
Согласен! Некоторые другие возможности тоже хочется видеть стабильными (плагины компилятора, например, но это пока всё ещё довольно сырое).
Что касается Result, заметил интересную особенность: если никогда не делать unwrap, код очень выигрывает в качестве, так как приходится явно продумать как Result дойдёт до верхушки стека. Это привело к тому, что код на Rust для меня теперь является эталонным в проекте, все протоколы описаны в нём и я получаю подробнейшее указание, где была ошибка в одном лаконичном сообщении. Скорость решения любой проблемы удивительно высокая. Да, и больше не требуется пугать системных администраторов трассировкой исключений.
Что касается Result, заметил интересную особенность: если никогда не делать unwrap, код очень выигрывает в качестве, так как приходится явно продумать как Result дойдёт до верхушки стека. Это привело к тому, что код на Rust для меня теперь является эталонным в проекте, все протоколы описаны в нём и я получаю подробнейшее указание, где была ошибка в одном лаконичном сообщении. Скорость решения любой проблемы удивительно высокая. Да, и больше не требуется пугать системных администраторов трассировкой исключений.
0
Тут от специфики программы зависит. Я вот, например, игру пытаюсь писать и меня полностью устраивает во многих случаях при возникновении ошибки просто сразу грохнуть все приложение. Ну и о причине написать в консоль, для чего expect и нужен.
0
Игра — это интересно! Пока не удалось опробовать пласт графических и звуковых библиотек. Какие библиотеки используете? Быстро ли работают? Какие есть недостатки в их реализации?
0
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. Вроде, терпимо работает.
Звук пока не трогал совсем.
Для создания окна и получения ввода использую 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. Вроде, терпимо работает.
+1
Походил по ссылкам, честное слово, узнал много нового. Проект получился не маленький совсем. Есть, что скомпилировать на выходных )
Есть статистика, сколько FPS удаётся выжать?
Есть статистика, сколько FPS удаётся выжать?
0
Если интересно состояние ржавчины для написания игр, то вот еще хорошая и относительно свежая ссылка с мнением Tomaka (автором нескольких вышеупомянутых библиотек) — https://users.rust-lang.org/t/my-gamedever-wishlist-for-rust/2859.
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Выпущен Rust 1.4