История изменений
Исправление a--, (текущая версия) :
У тебя chunked array, какие еще прямые адреса элементов в памяти?))
Немного подумав, я пришел к мысли как еще ускорить твой дизайн, выкинув нафиг и unordered_map. Причем, похоже, даже и в многопоточке. В варианте «один поток крутит LRU/2Q, а другой достает закэшированные элементы без unordered_map».
Правда, есть сомнения в том, что все это ускорение кому-то интересно в случае кэширования, где по условию процесс доставания элементов мимо кэша достаточно медленный.
Но мне понравились модели доступа, даже если все это практически никому не нужно.
UPDATE: именно про модели доступа (проще говоря, указатели) в Раст мы и разговариваем в этой теме.
Исправление a--, :
У тебя chunked array, какие еще прямые адреса элементов в памяти?))
Немного подумав, я пришел к мысли как еще ускорить твой дизайн, выкинув нафиг и unordered_map. Причем, похоже, даже и в многопоточке. В варианте «один поток крутит LRU/2Q, а другой достает закэшированные элементы без unordered_map».
Правда, есть некоторые сомнения в том, что все это ускорение кому-то интересно в случае кэширования, где по условию процесс доставания элементов мимо кэша достаточно медленный.
Но мне понравились модели доступа, даже если все это практически никому не нужно.
UPDATE: именно про модели доступа (проще говоря, указатели) в Раст мы и разговариваем в этой теме.
Исходная версия a--, :
У тебя chunked array, какие еще прямые адреса элементов в памяти?))
Немного подумав, я пришел к мысли как еще ускорить твой дизайн, выкинув нафиг и unordered_map. Причем, похоже, даже и в многопоточке. В варианте «один поток крутит LRU/2Q, а другой достает закэшированные элементы без unordered_map».
Правда, есть некоторые сомнения в том, что все это ускорение кому-то интересно в случае кэширования, где по условию процесс доставания элементов мимо кэша достаточно медленный.
Но мне понравились модели доступа, даже если все это практически никому не нужно.