-------- Forwarded Message -------- From: PJ SearCon <[email protected]> To: [email protected], [email protected] 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 package. 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 -fno-guess-branch-probability 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 _______________________________________________ Bug-glpk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-glpk
