Вышел Rust 1.0 Beta

Многопоточная компиляция поддерживается?

Мне всегда было интересно — зачем это нужно? В больших проектах файлов много, несложно одновременно компилировать N файлов по числу ядер.

Ну вот хотя бы в список хочу элементы запихивать. Это что, каждый элемент будет box-ится выделением памяти в хипе? Это же ппц.

В расте вроде куча используется не чаще, чем в каком-нибудь C. Сдаётся мне, ты что-то путаешь.

в частности vec - как std::vector в С++ - это просто массив значений.

Все на векторе не напишешь.

Очевидно, более сложные коллекции активно выделяют память для своих внутренних структур, но это необходимый минимум

Вот и я говорю - тормозит.

Там да, для каждой вставки объект выделяется в куче, и контейнер хранит ссылку на Object, неявно приводя его к нужному типу.

Кукаретик, не знающий как работает JVM, детектед. Память в хипе выделяется сразу в количестве Xms, создание нового обьекта в жабе, это просто bump pointer-a, в этом боьшом предвыделенном пуле.

В серьезных приложениях на Си таки юзается активно, посмотри хотя бы код какой-нибудь СУБД. Но там есть штуки типа apache memory pool, всякие аллокаторы и так далее.

Вот и я говорю - тормозит.

По сравнению с чем? Ржавчина в этом плане аналогична си\плюсам.

Разве что, проверка времени жизни объектов позволяет многие вещи, которые в плюсах создали бы в куче, оставлять на стеке.

По сравнению с чем? Ржавчина в этом плане аналогична си\плюсам.

По сравнению с кодом на Си/С++, в котором юзается кастомный аллокатор, к примеру. Ржавчина в этом плане пока дно, а не аналог. Вон, есть продвижения в этом направлении: https://doc.rust-lang.org/arena/, это супер, но факт в том, что Rust еще пилить и пилить.

В серьезных приложениях на Си таки юзается активно, посмотри хотя бы код какой-нибудь СУБД. Но там есть штуки типа apache memory pool, всякие аллокаторы и так далее.

Как мне кажется, те пулы используются не столько ради скорости, сколько ради того, чтобы не следить за освобождением памяти. Могу ошибаться, конечно. Есть где-нибудь сравнение производительности обычного malloc-а и пулового? Я понимаю, что разница будет, но какая?

Вот и я говорю - тормозит.

Не понял, ты знаешь какие-то другие альтернативы? Может быть ты знаешь, как написать hash-map или b-tree без аллокаций?

Память в хипе выделяется...

Лол, какое мне дело, какие костыли придумали в JVM, лишь бы не делать нормальные генерики. Суть-то не меняется - вместо значений в структурах хранятся указатели на кучу, а значит каждое обращение требует минимум двух разыменовываний, а каждая вставка - аллкокации, пусть и дешевой. Но мне больше интересно, зачем ты продолжаешь проецировать свои жаба-комплексы на раст. В расте, в отличие от жабы, есть полноценные генерики и можно выделить нетривиальный объект на стеке, так что от «аллокации на каждый чих» он гораздо дальше.

Ну типа

--gc:off

Пул и для того и для того + еще с фрагментацией позволяет бороться. Бенчмарков под рукой нет, но разница большая.

Ну вот хотя бы в список хочу элементы запихивать. Это что, каждый элемент будет box-ится выделением памяти в хипе? Это же ппц.

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

С++ сам себя убъет возрастающей сложностью.

Страуструпп рекомендует использовать только часть С++ которую вы освоили.

День скучных новостей?

Мне интересно зачем ты свои комплексы и не грамотность пытаешся проецировать на работающие, причем работающие хорошо, решения?

Твои кукарекания про «нормальные женерики» просто смешны, так как ты не знаешь про такую оптимизацию, как Escape Analysys. Высокопроизводительный сервер сейчас - это или C/C++ c кастомными аллокаторами, или JVM c pointer bump-ом.

По сравнению с кодом на Си/С++, в котором юзается кастомный аллокатор, к примеру. Ржавчина в этом плане пока дно, а не аналог.

Пруф будет?

В минусы пула можно записать неоптимальное использование памяти. Пока обработка запроса не закончится — память не будет освобождена и другие части приложения не смогут её переиспользовать.

В принципе в расте никто не мешает сделать пулы и вроде ты сам приводил ссылку на какую то библиотеку. Я её не использовал, но может это оно? Разве что стандартная библиотека будет память брать из кучи, понятия заменяемых аллокаторов там вроде нет. Думаю для критичных мест можно изобрести велосипед.

Ну и получится у тебя С++, с текущей памятью, двойным удалением, нул поинтерами, buffer overflow и т.п.. Для этого Rust и пишут, чтобы без GC, но и не C++.

Узлы списка будут выделяться на хипе, но оно всегда так для списка.

В том то и дело не всегда. В С++ можно свой аллокатор впиндюрить, в JVM, как я уже говорил, вся доступная память - memory pool.

Это просто опыт с прошлой работы. У нас чуваки писали кусок на С++, в итоге запуск в прод показал, что наивное использование malloc дает больше тормозов, чем использование жабы. Но они в итоге наколдовали с аллокатрами, и полетело. Пруфы я думаю найти можно, но лень.

Узлы списка будут выделяться на хипе, но оно всегда так для списка.

В том то и дело не всегда. В С++ можно свой аллокатор впиндюрить

Свой аллокатор - это всё равно выделение памяти. Насколько оно быстрее аллокатора общего назначения - вопрос открытый.

в JVM, как я уже говорил, вся доступная память - memory pool.

И в результате Java жрет память в три горла.

нас чуваки писали кусок на С++, в итоге запуск в прод показал, что наивное использование malloc дает больше тормозов, чем использование жабы.

Слишком туманно.

Но они в итоге наколдовали с аллокатрами, и полетело

Ну так колдовство есть и в Rust. Уже сейчас.

Ок, понял.

Угу, продвижения есть, просто заметно, что у Раста нет хардкорного продакшна и с такими продвинутыми штуками пока плоховат то. Пока.

Насколько оно быстрее аллокатора общего назначения - вопрос открытый.

Ну дык да, все в твоих руках.

И в результате Java жрет память в три горла.

Верно, но обьекты создаются быстро, это факт. Поэтому меня и удручает, что в Расте пока все вяло с этим, до продакшна далеко. Но потенциал хороший.

Насколько оно быстрее аллокатора общего назначения - вопрос открытый.

Ну дык да, все в твоих руках.

Стандартный ответ на все вопросы о Си++ %)

Поэтому меня и удручает, что в Расте пока все вяло с этим

Да блин. Тебе уже несколько раз указали на Arena.

до продакшна далеко

Это у кого как. В reddit периодически пишут о продакшене на Rust.

Escape Analysys

Какая связь между подделкой под генерики через type erasure и способностью компилятора иногда заменять аллокацию в куче аллокацией на стеке?

Скорее бы уже браузер на servo, с html5-гуем вместо XUL-a, да под вэйланд

Такая, что эта оптимизации помогает справиться с недостатками дженериков. Ты хоть понимаешь почему дженерики такие какие они есть? Это сделано для совместимости со старым кодом, ну да, кукаретики не думают про совместимость. JVM - это куча trad off, которые необходимо было сделать в силу обстоятельств, и это жизнь.

Да блин. Тебе уже несколько раз указали на Arena.

Так это все пока детсад ведь, не? Как например заставить готовый список создавать элементы в арене? Это же тока для своего кода, как я понял.

Такая, что эта оптимизации помогает справиться с недостатками дженериков.

Я прочитал википедию и не понял, как эта оптимизация поможет справиться с недостатками дженериков. Конкретно, если я хочу создать вектор/список значений, типа std::vector<int>, как эта оптимизация поможет мне избежать списка указателей на значения в куче?

Ты хоть понимаешь почему дженерики такие какие они есть?

Да, я читал, я понимаю мотивацию разработчиков, наверно они были правы. Но это не отменяет того факта, что генерики в Java - тормозная подделка под настоящий параметрический полиморфизм а-ля Haskell или .NET 2.0, и что они-то как раз и провоцирую «аллокацию на каждый чих», под которую потом приходится затачивать ВМ.

Да блин. Тебе уже несколько раз указали на Arena.

Так это все пока детсад ведь, не?

Детсад - это капризничать «хочу создавать узлы списка в пуле, а иначе не готов для продакшена».

Это же тока для своего кода, как я понял.

Ну дык да, все в твоих руках.

JVM c pointer bump-ом.

ага, только чтобы было быстро используют offheap и... bump

Детсад - это капризничать «хочу создавать узлы списка в пуле, а иначе не готов для продакшена».

Вообще-то не детсад. Детсад - это кидаться на все новое и модное с вытаращенными глазами.

Offheap быстро только в очень специфичных случаях, когда затраты на гц больше затрат на offheap хранение.

Offheap быстро только в очень специфичных случаях,

зато часто

когда затраты на гц больше затрат на offheap хранение.

offheap хранение не про ресурсы, а про то, что оно потенциально небезопасно и правильно и безбажно его написать сложно

и хватит уже килограммы с километрами сравнивать

Детсад - это кидаться на все новое и модное с вытаращенными глазами.

Кидаться с вытаращенными глазами - глупо, и неважно, на новое или на старое. Но если под «новым и модным» ты подразумеваешь Rust, то я не вижу как минимум моды на него.

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

Но для этого уже есть Haskell, OCaml, SML и куча других более идиоматичных языков.

Да, но это все языки с неотрезаемым GC, а Rust пишется для задач, в которых GC крайне нежелателен.

уже есть Haskell, OCaml, SML

Но ведь Хаскель - игрушка академиков, Окамль - придворный язык Jane Street Capital, SML вообще сиротка бездомный.

У меня задымился парсер.

Ну да, синтаксис несколько страшный. Но мне что-то кажется, что читать навороченные растовые макросы будет проще, чем «шаблонное метапрограммирование» на С++.

Очередной высер. Вакансии по Rust уже есть, зайди на сайт Мозиллы и убедись.

SML вообще сиротка бездомный

После пересадки почки Харпер им сильно озаботился :)

Его, судя по всему, пока освоишь - просрёшь все полимеры.

Это всё-таки макросы, их по идее, не так часто писать приходится. Да и тот же С++ ничего такого вообще не предлагает. Сишные макросы - не то.

В остальном у меня никаких сложностей с языком не было. Ну это после С++.

Недавно предполагаемой датой выхода значилось Mar 31.

Дату релиза не перенесли. А с бетой, я так понял, что они коряво дни посчитали, потому и ошиблись.

И box-ов этих в реальном коде дохрена, взять хотя бы коллекции.

Что, опять? C++ уже зопарил всех необходимостью писать свой аллокатор и всячески бороться с фрагментацией кучи. Казалось бы, чуваки из тормозиллы должны были больше всех хлебнуть и вынести уроки. Но нет, нееееееет!

По сравнению с кодом на Си/С++, в котором юзается кастомный аллокатор, к примеру.

Часто ты в плюсовом коде кастомные аллокаторы видел? Да, бывает нужно и используется, но говорить, что без этого язык не нужен - не справедливо. Да и допилят к релизу может быть.

C++ запарил только неумех, которые используют его там, где он им не нужен и можно было обойтись чем-нибудь менее хардкорным. Rust - потенциальная замена С++.

На С++ стоит только хардкорные проекты писать вроде СУБД и high frequency trading и там аллокаторы - это обыденность, а не редкость. Rust метит туда же.

белки-истерички.жпг

Страуструпп рекомендует использовать только часть С++ которую вы освоили

ага, а если в чужом коде что-то незнакомое, просто скажи боссу, что этот код - говно, дайте мне другой

в JVM, как я уже говорил, вся доступная память - memory pool

внезапно, внутри твоего пула тоже нужно аллоцировать блоки