If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
P4C800E-Dlx & Hyperthreading & Quake 3 ???
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. |
#2
|
|||
|
|||
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. 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 .. 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 ! |
#3
|
|||
|
|||
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. -- DaveW "Noozer" wrote in message news:j7EAc.803254$Ig.13431@pd7tw2no... 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. |
#4
|
|||
|
|||
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/tr...rthreading.php I have yet to find one of my old software incompatible with HT technology. But it seems that there a 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/technolog...read/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 ? DaveW wrote in message 6PKAc.74962$Sw.39539@attbi_s51... 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. -- DaveW "Noozer" wrote in message news:j7EAc.803254$Ig.13431@pd7tw2no... 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. |
#5
|
|||
|
|||
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 "James Bald" wrote in message ... 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/tr...rthreading.php I have yet to find one of my old software incompatible with HT technology. But it seems that there a 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/technolog...read/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 ? DaveW wrote in message 6PKAc.74962$Sw.39539@attbi_s51... 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. -- DaveW "Noozer" wrote in message news:j7EAc.803254$Ig.13431@pd7tw2no... 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. |
#6
|
|||
|
|||
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) 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 |
#7
|
|||
|
|||
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 "James Bald" wrote in message ... 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) 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 |
#8
|
|||
|
|||
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/..._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 (Forgive me if I SNIP previous levels) |
#9
|
|||
|
|||
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 "James Bald" wrote in message news 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/..._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 (Forgive me if I SNIP previous levels) |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
questions about AMD 64 3200+, FSB and hyperthreading | Nikko | General | 7 | August 5th 04 02:34 AM |
PP-DLW Dual Xeon 2.8 Unable to Disable Hyperthreading? | 2boxers | Asus Motherboards | 2 | April 30th 04 01:00 PM |
Valid Points 101: 2x P4 Xeons + Hyperthreading + Windows XP Professional / W2K / NT4 / *Nix (long post!) | Duncan, Eric A. | General | 7 | February 3rd 04 05:06 PM |
P4C800E Deluxe and Hyperthreading | LJ | Asus Motherboards | 0 | December 1st 03 09:35 PM |
MSI 865PE and Hyperthreading P4 | J | Homebuilt PC's | 1 | August 11th 03 11:48 PM |