Intel EM64T Processor Platform

[Andre Guibert de Bruet]

On Tue, 31 May 2005, David O'Brien wrote:
> On Tue, May 31, 2005 at 12:00:44AM -0400, Andre Guibert de Bruet wrote:
>> On Sun, 29 May 2005, Roland Smith wrote:
>>> On Sun, May 29, 2005 at 12:00:29AM -0800, Jack L. wrote:
>>>>
>>>> What cpu type should I use for make.conf and the kernel if I want to
>>>> use the AMD64 platform?
>>>
>>> You do not need to have anything special in make.conf, and the GENERIC
>>> kernel for amd64 contains the necessary 'machine' and 'cpu' paramaters.
>>
>> This is not entirely correct. Sure, your system will run without anything
>> special in make.conf; But if you want decent performance, you probably
>> want to set CPUTYPE to "nocona" in order to get a build that is tailored
>> to your cpu (SSE3, etc). More information on what that CPUTYPE enables is
>> available in /usr/share/mk/bsd.cpu.mk.
>
> You're saying that one doesn't get decent performance on a Nocona with
> stock GCC code generation?  While one may get noticeably better
> performance with CPUTYPE=nocona, I doubt it is a huge difference.  What
> I'm saying is, I sure one will have decent performance with a stock
> FreeBSD/amd64 install.

>From the testing that I performed on my desktop a few months back, the 
interactive performance was noticeably better under heavy IO.

I have since switched the machine back to i386 mode because of vm-related 
panics (Which in all honesty, were most probably caused by the state of 
current at the time). Having just 4GB of memory in the system, the lack of 
EM64T has not really been that big of an issue (Even though the system is 
only reporting 3.5GB).

The hardware that I ran all of this on is detailed in the following dmesg: 
http://bling.properkernel.com/freebsd/boot-v.txt

Cheers,
Andy

/*  Andre Guibert de Bruet  * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */
/*   Code poet / Sysadmin   * 636f 656b 2e79 5320 7379 6461 696d 2e6e */
/*   GSM: +1 734 846 8758   * 5520 494e 2058 6c73 7565 6874 002e 0000 */
/* WWW: siliconlandmark.com *      Tormenting bytes since 1980.       */