[racket-dev] assembler code within gmplonglong.h
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
Re: [racket-dev] assembler code within gmplonglong.h
On the program (time (for/fold ([v (for/fold ([v 1]) ([i (in-range 1)]) (* (add1 i) v))]) ([i (in-range 1)]) (/ 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 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [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 1)]) (* (add1 i) v))]) ([i (in-range 1)]) (/ 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
