информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыSpanning Tree Protocol: недокументированное применениеСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 HP закрыла 16-летнюю уязвимость... 
 Microsoft советует пользователям... 
 MS Edge обогнал FireFox 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Файловый кеш ОС позволит достичь того же, просто немного... 13.06.05 14:16  Число просмотров: 2982
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Благодяры кэшу я хочу достигнуть
> такого эффекта - в памяти хранятся только те элементы
> которые сейчас используются, это должно очень сильно
> ускорить всю программу.

Файловый кеш ОС позволит достичь того же, просто немного переформулированного результата: в памяти хранятся только те СТРАНИЦЫ, под которыми находятся элементы, которые сейчас используются

> Что касается предложенного варианта кэширования - меня
> терзают сомнения относительно его эффективности, особенно
> при большом кэше. Если у нас кэш размером N элементов, то
> процесс уменьшения показателей будет занимать O(N), а это

Не следует забывать о чем речь. Кеш сам по себе на несколько порядков быстрее того, что он кеширует. Кроме того, операцию уменьшения показателей нужно производить не чаще раза в секунду (можно и реже) и сделать настраиваемым.

> может быть существенно (еще надо учитывать что будут
> выполняться действия типа взятия логарифмов). Я предложу

Никакого взятия логарифмов. Все что можно затолкать в таблицы - нужно туда затолкать. ПРИМЕРНОЕ (а другое нам и не нужно) вычисление логарифма можно выполнить за несколько тактов.

> другой вариант, более быстрый в этом плане.
> Сами элементы хранятся в бинарном дереве, так что
> искать/удалять элемент мы можем за O(logN). Также создадим
> очередь из элементов кэша, с ней операции будут занимать
> O(1). При обращении к элементу будем делать следующее:
> 1) если элемент найден в кэше, то переносим его в голову
> очереди
> 2) если элемент не найден, то удаляем элемент из хвоста
> очереди, грузим запрошенный и помещаем его в голову очереди
>
> Единственный минус этого способа - если элемент запрошен
> много раз, а потом забыт, то он вылетит из очереди очень
> быстро. Но при равномерном обращении наиболее
> востребованные элементы будут находиться ближе к голове
> очереди.

Этот вариант ты уже описал в корневом посте. Если говорить об эффективности, то метод с увеличением и уменьшением количества обращений универсальнее и будет давать нормальные результаты в бОльшем числе случаев. Метод с самосортирующимся списком проще и довольно эффективен для большинства РЕАЛЬНЫХ случаев.

> Т.е. я думаю чем больше нагрузка на всю систему, тем более
> адекватно кэш должен выбирать элементы для хранения. Имхо
> это неплохо.

Адекватным является как раз выбор не только по тому, как давно элемент был в последний раз затребован, но и по тому, насколько часто вообще этот элемент был нужен.
<theory> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach