Originally posted by: EmoshBZ
Here's the deal, we have some folks claiming the AMD64's absolutely suck as multitasking. We need to test this theory and eiter confirm it or put it to rest.
What you AMD64 owner's need to do, including myself once I get home tonight, is to do some testing. I suggest finding a very large music CD you personally own, begin ripping and encoding the whole cd to mp3, all while browsing the web. While it's in the oven, open several browser windows and note the performance. Does it take roughly a minute to open the browser during an encode? Does your machine seem extremely sluggish?
Let us know here.
Any system that doesn't have multiple CPUs (or one that pretends to be two) will be almost unusable if you run an encoder at higher priority. Note that if you're running low on ram that could also cause trouble. In order to validly test mutlitasking performance, you need to run everything at the same priority (e.g. SETI at normal priority, a game at normal priority). I don't know what you expect to find though.
Originally posted by: sandorski
Originally posted by: Megatomic
So what could we do to overwork the CPU? Run SETI or Prime95 while playing a game? And give each process a high priority?
Running SETI 24/7 while playing games, encoding, etc doesn't "bog" a system, I do it all the time. Although, if you do what Ulric just suggested, running SETI Realtime or High Priority will "bog" a system. IMO, "Bogging" a system really has little to do with Multitasking as Priortization allows Multitasking by good scheduling of tasks. What or How good Multitasking benefits is in the Performance that Multiple tasks acheive. For instance: I can run SETI and Game with no noticeable affect on the task that I'm doind(Gaming), however SETI will operate at a much lower rate. It really depends on the Priorities that tasks work at, if 2 try to operate with High Priority there could be problems, but that usually doesn't happen unless the User forces that Priority.
Right... when you're using 100% of the CPU time, the system appears "bogged" down to whatever processes have lower priorites. Making SETI high priority to "bog" down a system is pretty stupid - the computer is giving all it's resources to something that demands lots of power, just as you told it to.
To really test Multitasking, first test various tasks as a Single task, then run them at the same time and see how long they take to complete. This way you'll see how much longer the Individual tasks take when under a Multitasking environment. That's how I'd do it anyway.
edit: Oops, just re-read your post. Yes, if you give both a High Priority you'll "bog" your system, msot people wouldn't even know how to do it though, so it's not much of a useful test. Geeks would like to know though.
It is still hardly a valid test. A better test is multiple processes at the same priority.
Originally posted by: Duvie
What you will see is that without messing with priorities that for the most part the encoding will continue to fly almost as norma but in the end of it the cpu time of the SETI program will have barely got any cpu cycles or the frame time will be considerably higher then before.
When you run a CPU intensive app at a higher priority than another CPU intensive app, the low priority one gets starved. It doesn't matter WHAT architecture the processor is - unless you either have two CPUs or emulate two CPUs, the lower priority process does (and should) get starved.
Originally posted by: Duvie
YOu ppl want to know how a barton 3200+ acted in multitaksing test like I list above??? Go check out my multitasking thread in CPU forum and look at how the p4 acted in those cpu intensive applications with HT off in bios and that is about right with scores a bit less since the Barton 3200+ was no where near the the p4c at 3.2ghz......
I imagine the A64 would do better....With better memory controller and I think even hard drive controllers it may help it but I believe fundamentally it still comes down to thread scheduling and ultimately it may not do much better in times but will be harder to bog down...
Thread scheduling is done by the software (part of the OS kernel).
I believe SETI ppl have shown 2 instances of it run simultaneously gained no speed. The result was twce as long to get 2 wu down as 1....However for the P4 w/ HT (this is well documented) 2 instances result in faster time per WU.....
Yes, because of HT, which emulates two CPUs. One CPU can only run one thread at a time, unless it plays tricks to appear to be two CPUs. It isn't because of any weird scheduling differences - it's just that two CPUs can do more things at a time than one.
Facebook
Twitter