HyperThreading: HyperProblem!
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.
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.
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.
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
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.
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.
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...
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...
Quote:For the record, I am currently encoding a 352,480 mpeg2 file with an smp capable program. Both CPU's at 70% and realtime.
I suspect in this case that your processors are too fast! :x
Meaning really that you are probably processing faster the hard drive can supply data. An app running in realtime, or even in normal priority, should fill up the cpu if it has work to do. So if the cpu's are not being kept 100% busy, then it means they are waiting for work, which could mean they are stalled on reads/writes from the hard drive. It could be something else holding back the performance too, but that is the most obvious suspect.
I would be curious to know what your encoding times are, in realtime vs. normal priorities. I suspect that realtime is not helping you, by why hypothesize when we can experiment?
I suspect in this case that your processors are too fast! :x
Meaning really that you are probably processing faster the hard drive can supply data. An app running in realtime, or even in normal priority, should fill up the cpu if it has work to do. So if the cpu's are not being kept 100% busy, then it means they are waiting for work, which could mean they are stalled on reads/writes from the hard drive. It could be something else holding back the performance too, but that is the most obvious suspect.
I would be curious to know what your encoding times are, in realtime vs. normal priorities. I suspect that realtime is not helping you, by why hypothesize when we can experiment?
i run the folding at home distributed computing. i just turned it to realtime and the cycles got a little slower.
it's running 4 threads at 100% cpu usage.
ill play with some other configs and see how it all goes.
it's running 4 threads at 100% cpu usage.
ill play with some other configs and see how it all goes.
Quote:It's possible... if you are an Electrical Engineer, this is quite the possible!
To answer this (implied) question, since I don't think I've ever said - I received my BS in Electrical & Computer Engineering last spring, and I am currently working towards my MS in Electrical Engineering, with an emphasis on Computer Architecture.
So yes, we have very different backgrounds, but I hope we can continue "teaching" each other...
To answer this (implied) question, since I don't think I've ever said - I received my BS in Electrical & Computer Engineering last spring, and I am currently working towards my MS in Electrical Engineering, with an emphasis on Computer Architecture.
So yes, we have very different backgrounds, but I hope we can continue "teaching" each other...
for clarity im mp and h/t
it's gotta be different than sp h/t
im not seeing a time difference with 2 threads and realtime. pretty standard to normal.
normal being 1 or 2 threads no slowdown, 3 threads 3-7% slower and 4 threads 7-10% slower.
slower than 4 threads on 4 cpus but still much faster than 1 cpu to do 4 projects or 2 cpu's to do 2.
it's gotta be different than sp h/t
im not seeing a time difference with 2 threads and realtime. pretty standard to normal.
normal being 1 or 2 threads no slowdown, 3 threads 3-7% slower and 4 threads 7-10% slower.
slower than 4 threads on 4 cpus but still much faster than 1 cpu to do 4 projects or 2 cpu's to do 2.
mmmmm prescott with 1 meg cache
