Результаты тестов ForkJoin vs Disruptor?

Я запустил этот DisruptovsFJ Mirco-Benchmarks, написанный Aleskey Shipilev, где сравнивается производительность ForkJoin и библиотеки Disruptor. .

Результаты, которые я получил с помощью JDK1.8.40 на платформе Linux i5:

Benchmark                     Score,     Score Error (99.9%),Unit,Param: slicesK,

Disruptor.run,              939.801405,   20.741961,ms/op,   50000,0,10
ForkJoin.run,               1175.263451,  0.595711, ms/op,   50000,0,10
ForkJoinRecursive.run       771.854028,   26.022542,ms/op,   50000,0,10
ForkJoinRecursiveDeep.run,  1356.697011,  28.666325,ms/op,   50000,0,10
ForkJoinReuse.run,          7974.180793,  49.604539,ms/op,   50000,0,10

Первая часть результатов для slicesK < 50000 ожидалась, поскольку Disruptor использует RingBuffer и механизм, который делает его очень эффективным в параллельном контексте.

Теперь, когда slicesK >= 50000, Disruptor тест менее эффективен, чем ForkJoinRecursiveDeep и ForkJoinReuse. Может кто-нибудь объяснить мне эти результаты? Спасибо

jmh

Bionix1441 01.06.2015 источник

Ответы (1)

arrow_upward
5
arrow_downward

Отвечать :

Ваш пригодный для использования Disruptor кольцевой буфер каким-то образом переполнен при срезе K> = 50000, что приводит к падению производительности.

Примечания:

Для очень высокой производительности кольцевой буфер и его содержимое должны помещаться в кэш ЦП L3 для обмена между потоками. Если кольцевой буфер используется для сценария воспроизведения, такого как рыночные данные или восстановление сети, он может быть больше и иметь очевидные последствия для производительности из-за промахов в кэше.

Одна из функций секвенсора - гарантировать, что публикация не закроет кольцевой буфер. Для этого ни один из нижестоящих потребителей не может иметь последовательность, которая ниже, чем последовательность кольцевого буфера, за вычетом размера кольцевого буфера. Однако с помощью графа зависимостей можно сделать интересную оптимизацию Disruptor с набором зависимых потребителей.