github move to increase community participation ?

[Matthias Götzke]

It is obvious that the disruptor code is very interesting for a number
of scenarios and is a pretty awesome port effort. It also seems
obvious that the maintainer cannot do all the work in keeping up to
date with the Java version alone. Therefore I would like to propose to
move the project to github and thus allow all the git pull request
goodies that would allow others like me to dabble in porting some
features ...

Obviously one could just do that without asking for "official"
permission, but I would assume it would be more productive if done by
the current maintainers.

BTW: We are just integrating changes for better NUMA and logical
processor support, since the performance is extremely limited by the
tendendency of .NET/Windows to not schedule on the same processor....

Any comments ?

With kind regards,
Matthias

[Olivier]

Hi Matthias,

I was working on another side project that I've just finished and I'm now free to port the missing revisions from the Java version.

We can either move the project on Git or I can give you commit access on Google code. There are quite a lot of revisions to port to match v2.7, we need to be careful to not diverge too much from the original version as it make it harder to port the code.

Olivier

[Chrisa23]

Hey guys,

I went ahead and forked the project onto Github and ported the latest
Java code in a couple hours this last weekend.

https://github.com/chrisa23/Disruptor.net

I did a very quick job of things, but I tried to stay close to the
Java.

I'm happy to be a committer on the official one and help get up to
date.

Chris

[Matthias Götzke]

Wow, great job! Shall we make this official ? What do you guys think? I
would not want to cause fragmentation...

Cheers,
Matthias

Sent from my Windows Phone
Von: Chrisa23
Gesendet: 09.12.2011 15:33
An: Disruptor-net
Betreff: Re: github move to increase community participation ?

[Matthias Götzke]

hi everyone,

ok ... it seems we face a little diversion already...;)

what are the differences between the original google-code version and
the new port by chrisa23 ? I mean we all just want to build
applications using the disruptor and obviously would like to continue
to be close to the java implementation and thus benefit from any
advancements there. therefore the port should be as close to the java
code as possible to ease the migration. originally i even thought
about just using ikvm, but in order to make some changes to the code
were the java code is not extensible a simple port like the ones
discussed would indeed be better. but we should keep an eye on the
performance between the java version, a ikvm port and a real code
port.

so in order to get to my original point. which version should all devs
put their spare energy behind ? did anybody make throughput and
latency tests comparing the versions ?

matthias

[Chris Anderson]

Mine is not a new port and I wouldn't make it official.  I simply updated the code with the latest Java changes.  I think Olivier and others are more familiar with some of the high performance aspects of the code, CLR internals and all of the awesome automated build and performance stuff. 

I have no real preference on moving it to Github, but would prefer just contributing to the original.

Chris

2011/12/11 Matthias Götzke <mgt...@googlemail.com>

[Alexis Atkinson]

Hi Olivier,

I have followed the Disruptor project with interest and am keen to
contribute the project also. I think a move to github would be a good
one and would help increase participation. Do we have any plans to
move it over?

Cheers,

Alexis

[Olivier]

Hi All,

The main piece of work at the moment is to port the missing revisions
from the Java version. What I've done in the past was to port
revisions one by one, looking at all changes in the Java version file
by file and running the perf test before and after each new revision
to garantee there was no functional or performance regression.

I'm not sure this is the type of work which will be easier if we
distribute the repository. Don't get me wrong, I like the idea of
moving to GitHub but I would prefer to port the code base to 2.7 first
and then migrate.

If you want to help I'm happy to give you guys access to the
repository, just send me your google account email.

I will write a wiki post with some guidelines.

Olivier

[Matthias Götzke]

i think its ok to wait a little, the question is rather how long until 2.7 is reached before moving ? 

the changes i think about are centered around NUMA support for multiple disruptor topologies... meaning i would like to create a disruptor topology and have producers and consumers be associated with a defined cpu core set. that means very small changes but i would like to keep them around and not have  them disappear when downloading new changes, thus my inclination to use git or github, which i do locally right now...

all in all though i agree that not much community work should be required here, since i.e. it is "JUST" a port and should remain that way until there is sufficient reason to diverge.

github should just make it a little easier. obviously a pull request should always have already merged with master etc ... to minimize merge conflicts...

[Olivier]

I started porting the .NET version to 2.7, I hope to get this done and checked in soon, hopefully next week..

Olivier

[Olivier Deheurles]

I’ve now ported disruptor-net to the Java version 2.7.

 

I’ve tried to keep the API as close as possible from the Java version to facilitate upcoming ports.

 

There are a few more things I want to finish/port before releasing a new version :

- port experimentals (there is an experimental MultithreadedClaimStrategy I haven’t ported yet + unit tests)

- port OnePublisherToOneProcessorUniCastRawThroughputTest and  OnePublisherToThreeWorkerPoolThroughputTest (new performance tests)

- find a more flexible way to start threads (Disruptor.Start and WorkerPool.Start): I create threads manually since we don’t have an executor like in Java, need ot think about it… ideas welcome

- find an equivalent for LockSupport.parkNanos(1L); (Search TODOs in the code). This allow threads in Java to sleep for a very short period (micro seconds), not sure there is an equivalent on windows..

- port the DSL Tests

 

The performance tests run faster on my laptop than before, give it a try ;)

 

Olivier

 

De : disrup...@googlegroups.com [mailto:disrup...@googlegroups.com] De la part de Matthias Götzke
Envoyé : lundi 12 décembre 2011 11:04
À : disrup...@googlegroups.com
Objet : Re: github move to increase community participation ?

[Olivier Deheurles]

I’ve moved disruptor-net to github : https://github.com/odeheurles/Disruptor-net

 

I’m a noob with github so if you see anything misconfigured let me know ;)

 

Olivier

 

De : disrup...@googlegroups.com [mailto:disrup...@googlegroups.com] De la part de Olivier Deheurles
Envoyé : dimanche 18 décembre 2011 18:22
À : disrup...@googlegroups.com
Objet : RE: github move to increase community participation ?

[Tim Gebhardt]

I can't look now, I'll try tomorrow, but the Windows Multimedia Timers might offer a solution to the microsecond-level timing and sleeping.

Tim Gebhardt

t...@gebhardtcomputing.com

[James Miles]

Re: - find an equivalent for LockSupport.parkNanos(1L); (Search TODOs in the code). This allow threads in Java to sleep for a very short period (micro seconds), not sure there is an equivalent on windows..

 

Wouldn't something based on Thread.SpinWait be appropriate here?

[Olivier]

Hi James,

The disruptor uses spining internaly for some strategies. For other strategies we want to alternate spining, yielding and sleep (like the SpinWait struct) but we need a very short sleep (micro seconds not milliseconds).

I asked Martin about parkNanos:

"On the latest versions of Linux I've measured it at 60us + whatever time requested.  So with the park of 1L it will effectively sleep 60us then reschedule.  In a loop doing this it will only use ~2% CPU on Linux."

Olivier

[Tim Gebhardt]

It looks like the multimedia timers on Windows only have a 1 millisecond resolution so those won't be suitable.

However, it looks like if people need this they resort to using the socket Select() API and that has a block-for-read resolution in the microsecond range.

Here's a StackOverflow question from someone needing the same functionality and someone answering with some sample code:

http://stackoverflow.com/questions/85122/sleep-less-than-one-millisecond

The socket Select API exists in .NET (with it's lousy API and all), so there wouldn't be any marshaling out to unmanaged code overhead:

http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.select.aspx

Tim

[James Miles]

Wow. Sound cool. However at 60us, I'd have thought you be getting close to a context switch!

 

Can I ask exactly why Disruptor surfaces this particular API? what are the requirements;

 

1. To be a good citizen, allowing other processes to do some work?

2. Safe power / reduce heat?

[James Miles]

Another question.

~2% CPU on Linux does not really mean much... ;)

 

If its a 32 core CPU thats terrible :P

 

Is that ~2% of 1 core?

 

 

On Mon, Dec 19, 2011 at 5:36 PM, Olivier <ma...@odeheurles.com> wrote:

[Olivier]

Let's take the example of 2 threads claiming a slot in the ring buffer: thread A get sequence 1 and B gets 2. B can't commit (publish) until A has published.

If you have more physical cores than threads it is fine for B to spin until A commits but imagine you do not have enough cores: if B spins and A is waiting to be scheduled on the same core you are actually making the situation worse: A won't commit until B get unscheduled (ends its quantum).

This is just an example, there are several places where threads need to wait and depending on the scenario, it is sometimes better to spin, to yield (sleep(0)) or sleep a bit longer to save power.

The problem with a millisecond sleep is that it will introduce latency of the order of millisecond in some scenarios, which is sometime not acceptable.

Olivier

[Olivier Deheurles]

1 core ;)

 

De : disrup...@googlegroups.com [mailto:disrup...@googlegroups.com] De la part de James Miles
Envoyé : lundi 19 décembre 2011 14:27

[James Miles]

For the example you've described, Thread.Yield() seems like a suitable solution. For best performance & to protect agaist the problem you've described here, could you do something like;

 

while(buffer empty)
{

[James Miles]

Sorry (damn gmail)

 

while(buffer empty)
{

   if(!Thread.Yield()) Thread.SpinWait(...);

}

Question, is the power consumption really that much of a concern? (as CPU / SpinWait use PAUSE instruction) asuming it is...

 

In terms of saving power... Yes it would be nice, however I've looked into using Windows' "Multimedia Timers" in the past. It seems they only go down to a resolution of 1 ms :(

 

"Minimum timer resolution, in milliseconds, for the application or device driver. A lower value specifies a higher (more accurate) resolution."

 

http://msdn.microsoft.com/en-us/library/windows/desktop/dd757624(v=VS.85).aspx

 

It is only a multimedia timer after all....It's really a shame that MS don't expose this functionality.

 

It is possible you could write your own driver to access the machines HPET and callback via IO completion port? 

[Jimit Ndiaye]

I would imagine that the SpinWait structure would be ideal, rather than vanilla Thread.Yield/Spinwait. "SpinWait encapsulates common spinning logic. On single-processor machines, yields are always used instead of busy waits, and on computers with Intel™ processors employing Hyper-Threading™ technology, it helps to prevent hardware thread starvation. SpinWait encapsulates a good mixture of spinning and true yielding."

[Olivier Deheurles]

I use SpinWait in the SleepingWaitStrategy, but I’m looking for something that will sleep for microseconds, not millis.

 

/// <summary>

/// Sleeping strategy that uses a <see cref="SpinWait"/> while the <see cref="IEventProcessor"/>s are waiting on a barrier.

///

/// This strategy is a good compromise between performance and CPU resource. Latency spikes can occur after quiet periods.

/// </summary>

public sealed class SleepingWaitStrategy : IWaitStrategy

 

 

De : disrup...@googlegroups.com [mailto:disrup...@googlegroups.com] De la part de Jimit Ndiaye
Envoyé : lundi 19 décembre 2011 19:59

À : disrup...@googlegroups.com
Objet : Re: github move to increase community participation ?

 

I would imagine that the SpinWait structure would be ideal, rather than vanilla Thread.Yield/Spinwait. "SpinWait encapsulates common spinning logic. On single-processor machines, yields are always used instead of busy waits, and on computers with Intel™ processors employing Hyper-Threading™ technology, it helps to prevent hardware thread starvation. SpinWait encapsulates a good mixture of spinning and true yielding."

[Jimit Ndiaye]

Looking at the documentation for LockSupport.parkNanos it actually seems similar to Thread.Sleep. So the closest thing would be to use the overload that takes a timespan and pass in a timespan equivalent to the desired number of ticks ( 1 tick = 100 nanoseconds )

The Java implementation of the SleepingWaitStrategy spins for a 100 cycles, then yields a 100 times them resorts to LockSupport.parknanos to sleep for the "minimum number of nanos the OS and JVM will allow". For .NET that's 1 tick or 100 nanoseconds (the minimum value of System.TimeSpan).

[Jimit Ndiaye]

- find a more flexible way to start threads (Disruptor.Start and WorkerPool.Start): I create threads manually since we don’t have an executor like in Java, need ot think about it… ideas welcome

I'd recommend TaskSchedulers as the equivalent to Java Executors and use Tasks rather than directly creating threads.

[James Miles]

Based on my testing... Thread.Sleep rounds to the nearest millisecond.

 

Been thinking though (i'm sure you've already considered this).

 

It seems to me that if you're concern is power consumption, you'd be much better off with a signalling mechanism (monitor wait & pulse). I know signalling won't give you the same throughput as SpinWaits but I think it would be comparable to any microsecond thread.sleep solution?

 

I'm assuming the reason you have not done this, is that it doesn't fit into the distruptor pattern nicely?

[Jimit Ndiaye]

You could combine the two strategies - use spinwait initially then fall back to signalling. Kinda like the Latch sample given on the MSDN page for SpinWait.

Sent from my iPhone

[Olivier]

This is what Monitor (lock) does but this is not ideal in all scenarios. There is already a strategy using this construct in the Disruptor.

Olivier