В Rust за 10 лет не сделали аллокаторов?

Но, разве там нет gc в D? По идее с gc - прощай как минимум риалтайм на многих частотах?

Вот что пишут в D.

Normally, it’s only run when you call new. When you call new, if it thinks that it needs to do a collection to free up some space, then it will. Otherwise, it won’t normally ever run, because it’s not sitting in its own thread like happens with Java or C#. However, if you need it to run at a particular time, you can call core.memory.GC.collect to explicitly tell it to run a collection. Similarly, you can call GC.disable to make it so that a section of code won’t cause any collections (e.g. in a performance critical loop that can’t afford for the GC to kick in), and then you can call GC.enable to turn it back on again.

Типа у них чуток другой GC чем в Java/C#…

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

Ну например тип объекта + «приоритет/класс обслуживания», т.е. условно задача с входом копируется в разные очереди, в одной очереди идёт всякий кэшаваре и мемори манагер аваре дрочь на одном наборе ядер и одной зоне памяти а в другой очереди с более низким приоритетом на другом наборе ядер, которые параллельно что-то считают есчё и жалко там цпу тратить и на поддержание максимально эффективного пула, разгребается - и хрен с ним, когда нить либо разгребётся либо память кончится. Пример конечно надуманный, реальный кейс для одного типа объектов не видел, но для разных типов - легко.

Это я конечно переусложнил все для случая когда этот поинтер таскать с собой куда попало нужно. Если просто референс достаточно, то можно как тут https://docs.rs/typed-arena/2.0.1/typed_arena/struct.Arena.html#method.alloc

Ааааа! Т.е. интерфейсы для пулов то есть, дык это может даже веселее чем умные указатели с кастомными аллокаторами хранить в кастомном контейнере. Вот вам пулл, ссылки по контейнерам сами кидайте, вот только непонятно как освобождать сходу, но это я видимо просто раст не знаю. Кажется, что тогда где-то в ссылке на объект нужна ссылка на арену.

Мммм, т.е. похоже на те велосипеды что в каждом втором проекте на коленке делают, прикольно.

А спросить этот gc про то насколько мы близко к ситуации когда «уже пора» - можно?

А спросить этот gc про то насколько мы близко к ситуации когда «уже пора» - можно?

Есть GC.stats(), который вернёт структуру

size_t usedSize; 
size_t freeSize;
ulong allocatedInCurrentThread;

Ещё есть GC.malloc() чтобы выделить память без сборки.

И GC.free() чтобы самому вернуть память в GC, без сборки.выделенной хоть new, хоть GC.malloc.

Ещё там на форуме была ссылка на гитхаб, чтобы показать что D быстрый: https://github.com/eBay/tsv-utils/blob/master/docs/Performance.md#2018-benchmark-summary

P.S. Это просто сейчас нагуглил, я не пишу на D…

Типа у них чуток другой GC чем в Java/C#…

Там раньше же был (и вроде так и остался) тупой консервативный GC который гораздо медленнее и склонен к фрагментации в отличии от перемещающих GC в яве, шарпе и многих других языках. Правда D может спасти большая гибкость в размещении переменных на стеке, но это все придется ручками в виде структур, так как объекты все на куче и управляются GC.

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

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

Типа у них чуток другой GC чем в Java/C#…

Совсем другой. В яве он же проходит красной нитью через весь код. В D он именно опционален, там есть еще такие моменты, что часть стандартной либы написана с прицелом на сборщик мусора, но это потихоньку фиксится. Сборщик мусора в D это просто удобный способ работать с памятью, очень полезен на этапе прототипирования, когда нужно проверить основную идею и ты можешь просто не отвлекаться на ручное выделение памяти, а именно сосредотачиваешься на основной задачи. А потом, когда уже ты пять-шесть вариантов отбросил и выбрал решение уже можно начинать заморачиваться оптимизацией в виде аллокаторов. Там очень удобно можно комбинировать аллокаторы, можно сделать аллокатор, который объекты разных типов/размера будет выделять на разных кучах/аренах и прочее, да еще статистику в конце можно вывести и все это без лишних телодвижений и разной магии.

Там уже есть и прецизионный, правда не на всех вроде платформах, и настраивать его можно. Фишка в том, что там и не требуется по факту быстродействие от сборщика - его задача упростить реализацию, а критически важные участки кода надо все равно оптимизировать. Его не нужно сравнивать с явовским сборщиком, который используется для всего. Это просто вспомогательный инструмент. Если в основном рабочем цикле выделять память мегабайтами, никакой сборщик мусора не справится.

А что эксперты скажут про std.stdc.stdlib в D?

Я недавно пробовал себя в D, производительность vibe.d расстроила конечно, но свой код с помощью libc можно нехило оптимизировать как я понял. И все это без упарывания биндингами к C.

Глядя на вектор развития Rust диванный аналитик во мне говорит что через 5 лет это будет такой же перегруженный парадигмами и прочими абстракциями язык как и C++.

А вот традиционное ООП в D мне понравилось, и это при том что enumы и structы никто не запрещает.

Вот вам пулл, ссылки по контейнерам сами кидайте,

Это невозможно.

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

Это невозможно.

В этом бездарном дерьме борроу-чекер дерьма работает на бездарных алиасах. Поэтому это говно считает твой аллоцированный объект алиасом пулла.

Глядя на вектор развития Rust диванный аналитик во мне говорит что через 5 лет это будет такой же перегруженный парадигмами и прочими абстракциями язык как и C++.

Так и D уже сейчас такой же язык. Да чуть более прилизанный и более легкий для начального освоения (в основном из-за GC), но в остальном это тот же C++.

https://habr.com/ru/post/506598/ Microsoft: Rust является ‘лучшим шансом’ в отрасли программирования безопасных систем

А в каком месте? Мультипарадигменность это одно, а перегруженность - совсем другое.

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

Спасибо что погуглил за меня, кроме шюток.

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

D намного проще плюсов, после него плюсы становятся намного понятнее, но возникает вопрос почему в с++ так не сделали

производительность vibe.d расстроила конечно

А ты ldc собирал или dmd?

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

А в каком месте? Мультипарадигменность это одно, а перегруженность - совсем другое.

Там есть все что есть в C++ еще полюс добавили немного сверху.

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

Сахара чуть больше да, читаемость лучше.

D намного проще плюсов, после него плюсы становятся намного понятнее, но возникает вопрос почему в с++ так не сделали

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

Единственная у них крупная ошибка это обязательный GC.

Большое заблуждение. GC не является обязательным в D. Не нужно путать с явой/шарпом. памятью можно вручную управлять как в си через malloc/free, а также с помощью аллокаторов

Большое заблуждение. GC не является обязательным в D. Не нужно путать с явой/шарпом. памятью можно вручную управлять как в си через malloc/free, а также с помощью аллокаторов

И что, если отключить GC, то не отвалится часть стандартной библиотеки?

Большое заблуждение. GC не является обязательным в D.

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

Не нужно путать с явой/шарпом. памятью можно вручную управлять как в си через malloc/free, а также с помощью аллокаторов

Можно, но отваливается большая часть стандартной библиотеки. На таком уровне памятью можно и в шарпе управлять, там сейчас много штучек добавили для этого.

Большое заблуждение. GC не является обязательным в D. Не нужно путать с явой/шарпом. памятью можно вручную управлять как в си через malloc/free, а также с помощью аллокаторов

В C# тоже не совсем обязательный GC, есть структуры на стеке с RAI без GC, и есть stackalloc: https://www.youtube.com/watch?v=nK54s84xRRs

Любителем C# зашла эта лекция, вот несколько комментариев под роликом :)

I applied this to my code today - and got a performance gain that looks like an order of magnitude!

C# slowly turns into C++

Perfect talk related to C# performance. Now C# and C++ equal in performance using these techniques.

запускать какой-то лапшекод в цикле, на каждой итерации дропая арену

Вынести арену из цикла и менять её в цикле. Всё равно ЯП не вкурит в каком цикле и сколько тебе нужно. Если в первую итерацию ты выделяешь гиг, то это не значит что во вторую тоже. И есть два стула у ЯП – держать максимально выделенное пространство. Либо дропать на каждую итерацию. Учёные всего мира спорят какой из этих подходов менее прогрессивен в средней школьной поделке.

Да это всё фигня, давай конкретный пример кода, где прям видно, что аллокатор нужен?

Когда нужны huge pages, тогда и аллокатор нужен. Но это не точно.

https://habr.com/ru/post/506598/ Microsoft: Rust является ‘лучшим шансом’ в отрасли программирования безопасных систем

ахеть какое дежавю. Тоже самое читал про окамл от того же самого мекрософт ресерч лет 10-12 назад. кресты, де, устарели, надо что-то делать, мусье, индусы не могут писать без ошибок, нужен инструмент чтоб умнее был разраба…

Все это вылилось в F# а плюсы так и не заменили.

Все это вылилось в F# а плюсы так и не заменили.

F# появился 15 лет назад и никогда не позиционировался как замена C++. OCaml >20 лет назад любили сравнивать с C++ (он в хорошую безлунную погоду иногда его обгонял в правильных тестах), но тоже как замену никто ни предлагал.

В Rust за 10 лет не сделали аллокаторов?

Ныне Microsoft «глаз положила» на Rust.
«Улетит он в облака».

Не клал. Какой-то экзальтированный хипарь, приближенный к M$ расписал, что они там чуть не молятся на раст. Потом руководство оправдывалось за него на реддите

Потом руководство оправдывалось за него на реддите

Дашь ссылку почитать?

Лол, проиграл.

Твой пример кстати можно будет реализовать сразу после добавления в метапрог «цикла по структуре», а оптимизация доведет это все до компилтайма. Метапрог-прототип 16 + СУВТ по енумам (комментарий)

Интроспекцию добавляете?
Скорее всего у вас она будет называться - «СУВТ4».

Владимир

https://www.reddit.com/r/rust/comments/h84zwp/microsoft_rust_is_the_industrys_best_chance_at/

I’m the speaker the article is quoting. This article is a bit over-enthusiastic. We at Microsoft, and specifically the Microsoft Security Response Center, see a lot of potential for Rust in security critical components of our software. We definitely encourage the industry to take a look at Rust for security critical components, but Rust is one of three ways we want to tackle this problem with continuing to make C++ safer and doing more research into safe systems languages (project Verona) being the other two. C++ is not going anywhere and we’ll be writing and supporting C++ for a long time to come. Rust is not a panacea and we couldn’t switch over to Rust immediately even if we wanted.

Интроспекцию добавляете?

Нет, получить информацию по типу в рантайме нельзя будет все же.

В метапроге можно сделать typedef и свои структуры. Метапрог-прототип 16 + СУВТ по енумам (комментарий)

А это тогда что?

Владимир

Кто хочет «повеселится» загляните сюда https://forum.mista.ru/topic.php?id=856025&page=1 Killer 1s Application

Владимир

В метапроге можно сделать typedef и свои структуры. Метапрог-прототип 16 + СУВТ по енумам (комментарий)

Столько отрицания было: объектов, текстовых языков, …
И вот те на - еще не много и в Метапрог ООП изобретут.
Что интересно, так - какое название придумают?

Владимир

Что интересно, так - какое название придумают?

Вообщем то молодцы.
Но зачем было целый год всякую чушь нести?

Владимир

Это ж не интроспекция, typedef + структуры и в С есть.

Это ж не интроспекция, typedef + структуры и в С есть.

Вы правы.
Все впереди /об этом речь/.

Владимир

Вы правы. Все впереди /об этом речь/.

metaprog ни кого не послушает - только вас.
Let it be.

Владимир

Спасибо.

Ничего особо критичного не вижу. Вообще удивлён, что всяким левым чувакам позволяют делать заявления, вроде как, от лица компании. Ну или это всё-таки было согласовано.

Ничего особо критичного не вижу

Тах то ж пиндосы. Толерантность, всё завуалировно. Прямой критики в жизни не дождешься

об успехах Раста можно следить за подгоранием у плюсофанатов. Милота же!

С точки зрения раста прикольно будет посмотреть именно на безопасные арены. Т.е. аллоцируем как в nginx-е в арене одного http запроса и потом всё забываем.

В плюсах то такое, понятное дело, невозможно, там как всегда всё закончится «не пиши багов и оно всё равно будет в корку сыпаться»

об успехах раста показывает уровень растоманов в этой теме.

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

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

об успехах Раста можно следить за подгоранием у плюсофанатов. Милота же!

Это оправдание по сабжу штоле? Лол

примитивный плюсовый мозг не способен осознать глобальные аллокаторы без локов

Это оправдание по сабжу штоле? Лол

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