Size: a a a

Rust — русскоговорящее сообщество

2017 November 23

分解物質 in Rust — русскоговорящее сообщество
Anton TrionProg
Хах, а где Box хранится? напрямую в Jemalloc-е вроде бы(хотя можно кстати это подправить, ведь тип и его размер нам известны). Те Vec<Box<T» это массив из ссылок, имеющий длину 44 байта, но юзающий блок кучи в 64, и куча T, имеющих длину 33, но юзающих блоки в 64. И вот, память куда-то делась? А если запишешь Vec<T>, то получишь один сегмент длиной 44*33=1452, который будет юзать сегмент длиною 2048

Вроде так jemalloc устроен, как я понял
> куча T
что?
источник

分解物質 in Rust — русскоговорящее сообщество
jemalloc не знает о типах
источник

分解物質 in Rust — русскоговорящее сообщество
jemalloc это реализация стандартного С malloc()
источник

分解物質 in Rust — русскоговорящее сообщество
источник

FS

Filipp Samoilov in Rust — русскоговорящее сообщество
Oleg ℕizhnik
а вот представим, что один мой друг некогда написал такой кот
https://gist.github.com/Odomontois/f1ed29ea121564aa009facd0229c5fec
но написав его он увидел ,что джавовый аналогичный всё равно гоняет в полтора -два раза быстрее
и он такой думает: ЧЯНДТ
помогите моему другу, время пошло
Атака клонов
источник

Oℕ

Oleg ℕizhnik in Rust — русскоговорящее сообщество
Filipp Samoilov
Атака клонов
как без клонов?
источник

Oℕ

Oleg ℕizhnik in Rust — русскоговорящее сообщество
там предполагается, что чаще всего это будут типы навроде i32 или там struct(i32, i32)
источник

V

Vladimir in Rust — русскоговорящее сообщество
делай копи
источник

С

Серж in Rust — русскоговорящее сообщество
Oleg ℕizhnik
а вот представим, что один мой друг некогда написал такой кот
https://gist.github.com/Odomontois/f1ed29ea121564aa009facd0229c5fec
но написав его он увидел ,что джавовый аналогичный всё равно гоняет в полтора -два раза быстрее
и он такой думает: ЧЯНДТ
помогите моему другу, время пошло
я не знаю что там, но там очень много вызово clone и там где джавовый код наверняка передавал ссылки на объекты, мне тут недавно объяснили, что клон это когда дипкопи и дорого (на хипе).
источник

С

Серж in Rust — русскоговорящее сообщество
ну или аллоцировал быстрее, потому что аллокация из преаллоцированной памяти в жвм
источник

AT

Anton TrionProg in Rust — русскоговорящее сообщество
*куча T>
имеется ввиду множество, не heap
источник

С

Серж in Rust — русскоговорящее сообщество
без клонов если сначала посчитать сколько хипа выделить, в дереве хранить индексы на элементы в превыделенном буфере
источник

С

Серж in Rust — русскоговорящее сообщество
ну добавлять и удалять элементы будет не здорого конечно же, как и сортировать
источник

AT

Anton TrionProg in Rust — русскоговорящее сообщество
Нафига clone в new, в том то и прикол, что если вызываешь clone, то получаешь 2 объекта, для каждого из которых вызываются drop + копирование памяти. clone зло, это же очевидно
источник

V

Vladimir in Rust — русскоговорящее сообщество
клон специализирован для копи чтоб юзать копи?
источник

Oℕ

Oleg ℕizhnik in Rust — русскоговорящее сообщество
Я забыл сказать
источник

Oℕ

Oleg ℕizhnik in Rust — русскоговорящее сообщество
Что я тоже усомнился в клонах
источник

Oℕ

Oleg ℕizhnik in Rust — русскоговорящее сообщество
И для конкретной задачки переписал всё для конкретных типов
источник

Oℕ

Oleg ℕizhnik in Rust — русскоговорящее сообщество
Которые были i32 и i32
источник

Oℕ

Oleg ℕizhnik in Rust — русскоговорящее сообщество
везде был неявный copy, где сейчас clone
источник