GNU bug report logs -
#30020
floating point unboxing regression in 2.2.3
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30020 in the body.
You can then email your comments to 30020 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guile <at> gnu.org
:
bug#30020
; Package
guile
.
(Mon, 08 Jan 2018 03:17:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Thompson, David" <dthompson2 <at> worcester.edu>
:
New bug report received and forwarded. Copy sent to
bug-guile <at> gnu.org
.
(Mon, 08 Jan 2018 03:17:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello,
Guile 2.2.3 seems to have lost some of the abilities that Guile 2.2.2
had wrt unboxing floats. Here's a simple procedure to show the
problem. It simply adds the first two elements of an f32vector:
(define (add-two-floats bv)
(+ (f32vector-ref bv 0) (f32vector-ref bv 1)))
Here's the disassembly from 2.2.2 (note that f64->scm appears only once):
Disassembly of #<procedure add-two-floats (bv)> at #x7efef4006230:
0 (assert-nargs-ee/locals 2 1) ;; 3 slots (1 arg) at
(unknown file):22:0
1 (load-u64 2 0 0) at
(unknown file):23:26
4 (bv-f32-ref 2 1 2)
5 (load-u64 0 0 4) at
(unknown file):23:47
8 (bv-f32-ref 1 1 0)
9 (fadd 2 2 1) at
(unknown file):23:23
10 (f64->scm 1 2)
11 (handle-interrupts)
12 (return-values 2) ;; 1 value
And here is 2.2.3:
Disassembly of #<procedure add-two-floats (bv)> at #x2457140:
0 (assert-nargs-ee/locals 2 1) ;; 3 slots (1 arg) at
(unknown file):29:0
1 (load-u64 2 0 0) at
(unknown file):30:26
4 (bv-f32-ref 2 1 2)
5 (f64->scm 2 2)
6 (load-u64 0 0 4) at
(unknown file):30:47
9 (bv-f32-ref 1 1 0)
10 (f64->scm 1 1)
11 (scm->f64 2 2) at
(unknown file):30:23
12 (scm->f64 1 1)
13 (fadd 2 2 1)
14 (f64->scm 1 2)
15 (handle-interrupts)
16 (return-values 2) ;; 1 value
2.2.3 is reading unboxed floats from the bytevector, boxing them,
unboxing them, then calling fadd. The result is that some formerly
well optimized code of mine that generated little to no garbage is now
generating lots of garbage. Is this intentional due to the
"instruction explosion" work going on is it a legitimate bug?
Thanks,
- Dave
Information forwarded
to
bug-guile <at> gnu.org
:
bug#30020
; Package
guile
.
(Wed, 02 May 2018 14:12:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 30020 <at> debbugs.gnu.org (full text, mbox):
Hello,
On Sun, Jan 7, 2018 at 10:16 PM, Thompson, David
<dthompson2 <at> worcester.edu> wrote:
> Guile 2.2.3 seems to have lost some of the abilities that Guile 2.2.2
> had wrt unboxing floats.
Ping. This regression is a bummer. :(
- Dave
Information forwarded
to
bug-guile <at> gnu.org
:
bug#30020
; Package
guile
.
(Mon, 28 May 2018 06:23:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 30020 <at> debbugs.gnu.org (full text, mbox):
Hi David,
Sorry for the long delay.
"Thompson, David" <dthompson2 <at> worcester.edu> writes:
> Guile 2.2.3 seems to have lost some of the abilities that Guile 2.2.2
> had wrt unboxing floats. Here's a simple procedure to show the
> problem. It simply adds the first two elements of an f32vector:
>
> (define (add-two-floats bv)
> (+ (f32vector-ref bv 0) (f32vector-ref bv 1)))
Thanks for the tiny test case. This helps a lot!
> Here's the disassembly from 2.2.2 (note that f64->scm appears only once):
>
> Disassembly of #<procedure add-two-floats (bv)> at #x7efef4006230:
>
> 0 (assert-nargs-ee/locals 2 1) ;; 3 slots (1 arg) at
> (unknown file):22:0
> 1 (load-u64 2 0 0) at
> (unknown file):23:26
> 4 (bv-f32-ref 2 1 2)
> 5 (load-u64 0 0 4) at
> (unknown file):23:47
> 8 (bv-f32-ref 1 1 0)
> 9 (fadd 2 2 1) at
> (unknown file):23:23
> 10 (f64->scm 1 2)
> 11 (handle-interrupts)
> 12 (return-values 2) ;; 1 value
>
> And here is 2.2.3:
>
> Disassembly of #<procedure add-two-floats (bv)> at #x2457140:
>
> 0 (assert-nargs-ee/locals 2 1) ;; 3 slots (1 arg) at
> (unknown file):29:0
> 1 (load-u64 2 0 0) at
> (unknown file):30:26
> 4 (bv-f32-ref 2 1 2)
> 5 (f64->scm 2 2)
> 6 (load-u64 0 0 4) at
> (unknown file):30:47
> 9 (bv-f32-ref 1 1 0)
> 10 (f64->scm 1 1)
> 11 (scm->f64 2 2) at
> (unknown file):30:23
> 12 (scm->f64 1 1)
> 13 (fadd 2 2 1)
> 14 (f64->scm 1 2)
> 15 (handle-interrupts)
> 16 (return-values 2) ;; 1 value
>
> 2.2.3 is reading unboxed floats from the bytevector, boxing them,
> unboxing them, then calling fadd. The result is that some formerly
> well optimized code of mine that generated little to no garbage is now
> generating lots of garbage.
I did the moral equivalent of a git bisect, and found the culprit:
commit d4883307ca64a7028b9a6cd072974437306c19d3
Author: Andy Wingo <wingo <at> pobox.com>
Date: Thu Nov 30 10:41:45 2017 +0100
Minor CSE run-time optimization
* module/language/cps/cse.scm (compute-equivalent-subexpressions): Minor
optimization to reduce the size of equivalent expression keys, and to
avoid some work if an expression has no key.
Fortunately, this commit can be reverted in isolation without any
difficulty, and apparently without any negative consequences. If a
better solution isn't found soon, perhaps that's what we should do.
Andy, do you have any idea what's going on here?
Thanks,
Mark
Information forwarded
to
bug-guile <at> gnu.org
:
bug#30020
; Package
guile
.
(Mon, 28 May 2018 19:41:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 30020 <at> debbugs.gnu.org (full text, mbox):
Hi Mark,
On Mon, May 28, 2018 at 2:21 AM, Mark H Weaver <mhw <at> netris.org> wrote:
> Hi David,
>
> Sorry for the long delay.
No worries!
> I did the moral equivalent of a git bisect, and found the culprit:
>
> commit d4883307ca64a7028b9a6cd072974437306c19d3
> Author: Andy Wingo <wingo <at> pobox.com>
> Date: Thu Nov 30 10:41:45 2017 +0100
>
> Minor CSE run-time optimization
>
> * module/language/cps/cse.scm (compute-equivalent-subexpressions): Minor
> optimization to reduce the size of equivalent expression keys, and to
> avoid some work if an expression has no key.
Thanks for taking the time to look at it. Curious to know what Andy thinks.
- Dave
Reply sent
to
Mark H Weaver <mhw <at> netris.org>
:
You have taken responsibility.
(Mon, 11 Jun 2018 14:29:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
"Thompson, David" <dthompson2 <at> worcester.edu>
:
bug acknowledged by developer.
(Mon, 11 Jun 2018 14:29:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 30020-done <at> debbugs.gnu.org (full text, mbox):
Mark H Weaver <mhw <at> netris.org> writes:
> I did the moral equivalent of a git bisect, and found the culprit:
>
> commit d4883307ca64a7028b9a6cd072974437306c19d3
> Author: Andy Wingo <wingo <at> pobox.com>
> Date: Thu Nov 30 10:41:45 2017 +0100
>
> Minor CSE run-time optimization
>
> * module/language/cps/cse.scm (compute-equivalent-subexpressions): Minor
> optimization to reduce the size of equivalent expression keys, and to
> avoid some work if an expression has no key.
>
> Fortunately, this commit can be reverted in isolation without any
> difficulty, and apparently without any negative consequences. If a
> better solution isn't found soon, perhaps that's what we should do.
I pushed commit df93752479ab88446f5db4b1d6ebf53a85c7593f to the
stable-2.2 branch, which reverts the above commit. I'm closing this
bug, but feel free to reopen if there are still issues to resolve.
Thanks,
Mark
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 10 Jul 2018 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 289 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.