--WIW0mBdZQbss59/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 19, 2005 at 12:17:39AM -0500, Thor Lancelot Simon wrote:
> For *some* workloads, notably certain application-level
> floating-point-intensive workloads, even when there's already an out of
> order execution engine working on the same problems, hyperthreading can
> be a small win.

Nevertheless, the approach has promise, even if the present chips and
implementations don't show it.  For example, it may be that in some
future rev of the chip, there's room for an extra floating point and a
couple of integer units, or something. These go into the common pool
of execution resources. Where it might normally be very hard to make
use of them from a single instruction stream, it might be easier from
two. =20

It's a cheaper compromise than duplicating the whole rest of the cpu
for a true multi-core die, and possibly more effective if some of the
duplicated resources then sit idle again.

> But for most workloads, it is not.=20

It seems pretty borderline, either way, at least until you get to
multi-xeon machines where you start tripping over scheduler
deficiencies.

My entirely unscientific observation is that it seems to help most
when part of the workload involves reasonable levels of I/O; it seems
that interrupts can be serviced by one 'cpu' while computationally
intensive work can continue in the other.

--
Dan.
--WIW0mBdZQbss59/X
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)

iD8DBQFB7fV3EAVxvV4N66cRAu2eAKDMShUB37EH4aUEvHw3yuG79wZYIACfRAcl
AfSvju8jMPBd1v43uiCPzZw=
=6cUR
-----END PGP SIGNATURE-----

--WIW0mBdZQbss59/X--