Hi
I've been testing Rex's build of Qt 4.8 (and KDE 4.10) on a CentOS 6 VM. When I tried to build QtCreator, I found that the gcc arguments were march=i686 mtune=atom.
I tried to see where 'atom' option was coming from but it wasn't from QtCreator sources. I created a small Qt test project and found that the Makefile generated after running qmake-qt4 has mtune=atom in the compiler options. The sample project and the makefile is attached.
The VM has Core i5 CPU (2 cores; the host has 4 cores). I'm attaching /proc/cpuinfo of the VM.
I'm also attaching the output of "g++ -Q -v" when run on a C++ source file (that contains just an empty main function) on the VM. That output says that the options were march=i686 & mtune=generic.
Can anybody tell me why 'mtune=atom' is generated by qmake?
regards,
Syam
Syam Krishnan wrote:
I've been testing Rex's build of Qt 4.8 (and KDE 4.10) on a CentOS 6 VM. When I tried to build QtCreator, I found that the gcc arguments were march=i686 mtune=atom.
...
Can anybody tell me why 'mtune=atom' is generated by qmake?
distro default optimization flags, to query for your OS/arch,
rpm --eval "%{optflags}"
(having redhat-rpm-config installed will probably make a difference)
-- rex
On 06/09/2013 07:42 PM, Rex Dieter wrote:
Syam Krishnan wrote:
...
Can anybody tell me why 'mtune=atom' is generated by qmake?
distro default optimization flags, to query for your OS/arch,
rpm --eval "%{optflags}"
The output is: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables
What exactly does this mean? As far as I know, the VM shouldn't have anything to do with Atom processor.
uname -a gives: Linux nutan 2.6.32-358.el6.i686 #1 SMP Thu Feb 21 21:50:49 UTC 2013 i686 i686 i386 GNU/Linux
As suggested by Thiago Macieira of Qt-Interest, I ran
qmake -d -d 2>&1 | grep atom > output
The output is attached. 'atom' came from /usr/lib/qt4/mkspecs/default/qmake.conf.
Regards,
Syam
Syam Krishnan wrote:
What exactly does this mean? As far as I know, the VM shouldn't have anything to do with Atom processor.
We build i686 packages with -mtune=atom based on the principle that all the non-Atom CPUs these days should be 64-bit and thus use the x86_64 version.
Kevin Kofler
On Thursday, June 27, 2013, Kevin Kofler kevin.kofler@chello.at wrote:
Syam Krishnan wrote:
What exactly does this mean? As far as I know, the VM shouldn't have anything to do with Atom processor.
We build i686 packages with -mtune=atom based on the principle that all
the
non-Atom CPUs these days should be 64-bit and thus use the x86_64 version.
I'm not sure if that's such a good assumption. For example, We stick to 32bit at work since some of the special purpose hardware we use don't have drivers for 64bit.
So, to use KDE 4.10 & qt 4.8.x on el6 32bit, do I need to build all rpms myself to avoid this atom business? The problem is it affects every qt based compilation on the machine!
If that's so, I wonder what performance would I be losing if I'm on something like an i7 or at least a core2.
Thanks,
Syam
Kevin Kofler
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On 06/27/2013 02:10 PM, Syam wrote:
On Thursday, June 27, 2013, Kevin Kofler <kevin.kofler@chello.at mailto:kevin.kofler@chello.at> wrote:
Syam Krishnan wrote:
What exactly does this mean? As far as I know, the VM shouldn't have anything to do with Atom processor.
We build i686 packages with -mtune=atom based on the principle that
all the
non-Atom CPUs these days should be 64-bit and thus use the x86_64
version.
I'm not sure if that's such a good assumption. For example, We stick to 32bit at work since some of the special purpose hardware we use don't have drivers for 64bit.
So, to use KDE 4.10 & qt 4.8.x on el6 32bit, do I need to build all rpms myself to avoid this atom business? The problem is it affects every qt based compilation on the machine!
The entire distribution is built using these same flags. Sounds like you'd rather be using gentoo?
-- rex
On Friday, June 28, 2013, Rex Dieter rdieter@fedoraproject.org wrote:
I'm not sure if that's such a good assumption. For example, We stick to 32bit at work since some of the special purpose hardware we use don't have drivers for 64bit.
So, to use KDE 4.10 & qt 4.8.x on el6 32bit, do I need to build all rpms myself to avoid this atom business? The problem is it affects every qt based compilation on the machine!
The entire distribution is built using these same flags. Sounds like
you'd rather be using gentoo?
Is that about Fedora or even RHEL?
Anyway, I'm no big fan of self-compilation. So gentoo wouldn't be my choice :-)
Syam
On 06/27/2013 08:01 PM, Syam wrote:
On Friday, June 28, 2013, Rex Dieter <rdieter@fedoraproject.org mailto:rdieter@fedoraproject.org> wrote:
I'm not sure if that's such a good assumption. For example, We stick to 32bit at work since some of the special purpose hardware we use don't have drivers for 64bit.
So, to use KDE 4.10 & qt 4.8.x on el6 32bit, do I need to build all rpms myself to avoid this atom business? The problem is it affects every qt based compilation on the machine!
The entire distribution is built using these same flags. Sounds like
you'd rather be using gentoo?
Is that about Fedora or even RHEL?
Both. RHEL is derived from fedora, and fedora (generally) builds the entire distribution with a standard set of optimization flags, which is what we are discussing here (apparently?).
-- rex
On Friday, June 28, 2013, Rex Dieter rdieter@fedoraproject.org wrote:
On 06/27/2013 08:01 PM, Syam wrote:
On Friday, June 28, 2013, Rex Dieter <rdieter@fedoraproject.org mailto:rdieter@fedoraproject.org> wrote:
I'm not sure if that's such a good assumption. For example, We stick
to
32bit at work since some of the special purpose hardware we use don't have drivers for 64bit.
So, to use KDE 4.10 & qt 4.8.x on el6 32bit, do I need to build all
rpms
myself to avoid this atom business? The problem is it affects every
qt
based compilation on the machine!
The entire distribution is built using these same flags. Sounds like
you'd rather be using gentoo?
Is that about Fedora or even RHEL?
Both. RHEL is derived from fedora, and fedora (generally) builds the
entire distribution with a standard set of optimization flags, which is what we are discussing here (apparently?).
Hmm.. then there's no escape I guess. I was surprised since I hadn't seen this when building things on RHEL5.
Syam
-- rex _______________________________________________ kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Syam wrote:
Hmm.. then there's no escape I guess. I was surprised since I hadn't seen this when building things on RHEL5.
This changed between RHEL 5 and 6. (It changed in Fedora 12. https://fedoraproject.org/wiki/Features/F12X86Support RHEL 6 is based on Fedora 12. RHEL 5 was based on Fedora 6.)
Kevin Kofler
Am 28.06.2013 03:59, schrieb Syam:
Both. RHEL is derived from fedora, and fedora (generally) builds the entire distribution with a standard set of
optimization flags, which is what we are discussing here (apparently?).
Hmm.. then there's no escape I guess. I was surprised since I hadn't seen this when building things on RHEL5.
RHEL5 is quite old and has fewer CPU optimization to sopport older hardware, i am even not sure if they still had i686 or stucked at i386/i586
Syam wrote:
Anyway, I'm no big fan of self-compilation. So gentoo wouldn't be my choice :-)
Mine neither, but Rex's point was that the only way for you to control the exact flags used to compile your binaries is to compile them yourself. But I don't think it's worth it, you waste so much CPU time on compiling that it destroys any performance benefits from the CPU-specific optimization.
Kevin Kofler
Am 27.06.2013 21:10, schrieb Syam:
On Thursday, June 27, 2013, Kevin Kofler <kevin.kofler@chello.at mailto:kevin.kofler@chello.at> wrote:
Syam Krishnan wrote:
What exactly does this mean? As far as I know, the VM shouldn't have anything to do with Atom processor.
We build i686 packages with -mtune=atom based on the principle that all the non-Atom CPUs these days should be 64-bit and thus use the x86_64 version.
I'm not sure if that's such a good assumption. For example, We stick to 32bit at work since some of the special purpose hardware we use don't have drivers for 64bit
in that case the atom-optimized binaries are working if your machine is not 10 years old
-
Kevin Kofler -
Reindl Harald -
Rex Dieter -
Rex Dieter -
Syam Krishnan