[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-glpk] [Fwd: GLPK version 4.4 and up compiled with mingw 8 crasches]

From: Andrew Makhorin
Subject: [Bug-glpk] [Fwd: GLPK version 4.4 and up compiled with mingw 8 crasches]
Date: Thu, 26 Sep 2013 03:53:19 +0400

-------- Forwarded Message --------
From: PJ SearCon <address@hidden>
To: address@hidden, address@hidden
Subject: GLPK version 4.4 and up compiled with mingw 8 crasches
Date: Wed, 25 Sep 2013 19:17:01 +0200

I have during some months, tested and built an array of opensource src with
mingw version 4.6 to 4.8 stable/msys chains.

As having a break for some four years now with building programs, I was
a bit surprised of the performance of the latest mingw's, in average, 
cpu tuned only
outperforming equally optimized msvc builds by 40% in execution speed.

Also found that the -march=(xxx) specified build only working on 
specified host cpu
builds were up to 150% faster in comparison subject equal msvc builds.
"I dont like implementations compared to several switches connected in 
serial for to turn on the light in a room"
I today regard the MSVC built executablesquite pathetic , not all src 
works though as macros for windows
builds often equals MSVC only, Python, one really MSVC corrupted src 

Al builds, including 
BOOST,ITK,VTK,Paraview,Cmake,QT,GMSH,FFTW,OpenSSL,R,Maxima and a lot more
turned out as extremely fast aka "not using 3 main switches to turn on 
the light" exec's
and as far as I can detect, during heavy deployment, would not hesitate
to apply them in mission critical appliances.

Been using GLPK 4.52 for a while as it compiled well with mingw 4.6/4.7
Installed mingw 4.8 and rebuild much of the src i had without any 
problems, and it built R latest
the first I've succeeded to build with mingw4.6 and up,
all optimizers on completely cpu structured/aligned, only disabling the 
gcse group
and guess branch probability GNUplot turned out 150% percent faster than 
the second best
mode enter down running demos.

GLPK 4.52 compiled without any problems but all build variants crashed 
during *.mod parsing.
Tested downwards and all builds the same, until 4.39 that now runs like 
charm and with realtime speed
with all types of optimizer arrays tested, running best with full cpu 
aligned -mtune=(xx) and gcse group disabled.

Unfortunately rinning out of time to track these bugs with gdb, and as 
of gdb "enabled" compiles i see in the configure
file that -g -O2 is implemented, and that is a major issue when it comes 
to gdb's reputation.
from -O and up -fguess-branch-probability is on by default, and all 
binaries produced comes out slightly different
in structure with each and every build, so to have a fair chance -g -O2 
would be more appropriate.

Hope this at least can provide you with a tracer to above mentioned issues.

Sincerely and with many thanks for your src package.

Peter J'sson

reply via email to

[Prev in Thread] Current Thread [Next in Thread]