Which CPUTYPE for AMD X2?

W

Weaseal

The CPU is fulled dubbed AMD Athlon 64 X2 5600 Brisbane. More info:
Code: 
$ sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
hw.machine: amd64
hw.model: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
hw.ncpu: 2
hw.machine_arch: amd64
Trying to determine the best CPUTYPE for make.conf. Right now it's set to athlon64. That seems to be stable but I'm wondering if there's a more specifically optimized target.
 
What are the possible values for CPUTYPE for a give CPU?

CPU: AMD ATHLON 64 X2 Dual Core
CPUTYPE: athlon64

CPU: Intel Pentium 4
CPUTYPE: ?

CPU: Intel Core 2
CPUTYPE: ?

CPU: AMD Phenom X4
CPUTYPE: ?

please list other possible values and CPU type..

Thanks again
 
Code: 
$ cat /usr/share/examples/etc/make.conf | grep -i pentium
#       (Intel CPUs)    core2 core nocona pentium4m pentium4 prescott
#                       pentium3m pentium3 pentium-m pentium2
#                       pentiumpro pentium-mmx pentium i486 i386
Code: 
$ cat /usr/share/examples/etc/make.conf | egrep -i 'k8|amd'
#       (AMD CPUs)      opteron athlon64 athlon-mp athlon-xp athlon-4
#                       athlon-tbird athlon k8 k6-3 k6-2 k6 k5
I find the AMD names to be a little more vague, but the Intel ones are fairly straightforward.
 
Since branch 7-stable uses gcc4 I tend to extract CPUTYPE from the compiler or just use native as a value. I remember seeing smth like this on lists
Code: 
> cc -march=native -E -v - </dev/null |& fgrep cc1
 /usr/libexec/cc1 -E -quiet -v -D_LONGLONG - -march=nocona -mtune=generic
> gcc44 -march=native -E -v - </dev/null |& fgrep cc1
 /usr/local/libexec/gcc/x86_64-portbld-freebsd8.0/4.4.0/cc1 -E -quiet -v - -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=core2
I don't know who placed core2 in examples/etc/make.conf but obviously it's bogus. There is no such thing as core2 in gcc 4.2.1 man page. And if you try to set it to core2 gcc will complain about bad value.
 
core2 will be translated into prescott (i386) or nocona (amd64)
Try looking in /usr/share/mk/bsd.cpu.mk
 
Since branch 7-stable uses gcc4 I tend to extract CPUTYPE from the compiler or just use native as a value. I remember seeing smth like this on lists
Click to expand...

so using

CPUTYPE: native

will be fine for the most part?

Will it be the best value?
 
It's best not to change whatever is picked as default. If you run into problems everyone is going to advise you to remove those settings. So, just don't set it unless you know what you are doing. If you know what you are doing you don't need to ask what to put in there.
 
I had a long debate over CPU optimization on the mailing list awhile ago. After long debate, and a good deal of factual data, and results. It was clear that the only thing in BASE, and for the most part ports(7); was openssl, and even then, it was negligible -- really. Almost all ports(7) that benefit from CPU profiling, know how to get the information they need to profile the application accordingly.
Bottom line:
there is no discernible benefit to changing CPUTYPE to better profile the code.
Spend the time you would have on that, on something that's actually productive. ;) :)

--Chris
 
Assuming this is upto date, from make.conf(5):

Code: 
CPUTYPE       (str) Controls which processor should be targeted for gen‐
                   erated code.  This controls processor-specific optimiza‐
                   tions in certain code (currently only OpenSSL) as well as
                   modifying the value of CFLAGS and COPTFLAGS to contain the
                   appropriate optimization directive to cc(1).  The automatic
                   setting of CFLAGS and COPTFLAGS may be overridden using the
                   NO_CPU_CFLAGS and NO_CPU_COPTFLAGS variables, respectively.
                   Refer to /usr/share/examples/etc/make.conf for a list of
                   recognized CPUTYPE options.

So in summary, the only thing that could even benefit from setting CPUTYPE is OpenSSL as noted above. Even then there's very little gain because you have other options for big gains in performance such as hardware accelerated AES as implemented in the aesni(4) driver for Intel CPUs that support the special instructions (and before you try suggest it, there is currently no evidence that AES-NI is compromised by backdoors).
 
You must log in or register to reply here.
Back
Top