Alright, I've pushed out an update that includes the resizing
functionality. I haven't explored the question of whether there's a
performance penalty or not, but it looks like there may not be one. If
there is one, it's very small. Even with reallocations occurring (which
would not be the norm),
A small update: I've gotten a resizable version of my disruptor
implementation working, and the performance looks pretty good so far. I
still have a few loose ends to tie up before I push out the changes. I
should have the updated code on GitHub hopefully within a couple of weeks,
depending on how
On Sat, Nov 9, 2013 at 8:13 PM, Simon Ruggier simo...@gmail.com wrote:
Hi all, I've tentatively come up with a design that would allow the sender
to reallocate the buffer as necessary, with very little added performance
cost. The sending side would bear the cost of reallocation, and there
Hi all, I've tentatively come up with a design that would allow the sender
to reallocate the buffer as necessary, with very little added performance
cost. The sending side would bear the cost of reallocation, and there would
be an extra test that receivers would have to make every time they
Note pre fetch and non temporal instructions really help with this..
I'm not deeply familiar with Disruptor, but I believe that it uses bounded
queues. My general feeling thus far is that, as the general 'go-to' channel
type, people should not be using bounded queues that block the sender when
Greetings fellow Rustians!
First of all, thanks for working on such a great language. I really like
the clean syntax, increased safety, separation of data from function
definitions, and freedom from having to declare duplicate method prototypes
in header files.
I've been working on an alternate
Hi Simon ,
You may want to test the througput of tasks first to set a base line.
Disruptor is faster but normally runs in a tight loop ( or a yield loop) so
pretty much tying up a core ( even when yielding it will run again very
soon , its the fact that its always running which makes it very
