Difference between revisions of "Intel Core 2 Duo (Merom)"

From ThinkWiki
Jump to: navigation, search
(GCC Optimization Flags)
Line 73: Line 73:
 
These latter two values will of course depend largely on cooling systems and available airflow.
 
These latter two values will of course depend largely on cooling systems and available airflow.
  
=GCC Optimization Flags=
+
=Compiler optimisation flags=
 +
==GCC==
 
In addition to the architecture independent <code>-O[0123s]</code> option hierarchy, architecture dependent optimisations are controlled by the <code>-march=<cpu-type></code> and <code>-mtune=<cpu-type></code> options. The <cpu-type> argument (not surprisingly) describes the type of cpu for which to optimise the compiled code. The <code>-mtune</code> option will generate code that is optimised for the given cpu type which will nevertheless run on cpu types other than the optimisation target. On the other hand, <code>-march</code> will attempt to optimise more aggressively at the expense of reducing portability to other cpu types. Optimisations implied by <code>-mtune</code> are a subset of <code>-march</code> optimisations, and thus it is only necessary to specify <code>-march</code> if the the maximum level of optimisation is desired.
 
In addition to the architecture independent <code>-O[0123s]</code> option hierarchy, architecture dependent optimisations are controlled by the <code>-march=<cpu-type></code> and <code>-mtune=<cpu-type></code> options. The <cpu-type> argument (not surprisingly) describes the type of cpu for which to optimise the compiled code. The <code>-mtune</code> option will generate code that is optimised for the given cpu type which will nevertheless run on cpu types other than the optimisation target. On the other hand, <code>-march</code> will attempt to optimise more aggressively at the expense of reducing portability to other cpu types. Optimisations implied by <code>-mtune</code> are a subset of <code>-march</code> optimisations, and thus it is only necessary to specify <code>-march</code> if the the maximum level of optimisation is desired.
  
 
With version of gcc before 4.3, 32-bit code should be compiled with the "prescott" as the cpu-type argument to <code>-march</code> or <code>-mtune</code> whereas 64-bit code should use the "nocona" argument. Gcc 4.3 however introduces "core2" as a valid argument to the <code>-mtune</code> and <code>-march</code> options which should be used. Alternatively, as of gcc 4.2, the "native" argument is supported. This will automatically determine the cpu-type on which compilation is taking place and apply optimisations specific to that cpu.
 
With version of gcc before 4.3, 32-bit code should be compiled with the "prescott" as the cpu-type argument to <code>-march</code> or <code>-mtune</code> whereas 64-bit code should use the "nocona" argument. Gcc 4.3 however introduces "core2" as a valid argument to the <code>-mtune</code> and <code>-march</code> options which should be used. Alternatively, as of gcc 4.2, the "native" argument is supported. This will automatically determine the cpu-type on which compilation is taking place and apply optimisations specific to that cpu.
  
=Intel Compiler Optimization Flags=
+
==Intel==
 
For the [http://www.spec.org/cpu2006/ SPEC CPU 2006 benchmarks], Intel used the shorthand <code>-fast</code>, which translates into <code>-O3 -ipo -static -no-prec-div -xP</code>. However, the compiler also provides the flag <code>-xT</code>, which activates the optimization for Core 2 Duo and SSSE3 (instead of SSE3 only with <code>-xP</code>).
 
For the [http://www.spec.org/cpu2006/ SPEC CPU 2006 benchmarks], Intel used the shorthand <code>-fast</code>, which translates into <code>-O3 -ipo -static -no-prec-div -xP</code>. However, the compiler also provides the flag <code>-xT</code>, which activates the optimization for Core 2 Duo and SSSE3 (instead of SSE3 only with <code>-xP</code>).
  

Revision as of 07:38, 23 March 2008

The Intel 2 Core is the successor of the Intel Core Duo (Yonah) processor. Unlike the Yonah, the Merom was designed specifically with mobile applications in mind. The Merom introduced various architectural additions such as EM64T, SSSE3 and improved the performance by up to 25 percent. The 667 MHz FSB versions are part of the "Napa" platform, while the 800MHz FSB versions are part of the "Santa Rosa" platform. The chip is also part of the hardware from both the Centrino Duo and Centrino Pro brands.

Features

Available Types and ThinkPads featuring them

Standard Voltage

Nr. Frequency (MHz) L2 Cache FSB (MHz) VT core Voltage (V) TDP (W) ThinkPad Models
max. min. high low high freq low freq
T7800 2600 1000 4MB 800 yes 1.30 ? 35 ? T61p
T7700 2400 1000 4MB 800 yes 1.30 ? 35 ? R61, T61, T61p
T7600 2333 1000 4MB 667 yes 1.30 0.95 34 20 T60, T60p
T7500 2200 1000 4MB 800 yes 1.30 ? 35 ? R61, T61, X61
T7400 2166 1000 4MB 667 yes 1.30 0.95 34 20 T60, Z61t
T7300 2000 1000 4MB 800 yes 1.30 0.95 35 ? R61, T61, X61
T7200 2000 1000 4MB 667 yes 1.30 0.95 34 20 R60, T60, X60, Z61m, Z61t
T7100 1800 1000 2MB 800 yes ? ? 35 ? R61, T61
T5600 1833 1000 2MB 667 yes 1.30 0.95 34 20 R60, T60, X60, Z61t
T5500 1666 1000 2MB 667 no 1.30 0.95 34 20 R60, T60, X60, Z61m, Z61t

Low Voltage

Nr. Frequency (MHz) L2 Cache FSB (MHz) VT core Voltage (V) TDP (W) ThinkPad Models
max. min. high low high freq low freq
L7400 1500 1000 4MB 667 yes 1.2 0.9 17 ? X60s, X60 Tablet
L7500 1600 800 4MB 800 yes 1.1 0.9 17 ? X61s, X61 Tablet
L7700 1800 800 4MB 800 yes 1.1 0.9 17 ? X61s, X61 Tablet

Thermal Specifications

The maximum temperature for safe operation is 100°C.

The catastrophic thermal protection temperature is 125°C.

Idle temperature is typically around 30-50°C.

Temperature at full utilisation is around 60-70°C.

These latter two values will of course depend largely on cooling systems and available airflow.

Compiler optimisation flags

GCC

In addition to the architecture independent -O[0123s] option hierarchy, architecture dependent optimisations are controlled by the -march=<cpu-type> and -mtune=<cpu-type> options. The <cpu-type> argument (not surprisingly) describes the type of cpu for which to optimise the compiled code. The -mtune option will generate code that is optimised for the given cpu type which will nevertheless run on cpu types other than the optimisation target. On the other hand, -march will attempt to optimise more aggressively at the expense of reducing portability to other cpu types. Optimisations implied by -mtune are a subset of -march optimisations, and thus it is only necessary to specify -march if the the maximum level of optimisation is desired.

With version of gcc before 4.3, 32-bit code should be compiled with the "prescott" as the cpu-type argument to -march or -mtune whereas 64-bit code should use the "nocona" argument. Gcc 4.3 however introduces "core2" as a valid argument to the -mtune and -march options which should be used. Alternatively, as of gcc 4.2, the "native" argument is supported. This will automatically determine the cpu-type on which compilation is taking place and apply optimisations specific to that cpu.

Intel

For the SPEC CPU 2006 benchmarks, Intel used the shorthand -fast, which translates into -O3 -ipo -static -no-prec-div -xP. However, the compiler also provides the flag -xT, which activates the optimization for Core 2 Duo and SSSE3 (instead of SSE3 only with -xP).

Microcode

Much like software products, bugs, errata or ways to improve upon operation are often found in CPU's after they have reached the market. In some cases, the necessary changes can be applied by the end user without any change to the underlying hardware in the form of microcode updates downloadable from the manufacturer. Intel offers these microcode updates for download on their website.

Provided the availability of the microcode and firmware kernel modules (which are enabled in the stock kernels of most distributions) and a suitable user space tool such as microcode_ctl, one can install the updated microcode into their processors at runtime. The microcode update is volatile however, meaning that it disappears upon reboot. While this reduces the risk of applying such an update to essentially 0, it does mean that it must be applied on each boot.

Debian

You can install the microcode.ctl package which will take care of everything (including downloading the microcode itself) for you. Just run # aptitude install microcode.ctl. This package includes an init script which will run at boot to load the microcode into the processor. This script also contains a line which will remove the microcode kernel module once the operation is complete and it is no longer needed, however it is strangely commented out by default. If you want to keep your loaded modules (used memory) to a minimum, you can edit /etc/init.d/microcode.ctl and uncomment the line

[ -x /sbin/modprobe ] && /sbin/modprobe -r microcode > /dev/null 2> /dev/null

Note on Hyper-Threading

Note that as opposed to Pentium 4/NetBurst, current Core 2 do not support hyper-threading, and therefore there is usually no option in the BIOS to activate it. Refer to Intel's Hyper-Threading Technology for a list of hyper-threading capable CPU.

See also

Intel Core Solo (Yonah)

Intel Core Duo (Yonah)

External Links