[racket-dev] assembler code within gmplonglong.h

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Sat Jan 11 22:22:21 EST 2014

On the program

 (time
  (for/fold ([v (for/fold ([v 1]) ([i (in-range 10000)])
                  (* (add1 i) v))])
      ([i (in-range 10000)])
    (/ v (add1 i))))

when compiling for 32-bit x86 with the latest XCode's clang and using a
2013 MacBook Pro running Mavericks, I get a 50% speed decrease when
disabling the assembly code in "gmplonglong.h". So, at least for 32-bit
x86, I think the assembly code is probably worthwhile.

Assembly seems to matter less for 64-bit mode. I copied the x86_64
assembly from the current GMP, and it seems to improve performance by
10%. That's not much of a difference, but enough that I would be
inclined add the assembly; I hesitate only because adding more assembly
is exactly the opposite of your request.

At Sun, 12 Jan 2014 01:31:21 +0100, Juan Francisco Cantero Hurtado wrote:
> Hi. The last days I've been reading the code within gmplonglong.h and 
> I've a question/request. Why there is assembler code? Why not just to 
> remove the assembler code and to use the C fallback for every CPU?.
> 
> These days the racket developers (and users) mostly only test their code 
> on amd64, specially the math code. The file doesn't contain assembler 
> code for amd64, so almost every one is compiling their interpreters with 
> the C code.
> 
> The old CPUs supported by gmplonglong.h are dead or have a modern C 
> compiler. I doubt the assembler code even gives a better performance to 
> racket than the C version.
> 
> I'm complaining because I've tried to compile racket 5.3.6 (with some 
> patches related to clang and gmp backported from the master branch) with 
> clang and the build failed. I read the code and I was stunned when I saw 
> the assembler code supporting so old CPUs and the C fallback used by amd64.
> 
> 
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev

Posted on the dev mailing list.