D
Ну, кроме мб сложности алгоритмической
Size: a a a
2021 October 19
D
Но к памяти то отношение не имеет, конечно же
c
Minoru
@ttldtor: если смотреть с точки зрения виртуальной памяти, то проблема двусвязных списков в том, что каждая их нода может оказаться в отдельной страничке памяти и, следовательно, каждое обращение будет вызывать page fault. С массивами такого можно добиться, только сделав элементы крупнее страницы памяти
@ttldtor: если смотреть с точки зрения виртуальной памяти, то проблема двусвязных списков в том, что каждая их нода может оказаться в отдельной страничке памяти и, следовательно, каждое обращение будет вызывать page fault. С массивами такого можно добиться, только сделав элементы крупнее страницы памяти
t
ну, то есть. Вот у нас какой-то список с адресами
1 30 40 349 200 90
Мы говорим: эй железка, ну ка линеаризуй задёшево
и получаем
i i+1*s i+2*s i+3*s i+4*s i+5*s
где s - размер элемента (учли выравнивание, допустим)
1 30 40 349 200 90
Мы говорим: эй железка, ну ка линеаризуй задёшево
и получаем
i i+1*s i+2*s i+3*s i+4*s i+5*s
где s - размер элемента (учли выравнивание, допустим)
t
можно даже не перемещать в памяти, да
t
это, уже немного тема в бок
D
Мы такого добивались кастомным менеджером памяти и аллокаторами
D
Не уверен, что это то решение, которое тебе нужно
c
Minoru
@ttldtor: м, слушай, наверное ты таки прав и «дефрагментация» имеет смысл :)
@ttldtor: м, слушай, наверное ты таки прав и «дефрагментация» имеет смысл :)
t
тут да, не дефрагментация, а линеаризация адресов
t
если мне такое любая ось уже сейчас может сделать и ей нужно только побольше виртуальных адресов, то ок
t
меня интересует, как оно в командах процессора будет всё
c
Minoru
или нет, не имеет смысла…
или нет, не имеет смысла…
D
А как ты это себе это представляешь? Какие-то нестандартные маллоки?
D
И почему недостаточно аллокаторов?
D
Ну, да, придется написать кода
t
забудьте про линеаризацию)
D
(или может ну их связные списки то?)
D
Я теперь запутался :)
t
я же сказал, что это "тема в бок"