Hallo,
The following program works fine when interpreted, but crashes when compiled:
``` (declare (block) (standard-bindings) (extended-bindings))
(define (calculate-largest-prime) (- (expt 2 74207281) 1))
(define *largest-prime* (time (calculate-largest-prime))) (define *prime-string* (time (number->string *largest-prime*))) (time (println *prime-string*)) ```
Gambit 4.8.3, GCC 5.3.0, Ubuntu 14.04
Afficher les réponses par date
That is amusing! When you compile this program the compiler sees that the expression in calculate-largest-prime is a constant, so it computes the value at compilation time and dumps the value in the generated C code. If you are patient, add the -expansion option to see the code after the high level program transformations. You will see:
(define calculate-largest-prime (lambda () 3003764…))) ;; over 22 million digits!
So the (time (calculate-largest-prime)) reports a run time of 0 milliseconds!
Anyway, the segfault happens in number->string . I don’t yet know why but I suspect a bug in gcc due to the enormous bignum constant. I’ll investigate.
Marc
On Jan 25, 2016, at 3:58 AM, Alex Silva asandroq@gmail.com wrote:
Hallo,
The following program works fine when interpreted, but crashes when compiled:
(declare (block) (standard-bindings) (extended-bindings)) (define (calculate-largest-prime) (- (expt 2 74207281) 1)) (define *largest-prime* (time (calculate-largest-prime))) (define *prime-string* (time (number->string *largest-prime*))) (time (println *prime-string*))
Gambit 4.8.3, GCC 5.3.0, Ubuntu 14.04
-- -alex http://unendli.ch/ _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
The problem is now fixed. It was due to an unexpected sign extension of the bignum length, a large int constant about 2^31. This was causing the sign to become negative when cast to a 64 bit int (to be put in the header of the huge bignum constant). The same problem existed for structured constants (such as vectors, strings, u8vectors, etc) with a few million elements… not a very common thing in a program.
Now I get (without the printing of the number):
% time gsc/gsc -:=. -exe largest-prime.scm
real 0m26.256s user 0m24.616s sys 0m1.445s % time ./largest-prime (time (calculate-largest-prime)) 0 ms real time 0 ms cpu time (0 user, 0 system) no collections no bytes allocated 1 minor fault no major faults (time (number->string *largest-prime*)) 31878 ms real time 31863 ms cpu time (29263 user, 2600 system) 141 collections accounting for 2277 ms real time (1400 user, 877 system) 10453851736 bytes allocated 1763485 minor faults no major faults
real 0m31.946s user 0m29.267s sys 0m2.648s
Marc
On Jan 25, 2016, at 8:41 AM, Marc Feeley feeley@iro.umontreal.ca wrote:
That is amusing! When you compile this program the compiler sees that the expression in calculate-largest-prime is a constant, so it computes the value at compilation time and dumps the value in the generated C code. If you are patient, add the -expansion option to see the code after the high level program transformations. You will see:
(define calculate-largest-prime (lambda () 3003764…))) ;; over 22 million digits!
So the (time (calculate-largest-prime)) reports a run time of 0 milliseconds!
Anyway, the segfault happens in number->string . I don’t yet know why but I suspect a bug in gcc due to the enormous bignum constant. I’ll investigate.
Marc
On Jan 25, 2016, at 3:58 AM, Alex Silva asandroq@gmail.com wrote:
Hallo,
The following program works fine when interpreted, but crashes when compiled:
(declare (block) (standard-bindings) (extended-bindings)) (define (calculate-largest-prime) (- (expt 2 74207281) 1)) (define *largest-prime* (time (calculate-largest-prime))) (define *prime-string* (time (number->string *largest-prime*))) (time (println *prime-string*))
Gambit 4.8.3, GCC 5.3.0, Ubuntu 14.04
-- -alex http://unendli.ch/ _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Hi,
On 25/01/16 22:16, Marc Feeley wrote:
The problem is now fixed. It was due to an unexpected sign extension of the bignum length, a large int constant about 2^31. This was causing the sign to become negative when cast to a 64 bit int (to be put in the header of the huge bignum constant). The same problem existed for structured constants (such as vectors, strings, u8vectors, etc) with a few million elements… not a very common thing in a program.
Thanks!