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 of multiple cores seems
> inefficient.
Place creation probably appears slower because loading code is slower.
The creation of places is actually around 10 times as fast. To check
that, try
#lang racket/base
(require racket/place)
(time
(for ([i (in-range 10)])
(place-wait (dynamic-place '(file "/tmp/go.rkt") 'void))))
where "/tmp/go.rkt" starts as
(module m '#%kernel
(#%provide void))
The loop should run around 10 times as fast in CS. But change
`'#%kernel` in "go.rkt" to `racket/base`, and the CS is only about 2
times as fast. Change it to `racket`, and CS is about the same or
slower.
Utilization of multiple cores is lower primarily (I think) due to a
shared allocation heap in CS:
* BC gives each place its own allocation heap (with one extra heap for
shared objects, such as place channels), so different places can
allocate and GC independently.
At least, that's true up to the limits of a shared page table. That
limit becomes significant at around 10 places, because generational
GC relies on page-level protection, and then OS pagetable operations
become a bottleneck.
* 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.
Locks on shared system data structures may also be a significant
obstacle to CPU utilization with places in CS, but I'm not sure.
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/20200225150544.F3BB66501B7%40mail-svr1.cs.utah.edu.
