# Which CPUTYPE for AMD X2?



## Weaseal (Feb 14, 2009)

The CPU is fulled dubbed _AMD Athlon 64 X2 5600 Brisbane_.  More info:
	
	



```
$ 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.


----------



## danger@ (Feb 14, 2009)

athlon64 is probably the most suitable...


----------



## nickolas (Feb 14, 2009)

I have the same CPU, and I'm using CPUTYPE=athlon64.


----------



## jemate18 (Feb 17, 2009)

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


----------



## Weaseal (Feb 17, 2009)

```
$ 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
```


```
$ 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.


----------



## blah (Feb 17, 2009)

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
	
	



```
> 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.


----------



## ale (Feb 17, 2009)

core2 will be translated into prescott (i386) or nocona (amd64)
Try looking in /usr/share/mk/bsd.cpu.mk


----------



## jemate18 (Feb 17, 2009)

> 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



so using 

CPUTYPE: native

will be fine for the most part?

Will it be the best value?


----------



## keithandr1 (May 23, 2016)

hw.model: AMD Phenom(tm) II X4 820 Processor

would athlon-4 be the correct choice?


----------



## SirDice (May 23, 2016)

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.


----------



## Chris_H (May 24, 2016)

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


----------



## kpa (May 24, 2016)

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


```
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).


----------



## Chris_H (May 24, 2016)

Then it's settled; `CPUTYPE` is purely cosmetic.

--Chris

Sorry. I couldn't resist.


----------

