Alright kids, it's quiz time. By looking at the picture to the right, please tell me how many processors I recently purchased? In the past, this was a really simple question to answer, why two of course! Since Intel rolled out hyper-threading, a simple glimpse at Task Manager just isn't enough to tell you what someone has under the hood of their precious boxen.

We did take a brief look at hyper-threading performance quite awhile ago with two sets of Xeons (2.0 and 2.4 GHz), but due to time constraints I didn't really have a lot of time to talk about the technical aspects of hyper-threading and I was only able to run a few Windows benchmarks. Even with these limitations, the article actually did quite well. It was mentioned in an Arstechnica piece and continues to be read to this day. However, in an effort to improve upon past work and to further educate readers on the benefits of hyperthreading while continuing to advocate for symmetric multi-processing, we'll forge ahead.

I'm not going to sit here and try to regurgitate technical documentation and I certainly don't put myself in the class of Hannibal (who I'm pretty sure is an engineer) but I'll try to run through the scenarios in which hyper-threading will increase performance and hinder it.

The reason I decided to split this into two separate articles was really centered around timing. Intel was kind enough to supply us with the processors used in testing (2.8GHz Xeons and a 3.2GHz P4C) and I wanted to get some content posted by the end of the year. Also, my intention is to look at hyper-threading performance in Linux, and I haven't completely sorted out the details of the tests I'd like to run. Ideally, I'd like to look at Apache/PHP/MySQL performance as there are a lot of 1U web servers out there being powered by Pentium 4 processors.

So, in Part I, we'll talk about architecture and look at hyper-threading's impact on the following benchmarks: