Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Laptop (http://www.linux-archive.org/debian-laptop/)
-   -   new laptop: compiling source for i7 CPUs??? (http://www.linux-archive.org/debian-laptop/713593-new-laptop-compiling-source-i7-cpus.html)

ken 10-27-2013 08:57 PM

new laptop: compiling source for i7 CPUs???
 
One laptop I'm looking at buying offers these CPU options:

* 4 Generation Intel® Core™ i7-4700MQ Processor ( 2.4 GHz 6MB L3 Cache -
4 Cores plus Hyperthreading )


* 4th Generation Intel® Core™ i7-4800MQ Processor ( 2.7 GHz 6MB L3 Cache
- 4 Cores plus Hyperthreading )


* 4th Generation Intel® Core™ i7-4900MQ Processor ( 2.8 GHz 8MB L3 Cache
- 4 Cores plus Hyperthreading )


There are considerable price increases with each quite small increase in
speed-- hundreds of dollars--, but over two or three years I think the
extra dollars would be worth the performance increase... *IF* there is a
noticeable performance increase.


This would depend to a large degree upon the code... specifically, if
the code (OS and apps) makes use of the expanded instruction sets of the
more expensive CPUs. Generally the code doesn't, unless gcc/make is
configured for the particular CPU and then that source is compiled.
I've done this in the (distant) past and noticed a significant increase
in performance over the stock executables provided by the distro.


Though I'm currently not using debian, it's what I'm planning to use.
From the web I find that the latest stable wheezy has gcc 4.6, but the
manual for that version doesn't seem to offer many option for core i7
cpus, let alone options which distinguish the three CPUs above.


http://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
says "mtune" can be set to one of these:


corei7
Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3,
SSSE3, SSE4.1 and SSE4.2 instruction set support.

corei7-avx
Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3,
SSSE3, SSE4.1, SSE4.2, AVX, AES and PCLMUL instruction set support.

core-avx-i
Intel Core CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
SSE4.1, SSE4.2, AVX, AES, PCLMUL, FSGSBASE, RDRND and F16C instruction
set support.


Does 'cpuinfo' tell us about all of these when they're present, or are
we supposed to find out some other way?


These three options wouldn't seem to come close to specifying all the
various core i7 CPUs there are and optimizing for all the features of
each. Getting *some* of the additional instructions offered by i7s
would certainly help performance over what the standard distro offers,
but probably still not enough to warrant the extra expense of the
higher-end CPUs.


http://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
also offers:


native
This selects the CPU to tune for at compilation time by determining
the processor type of the compiling machine. Using -mtune=native will
produce code optimized for the local machine under the constraints of
the selected instruction set. Using -march=native will enable all
instruction subsets supported by the local machine (hence the result
might not run on different machines).


but, again, does it make a distinction between the three CPUs cited at
top (and yet others)? If the code produced for all three CPUs is the
identical, then there isn't much point in spending for the costlier CPUs.


And does using "native" give better or worse results than specifying one
of the core* options?


Also, when compiling a kernel to run on a VM, should some other gcc
option(s) be used?



At this point I'd just be making wild guesses about how all this
actually works out. So does anyone have experience with, or maybe some
inside knowledge about, any of this?


If so, thanks for any light you can shed.


--
To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 526D8C30.6050809@mousecar.com">http://lists.debian.org/526D8C30.6050809@mousecar.com

ken 11-01-2013 07:56 PM

new laptop: compiling source for i7 CPUs???
 
On 10/27/2013 05:57 PM ken wrote:

One laptop I'm looking at buying offers these CPU options:

* 4 Generation Intel® Core™ i7-4700MQ Processor ( 2.4 GHz 6MB L3 Cache -
4 Cores plus Hyperthreading )

* 4th Generation Intel® Core™ i7-4800MQ Processor ( 2.7 GHz 6MB L3 Cache
- 4 Cores plus Hyperthreading )

* 4th Generation Intel® Core™ i7-4900MQ Processor ( 2.8 GHz 8MB L3 Cache
- 4 Cores plus Hyperthreading )



<http://ark.intel.com/compare/75131,75128,75117> shows a side-by-side
comparison of the CPUs above. There are differences between the first
two. Some of these (as described by Intel) are:


* Intel® vPro™ Technology: a set of security and manageability
capabilities built into the processor aimed at addressing four critical
areas of IT security: 1) Threat management, including protection from
rootkits, viruses, and malware 2) Identity and web site access point
protection 3) Confidential personal and business data protection 4)
Remote and local monitoring, remediation, and repair of PCs and
workstations.


* Intel® Virtualization Technology for Directed I/O (VT-d): continues
from the existing support for IA-32 (VT-x) and Itanium® processor (VT-i)
virtualization adding new support for I/O-device virtualization. Intel
VT-d can help end users improve security and reliability of the systems
and also improve performance of I/O devices in virtualized environments.


* Intel® Transactional Synchronization Extensions New Instructions
(Intel® TSX-NI): a set of instructions focused on multi-threaded
performance scaling. This technology helps make parallel operations
more efficient via improved control of locks in software.


* Intel® Trusted Execution Technology for safer computing: a versatile
set of hardware extensions to Intel® processors and chipsets that
enhance the digital office platform with security capabilities such as
measured launch and protected execution. It enables an environment where
applications can run within their own space, protected from all other
software on the system.


These aren't the only additional instruction sets on these chips, but,
as said, just those which are offered on the two higher models and not
on the first-listed. There are quite a few other feature sets listed.




There are considerable price increases with each quite small increase in
speed-- hundreds of dollars--, but over two or three years I think the
extra dollars would be worth the performance increase... *IF* there is a
noticeable performance increase.

This would depend to a large degree upon the code... specifically, if
the code (OS and apps) makes use of the expanded instruction sets of the
more expensive CPUs. Generally the code doesn't, unless gcc/make is
configured for the particular CPU and then that source is compiled. I've
done this in the (distant) past and noticed a significant increase in
performance over the stock executables provided by the distro.


http://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
says "mtune" can be set to one of these:

corei7
Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3,
SSSE3, SSE4.1 and SSE4.2 instruction set support.
corei7-avx
Intel Core i7 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3,
SSSE3, SSE4.1, SSE4.2, AVX, AES and PCLMUL instruction set support.
core-avx-i
Intel Core CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
SSE4.1, SSE4.2, AVX, AES, PCLMUL, FSGSBASE, RDRND and F16C instruction
set support.

Does 'cpuinfo' tell us about all of these when they're present, or are
we supposed to find out some other way?

These three options wouldn't seem to come close to specifying all the
various core i7 CPUs there are and optimizing for all the features of
each. Getting *some* of the additional instructions offered by i7s
would certainly help performance over what the standard distro offers,
but probably still not enough to warrant the extra expense of the
higher-end CPUs.

http://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
also offers:

native
This selects the CPU to tune for at compilation time by determining
the processor type of the compiling machine. Using -mtune=native will
produce code optimized for the local machine under the constraints of
the selected instruction set. Using -march=native will enable all
instruction subsets supported by the local machine (hence the result
might not run on different machines).

but, again, does it make a distinction between the three CPUs cited at
top (and yet others)? If the code produced for all three CPUs is the
identical, then there isn't much point in spending for the costlier CPUs.

And does using "native" give better or worse results than specifying one
of the core* options?

Also, when compiling a kernel to run on a VM, should some other gcc
option(s) be used?


At this point I'd just be making wild guesses about how all this
actually works out. So does anyone have experience with, or maybe some
inside knowledge about, any of this?

If so, thanks for any light you can shed.





--
To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 5274157A.6070301@mousecar.com">http://lists.debian.org/5274157A.6070301@mousecar.com

ken 11-11-2013 12:12 PM

new laptop: compiling source for i7 CPUs???
 
On 11/10/2013 03:02 PM Stefan Monnier wrote:

There are considerable price increases with each quite small increase in
speed-- hundreds of dollars--, but over two or three years I think the extra
dollars would be worth the performance increase... *IF* there
is a noticeable performance increase.


The rule of thumb, in general is that a speed increase smaller than
about 30% goes unnoticed.


Stefan, thanks for your reply.

That 30% sounds about right, but then too I suppose it would also depend
upon how closely the speed is being examined and how perceptually
prominent the executable is and other factors.






This would depend to a large degree upon the code... specifically, if the
code (OS and apps) makes use of the expanded instruction sets of the more
expensive CPUs. Generally the code doesn't, unless gcc/make is configured
for the particular CPU and then that source is compiled. I've done this in
the (distant) past and noticed a significant increase in performance over
the stock executables provided by the distro.


Over time, the "baseline" used by the distros evolves, so by the time
your machine is old, most of its features will be used by the distro.


This is why I'm not interested in the "baseline" used by distros, but
rather in compiling from sources and tailoring compilation to a specific
CPU. This brings up the next issue: how difficult is it in debian to
configure the upgrade process so that it is the sources which are
automatically downloaded and (also automatically) compiled?





But don't forget that most of those new features only affect very
specific programs. Some of them may not even affect any program at all
(e.g. because later improvements in compiler techniques work better than
those hardware assists). IOW it's largely marketing.


True, there is a terrible amount of marketing hype thrown at us with
everything that comes to market, with computers especially. I try to
temper my cynicism though in thinking that the designers and engineers
can and actually intend to produce a better product. The corporation as
a whole should be fully behind them in this endeavor, otherwise
competitors will be eating their lunch. Though my studies never brought
me close to taking a role as such an engineer, I did learn that if
you're going to take the trouble to bring out a new design, the
improvements should be those which bring about the greatest effect,
e.g., those instructions which are most often used. These would be for
naught, however, if the end-user and all players in between don't make
use of the such improvements. E.g., getting a 64-bit system is a
questionable decision if you're going to run nothing but 32-bit software
on it. On the other hand, if you're going to run VMs, then a CPU with
instructions enhanced for that makes sense if you'll be compiling the
code to take advantage of those instructions, and this also assuming
that the compiler is capable of creating such executables.


So there are a lot of factors at play, making it hard for me to
generalize. I've found too that the relevant specifics are really
difficult to dig out, at least in the places I've been digging.



Thanks again for your reply.






Stefan





--
To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 5280D7D9.9050104@mousecar.com">http://lists.debian.org/5280D7D9.9050104@mousecar.com


All times are GMT. The time now is 05:30 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.