> Тогда не понятно в чём может быть затык. Ты бы лучше куски кода > постил, а то телепатия нынче редкость.
На текущий момент - затык с диском. > > - Послушал как работает машина (в натуре на слух), и понял - нужно > > нафиг отключить буферизацию файловых операций. То бишь указал флаги > > FILE_FLAG_WRITE_THROUGH, FILE_FLAG_NO_BUFFERING > > Ага. Именно назад, к природе. А ты ещё на IBAPI бочку катил ;) Ну не равняйте этого с этой, пожалуйста. > На самом деле FILE_FLAG_WRITE_THROUGH имеет смысл для увеличения > надёжности и когда памяти в компе мало. Если памяти много, то > этот флаг лучше не ставить. FILE_FLAG_NO_BUFFERING я вообше не > понимаю чем тут может помочь. Я тоже. Но это работает и ладно. > > отказаться от > > мелких блоков, а перейти к блокам занимающим всю страницу целиком. > > Продолбенился над реализацией целый день. Получилось красиво. > > И - о чудо! У меня многопоточная реализация стала работать вровень с > > однопоточной. > > Ну что и следовало доказать. При увеличении размера блоков издержки > на синхронизацию в процентном отношении падают. Знаешь, Алексей, что меня веселит. Все всё знают, но до сих пор никто не дал готовый шаблон кода для управления индексом со словами - вот тут подключи менеджер страниц, который дает вот такой набор методов. На текущий момент времени, я осознал что увеличение размера блоков и прямой доступ к памяти кэша - это только часть требований. Не только осознал, но и реализовал. > > Напомню, мне нужно построить уникальный индекс для (по последним > > прогнозам) 100 лимонов элементов вида (ID1, ID2). Максимум что я смог > > осилить - 20 лимонов. > > Что значит осилить? Какая цель то? Есть множество пар (ID1, ID2). Их общее число где-то 350 лимонов. Уникальных - 100 лимонов. Нужно получить это множество уникальных пар. ID это целые числа. Начинаются с 1 и заканчиваются, полагаю, в районе 100 лимонов. Есть ещё одно правило - ID1 строго меньше ID2. Которое, возможно, сможет оптимизировать конструкцию индекса. ------------------------------------ Я там про два часа говорил. Я не учел, что при том махании топором неизбежно возникнут баги :( Короче, я провел эксперимент. Из последних модернизаций движка, управляющего кэшем и работающего с файлом - ассинхронный чтение и запись. Но это так - чисто для успокоения души. Как я и предполагал - чтобы потоки генерации не забивали поток выгрузки модифицированных страниц, при добавлении новой комбинации нужно как можно меньше модифицировать страниц. В моем случае (хеш таблица со списками отсортированных блоков) это 1-2 страницы. Если поддерживать отсортированность сквозь все блоки списка - производительность резко падает (модифицируется много блоков + из-за разряженности быстрее жрется память) Вот статистика по проведенному эксперименту overflow [4] - число переполнений буфера входящих данных flush [4879] - число опустошений этого буфера words [102104] - число слов, из которых потом генерировались комбинации ip [17758789] - число уникальных комбинаций. Это то, что как раз помещается в индекс hit ip [11215320] - это число обращений к кэшу, которые нашли ранее сгенерированную комбинацию d_pages [30010] - число грязных страниц кэша c_pages [90000] - число чисты страниц кэша BlockCapacity:127 - число элементов на блоке списка (короче на - на одной странице) Далее число блоков в списке / количество списков с такой длиной 13:14 14:5287 15:4681 16:18 Общее число списков в хеш-таблице - 10000. Размер кэша 120010 страниц. Как видно -таблица заполняется равномерно. Скорость упала в районе 14.5 млн комбинаций. Это как раз кэш закончился. Упала с 25 тысяч комбинаций до 300-400 комбинаций (это финальная скорость). Ассинхронная работа с файлом не помогла - хотя работало 4 потока генерации. Сразу после того как кэш закончился, поток выгрузки модифицированных страниц, стаблизировал соотношение 30 тыс / 90 тыс, и оно не менялось до самого финиша (+/- 10 страниц). Последние три лимона генерировались свыше 7 часов. Начальные 14.5 лимонов - полтора часа. ---- Вообщем движок есть. Я уже не знаю что туда можно прикрутить. Есть понимание - длина пути поиска должна быть как можно короче. Страницы должны заполняться как можно плотнее. Возможно это спорное утверждение. При вставке нужно модифицировать как можно меньше. ---- Вопрос - как это все объединить? Я тут поприкладывал умную книгу к голове. Две вещи понравились Первая - так называемые DST. Digital Search Tree. Высота дерева не больше числа байт в ключе. В моем случае она не превысит восьми. Хотя, вообще говоря - ID у меня 64-битное. Вторая - Б-деревья. Первая, в силу своей интутивной понятности, мне нравится гораздо больше чем вторая. Не требует расшеплений узлов, балансировки. Не нужно хранить ключ - он вычисляется при переходах. И я вроде как понимаю как можно сделать параллельную работу с индексом. Для первых двух байт ключа можно поддерживать таблицу в памяти. То есть, высота сократится до 6 уровней. Вторая вещь моим опухшим моском понимается. Но с трудом. Люди, скажите что нибудь. Хотя бы такую вещь - FB может параллельно добавлять новые ключи в индексы? Я уже начинаю верить, что в FB есть что-то нереальное, раз он в состоянии управлять индексами для таблиц размером больше 25 лимонов записей. Я на выходных провел еще один эксперимент. И выяснил - пиво уже не в состоянии расслабить мой моск. Его вытесняют в течении часа :( Коваленко Дмитрий.
