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

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

Слишком уныло даже для мастдайщика.

Это хрущевщина, затаскивание капитализма в коммунизм. Нахер тебе аллокаторы в расте? Давай прям пример кода

ТС - фанбой плюсов уровня царя.

Лоровским растовикам не понять. Но аллокаторы это для скорости аллокации и деаллокации, чтобы не было диффузии памяти и фрагментации.

Вот тебе картинка: https://imgur.com/a/L6z2Eze

Мой лично написанный аллокатор против С++ new и С malloc.

Подумай над ней.

Если мыслей не появится, можешь посмотреть видос александреску: https://www.youtube.com/watch?v=LIb3L4vKZ7U

Нахер тебе аллокаторы в расте?

Вот тебе тесты типа из Bloomberg: https://imgur.com/a/IjPP6E4

И вообще для понимания проблемы: https://www.youtube.com/watch?v=nZNd5FjSquk

Нахер тебе аллокаторы в расте?

Классический пример - запускать какой-то лапшекод в цикле, на каждой итерации дропая арену. Вот библиотека которая это делает уже, в принципе я бы ней пользовался

https://docs.rs/typed-arena/2.0.1/typed_arena/

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

Пока не убедил, и по сути не ответил не на один из тезисов. Ну ладно допустим ты на своем С++ написал собственный аллокатор, у тебя какие-то проблемы с тем же самым на раст, серьезно?

Где нормальные тесты твоего аллокатора на различных вариациях использования? Что эта картинка без кода вообще должна была доказать?

Раст - не про алокаторы. И вряд ли они когда-нибудь будут добавлены в язык. В расте даже нет placement new. Поставим вопрос по другому. А нужны ли в расте алокаторы?

Второй вброс про то, что в расте избирательная поддержка операционок. Это чистая правда. Мне тоже не нравится, даже подбешивает.

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

Притом в Rust до версии 1.27 было какое-то API в nightly с помощью которого люди пытались делать аллокаторы: https://docs.rs/crate/allocators/0.1.9/source/src/freelist.rs

Но потом его выпилили, а замены до сих пор нет :(

https://github.com/rust-lang/rust/pull/48333

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

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

и the Phobos Standard Library of the D Programming Language

Тут какое-то время назад, в теме про новый стандарт C++, фанатики раста писали, что фичи в C++ из раста тащат, а мы, фанатики D, утверждали, что из D. Таки больше нет возражений - в C++ притащили из раста, НО в раст притащили из D

Любой?

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

Или посмотри OpenSource код любой игры.

Вот недавно открыли код Command & Conquer, и видно что даже в 1995 году, до первого стандарта С++, люди писали свои менеджеры памяти: https://github.com/electronicarts/CnC_Remastered_Collection/blob/master/TIBERIANDAWN/HEAP.CPP

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

Ну да, и не будет никакой стандартной библиотеки. И зачем нужен тогда раст?

Пока в расте не адаптируют стандартную библиотеку для использования аллокаторов, то раст мёртв, можешь следить за этой issue: https://github.com/rust-lang/wg-allocators/issues/7

Ну да, и не будет никакой стандартной библиотеки. И зачем нужен тогда раст?

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

Пока в расте не адаптируют стандартную библиотеку для использования аллокаторов, то раст мёртв, можешь следить за этой issue: https://github.com/rust-lang/wg-allocators/issues/7

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

И вряд ли они когда-нибудь будут добавлены в язык.

Глобальные алокаторы уже давно есть.

В расте даже нет placement new.

Ещё нет.

А нужны ли в расте алокаторы?

Нет.

Второй вброс про то, что в расте избирательная поддержка операционок.

Шта?!

Насколько я понимаю работа в этом направлении ведется: https://github.com/rust-lang/rust/issues/32838

и в nigtly даже уже что-то есть: https://doc.rust-lang.org/1.24.1/alloc/allocator/trait.Alloc.html

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

в расте избирательная поддержка операционок. Это чистая правда.

Присоединяюсь к вопросу «шта?».

Чё штакаешь и шлангуешь? Не видел, как отказываются от поддержки 32-битных систем apple? И где поддержка спарков?

Может быть, спарки еще и поддерживаются в отличие от 32-битного apple, но я с ходу не нашел вчера, когда искал.

Не видел, как отказываются от поддержки 32-битных систем apple?

Это Apple от них отказалась, а не Rust.

А что со спарками? Можете дать ссылку? Вообще-то, живая система.

Нужны мне твои спарки. Rust - FOSS проект. Поддержка архитектур с неба не падает. Тебе нужно - пили.

Чё штакаешь и шлангуешь?

Пока я просто задаю вопрос.

Не видел, как отказываются от поддержки 32-битных систем apple?

Не знал даже, что они еще существуют.

И где поддержка спарков?

Спарки - это архитектура, а не ОС. Tier 2 platform.

Так что с поддержкой именно ОС? Что такого Rust требует от ОС?

Ну, и чего тогда спорить стали?

Ох, до чего же тяжело бывает общаться с программистами!..

Нечего дезу распространять и всё будет ок.

Извините, но спорить до усрачки, отстаивая свою точку зрения, я не стану. Всего доброго!

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

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

faq2 (25.06.20 16:47:30)

Дата регистрации: 25.06.20 16:33:16

Слишком уныло, толстячок.

Это не точка зрения, а маняфантазии.

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

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

Промазал, отписал анону. Вопрос и правда - без подвоха. Можно - можно, не можно - не можно, просто интересно как эту проблему решают, если решают.

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

Эмм, понятно что оно шагает семимильными шагами, но как бэ, может пример хоть какой-то референсный есть?

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

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

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

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

В изначальном сообщении нет слов «сложная вещь». Просто не интересно, раз ты знаешь как это делается в альтернативном языке, значит знаешь как это делается в раст, осталось просто попробовать реализовать.

В Rust пока можно лишь переопределить глобальный аллокатор: https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html

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

Вот какой-то тип пытался делать NUMA-aware allocator:

https://github.com/bastion-rs/numanji

Но там всего 8 коммитов, я хз насколько он работоспособен.

никому в принципе не интересно разжевывать механизм работы

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

Остальное и правда спорно покорно и кто как хочет тот такие фломастеры и кушает.

Т.е. примерно как с таймзонами в старых версиях глибЦ. Понятно, ну надеюсь reentrant интерфейсы подвезут, спасибо за пояснения.

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

Непонятно для чего ты создал этот тред, просто пособачиться с позиции крестокаши в которой уже что-то успели написать за более чем 20 лет существования?

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

Понятно, ну надеюсь reentrant интерфейсы подвезут

Не работал с NUMA, но глобальный аллокатор обязан быть thread-safe.

Так что тебе или тому кто реализовал методы у трейта GlobalAlloc

unsafe fn alloc(&self, _layout: Layout) -> *mut u8;
unsafe fn dealloc(&self, _ptr: *mut u8, _layout: Layout);

нужно делать их со спин-локами/мютексами…

Но когда сделают локальные аллокаторы, всё будет гораздо лучше.

Кстати, вот тут тоже спрашивают про NUMA: https://github.com/rust-lang/wg-allocators/issues/29

Разница между реинтрант и тредсейф аллокатором будет примерно следующая:

маллок как ни крути должен быть тредсейф, но вот выбор конкретного маллок и его параметров в зависимости от заданного параметра хотелось бы иметь реинтрант, дабы не вводить лишнюю битву за ресурсы на пустом месте, т.к. в точке где ты знаешь тип объекта ты и так знаешь способ которым хотел бы его в данном случае выделить, тратить время на вычисления тут такое себе удовольствие тебе надо получить буфер и разместить там объект. Конечно это всё можно обыграть через TLS, но работа с ним чуть но дороже чем со стеком напрямую, да и напоминает использование глобальных переменных для хранения состояния ПО. Хотя может в нынешние времена это совсем экономия на спичках.

Не нужно?

Чего взорвался-то? Вопрос по делу, между прочим.

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

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

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

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

Да-да, можно сказать «а я хочу вот так без смарт-поинтеров, как деды в C». Ну так там и Drop нету, прийдется вообще все ручками удалять.

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

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

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