Nice result! How many threads were used in each of those lines?
Regards,
Roland
15 jan 2014 kl. 13:00 skrev Roger Alsing :
> I let you know once I've implemented the dispatcher for single threads.
>
> The BlockingCollection has horrible performance compared to the current
> implementation..
>
I let you know once I've implemented the dispatcher for single threads.
The BlockingCollection has horrible performance compared to the current
implementation..
I cleaned up the benchmark code to map 1-1 with the scala version.
things looks much more stable now and it doesn't fall flat when I a
Hi!
Roger, can you compare using "manual" threads, instead of built-in .NET
thread pool? any difference?
By the way, you could use a BlockingCollection instead of concurrent Queue
http://msdn.microsoft.com/en-us/library/dd997371(v=vs.100).aspx
But, maybe, you want more control in the access to t
Ouch.
So what doe Akka muster on your machine with the same-ish type of config?
On Wed, Jan 15, 2014 at 11:32 AM, Roger Alsing wrote:
> The .NET thread pool does some magic with the threads, I'm not sure what
> state those threads are in by default or if they even are alive at all.
> But the thr
The .NET thread pool does some magic with the threads, I'm not sure what
state those threads are in by default or if they even are alive at all.
But the threadpool does measure how long each job takes and how much is
scheduled on the queue, and decide how many threads to use from that.
>>So if y
On Wed, Jan 15, 2014 at 11:16 AM, Roger Alsing wrote:
> On my machine I get the best throughput with only 4 actors and I guess
> that maps to my 4 cores.
> Scheduling in the .NET thread pool seems pretty darn expensive even though
> it is lock-less, the more actors I add after this, the throughput
On my machine I get the best throughput with only 4 actors and I guess that
maps to my 4 cores.
Scheduling in the .NET thread pool seems pretty darn expensive even though
it is lock-less, the more actors I add after this, the throughput drops
considerably.
The threadpool defaults to 1023 worker
On Wed, Jan 15, 2014 at 10:40 AM, Roger Alsing wrote:
> I couldn't find much else than that the Java ThreadPool does
> locking/blocking when scheduling, I guess that is the main reason?
> And that the new modified fork join pool does random scheduling and work
> stealing (?)
> It turns out that th
I couldn't find much else than that the Java ThreadPool does
locking/blocking when scheduling, I guess that is the main reason?
And that the new modified fork join pool does random scheduling and work
stealing (?)
It turns out that the .NET ThreadPool is non locking and also does job
stealing, s
On Mon, Jan 13, 2014 at 11:52 AM, Roger Alsing wrote:
> I'm trying to understand why the fork join pool scales better than the
> thread pool.
>
LMGTFY? :)
https://www.google.com/search?q=akka+scale+ForkJoinPool&oq=akka+scale+ForkJoinPool
> My understanding is that FJP can partition tasks into
I'm trying to understand why the fork join pool scales better than the
thread pool.
My understanding is that FJP can partition tasks into subtasks to optimize
the work done on the underlying threads.
How does this affect the mailboxes in Akka?
Since a given mailbox can only process one message a
11 matches
Mail list logo
