freenode/#sicl - IRC Chatlog
Search
13:28:08
jackdaniel
beach: if you are not familiar with a "red team" term, I think that looking at opposing opinions with this optic may prove being more comfortable (https://en.wikipedia.org/wiki/Red_team)
13:31:24
pfdietz
beach: the garbage collector is a good candidate for parallelism. In SBCL., GC quickly becomes the bottleneck when using multiple threads.
13:47:37
shka__
each thread has local memory pool for objects, and there is a also global, shared memory area for stuff that is, well, shared
13:48:29
shka__
so well separated threads in SICL in theory should not be throttled by garbage collector
13:55:40
heisig
Except for collecting the global heap. In that case, a multi-core GC would help a lot.
14:25:20
pfdietz
For the particular use case I was thinking of (largely independent threads that don't communicate much) the SICL style would be fine.
14:26:51
pfdietz
This came up testing the multithreading compatibility of the SBCL compiler, which recently had a global lock removed from it. Even in 8 threads, it was just achieving a ~1.4 speedup. GC was the problem.
14:31:55
jcowan
"Sir, we have an insurmountable problem." "Mr. Jones, in this company, we do not have problems, we have opportunities!" "Yessir. Excuse me, sir. Sir, we have an insurmountable opportunity."
14:32:20
pfdietz
"Boss, we're faced with insurmountable problems." "Don't call them that! We have opportunities, not problems." "Boss, we're faced with insurmountable opportunities."
15:35:05
beach
pfdietz: Is there a version of the SBCL system that does not stop the world for a GC?
15:37:49
beach
It seems Clasp has been able to use MPS successfully. It would be interesting to know how dependent the SBCL GC is on the way other things are done in the system. I imagine hash tables would complicate things for instance.