Web lists-archives.com

Re: [Mingw-users] msvcrt printf bug




Hi Peter,

On 19-Jan-17 12:35, Peter Rockett wrote:
> Guys
>
> At the risk of wading into a thread that has become very heated, could I
> drag this back to technical matters.

Excellent idea indeed.

> I think everybody (apart maybe from the OP) agrees how floating point
> numbers behave. Keith makes a good point about rounding. Can I toss in
> another feature that changing the compiler optimisation level often
> reorders instructions meaning that rounding errors accumulate in
> different ways. So changing the optimisation level often slightly
> changes the numerical answers. :-\

I agree that it could well (or even should?) be the case... but it's not 
in my case - to my own pleasant surprise.

I can build with -O3 to get the most juice for releases, or with -O0 to 
debug... my logs are still the same (spare for actual bugs). I even 
compile with -mtune=native -march=native -mpopcnt -mmmx -mssse3 -msse4.2 
(native: I'm on Xeons), although I doubt very much the Borland compiler 
knows anything about those optimizations... and yet the latter's logs 
are still identical to MinGW's.
Honestly it beats me as well... but I'm sure glad it's the case! :-)

> Emanuel - The one thing I cannot grasp is that you have built s/w with a
> range of toolchains, but you are very focussed on obtaining exactly the
> same numerical answers - seemingly to the level of false precision - for
> each build.

Argh... no, Peter: I am (and always was!) well aware of the inherent 
IMprecision of floats - it is thoroughly managed in the algorithm and is 
sufficient for that particular purpose (e.g. nobody cares whether a task 
should be scheduled a millisecond sooner or later... when most of them 
take hours!).

> I am struggling to see the reason for this, especially as
> you are talking about a stochastic (GA) algorithm. Why is this such a
> big issue for you? You mentioned you work in aerospace. Is this some
> sort of ultra safety conscious aerospace certification thing?

No - we optimize the scheduling of processes, not the internals of the 
processes themselves. There are two reasons for my obsession with 
consistency across compilers, as I explained a few posts back:
(1) we edit and _debug_ in Borland, for the simple reason that the 
environment is frankly very good, so our productivity is excellent(*)... 
but we actually release (ship) MinGW builds, because they are 
dramatically faster than Borland's. Now in order to debug in Borland a 
glitch spotted in our MinGW releases, we must be able to reproduce 
exactly the same glitch in the former. On the other hand, given the 
nature of what we do (GAs), and the fact that some glitches don't show 
up before hours of computation... well I think you've got it already
(2) I found that it really is an excellent QC practice to make sure the 
two builds behave exactly the same, because each time it was NOT the 
case, there was a bug somewhere. Each and every time, no exceptions.

(*) Before sending me a barrage of complaints, please be aware that I do 
have NetBeans... but (1) I find its editor simply not on par with 
Borland's, and (2) trying to attach our DLL to debug, the list of PIDs 
was just empty (if some of you has an advice on how to solve that, I 
would be grateful - because the raw gdb is really painful).

All the best,

Emanuel

> P.
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe