Hey all Nothing uber important just starting to wonder.
I recently upgraded my processor from an AMD 3500+ to an AMD X2 4800+
Basically. There is no difference in performance. Same speeds at opening / closing programs, same sort of FPS Rate.
Now i changed to a New motherboard too so u cabt see ut being the Cache as i only put the 4800 in it.
System as is is now
AMD 4800+
1 Gig (2x512) Corsair PC3200 DDR400 ram
Elitegroup ECS, KN1 SLI lite Motherboard (Shitty i know but shouldnt halt the performance in theory)
Graphics Nvidia 7300 GS (same results with my 6600 GT)
Just wondering if anybody has any ideas as to what i can try to improve the performance. OBviously ram upgrade. But should still notice a difference from 3500 to 4800. Only thing i can think of is the Bios.
Other than that.... Any ideas?
lol...opening and closing programs is more ram/hard drive. I doubt you'll really see the true benefits of dual core unless you are doing extreme multi-tasking, running SLi, video editing...etc.
Opening and closing programs would also relate alot to how fast the HD it's running off and how fragmented it is. Other than that you can try the typical tweaks like modifying the IO Page Lock Limit - do a search on google for the registry key, I forget now - which can help alot.
erm you could try getting a better graphics card - you have an SLi mobo and a spare 6600GT, or you could drop in another 7300GS - but either way you gfx card is the limiting factor
I'm not sure if LFS supports multi CPU systems at all. You might wanna check the taskmanager while LFS is running, to see if it uses only one or both. My guess is only one (or does the motherboard make it look like a single CPU system anyway?). You know, a 3500+ has 2.2GHz, while a 4800+ has 2.4GHz. So if LFS runs one one die only, you might have effectively upgraded your CPU by 200MHz.
But then again, take what I've said with a grain of salt. Maybe it's complete BS.
Almost no programs use dualcore yet, but u should notice a difference when multitasking (unzipping/encoding and playing a game at the same time)
The X2 4800+ has 2cores each running at 2400Mhz and the 3500+ has one core running at 2200Mhz, so that is a tiny difference when using programs that only utilize 1core.
U could try overclocking the X2 4800+ as it should easily reach 2700Mhz/core, which should give a noticeable performance increase
(overclocking is safe and u would have to be a real nitwit to kill any part while doing it.. so dont listen to people who know nothing about it and say that OC'ing will reduce your processor's life. Unless u plan to run the X2 4800 for over 10years the overclocking wont have any effect whatsoever on CPU life. And unless u have the money to buy a Fx-60...overclocking is a excellent way to get FX-60 performance for 1/4th of the price)
Also ..return the 7300gs if u still can.
It is 50% slower then the 6600Gt in most cases, as proven by toms VGA-chart http://www.tomshardware.co.uk/ ... ;model2=540&chart=212
(check any reso u want and all the games..a 7300gs will be about 50% slower then a 6600gt)
Even though the model numbers are drastically different, most apps will not see a noticeable increase in performance. A little research would have told you this.
I just noticed the difference on them charts for the 7300 S and the 6600GT. Better chuck the 6600 in instead .
As far as the clock speeds go dont forget forbin this is per core.
I didnt expect to see massive changes in the way things worked on their own. But its the performance when using more than one app / game which got me stumped.
I'll Get a defrag done tonight at some point. Not a clue why i never looked at that. As for the ram timings.. any suggestions? thats something i have never played with.
What exactly do you mean by that? It's merely 2 CPU's in a single package. It's not like your clock speed doubled because there are now 2 CPU's. Single-threaded apps (i.e. 99% of games right now) are still going to use 1 core. Running 2 games at once is just silly. You're sharing more than just the CPU between multiple apps, and in the case of games, one game already puts massive strain on the video card.
RAM timings generally have minimal effect on performance. Maybe a few percent, that's it. Timings that are too fast can result in system instability and data corruption, so I opt for very conservative timings.
@der_jackal: That's beside the point. A single-threaded app (I suppose we could call it "a program NOT designed to run on multiple cores/CPUs") will run on 1 core at a time. There is no way such an app would be running on 2 cores at the same given point in time and the fact that the scheduler switches the program between both cores is irrelevent. I'd be appaled if such load balancing was not in place.
I notice I made the same exact point in the other thread...
And I believe I answered you in that thread, LFS is not a single threaded application, you'd be hard pressed to find any game today that is single threaded.
By Aaron Cohen & Mike Woodring 1st Edition December 1997
So what is multithreaded programming? Basically, multithreaded programming is implementing software so that two or more activities can be performed in parallel within the same application. This is accomplished by having each activity performed by its own thread. A thread is a path of execution through the software that has its own call stack and CPU state. Threads run within the context of a process, which defines an address space within which code and data exist, and threads execute. This is what most people think of when they refer to "multithreaded programming," but there really is a lot more to programming in a multithreaded environment.
But if I understand you right, you're telling me because LFS's main thread is on processor 1, so any subsequent threads are also launched on processor 1? Or that LFS runs all its threads in a synchronous order and they are all run on the same hardware thread as the main LFS thread?
Meaning Thread1 is launched, LFS waits until it's completed and then Thread2 is launched...
There is a slight difference between what Forb is saying and what you're reading.
For software to make use of multiple cores, or even multiple cpu's, it has to be programmed to do so, otherwise it will continue to do what processors currently do. Trick the user into thinking it is multitasking. Each clock cycle happens so fast no human will never notice it, my typing this has just ran of a hell of a lot of them.
By switching processes out from one to another it gives the impression that it is multitasking, but in reality it is only running one at a time. What windows does with two processors is the same thing but over two cores. It can run two tasks at once, but still does the same thing, swops out the process to give the impression of multitasking. If a process isn't a real multicore process in task manager it'll use a 50-50 split, a true multicore process will use 100-100.
So there you go, a very rough idiot speak, using lots of incorrect terms run down of what forbs was talking about.
That's vague at best, what processors do is what they are instructed to do.
Again, any and all mutlithreaded applications inherit the usage of both cores from the OS. Again, any application (which is multithreaded, as you're hard pressed to find any commercially available software today that ISN'T) inherits the use of multiple hardware threads via the OS. Anytime an application calls CreateThread from within its execution space, the OS determines what hardware thread it goes to.
For an application to be OPTIMIZED for multiple hardware threads it has to determine and then set Affinity for the hardware thread executor it wants to use for that thread, and for it to really be optimized (ensure 100% CPU utilization on both cores) it has do more to guarantee those threads aren't stumbling over each other for shared resources (amongst other things)...but more on than that later.
CPU clock cycles don't have much play other than they are the basis for the thread quantum (which is 2 clock cycles on Win2k and above, or 12 if you're running Server platforms btw). However a high priority (DPC - High / RealTime) thread will run until its completed regardless of the quantum.
Ever had your single core system "stall" or "hang" for a second or two while something was running? Generally you were the victim of a high priority thread running until it was done, which in turn stalled (on queue) all other lower priority threads (keyboard input, mouse input, etc).
Lower priority threads run on that quantum, they are scheduled, run until they are done, interrupted by a higher priority thread or their quantum is reached. If their quantum is reached or they are interrupted, the context is stored off, and the thread is placed back on queue until its turn comes up again. The vast majority of user mode software runs at < Dispacth Level (Levels go from 0-31, 0 being the lowest, 2 being Dispacth)
Are you thinking only 1 thread can run at a time and that the OS is using parallel processing to split that thread across both cores? Actually not how it works.
Each core was processing a different thread at the time of death (each core is noted by the n: kd>). And actually core 0 was in an idle state when the BugCheck happened.
So, you have three threads on queue. All three w/ the same priority level. All three from one appplication. Thread Scheduler walks the queue, finds that thread1 is in a ready state, sees that processor 0 is running the idle thread, and submits thread1 to processor 0. Scheduler returns to the queue, sees thread2 is in a ready state, sees processor 0 is busy and the thread quantum hasn't been reached, looks at processor 1, sees it's idle and submits thread2 to processor 1. Scheduler walks the queue and sees thread3 is in it's ready state, looks at processor 0, sees that thread1 has reached its quantum, stores the context off for thread1, places it back on queue and starts thread3.
Scheduler walks the queue and sees that thread1 is in a ready state, looks on processor 0 and sees that thread3 hasn't reached it's quantum, looks on processor 1 and sees that thread2 has reached its quantum. Stores the context off for thread2, drops it back on queue and submits thread1 to processor 1. Meanwhile, thread3 completes and unloads, the Scheduler is notified, walks the queue, sees that thread2 is in a ready state, submits thread2 to processor 0.
Your perception about how it works based on processor utilization shown in task manager is kinda of skewed. Multiple processor utilization issues are generally bound by the threads stalling for synchronization objects. I.e. there is lock being held on one thread for a resource required on the other, anything causing contention will limit CPU utilization across two cores.
Unless stalled by higher threads, Thread[0] will run on processor 0, Thread[1] on processor 1
If Foo1 calls or holds any synchronization objects for a chunk of memory, those two threads will be in constant contention and subsequently stalling until the contention is released.
There is one way you reach 50/50 processor utilization. An optimized MP/MC application will clear / reduce those contentions as well as define processor affinity for the threads which is where you will see closer to 100% utilization.
While games, including LFS, do usually have multiple threads created, about 99% of games today only use one thread to do anything meaningful in terms of cpu usage.
In case of LFS for example, there's 11 threads created for me. But if you'll look at the CPU time taken by those threads, you'll see that over 99% of the CPU time is used by only one thread. This one thread does the physics, graphics, sound, input, etc. one after another. With this kind of setup you are not going to get anything useful out of a multi-core/SMP/SMT system for the game alone. While that single thread is, by default, switching between the cores/processors by the windows scheduler it will still never be executing in both cores in parallel because it is only one thread.
For a game to take advantage of multi-core, you'd need to separate major chunks of the game. For example in LFS you could separate the physics code from the graphics code, or handle the physics of each car in their own thread. But coding this to work (well) in a game is rather difficult, especially if the engine was not originally designed with this in mind.
