I'm trying to debug an extremely strange bug whose symptoms appear in a
std.parallelism example, though I'm not at all sure the root cause is in
std.parallelism. The bug report is at
https://github.com/dsimcha/std.parallelism/issues/1#issuecomment-1011717 .
Basically, the example in question
On 4/15/11 10:22 PM, dsimcha wrote:
I'm trying to debug an extremely strange bug whose symptoms appear in a
std.parallelism example, though I'm not at all sure the root cause is in
std.parallelism. The bug report is at
https://github.com/dsimcha/std.parallelism/issues/1#issuecomment-1011717 .
D
On Fri, 15 Apr 2011 23:22:04 -0400, dsimcha wrote:
I'm trying to debug an extremely strange bug whose symptoms appear in a
std.parallelism example, though I'm not at all sure the root cause is in
std.parallelism. The bug report is at
https://github.com/dsimcha/std.parallelism/issues/1#iss
On 4/15/2011 8:40 PM, Andrei Alexandrescu wrote:
On 4/15/11 10:22 PM, dsimcha wrote:
I'm trying to debug an extremely strange bug whose symptoms appear in a
std.parallelism example, though I'm not at all sure the root cause is in
std.parallelism. The bug report is at
https://github.com/dsimcha/s
On 16-apr-11, at 09:41, Walter Bright wrote:
On 4/15/2011 8:40 PM, Andrei Alexandrescu wrote:
On 4/15/11 10:22 PM, dsimcha wrote:
I'm trying to debug an extremely strange bug whose symptoms appear
in a
std.parallelism example, though I'm not at all sure the root cause
is in
std.parallelis
On 16-apr-11, at 05:22, dsimcha wrote:
I'm trying to debug an extremely strange bug whose symptoms appear
in a std.parallelism example, though I'm not at all sure the root
cause is in std.parallelism. The bug report is at https://github.com/dsimcha/std.parallelism/issues/1
#issuecomment-10
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> On 4/15/2011 8:40 PM, Andrei Alexandrescu wrote:
> > On 4/15/11 10:22 PM, dsimcha wrote:
> >> I'm trying to debug an extremely strange bug whose symptoms appear in a
> >> std.parallelism example, though I'm not at all sure the roo
On 4/15/2011 11:40 PM, Andrei Alexandrescu wrote:
On 4/15/11 10:22 PM, dsimcha wrote:
I'm trying to debug an extremely strange bug whose symptoms appear in a
std.parallelism example, though I'm not at all sure the root cause is in
std.parallelism. The bug report is at
https://github.com/dsimcha/
On 4/16/2011 2:09 AM, Robert Jacques wrote:
On Fri, 15 Apr 2011 23:22:04 -0400, dsimcha wrote:
I'm trying to debug an extremely strange bug whose symptoms appear in
a std.parallelism example, though I'm not at all sure the root cause
is in std.parallelism. The bug report is at
https://github.c
On 4/16/2011 10:11 AM, dsimcha wrote:
My only concern is whether this non-determinism represents some deep
underlying bug. For a given work unit allocation (work unit allocations
are deterministic and only change when the number of threads changes or
they're changed explicitly), I can't figure ou
On 4/16/2011 10:55 AM, Andrei Alexandrescu wrote:
On 4/16/11 9:52 AM, dsimcha wrote:
Output:
Rounding mode: 0
0.7853986633972191094
Rounding mode: 0
0.7853986633972437348
I think at this precision the difference may be in random bits. Probably
you don't need to worry about it.
Andrei
"rando
On 4/16/11 9:52 AM, dsimcha wrote:
Output:
Rounding mode: 0
0.7853986633972191094
Rounding mode: 0
0.7853986633972437348
I think at this precision the difference may be in random bits. Probably
you don't need to worry about it.
Andrei
== Quote from dsimcha (dsim...@yahoo.com)'s article
> On 4/16/2011 10:11 AM, dsimcha wrote:
> Output:
> Rounding mode: 0
> 0.7853986633972191094
> Rounding mode: 0
> 0.7853986633972437348
This is not something I can replicate on my workstation.
On 4/16/2011 11:16 AM, Iain Buclaw wrote:
== Quote from dsimcha (dsim...@yahoo.com)'s article
On 4/16/2011 10:11 AM, dsimcha wrote:
Output:
Rounding mode: 0
0.7853986633972191094
Rounding mode: 0
0.7853986633972437348
This is not something I can replicate on my workstation.
Interesting. S
"dsimcha" wrote in message
news:iocalv$2h58$1...@digitalmars.com...
> Output:
> Rounding mode: 0
> 0.7853986633972191094
> Rounding mode: 0
> 0.7853986633972437348
Could be something somewhere is getting truncated from real to double, which
would mean 12 fewer bits of mantisa. Maybe the FPU
On 4/16/11 9:59 AM, dsimcha wrote:
On 4/16/2011 10:55 AM, Andrei Alexandrescu wrote:
On 4/16/11 9:52 AM, dsimcha wrote:
Output:
Rounding mode: 0
0.7853986633972191094
Rounding mode: 0
0.7853986633972437348
I think at this precision the difference may be in random bits. Probably
you don't need
On 4/16/2011 6:46 AM, Iain Buclaw wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
That's a good thought. FP addition results can differ dramatically depending on
associativity.
And not to forget optimisations too. ;)
The dmd optimizer is careful not to reorder evalu
> Could be something somewhere is getting truncated from real to double, which
> would mean 12 fewer bits of mantisa. Maybe the FPU is set to lower precision
> in one of the threads?
Yes indeed, this is a _Windows_ "bug".
I have experienced this in Windows before, the main thread's FPU state regi
On 4/16/2011 2:15 PM, Timon Gehr wrote:
Could be something somewhere is getting truncated from real to double, which
would mean 12 fewer bits of mantisa. Maybe the FPU is set to lower precision
in one of the threads?
Yes indeed, this is a _Windows_ "bug".
I have experienced this in Windows be
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> On 4/16/2011 6:46 AM, Iain Buclaw wrote:
> > == Quote from Walter Bright (newshou...@digitalmars.com)'s article
> >> That's a good thought. FP addition results can differ dramatically
> >> depending on
> >> associativity.
> >
> >
On 4/16/2011 2:24 PM, dsimcha wrote:
On 4/16/2011 2:15 PM, Timon Gehr wrote:
Could be something somewhere is getting truncated from real to
double, which
would mean 12 fewer bits of mantisa. Maybe the FPU is set to lower
precision
in one of the threads?
Yes indeed, this is a _Windows_ "bug".
On 4/16/2011 9:52 AM, Andrei Alexandrescu wrote:
I seem to remember that essentially some of the last bits printed in such a
result are essentially arbitrary. I forgot what could cause this.
To see what the exact bits are, print using %A format.
In any case, floating point bits are not random.
On 4/16/2011 11:43 AM, Iain Buclaw wrote:
I was thinking more of a case of FPU precision rather than ordering: as in you
get
a different result computing on SSE in double precision mode on the one hand,
and
by computing on x87 in double precision then writing to a double variable in
memory.
On Apr 16, 2011, at 11:43 AM, dsimcha wrote:
>>
>> Close: If I add this instruction to the function for the new thread, the
>> difference goes away. The relevant statement is:
>>
>> auto t = new Thread( {
>> asm { fninit; }
>> res2 = sumRange(terms);
>> } );
>>
>> At any rate, this is a **huge*
On 4/16/2011 11:51 AM, Sean Kelly wrote:
On Apr 16, 2011, at 11:43 AM, dsimcha wrote:
Close: If I add this instruction to the function for the new thread, the
difference goes away. The relevant statement is:
auto t = new Thread( { asm { fninit; } res2 = sumRange(terms); } );
At any rate, thi
Walter:
> The dmd startup code (actually the C startup code) does an fninit. I never
> thought about new thread starts. So, yeah, druntime should do an fninit on
> thread creation.
My congratulations to all the (mostly two) people involved in finding this bug
and its causes :-)
I'd like to see
On Sat, 16 Apr 2011 15:32:12 -0400, Walter Bright
wrote:
On 4/16/2011 11:51 AM, Sean Kelly wrote:
On Apr 16, 2011, at 11:43 AM, dsimcha wrote:
Close: If I add this instruction to the function for the new thread,
the
difference goes away. The relevant statement is:
auto t = new Thread(
On Apr 16, 2011, at 1:02 PM, Robert Jacques wrote:
> On Sat, 16 Apr 2011 15:32:12 -0400, Walter Bright
> wrote:
>>
>>
>> The dmd startup code (actually the C startup code) does an fninit. I never
>> thought about new thread starts. So, yeah, druntime should do an fninit on
>> thread creation
On Tue, 19 Apr 2011 14:18:46 -0400, Sean Kelly
wrote:
On Apr 16, 2011, at 1:02 PM, Robert Jacques wrote:
On Sat, 16 Apr 2011 15:32:12 -0400, Walter Bright
wrote:
The dmd startup code (actually the C startup code) does an fninit. I
never thought about new thread starts. So, yeah, drun
Sean Kelly wrote:
On Apr 16, 2011, at 1:02 PM, Robert Jacques wrote:
On Sat, 16 Apr 2011 15:32:12 -0400, Walter Bright
wrote:
The dmd startup code (actually the C startup code) does an fninit. I never
thought about new thread starts. So, yeah, druntime should do an fninit on
thread creati
On Apr 20, 2011, at 5:06 AM, Don wrote:
> Sean Kelly wrote:
>> On Apr 16, 2011, at 1:02 PM, Robert Jacques wrote:
>>> On Sat, 16 Apr 2011 15:32:12 -0400, Walter Bright
>>> wrote:
The dmd startup code (actually the C startup code) does an fninit. I never
thought about new thread
"Sean Kelly" wrote in message
news:mailman.3597.1303316625.4748.digitalmar...@puremagic.com...
On Apr 20, 2011, at 5:06 AM, Don wrote:
> Sean Kelly wrote:
>> On Apr 16, 2011, at 1:02 PM, Robert Jacques wrote:
>>> On Sat, 16 Apr 2011 15:32:12 -0400, Walter Bright
>>> wrote:
The dmd s
On Apr 20, 2011, at 10:46 AM, JimBob wrote:
>
> "Sean Kelly" wrote in message
> news:mailman.3597.1303316625.4748.digitalmar...@puremagic.com...
> On Apr 20, 2011, at 5:06 AM, Don wrote:
>
>> Sean Kelly wrote:
>>> On Apr 16, 2011, at 1:02 PM, Robert Jacques wrote:
On Sat, 16 Apr 2011 15:32
Sean Kelly wrote:
On Apr 20, 2011, at 10:46 AM, JimBob wrote:
"Sean Kelly" wrote in message
news:mailman.3597.1303316625.4748.digitalmar...@puremagic.com...
On Apr 20, 2011, at 5:06 AM, Don wrote:
Sean Kelly wrote:
On Apr 16, 2011, at 1:02 PM, Robert Jacques wrote:
On Sat, 16 Apr 2011 15:32
34 matches
Mail list logo
