LINUX.ORG.RU

История изменений

Исправление 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».

Правда, есть некоторые сомнения в том, что все это ускорение кому-то интересно в случае кэширования, где по условию процесс доставания элементов мимо кэша достаточно медленный.

Но мне понравились модели доступа, даже если все это практически никому не нужно.