Ага, спасибо. Те. неделю заняла по сути индексация вчистую, без всякого разбора документов. Очень круто на самом деле — мне б терпения ждать не хватило :)
Еще один совет кстати вспомнил: проверить полную (!) выдачу поиска. После того, как выяснилось, что до 90% фактически совпадающих документов Xapian тупо теряют — мои тесты в свое время быстро свернулись :)
Вложенные вызовы убьют кеш конечно. Но тут они последовательные. И записываются одни и те же 256 байт (или меньше). Фактически фрейм растет и заполняется маркерами, но остается маленьким, горячим и полностью в L1.
Под критической секцией я имел в виду еще и всю прикрытую ей работу, а именно _Orphan_me. Там длинная цепочка унаследованных деструкторов, под десяток call-ов, ну и в самом низу защищенное локом обновление списка итераторов контейнера. Те. недешевый сам по себе деструктор вызывается в 3 раза чаще, отчего и основные тормоза.
L1 кеш куда больше 256 байт, а стек попадает примерно в одно и то же место при последовательных вызовах. Это около 100 тактов. Кроме того не все вызовы пишут 240 байт, например operator ++ пишет всего 28 байт, для чего делается 7 mov.
Основные тормозища видимо из-за… критической секции в деструкторе отладочного итераторе!
Как бенчмаркать тру-кроссплатформенно (см. включая AIX, z/OS, iOS, Android, и микроконтроллеры вплоть до smart утюгов) я не знаю. Под Linux, а также FreeBSD 7.2 и выше можно мерить время gettimeofday(2), аффинити прибивать либо sched_set_affinity(2) (если строго под Linux), либо pthread_setaffinity_np(3), ну и крутить governor тулзами конкретной дистрибуции. Под Solaris доки читать надо уже про processor_bind(), ну и так далее.
Эта, книжку вслух мне зачитывать необязательно. Я картину мира представляю довольно хорошо, не одна реализация STL обследована, да и не один вектор написан, собственно.
Зачем вектору (!) именно итераторы, плохо понятно все равно. Внятный юзкейс, который требует (!) итераторов вектора не могу себе представить.
Впрочем польза от этого обсуждения уже похоже есть, а именно: в предыдущем комментарии число 200 считать числом 10.
Гляди уже код, там в оригинале SetThreadAffinityMask(0) на каждый старт таймера зачем-то, и восстановление при выходе. Что опять же оказалось удобно для иллюстрации, что первого порыва исправить 0 на 1 в этом месте и успокоиться недостаточно, иначе в промежутка скачки с ядра на ядро дадут эффект. Если убрать SetTAM() из таймера и оставить один удар на процесс, этого должно хватить, конечно.
Так точно. У меня именно 2005, после #define _SECURE_SCL 0 перед include-ами внезапно становится примерно 0.078 сек на оба теста. Фарш из пяти лишних проверок и вызовов __imp___invalid_parameter_noinfo однако не помогают перформансу ни хрена.
Но вот иллюстрировать дрожание как раз куда лучше с этим фаршем. Нагляднее. ;)
Ну. Среднее считать как бы действительно не очень умно, если дисперсия зашкаливает. Тест ведь нерандомизированный нихрена, дрожать в 1.5 раза ну никак не должно. В моей среде исполнения, как видишь, зашкалила. Что было в твоей среде, не могу знать. (Возможно, все было ок, подробности своей методологии замеров ты не приводишь.)
Заметка, соотв-но, именно про борьбу с дисперсией как явлением, а не каким-либо конкретным тестом.
Я когда-то бенчил Xapian. Цифр нет, помню ряд занятных фактов. Disclaimer: это было минима год назад, ситуация могла измениться.
1. Первые 10 документов в порядке тн. релевантности (vanilla BM25) выдавались дико быстро. Видимо, для каждого слова хранится топ-N документов в порядке убывания частоты. Значение N выяснять не стал.
2. Число матчей при этом втупую врало, сильно. Вместо точного числа оно при таком поиске делает оценку, оценка получается слишком грубая.
3. Поиск фразы из двух слов резко исправляет ситуацию, все очень медленно.
4. Допсортировка по атрибутам либо отсутствует, либо опять все очень медленно.
По результатам этих простейших тестов плотнее мерить и глубже рыть не стал, тк. порядок скорости был сразу не тот. За исключением ровно одного юзкейса «дай топ-10 документов по bm25, соври в разы про количество совпадений».
Еще один совет кстати вспомнил: проверить полную (!) выдачу поиска. После того, как выяснилось, что до 90% фактически совпадающих документов Xapian тупо теряют — мои тесты в свое время быстро свернулись :)
Машина нормальная, именно на такой в свое время индексировал 100 мег за пару минут :)
Советую еще проверить время более сложного поиска, чем «первые 100 матчей и прикидка числа совпадений», может сильно отличаться.
А файлы текстовые или doc/pdf/...?
Под критической секцией я имел в виду еще и всю прикрытую ей работу, а именно _Orphan_me. Там длинная цепочка унаследованных деструкторов, под десяток call-ов, ну и в самом низу защищенное локом обновление списка итераторов контейнера. Те. недешевый сам по себе деструктор вызывается в 3 раза чаще, отчего и основные тормоза.
Основные тормозища видимо из-за… критической секции в деструкторе отладочного итераторе!
Зачем вектору (!) именно итераторы, плохо понятно все равно. Внятный юзкейс, который требует (!) итераторов вектора не могу себе представить.
Впрочем польза от этого обсуждения уже похоже есть, а именно: в предыдущем комментарии число 200 считать числом 10.
Но вот иллюстрировать дрожание как раз куда лучше с этим фаршем. Нагляднее. ;)
Заметка, соотв-но, именно про борьбу с дисперсией как явлением, а не каким-либо конкретным тестом.
«Очень часто» — можно согласиться, наверное.
«Практически всегда» — нет, конечно, бывают случаи и бывают случаи.
Зачем вообще вектору итераторы отдельный непонятный вопрос.
Особенно настолько толковые, что 200x тормоза в дебаге ж)
1. Первые 10 документов в порядке тн. релевантности (vanilla BM25) выдавались дико быстро. Видимо, для каждого слова хранится топ-N документов в порядке убывания частоты. Значение N выяснять не стал.
2. Число матчей при этом втупую врало, сильно. Вместо точного числа оно при таком поиске делает оценку, оценка получается слишком грубая.
3. Поиск фразы из двух слов резко исправляет ситуацию, все очень медленно.
4. Допсортировка по атрибутам либо отсутствует, либо опять все очень медленно.
По результатам этих простейших тестов плотнее мерить и глубже рыть не стал, тк. порядок скорости был сразу не тот. За исключением ровно одного юзкейса «дай топ-10 документов по bm25, соври в разы про количество совпадений».
дырки в перфе не от нейтива — а от клаттера
запросы и данные достаточно своеобразные — чтобы «обычные» инвертированные файлы на них ложились не вполне хорошо
навскидку (навскидку) при имеющихся входных — зарулило бы спецрешение
видимо, тупо заради предсказуемости разработки
А откуда взялась «большая любовь с ранкерами»? Там вроде ровно 1 вызов «выбрать ранкер» и несколько тех ранкеров.
Выложу слайды.
Про вопросы от непосетителей не совсем понятно.
К докладчикам оно в целом, или только команде, или как.
Но ответ, пожалуй, одинаковый.
Организуй сбор вопросов, по результатам я организую сбор ответов :-)