Alexander
я себе чуть очки не сломал
分解物質
Anton
Куча иероглифов, согласен.
Alexander
GC нужен, чтобы была общая рекурсия, нормальные замыкания например
Alexander
без них страдания типа растовых, и там ещё хорошо заделали
Anton
Тут можно долго спорить, что является оп, что не является, но если язык позволяет Struct+Implementation, то он должен работать хорошо и удобное, без описания тысяч гетторов хотя бы.
Маjко
Какие страдания с замыканиями?
Alexander
другое дело, что раст нужен там где страдания вместо удобства это нормально
Маjко
Ну вообще
Alexander
или копируй или доказывай что livetime является включением
Oleg
а как сделать замыкание, чтобы часть переменных по ссылке, а чать move?
Cuno
Какие страдания с замыканиями?
Нельзя захватывать всё подряд по ссылке и не париться, как люди привыкли делать в языках с GC.
Маjко
а как сделать замыкание, чтобы часть переменных по ссылке, а чать move?
Лайфтаймами доказать, что замыкание не переживет ссылки
Anton
мне толком никогда не требовалось. я перешел на раст с ++. Берешь бумажку, карандашек, рисуешь классики/структурки, указываешь, кто кого ХРАНИТ(Arc) и кто о ком ЗНАЕТ(Weak), потом пишешь. Да, в расте вообще, сначала 7 раз думаешь, потом пишешь. Это не C# =))
Кстати в swift вроде ВСЕ Arc.
Anton
GC нужен, чтобы была общая рекурсия, нормальные замыкания например
Oleg
Лайфтаймами доказать, что замыкание не переживет ссылки
но если оно переживёт там парочку ссылок, и их я хочу замувить
Vladimir
а как сделать замыкание, чтобы часть переменных по ссылке, а чать move?
Делаешь мув, а переменные которые по ссылке делаешь ref биндингом
Oleg
ну всё тогда, никаких страданий, чо
Маjко
мне толком никогда не требовалось. я перешел на раст с ++. Берешь бумажку, карандашек, рисуешь классики/структурки, указываешь, кто кого ХРАНИТ(Arc) и кто о ком ЗНАЕТ(Weak), потом пишешь. Да, в расте вообще, сначала 7 раз думаешь, потом пишешь. Это не C# =))
Кстати в swift вроде ВСЕ Arc.
> Arc Weak
Ты как-то не правильно готовишь быстрый системный язык. Может реально лучше на джавку?
Oleg
На будущее, если меня не будет: можете унижать людей "Может лучше на скалку" и сразу говорить, чтобы мне в личку кидали резюме
Vladimir
> Arc Weak
Ты как-то не правильно готовишь быстрый системный язык. Может реально лучше на джавку?
На самом деле, несмотря на то, что все делают оптимизации, юзают овнед здачени, унбоксед кложур и ТД. А по факту оказывается, что всё это почти не влияет на производительность в реальной задачи(
Маjко
Anton
И где же я ошибаюсь?
Anton
> Arc Weak
Ты как-то не правильно готовишь быстрый системный язык. Может реально лучше на джавку?
Маjко
Я избавившись от RefCell в горячем пути довольно хорошо выиграл
Alexander
вот когда все запихивают в Arc/RC а потом говорят про GC то иногда смешно становится
Alexander
хорошо что в расте так не делают
Vladimir
Ну если у него связи такие, что обратная связь нужна, то как тут без арков, графы там всякие сложные
Vladimir
Межпоточно используемые
Сережа
а как сделать замыкание, чтобы часть переменных по ссылке, а чать move?
использовать c++ [&po_ssike, po_move = std::move(origin)] { ... }
Alexander
нужны нужны
Alexander
но иногда GC оказывается тогда выгоднее
Vladimir
Чем РЦ?
Vladimir
Сложно верится
Alexander
зависит от паттерна работы
Anton
Потому что
borrowing юзаем временно, например, если составляем список объектов, которые нужно изменить
Box юзаем тогда, когда не хотим, чтобы из-за него структура распухла в памяти, либо есть рекурсия
Rc.. А он не работает с многопоточным кодом никак, даже когда он куда-то вложен. Те захотел добавить потоки — рефакторинг
Arc уже позволяет многопоточность. У меня всегда код многопоточный(спасибо расту, писать его не сложно и толком безопасно, дедлоки на бумажке находятся), поэтому Rc я не юзаю никогда
Vladimir
Хотя зависит от того как выгоду мерчть
Сережа
gc всегда выгоднее, когда ты можешь себе это позволить - написал на го и забыл!
Alexander
с GC у тебя очень дешевые аллокации
Alexander
в го дурацкий гц, как только вылезаешь из под того, под что проектируется
Alexander
соотвественно без GC ты или плодишь свои аллокаторы (тогда выиграешь) или при большом кол-ве быстромрущих объектов - теряешь в скорости
Alexander
если ты на го, то не работает
Alexander
там одно поколение
Сережа
а под что гц в го проектируется?
Сережа
быстромрущих объектов на хипе
Alexander
low latency
Alexander
там начиная с некоторой скорости аллокации и большого хипа все адски деградирует, и потребление памяти unbounded
Сережа
говорят что он тормозит на больших кучах, а еще что это побороли
Anton
у меня как раз все во всяких пулах лежит, и вообще у меня редко объекты летают в куче, они всегда в Vec<> как правило. Наверно специфика кода, когда есть карта, на карте есть деревья и здания, у зданий есть окна и двери
Anton
соотвественно без GC ты или плодишь свои аллокаторы (тогда выиграешь) или при большом кол-ве быстромрущих объектов - теряешь в скорости
Alexander
ну в языках с GC ты в итоге можешь сделать тоже самое
Alexander
раз уж решили что можно
Vladimir
Разве жмалоок не умеет делать то что ты хочешь?
Alexander
но на языке без ГЦ можно все сделать быстрее и лучше
Anton
Просто GC весьма умный, он заюзает кучу, когда объект редкий, или, пулы для быстрых.. Когда-то натыкался на уровни кучи в жабе, но.. вроде и в jemalloc тоже все по пулам раскидано, правда по пулам размера степени 2ки, а не специализированных под определённый тип (типа Vec<T>)
Vladimir
Лучше не может быть, чем у нас
Alexander
Ты в чате раста, не забывайся
ясно же что как бы допилим линейные типы, то раст станет не нужен
Сережа
байтолюбы на си специально вставляют padding в свои стркутурки, чтобы было кратно 4 и видно что кратно
Сережа
это бест практис
Vladimir
Просто GC весьма умный, он заюзает кучу, когда объект редкий, или, пулы для быстрых.. Когда-то натыкался на уровни кучи в жабе, но.. вроде и в jemalloc тоже все по пулам раскидано, правда по пулам размера степени 2ки, а не специализированных под определённый тип (типа Vec<T>)
А зачем тебе специализированные пулы? Хранить Vec<Box<T>>?
Anton
Другое дело, как GC чистит кучу, вот тут то у меня много нареканий. например, в системе реального времени НЕЛЬЗЯ повесить систему, пока GC думает. Там должно быть все прозрачно. Сделал Arc::new значит аллокнул память
A64m
Я думал, это чат Го, а название ироническое
Vladimir
ясно же что как бы допилим линейные типы, то раст станет не нужен
Вот и бегите в свой хаскель
Сережа
расскажи нам парочку
Alexander
скажешь, что в языке без ГЦ при особом старании можно лучше любой кейс решить - не нравится
Alexander
скажешь, что раст не нужен - не нравится
Anton
Хах, а где Box хранится? напрямую в Jemalloc-е вроде бы(хотя можно кстати это подправить, ведь тип и его размер нам известны). Те Vec<Box<T» это массив из ссылок, имеющий длину 44 байта, но юзающий блок кучи в 64, и куча T, имеющих длину 33, но юзающих блоки в 64. И вот, память куда-то делась? А если запишешь Vec<T>, то получишь один сегмент длиной 44*33=1452, который будет юзать сегмент длиною 2048
Вроде так jemalloc устроен, как я понял
Anton
А зачем тебе специализированные пулы? Хранить Vec<Box<T>>?
Маjко
А говоришь по памяти не раскидано
Маjко
Vec:: with_capacity(1452) будет выглядешь как сегмент в 1452 элемента
Маjко
Так же как Vec созданный из итератора в 1452 элемента