HyperThreading: HyperProblem!

[CyberGenX 0]

Running a P4 3.06C with an Intel 865GRH Motherboard, 1GB DDR400MHz in dual channel mode and hyperthreading enabled. I notice when I try to capture video from WinDVR, UleadDVD Workshop, Movie Maker or Premiere Pro the app hangs almost immediately. I can edit video and everything else works fine on the computer, just can't capture video. I have even tried 3 different video capture drivers. I am using an MSI TV@Anywhere capture card.

 

Here is the kicker: I disable hyperthreading and I can capture just fine in any of the apps.

 

So is hyperthreading all it's crapped up to be? I have noticed a difference in Premiere Pro but not really anything else. Should I just leave it disabled? Or has anyone heard of better performance in the video realm with it disabled?

 

I have heard that it hinders performance in that area because either thread can monopolize the cache and registers causing a pause or slow down.

[Jerry Atrik 0]

dual xeon ht, i can capture/encode from my pinnacle card at dv quality AND play cod... sure my frames drop to 70 sometimes but what the heck.

[CyberGenX 0]

I am using a GeForce4 Ti 128MB 4X AGP. I am using 53.03 Ref. Drivers.

[Jerry Atrik 0]

gforce4 ti4200 128 4x

 

ummm drivers are prolly 2 versions ago i think.

i dont notice a big increase from one to another but if they are fubar then it's a big deal so i only change them every couple months

[Mr.Guvernment 0]

Any application that will use %100 CPU power - HT is useless - why? Becuase HT allows the system to use CPU power not in use - but when you are using %100 cpu power - there is not cpu power left to allocate to anything else.

[Mr.Guvernment 0]

Quote:

I am using a GeForce4 Ti 128MB 4X AGP. I am using 53.03 Ref. Drivers.

go back to 43.* drivers - the 53.* have more optimizations in them .i.e - missing shadows / entire scenese in games etc.

[clutch 1]

Quote:

I have noted that with H/T enabled, IF I run SETI 3.x character mode as a REALTIME CPU priority priveleged application?

I occasionally get "jams"/hangups...

Blah, blah, blah...

Running anything in "Realtime" mode is a poor idea, as all the cpu cycles (effectively) get handed to the application, and thus you get hops and skips when the OS or other apps need attention. If the app cannot field all these resources properly (and most don't, for various reasons) the OS can collapse around it.

HT is more of a cheat at multi-processing. Rather than being a true SMP box, this CPU can spit requests as needed and run the independently(ish). I would imagine that a lot of apps out there cannot fully take advantage of it yet, but expect patches to update them. HT is a great way to go if you can, you just might have to wait to get all the support you want/need.

[duhmez 0]

Don't forget "Captuing DV" is not really capturing at all, jus transferring data. Moving DV data to the pc has NOTHING on actual analog video capture.

 

HT will be of no benefit to DV "capture" as very little CPU is needed. Editing the DV stream however will benefit from it.

[CyberGenX 0]

I AM capturing analog, NOT DV, YET. I didn't have any problems on my AMD XP 2500+ machine with the same capture card, video card, sound card, memory AND drivers. Just seems that the Intel setup I have isn't happy with capturing video in HT mode...

[clutch 1]

Quote:

Just seems that the Intel setup I have isn't happy with capturing video in HT mode...

...or rather, your software isn't happy with H/T. I would say it's the latter.

[CyberGenX 0]

Yeah true. What's wierd is that it worked for 2 weeks with no problems, then yesterday it started up. I have not installed ANYTHING new before the problems came on...

[CUViper 0]

Quote:

Any application that will use %100 CPU power - HT is useless - why? Becuase HT allows the system to use CPU power not in use - but when you are using %100 cpu power - there is not cpu power left to allocate to anything else.

Not really - 100% cpu usage according to task manager just means that there are processes running on the cpu on every cycle. That doesn't guarantee that the program is making use of all the resources during those cycles.

Processors very often have more ALU's and FPU's than a single program can utilize all of the time. In any given cycle, the program may be using, for example, only one of the ALU's and one of the FPU's. Then there are other functional units on the cpu left unused. So the point of hyperthreading is to let multiple programs run on the cpu in a single cycle. On a P4 it can run two threads at once; theoretically, a hyperthreading-type cpu could be made to handle any number of threads together. This, hopefully, results in more "full" cpu utilization, using all of the functional units, in order to increase the overall system throughput.

Hope that makes sense...

[jmmijo 1]

Quote:

Hope that makes sense...

Yeah I think it does to me. Basically it means that if the app and/or OS is not optimized for H/T then it's not running as effeciently on this type of CPU. Also you can possibly run into anomylous behavior like this Video Capture app/hardware.

You can kind of use the same analogy with 64-bit CPU's, if the OS is not re-written to take advantage of the extra CPU features then it's not running at full speed so to speak. I guess in a way this maybe like the old P1 MMX days before games and other apps took advantage of the extra features of the CPU

[CUViper 0]

Sort of, jmmijo, yes. Really, any multithreaded app should see a performance improvement when running on a hyperthreaded cpu. Apps that are only compiled for single-threaded use may still see some improvement though, as the operating system is still multithreading. So, any background tasks can run on the same cycles as your main program.

 

Forgive me if I go too far in explaining this - this is the kind of stuff I am researching in grad school, so I really like talking about it. If you (or anyone else) are interested in learning more about this, I would recommend you check out these multithreading slides. That's from a class I just took last semester... you can also check out the course webpage here. Those slides will probably be pretty confusing if you've never studied computer architecture, but let me make some quick highlights for this discussion. Slide 6 shows an example pipeline for a superscalar cpu, like a non-HT P4, and slide 14 shows another pipeline with simultaneous multithreading, which is what Intel calls hyperthreading. The columns represents different cycles during execution, and the rows represent the different functional units. The colors on the second one indicate different programs executing at the same time.

 

If you want to know more just ask - like I said, I love talking about this stuff...

[CUViper 0]

Getting back to the original topic, I would have to suspect your drivers for the capture card. Yes, I know you said it worked fine on your AMD machine, but... From a software point of view, HT is really no different from true multiprocessors. And it is very common for poorly-written drivers to have issues on multiprocessor machines. So, you may want to see if the manufacturer knows of any problems with multiprocessing with their capture cards. You could also look into getting a capture card that is known to work on multiprocessor machines, like the one Jerry Atrik mentioned.

[clutch 1]

When running in realtime mode with multiple CPUs, I doubt you are tying up all the resources of all of them, therefore you are leaving some available for the OS. Again, running anything in Realtime mode is a poor idea. Run it with a higher priority? Sure, but not Realtime.

[clutch 1]

Again, I stated that takes "most" of the resources, and not all of them. Duh. You also state that it is dependent on the application, which I stated earlier as well. Is there a *real* need to add all that text to simply reiterate what someone else already stated, or are you too busy typing and clicking "quote" to actually go through it? Nevermind, you will probably post "War and Peace" and I wouldn't care.

[duhmez 0]

I too have thought the "realtime bad never use" situation from what I have read. i however have a true Dual cpu rig. I encode alot of Divx and DVD (mpeg2)

 

Guess Ill set my encoders to realtime and see how much extra speed I get.

 

Currently one encoder I use only eats about 70% of both my cpu's, i wish it would use more. Hopefully realtime will help in this case.

 

The other encoder I use uses both cpu's 100%, but it takes longer (inefficient encoding) and it stays at 100% both chips when set to low priority, although my machine is very responsive even when it's at 100% both. ind of like the way prime95 makes my cpus go to 100%, yet the machine remains totally responsive.

 

Wwhat causes this behavior? (great responsiveness even at 100% use) ?

[CUViper 0]

Quote:

The other encoder I use uses both cpu's 100%, but it takes longer (inefficient encoding) and it stays at 100% both chips when set to low priority, although my machine is very responsive even when it's at 100% both. ind of like the way prime95 makes my cpus go to 100%, yet the machine remains totally responsive.

Wwhat causes this behavior? (great responsiveness even at 100% use) ?

I have to disagree with AlecStaar's assertion on this one. Also, this brings up an excellent point AGAINST realtime mode. The reason that your machine runs so nicely even when prime95 is running, is because prime95 does all of its processing at a very LOW priority. In fact, I'll quote their FAQ directly:

Quote:

Will the program interfere with my normal work?
Highly unlikely. The program runs at the lowest possible priority. This means it runs only when you are not using your computer for other purposes.

The point of the priority system is to indicate to the OS which tasks are most important. The way prime95 is set up, it like saying to the OS "Go ahead and do all the little things you need to do, and I'll do my work when you aren't busy." Conversely, if it were running in realtime, that is essentially saying "Give me the cpu - when I have a spare moment I will let you (the OS) do your thing." And for a program like prime95, which ALWAYS has stuff for the cpu, running in realtime priority would bring the rest of your system to its knees.

Now, I think this is a separate issue, but I will agree with AlecStaar that the multithreading your apps has a positive effect on the performance of the single application. Well-written programs will often have a gui thread and one or more work threads. The gui thread does the simple stuff, like accepting mouse input from the user and drawing the controls on the screen. The work threads does whatever cpu-intensive work needs to be done. However, if the work threads are placed at too high a priority, then the gui thread will suffer less cpu time than it needs to appear smooth.

[clutch 1]

CUViper has it, it is a poor idea, PERIOD. If you want to contribute to the instability of the OS, fine. Other applications that work in the same concept, but with available RAM, would be the Exchange server series. In Exchange 2000, it would gobble up all the free RAM it could and "release" RAM to the OS when it "needed" it. However, its definition of need seemed to differ from everyone else's and typically wouldn't release a damn thing (much to the chagrin of Small Business Server admins that had to run IIS and SQL server on the same box as Exchange). Running something in Realtime means you are granting the application the ability to supercede other apps and the OS for scheduling (and attempting to provide time constraints on the scheduling, which NT was never really meant to do). So, if you were to do this on a dual CPU box, you could conceivably tie up both CPUs and crash the OS (assuming the app could balance all CPUs). Now, the only way to guarantee that this wouldn't happen is to set the affinity of the process to one CPU, and let it spin its threads over there at Realtime. But, doesn't this defeat the purpose of using an SMP box with a multithreaded app (insert nod here)? Don't waste your time doing this unless it's for testing. Using High priority is good enough and will give your app a nice boost most of the time while not sucking away life from your system.

[CUViper 0]

At least clutch and I see eye-to-eye...

 

I will grant you, AlecStaar, running a program like prime95 in realtime will not tie up both cpu's of a dual-processor machine, nor will it completely block the OS. Why? Because the work thread of prime95 is a single thread, and a single thread can not run on more than one processor at a time.

 

But, any other app could be doing its work in more than one thread. If you start a multithreaded application in realtime, one that does its cpu-intensive processing in more than one thread, then those threads will consume all of the cpu time, even on a multiprocessor or hyperthreading machine. (Unless, as clutch pointed out, you tie the process affinity to one CPU.) The only time the OS will get to do anything is when the program has a stall in execution, like a disk access or something.

 

Running in realtime, or any higher priority, does not magically create more processing power for you to use. All it does is redefine the processor scheduling for the operating system. Any increases you see in your particular program by running in this manner WILL cause a decrease in performance somewhere else.

 

AlecStaar, you keep saying in your arguments how good your apps are, how efficient and user-friendly etc. etc... I am not arguing your programming skills, nor do I think it is relevant to this conversation. An efficient algorithm is always a better solution than new hardware. The issues of realtime priority, hyperthreading, and multiprocessing are really only relevant to apps that ARE "cpu hogs".

[CyberGenX 0]

hoe humm

[clutch 1]

I've grown weary of your incessant rambling. Setting anything to run in Realtime mode is a horrible idea. MS and everybody else states that, so get over it.

[duhmez 0]

For the record, I am currently encoding a 352,480 mpeg2 file with an smp capable program. Both CPU's at 70% and realtime. Computer is runing smooth. Then i fired up Prince of persia sands of time while encoding, and IT was smooth as silk.

 

I love my dual rig.

ive seen people with 1 p4 2.4 be virtually unusable while using some encoders with default priority even, but virtually unusable I mean sluggish as hell.

[CUViper 0]

Quote:

Quote:

At least clutch and I see eye-to-eye...

I have to be blunt about this, here goes:

For two guys with only one eye each worth of know-how in this field, I can see that, you in academia, Clutch as user/network admin. & novice coder! Without 2 eyes so to speak, or experience on THIS end of it hands on coding this kind of ap? It's like only having 1 eye... no depth perception, not able to see the depths of the big picture.

This was meant as a simple jest - I did not mean to indicate who knows more than who, etc.

I would be willing to wager that with my "one eye" worth of know-how, I know more about the underlying hardware than you, AlecStaar. And I don't think there's any question that you know more about Win32 programming than I do. I think this is really a matter of perspective - You are looking at the cpu from above, with software / programming experience, and I am looking at it from below, from a hardware design perspective. The "big picture" depends on what you are interested in.

Quote:

AGAIN: Only the main body thread gets "REALTIME".... second or more threads if scheduled by the OS only (not the app itself telling them what priority to run at) will run @ normal priority on another CPU, unless the app itself tells them to run @ HIGH or REALTIME for example.

The OS scheduler will take care of that... second threads run @ NORMAL PRIORITY (unless they are told not to) on the subsequent processors.

This I was not aware of - it seems counter-intuitive to me, but this point I will yield to you due to my own inexperience. In this case, it wouldn't seem very useful to run most programs at higher priorities, because I think the general practice on multithreaded apps is to do the cpu-intensive work in a child thread. But that's a matter of programming practice, which may be different elsewhere.

Quote:

Quote:

Running in realtime, or any higher priority, does not magically create more processing power for you to use.

I never stated it did...

Quote:

All it does is redefine the processor scheduling for the operating system. Any increases you see in your particular program by running in this manner WILL cause a decrease in performance somewhere else.

Yes, I know that... do you REALLY think I don't?

These statements were not really directed at you. A lot of people with less experience seem to get the idea that running at higher priorities will tap into some magical well of unused processing power. I just wanted to "debunk the myth". So I am glad we agree...


This thread is starting to degrade into a lot of defensive statements, on both sides, so I think maybe we all need to just step back and take a deep breath...