Re: new laptop: compiling source for i7 CPUs???
On Sun, Oct 27, 2013 at 05:57:04PM -0400, 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 )
>
> 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.
>
Cost performance trade off between speed/heat/battery life ... if
you're doing some really clever stuff fthen the difference in L3
cache between the 4700MQ and 4900MQ might make a difference
- otherwise, it's probbly marketing. More important is probably
speed of laptop chipset / I/O to a disk / memory overall
Chip is quite possiby almost identical inside - but selected on
speed / usable cache size at select on test stage and screen printed
with CPU identifier accordingly.
> 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.
See above - code and instruction set likely to be identical - clock
speeds are the only differene.
>
> 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.
>
Google for the Intel chip comparison charts / Wikipedia
> 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.
>
Hope this helps, at least somewhat. I suspect the GCC options are just
supersets, one of another, including more and more extensions - AVX is
virtualisation and AES is AES support in chipset instructions. You
might almost be as well off in taking gneric settings, seeing how well they do
out of the box - only if you need to pull every last assembly trick in the book
to get increased performance, think of adding optimisations one by one.
All the best,
Andy
>
> --
> To UNSUBSCRIBE, email to debian-user-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
Reply to: