Andy Wingo <wi...@pobox.com> skribis: > I see this, but I'm not quite sure what's going on. What I do see is > that par-map of 1+ on a list is horribly slow, both on 2.0 and master. > Ludovic do you know what's going on here?
As David put it, only one core is being used, which is clearly a bug. I believe the bug was introduced by 8a177d316c0062afe74f9a761ef460e297435e59 (however, before that commit, you would hit a stack overflow when doing ‘par-map’ on a large-enough list.) What happens is that ‘par-mapper’ creates nested futures whose dependency graph forms a comb-shaped tree; thus we quickly hit %MAX-NESTING-LEVEL. This is fine in itself, but for some reason, it ends up evaluating most of those futures in one thread while the other threads apparently remain stuck in ‘wait-condition-variable’ in ‘process-futures’. I’ve looked into it a bit but that needs more time… Ludo’.
