P4C800E-Dlx & Hyperthreading & Quake 3 ???

  • Thread starter Thread starter Noozer
  • Start date Start date
N

Noozer

Just wondering...

Using a P4C800E-Dlx mainboard with a 2.8Ghz CPU with Hyperthreading...
Should Quake 3 be able to run in SMP mode (multi-processor mode)?

Would there be an performance increase? How about other programs?

Just wondering. Video is an ATI 9600XT if it matters.
 
Noozer wrote in message ...
Just wondering...

Using a P4C800E-Dlx mainboard with a 2.8Ghz CPU with Hyperthreading...
Should Quake 3 be able to run in SMP mode (multi-processor mode)?

Would there be an performance increase? How about other programs?

Just wondering. Video is an ATI 9600XT if it matters.
Click to expand...
This is a cool question Noozer,
I made some research for you too:

From a french benchmark page, I see that you have to use the command r_smp 1 from the console or config,
in order to enable multithreading. Which is what makes use or HT or SMP for multiple processors.
http://www.gamesnhardware.com/tests/bp6/page3.html It's french sorry.
"Q3test, le mode SMP est activé grâce la la commande "r_smp 1" dans la console (nécéssite un redémarage du jeu)."

But his tests show a real difference. GREAT :D.. About 25%.

"I've been trying to get Quake 3 to work in SMP mode since upgrading to two processors"
http://www.ntcompatible.com/thread18843-1.html
This thread might also interest you, from talking about one guy with A3 SMP problems.

The video don't matter as much as your ATI 9600XT is a great performer, and will render it well.

Hyperthreading give a much welcomed boost, as long as your OS supports it. NT Kernels (2K/XP).
Have fun !
 
First of all, HyperThreading is NOT the same as SMP, just to clear that up.
And a lot of older programs cannot be used with HyperThreading enabled, or
you'll get freezes and crashes.
 
Specifically about Quake3, only one settings will allow HT use, and it's
unfortunately called SMP support, while it should work under HT hardware as well.

The incompatibilities issues for HT might be another VIA story...Who knows. ;)
You might be interested to check out about VIA's HT problems later.

http://www.teamits.com/connection/trends/hyperthreading.php
I have yet to find one of my old software incompatible with HT technology.

But it seems that there are:
http://www.ntcompatible.com/story15881.html
Most of the issues seem to be related to Micro$oft server softwares and
new licensing difficulties... Just use Linux Server solutions under Kernel 2.6+ ;)

Otherwise, it works and this article about Multimedia processing proves it.
http://www.osnews.com/story.php?news_id=2962

Anandtech explains Hyperthreading in details
http://www.anandtech.com/showdoc.html?i=1576

"OS support is required to enable multithreading while
application support is necessary in order to gain a
tangible performance increase out of having multiple processors
(in most cases)" -Anand.

If the Motherboard Chipset and BIOS supports it; If the OS supports it,
then the application only has to support multithreading in order to use it.

Intel's final words:
http://developer.intel.com/technology/hyperthread/index.htm
"This technology is largely invisible to the platform. In fact,
many applications are already multi-threaded and will automatically benefit
from this technology. However, multi-threaded applications
take full advantage of the increased performance that
Hyper-Threading Technology has to offer, allowing users
will see immediate performance gains when multitasking. "

What kind of older programs do you see crash DaveW ?
 
Hi,

Hyperthreading != Multithreading != SMP

SMP requires - as its name implies - Multiple Processors in a Symmetric
environment. This is where each processor is an (almost) equal peer on the
system. (One processor is the boot processor so has a dominance during
boot). Each processor has equal addressing capabilities to the entire
address space and equal access to the entire bus system. (NUMA systems are
designed to support Non-Uniform access to memory and each group of
processors may have localised memory and localised peripheral buses hence
the name - EG opteron multi processor above 4 processors.)

On an SMP system, if you run a Multi-Programming operating system then two
programs can be executing at the same time. Not timesliced, but actually
running. On an SMP system with a Multi-threading operating system then any
two threads can be scheduled for execution at the same time. AKAIK all
Multithreading systems are Multi Programming, but not all Multi Programming
systems are Multithreading (IE most variants of Unix - some may have changed
in recent years).

Windows is multithreading. A program consists of a minimum of 1 thread - the
primary thread. Most programs have only 1 thread, and when the programmer
writes ordinary code they seldom write for more than one thread. If a
programmer writes to use more than one thread then they have to be hugely
aware of what they are doing because suddenly two paths of
execution(threads) may be active simultaneously in the program so the
programmer has to be careful about access to memory that is common to both
threads. This is where the amateurs get sorted out and a lot of software
written neively for mutlthreading breaks. It is very common to write what
seems like a simple single threaded program to find that the program creates
at various points invisibly to the original programmer other threads. EG if
you use many of the common database management systems these often run with
multiple threads quite invisibly to the programmer. You can see how many
threads a process is running in Task Manager - Ctrl Alt Delete / Task
Manager, click on the Process tab and on the View menu click Select Columns
and tick the Thread Count.

HT on the other hand is a purely Intel invention. Not much to do with
Multithreading at all apart from the fact that it is possible for 2 threads
to now run on an HT processor at the same time - with large constraints
since there is no complete second processor, only a part of one. Basically,
HT is where the pipeline (the thing in the processor that extracts the next
instruction, locates and fetchs operands, checks to see if there is actually
anything to do and so on) in the Intel processor can see that two
instructions ready for execution do not share inputs and outputs so can be
executed at the same time - so a split occurs into parallel execution.

Some Pseedo code to illustrate a HT sort of friendly function:

array inData[256], outData[256]

- inData is initialised

int x, count

for x = 0 t0 count - 1

outData[x] = SomeFunction(inData[x])

next x

Where SomFunction has no side effects other than performing a function on x
and returning the result.
Notice that none of the calculations are reliant on the results of any of
the previous calculations.

HT Friendly loop part:

for x = 0 to count -1 step 4

outData[x] = SomeFunction(inData[x]) <- these can run at the same
time
outData[x + 1] = SomeFunction(inData[x + 1]) <- these can run at the
same time
outData[x + 2] = SomeFunction(inData[x + 2]) <- these can run at the
same time
outData[x + 3] = SomeFunction(inData[x + 3]) <- these can run at the
same time

next x

Here the programmer has written the code such that even a dumb compiler can
produce HT friendly code. This is called loop unwinding and is one of many
techniques. Smart optimising compilers do this kind of thing themselves.
Whatsmore, how many execution units does an AMD Athlon have? Hmmmm 3 integer
and 2 floating point? How many does Intel have? Hmmm. Oh is that why AMD
goes better at a lower clock speed?

Code can be written to facilitate HT - Intel has a library of routines
optimised for HT. The Intel opimising compiler generates code that is
strongly HT supportive. IE it can go out of its way to produce code that
supports well the HT capabilities of the processor. Having said all that at
the end of the day, unless you use the Intel compiler and or pick up on HT
friendly techniques you will only see an average performance improvement
when using HT since the chance of parallel execution is just Luck. Some
software is hand optimised for pre / non HT hardware systems. In this case
running the software on a HT system can be damaging for performance.
Personally I do not believe that a program crash will be due to HT - it is
far far more likely to be due to shoddy multithreading. I don't think Intel
would design a processor where it would chose and execution sequence that
intentionally differed from the programmers and compiler standards just to
squeek out a new mareting term.

- Tim
 
Tim wrote in message ...
Hi,

Hyperthreading != Multithreading != SMP
(SNIP)

Windows is multithreading. A program consists of a minimum of 1 thread - the
primary thread. Most programs have only 1 thread, and when the programmer
writes ordinary code they seldom write for more than one thread. If a
programmer writes to use more than one thread then they have to be hugely
aware of what they are doing because suddenly two paths of
execution(threads) may be active simultaneously in the program so the
programmer has to be careful about access to memory that is common to both
threads. This is where the amateurs get sorted out and a lot of software
written neively for mutlthreading breaks. It is very common to write what
seems like a simple single threaded program to find that the program creates
at various points invisibly to the original programmer other threads. EG if
you use many of the common database management systems these often run with
multiple threads quite invisibly to the programmer. You can see how many
threads a process is running in Task Manager - Ctrl Alt Delete / Task
Manager, click on the Process tab and on the View menu click Select Columns
and tick the Thread Count.
(SNIP)
Click to expand...
Thank you TIM for all the technical on these differences.
I learned a few things; Especially the part about the compiler creating multithreading
sections invisible to the programmer. I personally write multithreadig software preferrably,
using older compilers under Windows OS. In all my designs I always conceptualise multithreads
as potentially simultaneously running. The fact that I notice most if not all my current
'OLD' softwares to run just fine in an HT enabled environment is good sign that these
"invisible threads" have had no impact so far.
Writing Multithreaded apps that expect separate execution time isIMHO a bad design.
Data integrity must be preserved. Then if a database software developper ignore
these concepts, he's running after troubles, and HT should be scary to them.

Sharing data and I/O between threads is an important aspect that cannot be overlooked.
In vue of the excellent current software compatibility I notice here; I suspect that Micro$oft's
implementation of these "invisible threads" in libraries are well aware of a safe and sound design,
that should run also under Hyperthreading and maybe SMP.

Agreed HT is quite a limited feature, mode like parallel execution pipelines, with some
shared hardware resources. I've even read that in some cases it could even cripple the
performance of an multithread application. So far so good.

I look forward to Linux latest HT enabled compilersas well.
Here, Windows is legacy, multimedia fun, and does a great job at it.
You certainly are far more knowledgeable than I in these matters, and I thank you for
all these warnings and programming tips. I shall read more.

As for Quake3 HT support. I shall test it later with my own copy.
I have a feeling that since Quake3 is designed with SMP in mind, the worst case would
be a lost of performances; But I doubt it.

James
 
James,

There is (shouldn't be) nothing risky in what you call "invisible threads
in libraries". As soon as you use sockets, database or many other library or
DLL type functionality the original authors code comes into play. The fact
that these libraries are (or may be) written to use multiple threads is the
choice of those authors and consequently must be tested properly on SMP
systems by them. With MS supplied stuff EG Winsockets, ODBC and so on, they
all work well with seldom a bug to be found (no software is perfect).

Some common problems - particularly a while back - was device drivers that
were not tested on SMP systems. They would work find on single processors,
but not duals (I've only ever had duals). It is common to find applications
that will not run on SMP systems because of the types of problems I refer
to. In these cases there is nothing for it than to highlight the fact that
you are running on an SMP system and submit bug reports with evidence and
steps to recreate to the authors.

You say "Writing Multithreaded apps that expect separate execution time
isIMHO a bad design". If you are going to write multithreaded apps then how
you deal with synchronising access to shared data depends in part on the
language you use. Many languages impose a single streaming approach
invisibly on you so you are not going to get benefit from multi threading
(EG VB6 and prior). If you are going to do this then you will need to be
fluent in the appropriate use of things such as Mutexes, Semaphores, and
Events to facilitate the sharing and coordination of data. If you are
interested I suggest you go to http://msdn.microsoft.com and have a read up
there.


- Tim
 
My preferences go back as far as early Kernighan & ritchie C,
around 1982. Won't talk about BASICA here.
C++ is my current language of choice giving me all the controls and performance
I need. After MSVC++5, my next upgrade became Linux, now GCC 3.3.2
which supports all that I require in 2004.
http://www.2cpu.com/articles/41_2.html ..HT might not come as a huge benefit,
ulness the app is tuned for it. Most probably Intel's compiler would be the
wisest choice. (From the article above, I expect gains similar to those of the
Prescott)
http://www.intel.com/technology/itj/2002/volume06issue01/art04_fortrancompiler/p08_perf_eval.htm

And I do have lots of experience writing code with semaphores ext.
My target used to be embedded high speed SONET systems, nothing to
do with Microsoft server, database or visual basic. I wrote plenty, even an OSI stack.

Microsoft people and forums are just filled with great minds and good spirit.
I shall visit them eventually again...For now I go with the summer flow and upgrade.

Just a thought:..
Looking at the level of integration on these motherboards and recent ATI cards;
One thought comes to mind "INHUMAN". No mind can conceive that; It's now
machines that build machines. Even recent CISC architecture feels creepy to me.
Where have I been indeed.

You've been of a great help Tim. I guess I'm just a veteran getting ready to
get his hands dirty in this new technology... Too much eagerness.
Yet Intel's HT is not my destination but a massive RISC cluster "I have a dream". ;)
B
Tim wrote in message ...
James,

There is (shouldn't be) nothing risky in what you call "invisible threads
in libraries". As soon as you use sockets, database or many other library or
DLL type functionality the original authors code comes into play. The fact
that these libraries are (or may be) written to use multiple threads is the
choice of those authors and consequently must be tested properly on SMP
systems by them. With MS supplied stuff EG Winsockets, ODBC and so on, they
all work well with seldom a bug to be found (no software is perfect).

Some common problems - particularly a while back - was device drivers that
were not tested on SMP systems. They would work find on single processors,
but not duals (I've only ever had duals). It is common to find applications
that will not run on SMP systems because of the types of problems I refer
to. In these cases there is nothing for it than to highlight the fact that
you are running on an SMP system and submit bug reports with evidence and
steps to recreate to the authors.

You say "Writing Multithreaded apps that expect separate execution time
isIMHO a bad design". If you are going to write multithreaded apps then how
you deal with synchronising access to shared data depends in part on the
language you use. Many languages impose a single streaming approach
invisibly on you so you are not going to get benefit from multi threading
(EG VB6 and prior). If you are going to do this then you will need to be
fluent in the appropriate use of things such as Mutexes, Semaphores, and
Events to facilitate the sharing and coordination of data. If you are
interested I suggest you go to http://msdn.microsoft.com and have a read up
there.


- Tim
Click to expand...

(Forgive me if I SNIP previous levels)
 
I think the only way you would get great benefit out of prescott is if you
take the same approach Intel expects of itanium - hand crafted optimisation
to bring the best out of the instruction set and architecture along with the
cache size. IE who benefits from a large cache unless you have code designed
for it.

The trouble with HT and already highly optimised code is I think that the
optimised code is written with consideration to the current architecture and
maximising the cache benefits for the intended order of execution. HT comes
along and alters this sometimes so causes the cache to get shuffled around.

Oh and don't talk about C or K & R. That was an infliction on society best
forgotten. C++ is the only language (for the moment). I remember the days of
people trying to teach C and everyone would be fine with pointers - for a
while, then collapse into an great state of confusion. Not a pretty sight. I
never was good at C until C++.

- Tim
 
Back
Top