That is right if they were all set to EQUAL or LEVEL thread priorities....LOW setings throws all of that logic out the window...
That is right if they were all set to EQUAL or LEVEL thread priorities....LOW setings throws all of that logic out the window...
- Jan 16, 2003
- 21,219
- 54
- 91
Originally posted by: Duvie
Duvie Duvie!!!!!! I know I was wrong man... !!!I said that like 15 posts back. LOL.
No worries, I know my numbers are off and Marks were close to actual.
:beer:
Folks are posting so fast it's kinda hard to keep track.
NO Keys you are wrong.....I think the Intel was only perhaps down 4 hours max and not the difference of up[time...It is not AMD's fault the system went down 3 times and there was work done before the latest length of stability...in those areas the pattern of usage was similar so I can only conclude it doing similar in performance...MOvement now in the test is not far of what it (other then the rather randomness of app priority switching) was at the beginning so I cant see anything to prove your claims the currnt results of what cpu is winning each test would be any different...
But the priority level is equal to a percentage of a cpu-thread's computation. THE AMD X2 and Window XP combined is losing that percentage scale for some strange reason.
I think it maybe caused due to instruction congesting inside the CPU.
As tests have shown on other sites (if taken seriously,) the AMD X2 struggles with multitasking.
.
Did anyone find out what the real priority level was on the divx thread?
Normal? Below Normal? or Low? and what percentage of cpu time these priorities represent?
.
Normal? Below Normal? or Low? and what percentage of cpu time these priorities represent?
.
This test from performance point of view is ridicilous.
32bit Windows.
X2 4800 vs XE840
- 1 thread AMD wins
- 2 threads AMD wins
- 3 threads Intel wins
- 4 threads Intel wins
X2 ANY MODEL vs ANY Intel dual core (except XE)
- from 1 thread to infinite amount of threads AMD wins.
64bit windows AMD X2 beats any Intel DC and SC.
Also this pic is good to have a look at.
http://koti.welho.com/pnystro2/somepics/dc.multitasking.PNG
edit: this is how things usually go, but with different applications Intel might win few benches.
32bit Windows.
X2 4800 vs XE840
- 1 thread AMD wins
- 2 threads AMD wins
- 3 threads Intel wins
- 4 threads Intel wins
X2 ANY MODEL vs ANY Intel dual core (except XE)
- from 1 thread to infinite amount of threads AMD wins.
64bit windows AMD X2 beats any Intel DC and SC.
Also this pic is good to have a look at.
http://koti.welho.com/pnystro2/somepics/dc.multitasking.PNG
edit: this is how things usually go, but with different applications Intel might win few benches.
You are not getting get....
....This statement is wrong....Low priority is not equal to normal settings and can be in some instances given no cpu cycles to work...It depends on the other apps thirst for the cycle and since they have normal or "higher priority then a low setting" if they continually request the cycle they will always get them over the low priority...
Really I wont say it again..Go read some fvcking definitions of this at Microsoft and get a handle on this...It is pretty simple really....
I wonder if THG stuffed up and installed divx codecs in non Admin privilege level on the AMD system hard drive, and if that could possibly cause a poor balance on that application thread?
Back in a few hours...
.
Back in a few hours...
.
Every thread has a thread priority assigned to it. Threads created within the common language runtime are initially assigned the priority of ThreadPriority.Normal. Threads created outside the runtime retain the priority they had before they entered the managed environment. You can get or set the priority of any thread with the Thread.Priority property.
Threads are scheduled for execution based on their priority. Even though threads are executing within the runtime, all threads are assigned processor time slices by the operating system. The details of the scheduling algorithm used to determine the order in which threads are executed varies with each operating system. Under some operating systems, the thread with the highest priority (of those threads that can be executed) is always scheduled to run first. If multiple threads with the same priority are all available, the scheduler cycles through the threads at that priority, giving each thread a fixed time slice in which to execute. As long as a thread with a higher priority is available to run, lower priority threads do not get to execute. When there are no more runnable threads at a given priority, the scheduler moves to the next lower priority and schedules the threads at that priority for execution. If a higher priority thread becomes runnable, the lower priority thread is preempted and the higher priority thread is allowed to execute once again. On top of all that, the operating system can also adjust thread priorities dynamically as an application's user interface is moved between foreground and background. Other operating systems might choose to use a different scheduling algorithm.
Straight from Micorsoft.com.... http://msdn.microsoft.com/library/defau...pguide/html/cpconSchedulingThreads.asp
If you cant understand this you never will....
BOLD section>>>
If this isn't what I have been saying the whole fvcking time I dont know what is....In fact I have said this exact thing as well as why the Divx does get some minutes done...
Threads are scheduled for execution based on their priority. Even though threads are executing within the runtime, all threads are assigned processor time slices by the operating system. The details of the scheduling algorithm used to determine the order in which threads are executed varies with each operating system. Under some operating systems, the thread with the highest priority (of those threads that can be executed) is always scheduled to run first. If multiple threads with the same priority are all available, the scheduler cycles through the threads at that priority, giving each thread a fixed time slice in which to execute. As long as a thread with a higher priority is available to run, lower priority threads do not get to execute. When there are no more runnable threads at a given priority, the scheduler moves to the next lower priority and schedules the threads at that priority for execution. If a higher priority thread becomes runnable, the lower priority thread is preempted and the higher priority thread is allowed to execute once again. On top of all that, the operating system can also adjust thread priorities dynamically as an application's user interface is moved between foreground and background. Other operating systems might choose to use a different scheduling algorithm.
Straight from Micorsoft.com.... http://msdn.microsoft.com/library/defau...pguide/html/cpconSchedulingThreads.asp
If you cant understand this you never will....
BOLD section>>>
If this isn't what I have been saying the whole fvcking time I dont know what is....In fact I have said this exact thing as well as why the Divx does get some minutes done...
Gamingphreek
Lifer
- Mar 31, 2003
- 11,679
- 0
- 81
How has he made any bias? His only post was insulting you.
Also Duvie i believe owns an Intel processor. Does that make him biased, not one bit. I own an AMD processor, does that make me AMD biased, not one bit.
-Kevin
I dont even know why I bother, but i'll do it anyways, bored you see:
priority does not equal to a % of cpu time. if you run the divX encoding in idle on yer system and nothing else it will utilize everything not used, so if you are doing nothing else it will get 100% (minus the few background processes the OS runs but those are peanuts) if you then start a proces with higher priority (anything over idle) that utilizes the full 100% of the processor and will take everything it gets your idle encoding thread will get 0% of CPU essentially stopping completely. this is something everyone can test on his singlecore non HT CPU.
the issue is now what happens with HT. ideally HT would give only the exess cycles to the encoding thread so when the higher priority app really uses 100% of the chip in full capacity a HT aware OS would not assign any cycles to the divX encoding thread and have the same result as a non HT core. however that is why HT is effective, the intel CPU has such a long pipeline that in general it is quite hard to really use the CPU 100% to the full. this is why HT is actually beneficial from time to time. Be aware however that a non HT aware OS will see both virtual cores as real ones and will assign 100% of your idle encoding thread to the second core. and THEN it is up to the internal workings of the CPU in the most basic internal workings the CPU would be essentially cut in half, giving 50% to the higher priority thread and 50% to the idle priority thread, essentially overwriting the settings you made and making your high priority app go much slower than you'd want (there's a reason the other is set to idle, you might want to encode while gaming or doing other stuff for instance)
here it is the same situation except on a bigger scale and much more complicated.
and as I said before if the encoding thread is set to idle there is an issue with the thread scheduler in combination with a dualcore HT chip.
priority does not equal to a % of cpu time. if you run the divX encoding in idle on yer system and nothing else it will utilize everything not used, so if you are doing nothing else it will get 100% (minus the few background processes the OS runs but those are peanuts) if you then start a proces with higher priority (anything over idle) that utilizes the full 100% of the processor and will take everything it gets your idle encoding thread will get 0% of CPU essentially stopping completely. this is something everyone can test on his singlecore non HT CPU.
the issue is now what happens with HT. ideally HT would give only the exess cycles to the encoding thread so when the higher priority app really uses 100% of the chip in full capacity a HT aware OS would not assign any cycles to the divX encoding thread and have the same result as a non HT core. however that is why HT is effective, the intel CPU has such a long pipeline that in general it is quite hard to really use the CPU 100% to the full. this is why HT is actually beneficial from time to time. Be aware however that a non HT aware OS will see both virtual cores as real ones and will assign 100% of your idle encoding thread to the second core. and THEN it is up to the internal workings of the CPU in the most basic internal workings the CPU would be essentially cut in half, giving 50% to the higher priority thread and 50% to the idle priority thread, essentially overwriting the settings you made and making your high priority app go much slower than you'd want (there's a reason the other is set to idle, you might want to encode while gaming or doing other stuff for instance)
here it is the same situation except on a bigger scale and much more complicated.
and as I said before if the encoding thread is set to idle there is an issue with the thread scheduler in combination with a dualcore HT chip.
I can find countless more threads that explain this in relation to exactly what that article is stating...cpu cycle assigned to threads through the scheduler based on priority...Dont try to grey it up...This is simple to follow...It has been discussed in countless reviews and I can start pulling them up and embarassing the heck out of you....
Give it up...Tell your emplioyer you are done spreading the FUD..The gig is up and you are being revealed for what your are.....
Give it up...Tell your emplioyer you are done spreading the FUD..The gig is up and you are being revealed for what your are.....
BUT it should never go below it's assigned percentage of CPU instruction computation, or programs would be congested like the divx thread is uniquely doing on the AMD X2.
IDLE and LOW, priority are two different meanings, btw. (got to go)
.
http://msdn.microsoft.com/library/defau...mthreadingthreadpriorityclasstopic.asp
read some more here...
Is does mention a nioce line I have stated also before about thread priorities CAN BE dynamically changed by the OS based on whether t is in the foreground and bckground...i think Pabster called me a liar on that one....
read some more here...
Is does mention a nioce line I have stated also before about thread priorities CAN BE dynamically changed by the OS based on whether t is in the foreground and bckground...i think Pabster called me a liar on that one....
Lets get back on a real discussion.......
Does anybody have an idea or theory of what is happening in the current INtel cpu usage chart??? That is a bit chaotic yet I see no change in performance oddly....
Does anybody have an idea or theory of what is happening in the current INtel cpu usage chart??? That is a bit chaotic yet I see no change in performance oddly....
Duvie, you are quoting from the .Net framework, regarding the Common Language Runtime layer. It's is a layer to compiling IL code as it's demanded to be executed.
The term thread isn't just for API's or windows current mode of running tasks, it's also at a sub level within an application and also at a assembly level within a CPU. A 'Thread' has different meanings depending on the context.
Cheers.
Btw the .Net way of running threads maybe the same way the kernel runs them (without the .Net framework), anyway, so you maybe partly right.
.
kitkat22
Golden Member
- Feb 10, 2005
- 1,464
- 1,333
- 136
Wow, that was quite the stint of posts of going back and forth.
This is just my musings on the subject as the threads were being posted.
In essence, can we believe these numbers? Are they credible? If they are not, there is no use beating a dead horse and pulling out conclusions that it is still alive. In support of, "they are not," we have to look at the patterns that are exhibited over the course of the test. Typically speaking there is a pattern to a repeated series of events performed by the same device over an extended period of time. In other words, we should see a similiar rate of increase/decrease from one performance standpoint to another at any given point in time. We have seen that this is not true, thanks to the efforts of duvie. A possible theory of how this is so may stem from THG maximizing and minimizing windows to check that things are indeed going smoothly. Unfortunately, they are ruining the test at the same time. Another aspect deals with the downtime of the Intel processor. The only real consistency we've seen in stability is later in the test. What did these higher temps and instability issues do to the numbers earlier on? (Not just down time, but effect on the performance as well.) We don't know. A further point is the validity of the test in the end proving or disproving the ability of each processor. Is four threads the "say all, end all," of tests or do we need to verify these results through another independent study? As I have mentioned before, if this test has not been properly designed, why are some supporting the numbers when they could have been altered or flawed? The test is invalid in terms of performance. The only conclusion I will make is there is not enough data to support the abilities of one processor over the other.
Now, if the test is valid there are some conclusions we can also make. I have not looked at the recent numbers and I personally don't care to because my opinion lies in the test is invalid. If the numbers are correct we can conclude that there is a definitive issue with scheduling. Since Duvie was kind enough to quote straight from Microsoft's webpage we can rightfully blame the OS in this situation. We thus conclude there is a difference in terms of scheduling. Further, we can conclude that the tests are independent of each other and have no relation to each other because, as was mentioned, what is a Farcry score in relation to a winrar score, etc. If we look at it in these lights there are winners and losers, but again because we have to conclude the tests independent from each other we can only assume a 2 win-2 loss for Intel and a 2 win-2 loss for AMD, or whatever the numbers indicate. If it is 50/50 there is no real winner or loser. Frankly speaking, I have no possible reason to support the second paragraph. Looking at the data I can't justify myself saying "yes" or "no" to either processor. Even if the second paragraph were true there can be no rightful conclusion.
In conclusion, from what I have seen the people on this thread fall into either of these two camps. Reasoning would conclude the test invalid and would force the reintroduction of a new test with tighter controls and specs. If a test has a large amount of controversy associated with it the experimentars must create a test that is at least 99% sure the data is correct. For example, if we wanted to test abortion, gay rights, or the death penalty we would have to make sure the experiment is nearly failproof either for or against, there cannot be any grey area. However, if you wanted to determine which colors, red or blue, are better or more popular you can get away with less strict methodology. From this thread there is apparent controversy and the only way to prove in either direction is to have a better, stricter test.
This is just my musings on the subject as the threads were being posted.
In essence, can we believe these numbers? Are they credible? If they are not, there is no use beating a dead horse and pulling out conclusions that it is still alive. In support of, "they are not," we have to look at the patterns that are exhibited over the course of the test. Typically speaking there is a pattern to a repeated series of events performed by the same device over an extended period of time. In other words, we should see a similiar rate of increase/decrease from one performance standpoint to another at any given point in time. We have seen that this is not true, thanks to the efforts of duvie. A possible theory of how this is so may stem from THG maximizing and minimizing windows to check that things are indeed going smoothly. Unfortunately, they are ruining the test at the same time. Another aspect deals with the downtime of the Intel processor. The only real consistency we've seen in stability is later in the test. What did these higher temps and instability issues do to the numbers earlier on? (Not just down time, but effect on the performance as well.) We don't know. A further point is the validity of the test in the end proving or disproving the ability of each processor. Is four threads the "say all, end all," of tests or do we need to verify these results through another independent study? As I have mentioned before, if this test has not been properly designed, why are some supporting the numbers when they could have been altered or flawed? The test is invalid in terms of performance. The only conclusion I will make is there is not enough data to support the abilities of one processor over the other.
Now, if the test is valid there are some conclusions we can also make. I have not looked at the recent numbers and I personally don't care to because my opinion lies in the test is invalid. If the numbers are correct we can conclude that there is a definitive issue with scheduling. Since Duvie was kind enough to quote straight from Microsoft's webpage we can rightfully blame the OS in this situation. We thus conclude there is a difference in terms of scheduling. Further, we can conclude that the tests are independent of each other and have no relation to each other because, as was mentioned, what is a Farcry score in relation to a winrar score, etc. If we look at it in these lights there are winners and losers, but again because we have to conclude the tests independent from each other we can only assume a 2 win-2 loss for Intel and a 2 win-2 loss for AMD, or whatever the numbers indicate. If it is 50/50 there is no real winner or loser. Frankly speaking, I have no possible reason to support the second paragraph. Looking at the data I can't justify myself saying "yes" or "no" to either processor. Even if the second paragraph were true there can be no rightful conclusion.
In conclusion, from what I have seen the people on this thread fall into either of these two camps. Reasoning would conclude the test invalid and would force the reintroduction of a new test with tighter controls and specs. If a test has a large amount of controversy associated with it the experimentars must create a test that is at least 99% sure the data is correct. For example, if we wanted to test abortion, gay rights, or the death penalty we would have to make sure the experiment is nearly failproof either for or against, there cannot be any grey area. However, if you wanted to determine which colors, red or blue, are better or more popular you can get away with less strict methodology. From this thread there is apparent controversy and the only way to prove in either direction is to have a better, stricter test.
Markfw
Moderator Emeritus, Elite Member
- May 16, 2002
- 27,258
- 16,115
- 136
Well said cscpianoman. My summation at this point that I don;t think can be disputed:
1) Intel draws a lot of power and the current motherboards have a hard time supporting that.
2) Adding SLI to the equation makes it totally unstable with ANY current motherboard.
3) The Intel puts out much more heat and requires much more cooling.
4) The performance using the 4 threads of the type choosen by THG is at best debatable as to which wins.
1) Intel draws a lot of power and the current motherboards have a hard time supporting that.
2) Adding SLI to the equation makes it totally unstable with ANY current motherboard.
3) The Intel puts out much more heat and requires much more cooling.
4) The performance using the 4 threads of the type choosen by THG is at best debatable as to which wins.
okay, now do you want to stop spewing the fud about assembly languages, you got me so bored I put some time to disproove your statement.
as you can see in this example here (my own shots) when you run two cpu intensive tasks the one with higher priority gets all the cpu and the one with lower gets none of the CPU.
at the start of the second encoding process the first had been busy for 33 seconds and had encoded about 850 frames. then I let em settle a bit and took the first screenie. as you can see the PID 868 uses CPU whereas the idle one gets no CPU at all. the idle thread has gotten 36 seconds of CPU time during it's 2:27 min run time and the lowest thread has received 1:41 min CPU time during it's 1:56 min run time.
take into account I have started up psp in the mean time which also takes cycles away from the thread set to lowest.
then fastforward to the 5 min mark.
here you can see the PID 868 using 99% of the CPU and you can see that during it's 5:06 min runtime it has been assigned 4:40 min CPU time so since the previous sceenshot time has advanced 190 seconds and it has received 179 seconds of CPU time.
then you can see that the PID 1940 (the idle priority encoding thread) has received a full 2 seconds CPU time during those 190 seconds. quite a difference.
then we can check the last frame where you can see that the lowest priority thread has done 10 times as much as the idle priority one. but this is just for illustration to see that the time of completion actually increases on the idle one because as everyone here knows it is exactly processing at 0 frames per second because it is completely blocked by the other thread.
so I disproved your statement of this only happening on the AMDX2 and on AMD processors solely because this is a P4 2.4 Ghz. (no HT)
and for the ones wondering: yes I am very bored that I occupy myself with these things.
Edit: it would be nice if someone with a HT capable processor could duplicate this mini-test of mine, if possible under win2K too (to see how it acts exactly with a non HT-aware OS) virtualdub can be found at www.virtualdub.org and divx at www.divx.com (last time I checked the free version was no longer spyware) if not using divX make sure to use another CPU intensive codec, because some low compression codecs are more IO limited than CPU.
would be nice to compare and see.
edit2: links were fuggered.
I don't claim to know anything about CPU assembly level, or any programing, but just by reading here I know enough to enlighten you and help you realize that in this case Duvie is 100% right.
First let's take the facts we know in consideration.
1. GuardianKnot it automatically sets as low priority task.
2.Threads are scheduled for execution based on their priority... the thread with the highest priority (of those threads that can be executed) is always scheduled to run first. If multiple threads with the same priority are all available, the scheduler cycles through the threads at that priority, giving each thread a fixed time slice in which to execute. As long as a thread with a higher priority is available to run, lower priority threads do not get to execute.When there are no more runnable threads at a given priority, the scheduler moves to the next lower priority and schedules the threads at that priority for execution. If a higher priority thread becomes runnable, the lower priority thread is preempted and the higher priority thread is allowed to execute once again. On top of all that, the operating system can also adjust thread priorities dynamically as an application's user interface is moved between foreground and background. Other operating systems might choose to use a different scheduling algorithm.
This is what Duvie already posted from Microsoft's site.
So even if you are entirely right about the three levels of asaigning tasks, you still have to follow a vertical structure.
1. The priority level set as default in that aplication.
2. The dinamic change of level of priority by bacground/foreground switching of aplication
These two get combined to create the next vertical step
3. The priority level set for that aplication by the operating system in the task manager compared to the other tasks.
**4. The CPU priority level.**
If you look again at the Microsoft description you'll notice a vertical execution of tasks from High to Low (duh) so even if 3 aplications are set to normal (CD's rip, archive and game in our case) a lower level aplication (guardianknot in our case) is not sent to the CPU for execution at all unless all (or in our case only one) higher applications priority are not active.
**NOTE** I think that the CPU doesen't decide between doing the Divx or the CD's but more it decides between calculating (in a game for example) a physics algorithm or the position of a polygon. So it decides what thread to do in a app, not what app amongst the others.
But who am I to guess.
So my name means that Intel is better at handling threads ?
For the 1000th time, it's OS job to handle tasks.
Also server applications do have more threads than those apps at THG have.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 22K
-
News NVIDIA and Intel to Develop AI Infrastructure and Personal Computing Products- Started by poke01
- Replies: 384
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
Facebook
Twitter