On Mon, Nov 5, 2018 at 11:49 AM George Neuner <gneun...@comcast.net> wrote:

>
> Don't throw it away too quickly.
>
> With a nod to process/thread scheduling: unless you muck with
> process/thread groups, by default Linux tries to gang schedule all the
> (ready) threads of a process to run simultaneously.
>
> Rather than creating large numbers of processes each having 1 place, you
> might want to consider creating fewer processes that have several places
> each  [essentially a gang of thread pools].  If the places typically do
> significant amounts of work, leveraging the gang behavior of the scheduler
> *might* increase overall performance of the application as a whole.
> [Particularly if the machine is not dedicated to your computing, and if the
> admins are not actively preventing you from exploiting this.  YMMV.]
>

Fortunately, at the moment, the machine is mine to play with, so I'm not
about to run into contention with other users.

I had structured the whole application in a CSP-ish way, largely using
channels to manage my synchronization. Therefore, the new abstraction isn't
too large a step.

I'm going to think about how to structure this a bit more at this point. As
you suggest, there's more than one way to do it, and as long as I'm doing
some cleanup/restructuring, I might as well be sensible about it.

Many thanks,
Matt

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to