Performance Benchmark

[André]

Hi,

I have been playing with this framework and I find it to be a very
good piece of engineering. I am puzzled however by the benchmarks
results in my machine. The results show the Disruptor being slower
than BlockingQueue. Does anyone have a hint as to why this is
happeing?

Thank you,

André

ThrottledOnePublisherToThreeProcessorPipelineLatencyTest run 0
BlockingQueue Histogram{min=284, max=4495214, mean=20188.82,
99%=524288, 99.99%=8388608, [2=0, 4=0, 8=0, 16=0, 32=0, 64=0, 128=0,
256=0, 512=434, 1024=45120, 2048=291817, 4096=2262276, 8192=178188,
16384=60490, 32768=41961, 65536=33141, 131072=23227, 262144=22900,
524288=19400, 1048576=10015, 2097152=5691, 4194304=4843, 8388608=497,
16777216=0, 33554432=0, 67108864=0, 134217728=0, 268435456=0,
536870912=0, 1073741824=0, 9223372036854775807=0]}




ThrottledOnePublisherToThreeProcessorPipelineLatencyTest run 1
BlockingQueue Histogram{min=284, max=2971205, mean=23160.44,
99%=1048576, 99.99%=4194304, [2=0, 4=0, 8=0, 16=0, 32=0, 64=0, 128=0,
256=0, 512=405, 1024=37156, 2048=290734, 4096=2282144, 8192=136727,
16384=74887, 32768=45447, 65536=30416, 131072=22222, 262144=25027,
524288=22116, 1048576=15673, 2097152=14253, 4194304=2793, 8388608=0,
16777216=0, 33554432=0, 67108864=0, 134217728=0, 268435456=0,
536870912=0, 1073741824=0, 9223372036854775807=0]}


ThrottledOnePublisherToThreeProcessorPipelineLatencyTest run 2
BlockingQueue Histogram{min=285, max=1858994, mean=7315.83,
99%=131072, 99.99%=2097152, [2=0, 4=0, 8=0, 16=0, 32=0, 64=0, 128=0,
256=0, 512=591, 1024=63695, 2048=346890, 4096=2266523, 8192=164576,
16384=62879, 32768=37857, 65536=24042, 131072=13099, 262144=10292,
524288=4592, 1048576=2737, 2097152=2227, 4194304=0, 8388608=0,
16777216=0, 33554432=0, 67108864=0, 134217728=0, 268435456=0,
536870912=0, 1073741824=0, 9223372036854775807=0]}


ThrottledOnePublisherToThreeProcessorPipelineLatencyTest run 0
Disruptor Histogram{min=-36, max=6847420, mean=124590.66, 99%=4194304,
99.99%=8388608, [2=2, 4=0, 8=0, 16=0, 32=0, 64=0, 128=2629522,
256=2519, 512=2991, 1024=2388, 2048=5630, 4096=8956, 8192=13800,
16384=21022, 32768=26608, 65536=23017, 131072=23745, 262144=33255,
524288=35318, 1048576=57319, 2097152=53522, 4194304=48019,
8388608=12367, 16777216=0, 33554432=0, 67108864=0, 134217728=0,
268435456=0, 536870912=0, 1073741824=0, 9223372036854775807=0]}


ThrottledOnePublisherToThreeProcessorPipelineLatencyTest run 1
Disruptor Histogram{min=70, max=14374863, mean=176374.49, 99%=4194304,
99.99%=16777216, [2=0, 4=0, 8=0, 16=0, 32=0, 64=0, 128=2531830,
256=8444, 512=2283, 1024=2539, 2048=7663, 4096=16114, 8192=29086,
16384=36237, 32768=29715, 65536=25320, 131072=24479, 262144=30457,
524288=37066, 1048576=55888, 2097152=72451, 4194304=72062,
8388608=17758, 16777216=608, 33554432=0, 67108864=0, 134217728=0,
268435456=0, 536870912=0, 1073741824=0, 9223372036854775807=0]}


ThrottledOnePublisherToThreeProcessorPipelineLatencyTest run 2
Disruptor Histogram{min=70, max=5284701, mean=139240.36, 99%=4194304,
99.99%=8388608, [2=0, 4=0, 8=0, 16=0, 32=0, 64=0, 128=2620401,
256=1992, 512=2351, 1024=2709, 2048=6529, 4096=9830, 8192=14477,
16384=21228, 32768=26976, 65536=23935, 131072=21745, 262144=23018,
524288=27782, 1048576=50941, 2097152=70323, 4194304=70341,
8388608=5422, 16777216=0, 33554432=0, 67108864=0, 134217728=0,
268435456=0, 536870912=0, 1073741824=0, 9223372036854775807=0]}

[Michael Barker]

It can depend heavily on the hardware that you're running and the
waiting strategy employed. I'm seeing similar pattern to you on my
dual-core + HT Sandy Bridge with the BusySpinWaitStrategy. This is
not surprising though. The test requires 4 threads so in order run
well it needs 4 CPUs. While with HT my machine does have 4 logical
cores, some the subtleties of HT start to show through. On Intel if
you have a thread that is running a hard spin it can cause the CPU to
speculatively execute that loop a number of times, this will fill up
the instruction pipeline for that physical core. The instruction
pipeline is shared between hyper-threads on the same core, so if one
threads fills up the pipeline due to a busy spin it can starve the
other thread of resources. This may lead to undesirable results. A
way to mitigate this is to use the PAUSE instruction
(http://drdobbs.com/parallel/225702843?pgno=1), unfortunately this is
not available in Java.

I switched the waiting strategy to YieldingWaitStrategy and saw a much
better profile. The BusySpinStrategy is the best when looking for the
ultimate in low-latency performance, but you must ensure that you have
the resources to support it. At least one physical core per busy
spinning thread, ideally more so that you have resources spare for the
other activities that your system may need to perform (OS, GC, etc.).

Mike.

[André]

Hi Michael.

You got it right. It's running on a dual-core + HT Sandy Bridge. After
your advice I run it on 6 core it was much faster.

Thank you

Andre

[Rebecca Ahlvarsson]

When you say 6 cores, do you mean 6 *physical* cores or 6 *logical*
cores? I am trying to find the right machine to test Disruptor.
Running on a 6 *logical* cores it is worse than synchronized (ok,
exaggerating here a little bit) :)