have good VC++ 6.0 build of GMP 4.1; make it available?
Décio Luiz Gazzoni Filho
decio at decpp.net
Thu Apr 17 13:47:10 CEST 2008
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
> 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
> 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.
More information about the gmp-discuss