GNU bug report logs - #14756
threads - par-map - multicore issue

Previous Next

Full log

View this message in rfc822 format

From: ludo <at> gnu.org (Ludovic Courtès)
To: Andy Wingo <wingo <at> pobox.com>
Cc: 14756 <at> debbugs.gnu.org, David Pirotte <david <at> altosw.be>
Subject: bug#14756: threads - par-map - multicore issue
Date: Tue, 21 Jun 2016 10:33:47 +0200

Andy Wingo <wingo <at> 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.