Thanks a lot for your feedback. Thanks to your advice, I learn new things.
>A fully scalable actor model needs a work stealing thread pool I don't understand, if you have a threadpool which share threads, why we need work stealing? I know that if we want highly optimized code, we need it, but the implementation is not trivial and need to recreate a lot of code (even for ABP worker) :). I think threadpool is enough for the beginning, no? >and for the task queues to live per-thread in that pool, and not per-actor. you're right. I changed my code.. Now I push tasks. In fact, with the new code, my tests have the following results: (execution times for only one channel/mailbox) 0 actor (explicit call in the main thread) : 9.1337410689999992 seconds 1 actor (with his own thread) : 9.1125094860000004 10 actors : 4.6893007400000002 200000 actors : 4.7922086029999997 (with some issues for the malloc at the beginning, I had to integrate a memory pool in C code ( (is it possible in vala?) but I only look the execution, not initialization) So, with 2 actors it's a little slower than the older code( 0.5 % :) but it's seems to be ok. PS: I'm bad with foreign language, so i hope i was clear :-° Indeed an actor model for Vala would be a sweet deal. Perhaps an actor > model could even replace a "mainloop concept" in the Dova profile > (this is just me rambling :-)). > > Looking at your code I see two major issues that will prevent you from > scaling into millions of actors: > > * No work stealing > * The mailboxes are implemented as async queues living on a per-actor > basis > > A fully scalable actor model needs a work stealing thread pool and for > the task queues to live per-thread in that pool, and not per-actor. > This way you will have extremely low lock contention. > > -- > Cheers, > Mikkel >
_______________________________________________ vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
