Perhaps separate OS processes would be a win in this case?
On Tue, Feb 25, 2020 at 12:03 PM Matthew Butterick wrote:
>
> > On Feb 25, 2020, at 7:05 AM, Matthew Flatt wrote:
> >
> > * CS has a single heap with a single-threaded, stop-the-world GC ---
> > so allocation and GC easily become a bo
> On Feb 25, 2020, at 7:05 AM, Matthew Flatt wrote:
>
> * CS has a single heap with a single-threaded, stop-the-world GC ---
> so allocation and GC easily become a bottleneck.
>
> If GHC's experience is any guide, making the GC itself multithreaded
> may address much of this problem.
>
At Tue, 25 Feb 2020 06:48:53 -0800, Matthew Butterick wrote:
> What can you say about places & parallelism under CS vs. BC? This is
> one area that I find CS to reliably underperform BC (by about a
> factor of 2). Place creation seems slower under CS. More
> interestingly however, the utilization o
What can you say about places & parallelism under CS vs. BC? This is one area
that I find CS to reliably underperform BC (by about a factor of 2). Place
creation seems slower under CS. More interestingly however, the utilization of
multiple cores seems inefficient. For instance, when I run a ful
4 matches
Mail list logo
