Thanks for the heads-up. I’m glad to hear that mingw works for Avogadro and I’m obviously thrilled to hear of the speed boost. I’m forwarding your message to the Avogadro Devel mailing list so that the next (1.1.1) release can be tested with mingw compilation.
Since I don’t use Windows, much less mingw, would the Avogadro installation need to install msys as well?
Begin forwarded message:
4got a detail concerning the build of QT.
qmake.conf , change so they read
QMAKE_CFLAGS_RELEASE = -O3 -fno-gcse -mtune=(cpu at least pentium3)
before you start any configure.
in regard 2 “Hi Geoff”.
Just compiled Avogadro with mingw gcc 4.8.1, and as usual, having some 2 billion lines + of code compiled
with it recently, Cmake, Paraview, VTK, ITK, BOOST, QT 4 and 5 (don’t understand why 5 is issued,as no gains for a redundant restructure) ,
GMSH, Gimp, Imagemagick, Maxima, R, Povray, OpenCv, Qbittorrent, FLTK, GNUmeric, speed/stability critical parts of GTK,
GNUplot, 7zip, UPX, Scite/scintilla, wxWidgets, to mention a few,
All resulting in to the least, 40%, up to 150/200% increase in execution speed, and "super"stability during execution
on whatever winbox, tested on an array of xp’s and 7’ns.
The parsing and rendering of files was reduced to at least, half the time your msvc win binary issue performed.
Avogadro mingw runs like charm without spending precious cpu/gpu power on redundant register shifting.
I used my cmake 8,latest with msys makefiles and that performed an installation where the Avogadro installation
used the equally built openbabel plugins/shares directly.
There was only 2 minor issues of msvc contamination of the code, a defined win32 that equaled msvc, and
one other using msvc non C/C++ compatible code on a few lines, otherwise it compiled just fine.
You ought to consider a mingw issue of Avogadro, as it makes the msvc built one, appear as close to a joke.
If you decide to do so, some precautions.
Mingw/msys must be ahead of Windows in the path environment.
have in mind that gcc are highly structurable (the core of almost all supercomputers) and
gcc 4.6/4.7/4.8 -O3 by default implements.
-fcprop-registers > -O
-fgcse -fgcse-lm -fgcse-sm -fgcse-las **
-fcrossjumping > -O2
-falign-functions -falign-jumps -falign-loops
-falign-labels -freorder-blocks -fprefetch-loop-arrays > -O3
and most of them works just fine,
the gcse optimizers seems to be reliable only up to -O2, as garbling up computed goto’s, together with
-fguess-branch-probability, as I experimented with Gnuplot and some others -fno-gcse -fno-guess-branch-probability
performed around 150% faster/superstable, compared with fully optimized msvc/latest versions.
Beware of that -fguess-branch-probability actually fixes up code jumps of non perfectly structured cod and
hence can disable functionality of produced code, and another caveat is -g -O2 as of many default automake builds
actually is a source of gcc debugging systems poor reputation as this switch produces slightly different binaries
each and every build, -g -O2 -fno-guess-branch-probability gives the debugger a fair chance.
I commonly use -O3 -fno-gcse -mtune=pentium3 -pipe -mthreads for all programs that will be under portable deployment,
and add -march=(suitable cpu) -mtune=(suitable cpu) for stationary customized deployment, but such will only
run on the specified cpu architechture only, the will of course perform extremely fast.
Many thank’s for your src distro, all coders have performed an awesome job that I really appreciate
the application as whole is one of the best chemistry packages Iv’e ever used,
- with the hope that info can be of some assistance to make thing better.
With please welcome back if any Q’s