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.




_________________________
 Racket Developers list:
 http://lists.racket-lang.org/dev

Reply via email to