[racket-dev] assembler code within gmplonglong.h

I will give a try to your example.

I disabled the assembler code in the OpenBSD port because with your last 
patch to gmplonglong and clang, the 5.3.6 math lib was broken on i386. 
We will have the CVS lock soon and I want be very careful now. I used 
initially clang to fix a crash in udp.rktl, now the port uses GCC 4.6. I 
will report both bugs when I have some of free time, if I can reproduce 
both with racket 6.

It's OK if you want use assembler for the math code, I was just worried 
when I saw the amount of code for old CPUs, especially because I will 
work with some of these CPUs pretty soon and I fear there is more 
"untested" code for these archs. Compared with the usually elegant use 
of C macros in racket, that file is really hairy :) .

And yes, 50% is a big difference, good to know :) .

On 01/12/14 04:22, Matthew Flatt wrote:
> 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.
>>
>>