Mike.
If there's a c++ implementation people prefer more than disruptor-cpp, I'd be happy to update the code with that version. I'd rather maintain a repository people use than not.
Sent from my iPhone
Thanks -- yeah, I ran into the same issue that the official release is moving too fast for me to keep up with the C++ side (which is good!). Having said that, anyone who can contribute patches to bring it up to speed is welcome!
On Tue, 27 Sep 2011 08:25:19 -0700 (PDT), cde1537 wrote:
Dan, Your port was a great contribution to the community. It was the perfect entry point for getting the disruptor worked into existing c++ projects. I've been following through the Java changes and some of the changes to the API made in the past month have been very interesting (worker pool, event processor vs consumers among others). I started porting to 2.0 when that came out but before I was able to finish there 2.0.1, 2.0.2, 2.5, etc. Sometimes professional workflow allows me to spend time on side projects like this and other times not so much. The last month has been fairly hectic and I had to put all this aside. As far as I can tell there is no publicly released port of the disruptor that matches API 2.0 or higher. If anyone has found one could they please point me to it? If not, perhaps Martin or someone else at LMAX can comment on the possibility of an official port being in the works? If I recall there were comments made around the 2.0 release that the changes to the API were in part made to simplify the porting process. Thanks, Chris On Aug 30, 6:16 am, Dan Eisner wrote:
If there's a c++ implementation people prefer more than disruptor-cpp, I'd be happy to update the code with that version. I'd rather maintain a repository people use than not.Sent from my iPhone
On Aug 29, 2011, at 12:30 PM, cde1537 wrote:Hart,Is there a project started that contains your ported code (much like RobotTwo's disruptor-cpp) for review?~Chris
On Aug 20, 9:56 am, Martin Thompson wrote:Depends on your compiler and options. If you try the C++ example I use in my blog entry on inter thread latency the issue can be seen.http://mechanical-sympathy.blogspot.com/2011/08/inter-thread-latency....Try removing the volatile keywords and compile the code with and without the -O3 options and see what happens. The compiler can cache the variable in a register and spin forever. Preserving order and flushing buffer is achieved via fences, they don't change the usage of registers. You have to make sure the compiler generates the right instructions in the right order.My understanding is the fences are a better option on AMD and lock ... on Intel for performance for the same semantics. Not measured this extensively though.
I've made a port called disruptor--, it's quite different than Dan's
disruptor-cpp.
-no dependency on boost, only C+11 features
-no compilation needed, 100% templated
-autotools integrated for tests/benchmark
-almost up to date with latest LMAX's disruptor 2.6
-using Google C++ style guide
I want to replicate the performance tests.
Francois
--
Sent from my jetpack.
This is the kind of details I'm also interested in.
Francois