Initlal Java vs .NET Disruptor Performance Comparison
Initial timings from Mac OS X MacBookPro Dual Core i7 2.66GHz with 8G Ram running VMware Fusion allocated 4G Ram 2 CPU running Win7 64bit
Java 1.6.0_24:
JUnit version 4.5
.UniCast1P1CPerfTest OpsPerSecond run 0: BlockingQueues=9546903, Disruptor=24400956
UniCast1P1CPerfTest OpsPerSecond run 1: BlockingQueues=10529419, Disruptor=24241248
UniCast1P1CPerfTest OpsPerSecond run 2: BlockingQueues=10955062, Disruptor=28070963
.NET 4.0:
UniCast1P1CPerfTest OpsPerSecond run 0: BlockingQueues=2,221,235.00, Disruptor=7,987,220.00
UniCast1P1CPerfTest OpsPerSecond run 1: BlockingQueues=2,313,743.00, Disruptor=9,398,496.00
In summary, the .NET codebase needs to find 2.5x to catch the Java Disruptor
Advertisement
I’ve also started a project to port the java disruptor to .NET. You can find the project on GitHub: https://github.com/TimGebhardt/Disruptor.NET. I’ve got all the unit tests passing (as opposed to the project you linked). I’m beginning to port the performance tests now.
Excellent. Please post your performance numbers here once your are ready
It would be interesting to see if it is a bad port or if the JVM is more optimised for that purpose.
Bad port – v0.1. Improvements have already been found since the C# code was public a week or so ago
I’d run the test on Win7 native rather than virtualized to rule out anything in the VM layer that the CLR is interfering with?
[...] Davey (Technical Director at Lab49) also has a couple of posts about porting the Disruptor and comparing the performance of his port to the Java [...]
Disruptor.NET « codeaholics.org said this on July 3, 2011 at 8:54 pm |
I’m not sure why are you trying to benchmark since not all the apps have not been optimized to their respective framework. You can make any app behave badly due to a poor design, even if the underlying framework has outstanding inherent performance.
If looking for VM benchmarks you can start here:
http://www.codeproject.com/KB/dotnet/RuntimePerformance.aspx