have good VC++ 6.0 build of GMP 4.1; make it available?

[Décio Luiz Gazzoni Filho]

On Apr 16, 2008, at 6:37 PM, Rev. Chris Korda wrote:

> Du's project builds 4.1 correctly but without assembler  
> optimizations. This
> is a serious problem if performance is an issue. Gladman's project  
> has the
> assembler optimizations, but only works with .NET 2008 or 2005. I  
> don't like
> .NET, for various reasons, the most important of which is that .NET  
> binaries
> can can be significantly slower than their VC++ 6.0 equivalents.
>

They *CAN* be if you're using managed code (i.e. compiling to MSIL and  
JIT-compiling to native code at run time). I find it very hard to  
believe that unmanaged code is significantly slower than that produced  
by a previous version of the same compiler. Even more so considering  
the arithmetic code (you know, the code that most of the run time  
inside GMP is spent within) is virtually entirely written in assembly  
code, and this code would obviously be the same independent of the  
compiler used. In fact, I don't see enough time being spent in the C  
code, that even optimizing that time away to near zero would result in  
the 15% improvement you claimed below.

> My application only uses the mpf portion of GMP, and only does adds  
> and
> multiplies, at largish precision (e.g. 768 bits or more). I have  
> found that
> my application runs approximately 15% slower with Gladman's .NET
> Pentium4/SSE build than with my VC++ 6.0 P6 build. This is enough of a
> difference to keep me using VC++ 6.0 for the moment.

So you changed two variables (compiler and target CPU)? Maybe a third,  
considering Brian Gladman doesn't make his GMP 4.1.2 project files  
available for download anymore (that I could find, anyway), so you're  
changing the GMP version too? (Although again, I wouldn't expect a  
newer version of GMP to perform worse than an older one.)

Why not change a single one (compiler) and then report the tests? Your  
methodology is inherently flawed and hence your comparison is bogus.

Also, what hardware is this? And especially, are you compiling to  
managed or native code? If the former, then your comparison is invalid  
from the start, and you've been basically wasting your time with this.  
Try recompiling to native code and you'll see that both are on par,  
possibly Gladman's is a little faster.

If despite all this, VC++ 6.0 is still faster than the newer  
compilers, I would expect a mismatch in calling convention (i.e. using  
cdecl instead of fastcall), or some condition that's preventing code  
inlining. Rather than switching to an old, deprecated, non-standards- 
compliant (can you even compile the C++ interface?) compiler, I'd  
investigate what's wrong in the C code and/or compiler flags, try to  
fix that and contribute to the community, most of which should no  
longer be using a 10-year old compiler.

Décio