Для ELKI мне нужны (и есть) более гибкие реализации сортировки, чем те, что предоставляются в стандартной версии Java. JDK и API коллекций. (Сортировка не является моей конечной целью. Я использую частичную сортировку для массовой загрузки индексных структур, таких как kd-дерево и R*-дерево, и я хочу сделать их доступной довольно общей реализацией, более общей, чем то, что в настоящее время есть в ELKI. - но в любом случае оптимизация сортировки означает оптимизацию времени построения индекса).
Однако алгоритмы сортировки масштабируются по-разному в зависимости от размера ваших данных. Для крошечных массивов известно, что сортировка вставками может работать хорошо (и фактически большинство реализаций быстрой сортировки возвращаются к сортировке вставками ниже определенного порога); не теорией, а конвейерной обработкой ЦП и эффектами размера кода, не учитываемыми теорией сортировки.
Поэтому в настоящее время я тестирую несколько реализаций сортировки, чтобы найти наилучшую комбинацию для моих конкретных нужд; Я хочу, чтобы мои более гибкие реализации были примерно на одном уровне с реализациями JDK по умолчанию (которые уже точно настроены, но, возможно, для другой версии JDK).
В долгосрочной перспективе мне нужно, чтобы эти вещи можно было легко воспроизвести и запустить повторно. В какой-то момент мы увидим JDK8. И на Dalvik VM результаты также могут отличаться от результатов на Java 7. Черт возьми, они могут даже отличаться на процессорах AMD, Core i7 и Atom. Так что, возможно, Cervidae будет включать разные стратегии сортировки и выбирать наиболее подходящую во время загрузки класса.
Мои текущие усилия сосредоточены на GitHub: https://github.com/kno10/cervidae.
Итак, теперь к самому вопросу. Последний коммит суппорта добавил экспериментальный код для макротестов. Однако я столкнулся с проблемой, что мне нужны оба. Макротесты Caliper терпят неудачу, когда время выполнения составляет менее 0,1% от разрешения таймера; с 10000 объектов некоторые алгоритмы достигают этого порога. В то же время микробенчмарки жалуются, что вам следует проводить макротесты, когда ваши прогоны занимают слишком много времени...
Таким образом, для сравнительного анализа различных размеров сортировки мне действительно нужен подход, который динамически переключается с микробенчмаркинга на макробенчмаркинг в зависимости от времени выполнения. На самом деле, я бы даже предпочел, чтобы суппорт автоматически понял, что время выполнения достаточно велико для макротеста, а затем просто выполнил бы одну итерацию.
Прямо сейчас я пытаюсь эмулировать это, используя:
@Macrobenchmark
public int macroBenchmark() { ... }
public int timeMicroBenchmark(int reps) {
int ret = 0;
for (int i = 0; i < reps; i++) {
ret += macroBenchmark();
}
}
для совместного использования кода бенчмаркинга в обоих сценариях. Альтернативный код должен был бы использовать
@Macrobenchmark
public int macroBenchmark() {
return timeMicroBenchmark(1);
}
public int timeMicroBenchmark(int reps) { ... }
какой из двух "адаптеров" предпочтительнее? Любые другие подсказки для получения последовательного бенчмаркинга от микро до макро?
Учитывая, что веб-интерфейс калипера в настоящее время не работает, что вы используете для анализа результатов? В настоящее время я использую крошечный скрипт Python для обработки результата JSON и отчета о взвешенных средних значениях. И на самом деле, старый текстовый отчет мне нравился больше, чем веб-интерфейс.
О, и есть ли способ, чтобы Caliper просто повторно запускал тест, когда компиляция Hotspot происходила в цикле тестирования? Прямо сейчас он регистрирует ошибку, но, может быть, он может просто перезапустить эту часть теста?
