Building GMP-ECM with Visual Studio 2017

[xilman]

Originally Posted by Brian Gladman

The downside of static linking is that GMP-ECM has to be built for specific CPUs/GPUs if full optimisation is to be provided.

The zero-th law of optimization: first get it right, then get it fast.

For those who care about subsequent optimization steps, I'm sure that there a number of people here who will assist you.

[LaurV]

Originally Posted by xilman

The zero-th law of optimization: first get it right, then get it fast.

That is incomplete.
The zero-th law of optimization: first get it right, then get it fast, then get it right again.
Or even:
The zero-th law of optimization: first get it right, then get it fast, then repeat

In my daily job I met hundreds of situations where the firmware didn't behave as expected after optimizations were done (I mean both turning on/off different levels of optimizations in the compiler and also hand-made optimizations, i.e. changes in the code, but especially playing with the compiler's optimizer... we preffer to use -o0 due to better step-debugging features, then switch to -o1, -o2, etc, space, time, optimizations, as the MCU memory gets full, or things get slower, and in these cases we witnessed many situations in which the code didn't work as expected after the compiler did its tricks, especially things related to timers, interrupts, signals synchronization, pwm, etc).

[paulunderwood]

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

Source

[xilman]

Originally Posted by LaurV

That is incomplete.
The zero-th law of optimization: first get it right, then get it fast, then repeat

I'll stick with my version. What you are describing, in my view, is not the zeroth law but the overall process of optimization.

The first and second laws, as I know them are:

1) Don't do it.
2) Don't do it now.


I'll leave you to think about what they mean in terms of specific optimization techniques.

[Brian Gladman]

Originally Posted by xilman

The zero-th law of optimization: first get it right, then get it fast.

For those who care about subsequent optimization steps, I'm sure that there a number of people here who will assist you.

In this case it is not an optimisation issue for the GMP-ECM code but simply that of choosing an MPIR library to link to it that has been built with assembler code support for the target machine in question.

As of now there are 20 different machine architectures for x64 versions of MPIR and hence up to this number of GMP-ECM binaries, which is a lot to manage.

Since most DLL issues are the result of missing MS library DLLs, I had hoped to avoid these by providing a statically linked GMP-ECM and a statically linked MPIR DLL so that the the only dynamic link involved would be between GMP-ECM and MPIR. This almost works but fails for some reason when MPIR code involves file input/output.

Anyway for those brave enough to do their own builds, I have now uploaded my Visual Studio 2017 build files (with static linking) to the GMP-ECM repository.

[jwaltos]

As one of the end users who has downloaded your binaries from Jeff G.'s site, thanks for providing your work. I personally do not require optimized programs since what has been provided was more than sufficient for generic factorization.

Regarding optimization, here is a quote from Jon Bentley's "Programming Pearls" on p.88:
"Don Knuth has observed that premature optimization is the root of much programming evil;..."

Successful technological alchemy requires efficiency..and wizardry.