LINUX.ORG.RU

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

 


1

7

Это какой-то позор.

Через 5 лет после выхода версии 1.0 до сих пор нет поддержки локальных аллокаторов. Ужас…

Надеюсь аллокаторы в Rust появятся до того как дропнут поддержку Windows 7 и Mac OS 10.7: https://github.com/rust-lang/release-team/issues/2

Единственно, что обнадёживает, что Rust пишут не фанатики с лора, а программисты. В частности TimDiekmann, который пилит https://github.com/rust-lang/wg-allocators написал что вдохновлялся вот этим видео: https://www.youtube.com/watch?v=LIb3L4vKZ7U и the Phobos Standard Library of the D Programming Language. Это даёт хоть какую-то надежду что будет сделано норм…

★★★

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

fsb4000 ★★★ ()
Ответ на: комментарий от AntonyRF

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

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

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

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

vertexua ★★★★☆ ()
Ответ на: комментарий от fsb4000

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

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

anonymous ()

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

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

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

dave ★★★★★ ()
Ответ на: комментарий от vertexua

Притом в 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

fsb4000 ★★★ ()
Ответ на: комментарий от dave

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

anonymous ()

и the Phobos Standard Library of the D Programming Language

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

SR_team ★★★★ ()
Ответ на: комментарий от AntonyRF

Любой?

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

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

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

fsb4000 ★★★ ()
Ответ на: комментарий от anonymous

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

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

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

fsb4000 ★★★ ()
Ответ на: комментарий от fsb4000

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

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

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

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

anonymous ()
Ответ на: комментарий от dave

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

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

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

Ещё нет.

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

Нет.

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

Шта?!

RazrFalcon ★★★★★ ()

Насколько я понимаю работа в этом направлении ведется: 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, мне хватает, глобальный аллокатор стандартный.

Int64 ★★★ ()
Ответ на: комментарий от tailgunner

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

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

dave ★★★★★ ()
Последнее исправление: dave (всего исправлений: 1)
Ответ на: комментарий от dave

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

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

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

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от dave

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

anonymous ()
Ответ на: комментарий от RazrFalcon

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

faq2 ()
Ответ на: комментарий от faq2

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

anonymous ()
Ответ на: комментарий от anonymous

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

faq2 ()
Ответ на: комментарий от anonymous

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

faq2 ()
Ответ на: комментарий от faq2

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

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

anonymous ()
Ответ на: комментарий от faq2

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

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

anonymous ()
Ответ на: комментарий от faq2

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

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

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

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

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

fsb4000 ★★★ ()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

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

faq2 ()
Ответ на: комментарий от fsb4000

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

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

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

anonymous ()
Ответ на: комментарий от faq2

Понятно, ну надеюсь 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

fsb4000 ★★★ ()
Ответ на: комментарий от fsb4000

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

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

faq2 ()
Ответ на: комментарий от faq2

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

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

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

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

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

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

vertexua ★★★★☆ ()
Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от faq2

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

anonymous ()