Re: [oc] Re: Merlin Hybrid System

["Jim Dempsey" <dempsey@northnet.net>]

>From Intel (http://developer.intel.com/technology/hyperthread/)

"Intel® Corporation introduced its Hyper-Threading Technology at the Fall
2001 Intel Developer Forum. Hyper-Threading Technology will enable the world
's first simultaneous multi-threaded (SMT) processor. Today's processor
exploits Instruction Level Parallelism (ILP), but mutually exclusive
hardware resources exist. However, by developing an architecture state for
two processors which share a single physical processor's resources, two
programs or threads can execute simultaneously. Thus, one physical processor
looks like two logical processors to the OS and applications."

What I am talking about is something completely different.

The technology I am talking about will use multiple processors that will
give the operating system and applications running thereon the appearance of
running on one processor. But in reality what would normaly be viewed as a
single thread running on one processor is in fact running in fragments
concurrently on multiplt processors.

More from letter written to Transmeta...

When examining Multi-Processor implementations on the dominant Intel based
systems the distribution of the work amongst processors is issued in work
units called threads.

When examining Single-Processor implementations on the dominant Intel based
systems you can view the system as n-processor where n equals 1. On a
1-processor system only 1 thread can be processing at a time and during
interrupt and other kernel mode processing no processors are available for
thread processing.

When examining a Single-Processor operating system on an n-Processor system
only 1-processor is available for both the thread and system. e.g. Windows
95 on a dual processor system.

When examining an application written for 1 thread running on an n-Processor
system at most only 1 processor can be used for this thread's processing.

When examining an application written using n-threads at most n-processors
can be used for this application (assuming there are n available). At second
best n-1 processors are available for this application's processing.

Additionally, the overhead to start and stop threads combined with an
increase in complexity of code written specifically for multi-threaded use
makes it cumbersome at best and ineffective at worst to make full use of the
processing capability available. This is known as a situation of
"diminishing returns".

In particular, when an operating system or application target system has
single processor there is no payback in writing the code for use with
multiple processors.

Software vendors have a strong disincentive to make a single-threaded
application into multi-threaded as well as to make a multi-threaded
application into one with finer thread granularity (more threads). Added to
this, the nature of current (Intel) SMP design is such that the multiple
processors are attached to a single global memory system. Although each
processor has a local cache, the main memory system I/O becomes saturated
with a relatively low number of processors (4 - 8).

The description above represents the classic "immovable object".

Problems to overcome

? Applications that are written with one thread
? Applications that are written with a very small number of threads (2-4)
? Thread context switch overhead
? Memory I/O saturation (Read/Write)
? Unwillingness to rewrite the applications to run on a new configuration
? Unwillingness to rewrite the operating system to run on a new
configuration
? Unwillingness to add compiler optimizations for multi-thread conversion

Software vendors will not convert a single threaded application to a
multi-threaded application if most of their customers are on single
processor systems.

Software vendors are not willing to rewrite applications to take advantage
of new processor technology when their install base is on old processor
configurations.

Compiler writers are not willing to write new optimizing compilers for
non-industry leading processor technology.

Operating system writers are not willing to write to a new multi-processor
design.

The above declarations become a circular argument of why things cannot
change.

The Magic Bullet

The new venture has a magic bullet that solves these problems. The magic
bullet can go through the "immovable object" and around it.

? No change in operating system software
? No change in application software
? No change in compiler design
? Reduction in memory R/W

About 25 years ago Mr. Dempsey developed a minicomputer operating system
named OMNI. About 15 years ago he was involved with a computer manufacturer
in the design of a multi-processor computer to run a multi-processor version
of this operating system. The design of this system included the invention
of an instruction set that permits a very fine-grained work unit
distribution. Overhead is so low that work units of even a few instructions
are feasible. This technology combined with my new process and your
Transmeta processor will produce a product where

? A single processor operating system (e.g. Windows 9x) will run using
multiple processors. And do so with no code change to the operating system
or applications.
? A single threaded application will run using multiple processors and do so
with no code change to the application.
? A multi-processor operating system artificially restricted to run on few
processors (i.e. NT4 Workstation) can run on many processors with no code
change to the operating system.
? An n-threaded application can efficiently utilize more than n processors.
? The shared memory Read/Write saturation of current SMP designs is reduced
thus permitting an increase in the number of attached processors.

Jim Dempsey


----- Original Message -----
From: "David Feustel" <dfeustel@mindspring.com>
To: <cores@opencores.org>
Sent: Friday, December 07, 2001 1:45 PM
Subject: Re: [oc] Re: Merlin Hybrid System


> Are the participants in this thread familiar with
> Intel's hyperthreading as implemented (but not
> yet turned on) in the P4?
>
>
>
> --
> To unsubscribe from cores mailing list please visit
http://www.opencores.org/mailinglists.shtml
>

--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml