HettМожно виртуалку поставить и там запустить.
Думаю что виртуалка нам покажет парадоксальный результат.

Нам сложно будет отделить эффект влияния гостевой ОС на кеш L3 от нашего
полезного эффекта от приложения.

no56892Вы бы хоть набросали код какой оптимизируете в джава по кэш миссам. А то оптимизируете оптимизируете, и тут бац надо посчитать как на оптимизировали, и на оптимизировали ли вовсе.
Недавно просматривал статьи по SLRU, 2Q, ARC, e.t.c. и заметил что все методы "эффективного кеширования"
не имеют никакой общей теоретической формулы эффективности. Во всех случаях авторы
брали какие-то конкретные данные из внешнего мира. Файлы в файловой системе. URL-s на
прокси или в игровом клиенте. Тоесть говорить к примеру о том что 2Q лучше LRU можно
только после прогона на реальных выборках. С повторами... характерными для веб-сервинга,
актокорреляциями и прочее. Мне кажется что тут есть аналогия с топиком. Мы не можем
просто говорить о том что где-то в космосе существует стек аппаратных кешей и мы
кодим исходя из cache friendly. Некоторые отсылки к кешам есть в семинаре по Disruptor .
Но дизраптор это та еще херня. Попробуй его натянуть на реальное приложение. Бесконечный
тюннинг получается. Тут подкрутил - там упало. А может Unsafe memory как в Hazelcast ? Вариант!
Но кто этот Хозел-Каст купил с лицензией и отреверс-инжинерит? Или кто исходники Apache Cassandra
разберет? Чтоб проанализировать юзает ли эта тётка cache-friendly или нет.

Из практики БД еще пример. Ты тут из кожи вон лез... оптимизировал аналитический SQL query.
Скобками его загнал в определенный order joins. Хинтов добавил. Пабеда!
Быстро летает ночью. День начинается и капец. Конкуренция sessions. Бафер пул "вымывается" другими query.
Фигли.. у тебя индексных чтений больше. Всё затормозило и сдулось. А прерыдущий план - вообще
по дискам бегал. Мультиблочным. Медленнее данные собирал но никому не конкурировал.
И нахер тогда я старался? Директивно всё оптимизировал когда все по дефолту прилично работало.
По рукам себя линейкой....

Вобщем сорян за лирическое отступление.

Leonid Kudryavtsev,

Возникли следующие мысли:

1. Наш сферический алгоритм в вакууме (далее САВ ) должен иметь понятие о том в окружение какого железа он существует.
Cortex? Intel? Amd?

Здесь надо признать что мы делаем шаг в сторону от классического java кодинга и пытаемся приоткрыть занавес платформы.

2. После того как мы получили тип железа - мы далжны собрать максимум сведений о топологии кешей и о всех их количественных
Характеристиках.

Чуть позже я приаттачу поясняющую картинку.

3. Мы должны ввести в САВ вектор параметров который даст нём возможность регулировать влияние на каши и топологию.

Пару лет назад 18093734 я поднимал тему трех бенчмарков. В разрезе
популярных ЯП (C++/Python/Delphi/C# e.t.c) и изначально заданными задачами.
А именно:
1) CPU
2) Доступ к памяти
3) Производительность I/O

Из всех трех удалось реализовать только первый (CPU). Бенчмарк граф. алгоритма трассировки
луча с использованием вещественных чисел. Фактически нужный код
был написан. Спасибо сообществу. Остались неоконченными универсальные
shell-скрипты для тестинга всех ЯП на всех платформах. Эта цель так и осталась целью. Что впрочем
не мешало активным мемберам тихонько тестить 2-3 разных ЯП на своих
конфигурациях и репортить таблички с отчотами. Отчоты пролили много
интересных фактов. Как например провальные результаты Python по сравнению
с другими системами. Это кстати ставит под сомнение тезис Зимаргла к том
что Python быстрее чем "C" и тезис другого чела в ПТ который доказывал
что строки в Python это самые быстрые строки в мире ... впрочем
кто это был я забыл да и топик уже не помню.

Приятно также порадовал компиллятор Rust который в рамках небольших погрешностей
был где-то быстрее чем С/C++ реализации.

Но остались еще 2 теста которые я так и не смог сформулировать в виде
постановки.

И мой интерес к этому топику возник именно в разрее теста номер (2).
Я долго думал какую постановку взять для тестирования бенчмарков
по memory но так и не придумал. Мне нужны были алгоритмы которые
мощно и равномерно грузят полный диапазон бортовой памяти вашей
рабочей станции или сервера (2/4/8/16G) и не только диапазон но
и также интенсивные аллокации-деаллокации (malloc/free,
new/delete e.t.c.). И здесь алгоритмы сортировки не подходили.
Они обычно не используют явные аллокации-деаллокации и соотв
мой тест был-бы не полным.

Как вариант я рассматривал реализации кешей (LRU/2Q/MQ/ARC)
+ некая гипотетическая задача которая будет делать интенсивные
поисковые операции по кешам. Например поиск пароля по хешу.
Ну ... что-то вроде rainbow-table (по сабжу я не знаю пока как
работает радужня табличка но надеюсь что ей полюбому нужен
какой-то доступ к дисковым хранилищам уже расчитанных хешей
объем которых уже давно превысил оперативку. Это как раз
удобная постановка для кеша). Сюда-же можно включить
несколько бенчмарков.
1) Рост кеша (population)
2) Стационарная фаза (обычная работа)
3) Деградация (вытеснение старых ключей полностью новыми)

Но вобщем-то если у кого-то будут мысли - то пишите.