On Sun, 21 Sep 2003, Simon Burge wrote:

> On Thu, Sep 18, 2003 at 03:24:31AM -0500, Peter Seebach wrote:
>
> > I know that, on some systems, a P4 with hyperthreading looks like two
> > processors.  Should this be working on NetBSD-current?  Is it useful?
> > I know it works in BSD/OS, and I also hear that the net performance gain
> > is typically negative.  :)
>
> Here's some tests I ran on a dual 2.8GHz Xeon around the end of June,
> using "./build.sh release":
>
> 	1 CPU     3867.442u  738.180s 1:20:32.44  95.3%
> 	1 CPU -j2 4056.016u  858.126s 1:19:57.97 102.4%
> 	2 CPU     3961.342u 1020.396s 1:24:59.30  97.6%
> 	2 CPU -j2 4245.934u 1283.933s   56:41.13 162.5%
> 	2 CPU -j4 4451.800u 1451.676s   54:28.01 180.6%
> 	4 CPU     4734.427u 1481.303s 1:26:14.59 120.1%
> 	4 CPU -j2 5125.070u 1750.326s 1:01:33.84 186.1%
> 	4 CPU -j2 5156.206u 1741.361s 1:02:17.22 184.5%
> 	4 CPU -j4 7638.933u 3006.625s   54:48.12 323.7%
> 	4 CPU -j8 8346.961u 3559.969s   54:53.70 361.5%
>
> "1 CPU" was a UP kernel, "2 CPU" was with HT disabled in the BIOS,
> and "4 CPU" was HT enabled.  All of these tests were run by rebooting
> and running the test immediately after the box came up.  Repeating a
> build.sh straight after a run had finished had no noticable impact on
> the benchmark time.  It's interesting to note the differences in user
> and system time when the wall-clock time remains similar in the sub-1
> hour cases.

What is the memory configuration, single or dual channel DDR? In a
preliminary benchmark, I got about 10% better performace with
dual-channel, duing a ./build.sh tools. (The second stick now
fails a memory test, more results after it's replaced)

> Right now that box is running with HT disabled, since I figured the
> "extra" CPUs weren't worth it.

Hmm, looking at the elapsed time column, maybe you should sell the
second CPU and re-enable hyperthreading ;-)

-- 
    - aew