Hyper-threading

  • Thread starter Thread starter Illumineo
  • Start date Start date
I

Illumineo

My application uses multiple-threads and is a kind of AI simulation or
ALife. This works fine but I was wondering if and how one can make use
of hyper-threading in C#?


Thanks for any hint, Francois

____________________________
The Netron Project,
http://netron.sf.net
 
Illumineo said:
My application uses multiple-threads and is a kind of AI simulation or
ALife. This works fine but I was wondering if and how one can make use
of hyper-threading in C#?
Click to expand...

.NET threads are mapped on OS threads, so the OS will schedule these
threads and therefore if hyperthreading is enabled, the threads will
take advantage of that.

FB


--
 
Just a silly question: How do I enable hyperthreading? Is this an option in
the C# project or an option I have to set somewhere in the control panels or
is this a build in feature of the processor?

Ciao
Dante
 
hyper threading is enable by in the BIOS setting of the machine


--
HTH

Ollie Riches
http://www.phoneanalyser.net

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a programmer
helping programmers.
 
However, if it wasn't enabled when you installed windows I don't believe you
will have the correct HAL and therefore may not be able to take full
advantage of the multi CPU's. You will need to install the correct one once
you enable HT.

In Device manager you expand the Computer node, if you see multiprocessor PC
(or something that indicates more than one CPU) you are fine. However, if
you see Uniprocessor PC, you'll want to go to it's properties and update
driver. Choose the driver manually to install. You will want to use the
Multiprocessor driver that matches the uniprocessor driver you have, in my
case it is an ACPI driver. Be sure you don't select the wrong one.

In the past I did some experimenting and found I could go from Multi to Uni
in my machine, but was unable to go back to multi. Hopefully it was because
I switched from one to the other. If you can't upgrade the driver to get the
multi, you will need to reinstall windows with the HT enabled.

If all goes well you should see two CPU windows in the performance tab of
the Task Manager.

--
Thanks
Wayne Sepega
Jacksonville, Fl


"When a man sits with a pretty girl for an hour, it seems like a minute. But
let him sit on a hot stove for a minute and it's longer than any hour.
That's relativity." - Albert Einstein

Ollie Riches said:
hyper threading is enable by in the BIOS setting of the machine


--
HTH

Ollie Riches
http://www.phoneanalyser.net

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a programmer
helping programmers.


Dante said:
Just a silly question: How do I enable hyperthreading? Is this an option in
the C# project or an option I have to set somewhere in the control
Click to expand...
panels
Click to expand...
 
Thanks for the answers.

Well, then hyperthreading is just an eye catcher: As long I have a
hyperthreading CPU and an application with threats I get the Hyperthreading
technology for free, am I right?

Hyper, hyper...
 
Dante,

Beside your application there are a lot of other applications active.

You don't need to use an application with threads to have the benefit.

Cor
 
Ok, granted. I think even without my threads the application is running on
some threads.

I am just saying: If I would declare our application as hyperthreaded people
get impressed - "Wow, they are using hyperthreading technology". But in fact
we are only that HT technology because the OS is supporting it without that
I have do some tricky things to the application.
 
Ok, granted. I think even without my threads the application is running on
some threads.
Click to expand...

No it is not.

For the rest we do agree, in a lot of cases can using threading mean more
throughput time beside that it uses forever more processor time.

Cor
 
Cor Ligthert said:
No it is not.
Click to expand...

I disagree. Try running the following program and look at the number of
threads with something like prcview:

using System;
using System.Threading;

class Test
{
static void Main()
{
Thread.Sleep(50000);
}
}

On my box at least, there are three threads in the process.
 
Jon Skeet said:
I disagree. Try running the following program and look at the number of
threads with something like prcview:

using System;
using System.Threading;

class Test
{
static void Main()
{
Thread.Sleep(50000);
}
}

On my box at least, there are three threads in the process.
Click to expand...


I would claim that "the application" is running on only a
single thread in that case. The console has its own thread,
but that is an OS feature, beneath the application in a very
real sense, usually invisible except with tools. Likewise,
there is a thread associated with the CLR VM that does
garbage collection. The VM is also properly considered
part of the platform, not the application. (I realize this is
a fine distinction that hinges upon definitions.)

Of course, if you insist that those 3 threads are part of
the application which runs the console and VM as DLLs,
I won't quibble any further about it. <g>
 
Larry Brasfield said:
I would claim that "the application" is running on only a
single thread in that case. The console has its own thread,
but that is an OS feature, beneath the application in a very
real sense, usually invisible except with tools. Likewise,
there is a thread associated with the CLR VM that does
garbage collection. The VM is also properly considered
part of the platform, not the application. (I realize this is
a fine distinction that hinges upon definitions.)

Of course, if you insist that those 3 threads are part of
the application which runs the console and VM as DLLs,
I won't quibble any further about it. <g>
Click to expand...

Given the context of the question, that's exactly what I'd say. In
terms of the number of threads running within the process - threads
which can take advantage of hyperthreading for sure - there are always
multiple threads in any .NET app. I doubt very much that the scheduler
cares whether the thread is running code written by the .NET developer
or code written by MS :)

(I don't know for sure whether hyperthreading works for multiple
processes - I suspect it would be a lot simpler not to support that at
the OS level, but I'm not an expect on hyperthreading.)
 
The scheduling unit on Windows systems is the thread.
AFAIK, the Windows scheduler does not care at all which process a
thread belongs to when assigning CPU time.
Therefore, having an hyperthreaded CPU should boost the whole system
performance, not only your application's throughput.
Obviously, if your app is multi-threaded, it will gain benefit from
being executed on an HT CPU. But the same should apply when running
several single-threaded applications simultaneously.
That's the whole number of schedulable threads that counts, not only
your application's threads.

A good introduction can be found at
http://arstechnica.com/articles/paedia/cpu/hyperthreading.ars.

Claudio Brotto
 
Claudio Brotto said:
The scheduling unit on Windows systems is the thread.
AFAIK, the Windows scheduler does not care at all which process a
thread belongs to when assigning CPU time.
Click to expand...

Excellent - that's good to hear, thanks :)
 
Claudio,

In short I wrote that already to Dante, I got the idea, that he understood
from my answer that he could call his application therefore a hyperthreaded
application. And on that I answered. "No it is not".

Jon disagrees that with me, however I don't want to discuss that. When Jon
thinks that because of hyperthreading every .Net application has to be
called a hyperthreaded application, I let him free in that, than we
*disagree* and he is than right in that.

http://groups-beta.google.com/group/microsoft.public.dotnet.languages.csharp/msg/20991215cf1ffd21

Cor
 
Claudio said:
The scheduling unit on Windows systems is the thread.
AFAIK, the Windows scheduler does not care at all which process a
thread belongs to when assigning CPU time.
Therefore, having an hyperthreaded CPU should boost the whole system
performance, not only your application's throughput.
Obviously, if your app is multi-threaded, it will gain benefit from
being executed on an HT CPU. But the same should apply when running
several single-threaded applications simultaneously.
That's the whole number of schedulable threads that counts, not only
your application's threads.
Click to expand...

Keep in mind that context switching between threads takes resources and
can ruin that much CPU data internally (caches) that it can actually
SLOW down your system in some occasions. HT is more or less a trick on 1
CPU to use the time the CPU otherwise has to wait for the slow memory
connection. This only works if the 2 threads don't need excessive memory
access of course :)

FB

--
 
IMHO, the point here is this:

Claiming an application is "hyper-threaded" is wrong. An application is
not hyper-threaded: the underlying hardware and OS support may be HTed.
We, as programmers, can take advantage of such a technology, but all we
are enabled to do is develop a "multi-threaded" application, maybe
executing IO intensive code in a secondary thread to keep the UI thread
responsive, etc.
We do not write code such as

#ifdef MULTIPROCESSOR
// MP, or HT, stuff here
#else
// SP stuff here.
#endif

We can (most often we should) create and use threads no matter of the
number of processors our software will run on (be them real processors,
as in MP machines, or "virtual" processors as in HT machines).
That's quite obvious: how can we know what kind of hardware our
application will be deployed to ?

The OS is a piece of software which is there just to hide the
underlying hw idiosyncrasies and provide a coherent programming model
to the software developers.
Parts of the OS ARE different when run on SP/MP machines, just because
the OS is responsible for thread scheduling and all other issues which
change according to the # of processors we have.

I am not meaning that the code we write will run without bugs no matter
of the # of CPUs.
A lot of issues arise on MP machines which will never happen on SP
machines, especially when we try to avoid locking as much as possible
(on MP machines that is really a good choice !): then we'll have to
face any sort of strange bugs, and we must be very careful therefore.

And this just considers the OS.
What about the VM we program against (be it the CLR or the JVM or any
other VM) ?
I mean, between a call to System.Threading.Thread.Start(...) and the
real work done by the CPU there are a lot of levels of virtualization !
When writing .NET code, IMHO, we should take the CLR as out target,
understand as much as possible all its multi-threading issues (no, it's
not enough to know what the Monitor.Enter method does :-( ) and let the
VM do its work under the hood.
This is because
a) we don't see the CPU, we see the VM
b) we cannot fully control the VM behaviour
c) the VM behaviour might change in future releases

Ok, I'm done with my long post :-)
My basic opinion, just to summarize it: your code can leverage MP
thecnologies, but MP/HT are out of your code control !

Best Regards.

Claudio
 
Cor said:
Claudio,

In short I wrote that already to Dante, I got the idea, that he understood
from my answer that he could call his application therefore a hyperthreaded
application. And on that I answered. "No it is not".

Jon disagrees that with me, however I don't want to discuss that. When Jon
thinks that because of hyperthreading every .Net application has to be
called a hyperthreaded application, I let him free in that, than we
*disagree* and he is than right in that.
Click to expand...

What's there to disagree on? Windows XP supports hyperthreading,
Windows' kernel schedules threads, not processes, and every .NET app has
at least 2 threads and often 3. This means that every .NET app benefits
from hyperthreading if they fall into the category of threads which
benefit from hyperthreading (and I think they do).

There is no such thing as 'hyperthreaded application'. That's just pure
marketing bs, as every application is per definition a hyperthreaded
application as every application has at least 1 thread.

FB

--
 
What do you mean with the console has his own thread?

A managed V1.X process has a minimum of three threads:
1. The applications main thread.
2. The finalizer thread.
3. The Debugger helper thread.

1. Runs the CLR code and all of the (unmanaged) runtime libraries loaded by
the CLR and your JITted code (supposed here there are no extra threads
created directly/indirectly by your code) .
2. Runs the finalizer (executes the Finaly methods on the classes that have
registered their Finalizer) this thread Is woken by the GC. Note that the GC
run's on #1 your main thread if in pre-emptive mode and on this same thread
when in concurrent mode.
3. Is only used when debugging and profiling, but is always created when the
CLR starts the managed execution environment.

Note that during execution of managed code libraries extra threads might be
created, manual threads as well as threadpool threads, that's why I said
this 3 is a minimum.

Willy.
 
Back
Top