[cpp-threads] Floating-point state

[Boehm, Hans]

That sounds right to me, but I haven't looked at this in nearly enough
detail.

I'm also not sure how this precludes implicit parallelization.
Presumably we won't parallelize anything that contains explicit fp
status operations, or we'll treat it very gingerly.  If we parallelize a
loop that doesn't explicitly refer to the fp status, is there a problem
with just propagating the fp context into all threads and merging
accumulated exceptions at the end?

Note that we're also discussion other constructs, notably thread local
storage, that probably don't interact well with any form of implicit
threading.  In my view, that's OK.  Automatic parallelization only works
well in limited domains anyway.

Hans

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Lawrence Crowl
> Sent: Friday, August 18, 2006 11:41 AM
> To: C++ threads standardisation
> Subject: [cpp-threads] Floating-point state
> 
> On 8/18/06, Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote:
> > The point is that they are an alternate, NON-memory, 
> program-visible 
> > state (with somewhat different rules), and synchronising them with 
> > memory is tricky enough even when threads are not involved.
> >
> > The simplistic answer that there is a separate copy for each thread 
> > means that we are forever excluding any form of implicit 
> threading (as 
> > favoured by Bjarne), because we can no longer split two independent 
> > actions (as the flags make them dependent).
> 
> I'm not sure Bjarne was asking for implicit parallelism, but 
> for easy explicit parallelsism.
> 
> > And using floating-point (of ANY base) to emulate fixed-point with 
> > overflow detection REQUIRES the inexact flag to be both 
> supported and 
> > raise an exception.
> 
> Well, the problem is a bit more general.  The floating-point 
> flags are often accumulated without exceptions.  In order to 
> easily split a computation into parallel parts, we would have 
> to automatically merge the floating-point state on a join.  I 
> think this is reasonable, though I don't know how much 
> additional overhead it implies.
> 
> We also probably need to consider the floating-point state on 
> a fork.  As near as I can tell, the new thread should 
> probably have the same control settings, but have cleared event flags.
> 
> Comments?
> 
> --
> Lawrence Crowl
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>