Hallo,
Now that even smartphones get dual-core processors, I am wondering how can we use Gambit-C in a way to take advantage of that. Desktop machines with eight cores will be in widespread use soon. I know there is Termite but AFAIK it works by exchaging messages between different processes, not threads in the same process. Is anybody working on some solution for this?
Cheers,
Afficher les réponses par date
On Mon, Jul 04, 2011 at 04:17:42PM +0200, Alex Queiroz wrote:
Hallo,
Now that even smartphones get dual-core processors, I amwondering how can we use Gambit-C in a way to take advantage of that. Desktop machines with eight cores will be in widespread use soon. I know there is Termite but AFAIK it works by exchaging messages between different processes, not threads in the same process. Is anybody working on some solution for this?
I believe that Modula 3 now implements multithreading using pthreads, and they have a garbage collector. I'm currently investigating how their implementation handles garbage collection. Does it stop the world? Or does it manage collector concurrency.
It might be possible to have gambit-generated C code live on top of part of the Modula 3 run-time system. Or learn how they do it all in detail and reimplement some of that stuff for Gambit. Or maybe have a gambit-modula3?
--- hendrik
Cheers,
-alex http://www.artisancoder.com/ _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Hallo,
On Mon, Jul 4, 2011 at 5:38 PM, Hendrik Boom hendrik@topoi.pooq.com wrote:
It might be possible to have gambit-generated C code live on top of part of the Modula 3 run-time system. Or learn how they do it all in detail and reimplement some of that stuff for Gambit. Or maybe have a gambit-modula3?
The GHC's runtime system seems to have a pretty nice support for multithreading. They are able to schedule N green threads over M OS threads, where the scheduler can move green threads between cores transparently. Of course they have it easier because Haskell disallow mutable state, so they don't have to worry about locks.
Erlang's VM avoids locks as well by using shared-nothing threads and message passing. Maybe a cool solution for Gambit-C would involve the assimilation of Termite and further work on distributing the lightweight processes among different cores. Incidentally, there may be some work already done in that direction, given that for supporting late binding on Windows modules don't access global variables anyway and are half-way thread-safe.
Well, so far just a bunch of ideas anyway.
[1] - http://www.haskell.org/~simonmar/multicore-haskell-marlow-qcon2010.pdf
On Mon, Jul 04, 2011 at 11:38:23AM -0400, Hendrik Boom wrote:
On Mon, Jul 04, 2011 at 04:17:42PM +0200, Alex Queiroz wrote:
Hallo,
Now that even smartphones get dual-core processors, I amwondering how can we use Gambit-C in a way to take advantage of that. Desktop machines with eight cores will be in widespread use soon. I know there is Termite but AFAIK it works by exchaging messages between different processes, not threads in the same process. Is anybody working on some solution for this?
I believe that Modula 3 now implements multithreading using pthreads, and they have a garbage collector. I'm currently investigating how their implementation handles garbage collection. Does it stop the world? Or does it manage collector concurrency.
It's a stop-the-world garbage collector, alas. Mind you, it's probably a lot more reliable because of that.
-- hendrik
-
Alex Queiroz -
Hendrik Boom