MS
Size: a a a
2020 September 16
R
Я похожий трюк использовал с bumpallo и rayon. На тредпул создавал по арене и использовал внутренний индекс треда, что б выбрать арену.
R
Собственно тогда вообще мьютекс не нужен. Но unsafe код присутствует
RA
А бумпало все еще делает memcpy на каждую аллокацию?
R
Что именно он memcpy-л?
R
Если ты используешь Box::new_in, или Bump::alloc, то значение будет memcpy-ровано в аллоцированный блок, но там других функций хватает
RA
Ну типа я сделал арену на 10мб, выделил в ней массив на 5мб. У меня будет memcpy на 5 мегабайт, хотя память уже есть, и бамп аллокатору достаточно, собственно, бампануть указатель. Или я не прав?
MS
Ну типа я сделал арену на 10мб, выделил в ней массив на 5мб. У меня будет memcpy на 5 мегабайт, хотя память уже есть, и бамп аллокатору достаточно, собственно, бампануть указатель. Или я не прав?
Неправ.
MS
Такое сработает только с MaybeUninit
R
Если ты пытаешься аллоцировать '[u8; 5 242 880]' то их еще проинициализировать надо
MS
Иначе он обязан инициализировать.
R
Можно без memcpy, если ты аллоцируешь слайс из итератора, который выплюнет 5 мегабайт нулей. Будет memset :)
R
Если не повезет, то 5 миллионов мемсетов
R
В любом случае арены не заточены под крупные аллокации. Они для hot-path с кучкой мелких аллокаций
RA
Ну зачем-то же есть https://docs.rs/bumpalo/3.4.0/src/bumpalo/lib.rs.html#623-653 с комментариями вида "очень надеемся, что llvm это соптимизирует" :)
R
Ну это только если ты создаешь значение на месте. Однако какая-то запись в память все равно будет
R
Будь то memcpy, memset или прямо инструкции для записи в память
R
Разве что паддинг байты могут быть пропущены
RA
Но при создании сначала на стеке-то будет, условно говоря, memset + memcpy вместо только memset. В общем, без гарантированного placement new остается только "надеяться на оптимизации llvm".
R
Та же проблема и у Box::new. И вообще любого safe аллокатора