Well how would two cpu share the same ram then? Wouldn't they eventually step over each other?

Huh? No, why would they? CPU is not "using" the RAM, as I understand it... data is stored in the RAM that CPU is calling and storing to, simply put. And why would two CPUs get the same set of instructions to execute? Kind of defeats the purpose, now doesn't it?

No not really what if the texture thread loaded up a texture, and the render thread pushed it to the video card... two different cpus...working with the same exact data. How does CPU 1 know when CPU 2 is done loading the texture so CPU1 can copy it to the GPU? Don't worry these are all somewhat rhetorical questions I don't really expect you to have an answer to any of them, but I will say this.... it's memory issues like these that prevent multi-threading and multi-processing from happening in the first place. Otherwise every program would run on multiple processors effectively, but since they don't people just write applications to run on one CPU. Even though CPU 1 and CPU 2 do communicate and do this wonderful dance you don't want CPU1 and CPU2 communicating about what to do with 500+mb worth of textures and Autogen...you're shuffling around too much data and not letting anything render at that point

I don't want to get kicked in my arse for not reading through the whole thread, but here are some corrections of some posts I did read:1) FSX can address max. of 4GB of virtual space - this means the memory space FSX is working within2) Virtual space has nothing directly to do with physical memory you have in your computer3) NOT every 32bit application is capable of addressing 4GB of RAM, only if it has been programmed to4) You will NOT see an OOM on the 64bit system with 2GB of physical RAM and enabled swap file, not more often than you would see it on the 6GB system

Thanks Word Not Allowed.. I don't feel so alone anymore

Still bitter about the $600 you wasted on the 580?

Are you talking to me?

FSX, like any other 32-bit application, is capable of addressing a maximum of 4GB of memory. However, it's also possible that the need will ever arise for FSX to address this much memory. You have to remember 4GB is just a limit and FSX will not use 4GB all of the time. It may not ever use anywhere near that, though I don't have any figures as to how much RAM FSX actually uses on average, perhaps Chris B. can provide more info on that...

Sorry, when I posted earlier, I meant FSX uses an average of about 2.75GBy RAM, not a max of that.

Despite that my system is getting somehow good performance

If this is true, then there is no need to upgrade anything.

Buy yourself 6Gb of memory.I had 4Gb also and when flying with London VFR I ahd just 650mb left and my system started to "shiver"....After adding 2Gb extra the issue was gone.

Well how would two cpu share the same ram then? Wouldn't they eventually step over each other?

The OS Kernel is a prime example of memory sharing, as there is only one OS Kernel spanning all the CPUs. The kernel code uses spin locks to lock-out other threads from critical code that needs to be single-threaded, and semaphores to coordinate execution between threads.The CPU hardware also contributes, automatically flushing its caches when one CPU writes data to a memory location currently being looked at by another CPU.Cheers,- jahman.

Buy yourself 6Gb of memory.I had 4Gb also and when flying with London VFR I ahd just 650mb left and my system started to "shiver"....After adding 2Gb extra the issue was gone.

With his system being dual channel, he would be best to upgrade to 8GBy and maintain the dual channel memory, instead of dropping to single channel.

The OS Kernel is a prime example of memory sharing, as there is only one OS Kernel spanning all the CPUs. The kernel code uses spin locks to lock-out other threads from critical code that needs to be single-threaded, and semaphores to coordinate execution between threads.The CPU hardware also contributes, automatically flushing its caches when one CPU writes data to a memory location currently being looked at by another CPU.

True enough, but all this coordination brings in timing issues. If a critical section of memory is already locked by thread 1, then thread 2 will also try to lock it but it will be denied access. So now that thread 2 is blocked waiting and doing nothing, eventually thread 1 lets go of the memory lock, but thread 2 really has no way of knowing the memory is now available so it waits until the OS says go. So the real question is, if thread 2 is going to be waiting is it worth bothering to write threaded code in the first place. When you look at what's going on with SP2 the texture loader is really acting as a go between or a buffer for the harddrive. You'll see it launch 50 threads to load 50 different files, and each time it will communicate back to FSX that it is finished. All combined it's an improvement, but it's still taking the hits in performance any other threaded code would, just the good outweighs the bad..

With his system being dual channel, he would be best to upgrade to 8GBy and maintain the dual channel memory, instead of dropping to single channel.

Well, I´ll probably do this. I´ve just read through my MOBO user guide. It says, that it supports up to 16 GB of 1066Mhz DDR2 memory. Other frequencies supported are 800Mhz and 667 Mhz. How can I check, what frequency I´m actually running?

www.cpuid.comUnder memory you can read out the base clock, then multiply with FSB.

www.cpuid.comUnder memory you can read out the base clock, then multiply with FSB.

Thanks!Just downloaded CPU-Z, but I don´t knwo which data is the right one. In the "memory" section is written, that I do have 4096 MB RAM DDR2. Below that there is a row called "DRAM Frecquency" which is 480 Mhz. If I multiply this with my FSB of 1600Mhz, I get 768000. This can´t be right, I think.But there is annother section, called "SPD": There are some rows named "JEDEC#1", "JEDE#2" and "JEDEC#3" with also some MHz deteils below.Now I´m somehow confused, cause I don´t knwo which is the right data.

True enough, but all this coordination brings in timing issues. If a critical section of memory is already locked by thread 1, then thread 2 will also try to lock it but it will be denied access. So now that thread 2 is blocked waiting and doing nothing, eventually thread 1 lets go of the memory lock, but thread 2 really has no way of knowing the memory is now available so it waits until the OS says go. So the real question is, if thread 2 is going to be waiting is it worth bothering to write threaded code in the first place. When you look at what's going on with SP2 the texture loader is really acting as a go between or a buffer for the harddrive. You'll see it launch 50 threads to load 50 different files, and each time it will communicate back to FSX that it is finished. All combined it's an improvement, but it's still taking the hits in performance any other threaded code would, just the good outweighs the bad.

The answer is adding CPUs for extra threads adds performance only up to a point, after that the extra CPUs add only more heat (good in winter, though: "Honey, its chilly in here. Why don't you go simming for a few hours?") Due to the overhead you mention, the rule is each additional CPU adds say 90% of the previous CPU's performance, so in this case CPU1 would be 100%, 2-90%, 3-81%, 4-73%, 5-66% and 6-59%. CPU6 is now just barely over 1/2 the performance of CPU1 and contributes only 59% / (100% + 90% + 81% + 73% + 66% + 59%) = 69% / 469% = 13% of the total CPU horsepower (but at 100% the heat output of CPU1!) But perhaps the 90% figure is too generous, so we try 80%: CPU1 would be 100%, 2-80%, 3-64%, 4-51%, 5-41% and 6-33%. Now CPU6 falls to 1/3 of CPU1 and only 33% / (100% + 80% + 64% + 51% + 41% + 33%) = 33% / 369% = 9%, anemic at best, but again generates 100% the heat of CPU1. As you can see, total system performance is exponentially dependent on, and very sensitive to, the efficiency of the nth CPU. In this regard the efficiency (degree of thread concurrency) of the OS kernel plays a huge factor in determining the efficiency of the nth CPU and thus of the whole system. The other factor is the hardware itself, specifically the architecture of the caches, which is one of the reasons why CPU performance increases clock-for-clock from one microarchitecture to the next (degree of instruction pipelining and efficiency in branch prediction are the other reasons.) So a new generation is born: Nehalem is dead, long live Sandy Bridge!While the preceding analyzes the performance benefits of multiple CPUs for program software (as in the FSX flight dynamics engine), the situation for graphics is wildly different because threads can and do run independently, literally over thousands of "cores" essentially without the penalty of synchronising overhead. As GPU cores become ever smarter, with each new version of DirectX each new version of MS Flight will be able to transfer more and more tasks from the relatively parrallel-inefficient CPU to the massively parallel-efficient GPU. The future never looked better! :-)Cheers,- jahman.

The answer is adding CPUs for extra threads adds performance only up to a point, after that the extra CPUs add only more heat (good in winter, though: "Honey, its chilly in here. Why don't you go simming for a few hours?") Due to the overhead you mention, the rule is each additional CPU adds say 90% of the previous CPU's performance, so in this case CPU1 would be 100%, 2-90%, 3-81%, 4-73%, 5-66% and 6-59%. CPU6 is now just barely over 1/2 the performance of CPU1 and contributes only 59% / (100% + 90% + 81% + 73% + 66% + 59%) = 69% / 469% = 13% of the total CPU horsepower (but at 100% the heat output of CPU1!) But perhaps the 90% figure is too generous, so we try 80%: CPU1 would be 100%, 2-80%, 3-64%, 4-51%, 5-41% and 6-33%. Now CPU6 falls to 1/3 of CPU1 and only 33% / (100% + 80% + 64% + 51% + 41% + 33%) = 33% / 369% = 9%, anemic at best, but again generates 100% the heat of CPU1. As you can see, total system performance is exponentially dependent on, and very sensitive to, the efficiency of the nth CPU. In this regard the efficiency (degree of thread concurrency) of the OS kernel plays a huge factor in determining the efficiency of the nth CPU and thus of the whole system. The other factor is the hardware itself, specifically the architecture of the caches, which is one of the reasons why CPU performance increases clock-for-clock from one microarchitecture to the next (degree of instruction pipelining and efficiency in branch prediction are the other reasons.) So a new generation is born: Nehalem is dead, long live Sandy Bridge!While the preceding analyzes the performance benefits of multiple CPUs for program software (as in the FSX flight dynamics engine), the situation for graphics is wildly different because threads can and do run independently, literally over thousands of "cores" essentially without the penalty of synchronising overhead. As GPU cores become ever smarter, with each new version of DirectX each new version of MS Flight will be able to transfer more and more tasks from the relatively parrallel-inefficient CPU to the massively parallel-efficient GPU. The future never looked better! :-)Cheers,- jahman.

jahman - What the hell are you talking about? Does this have any in common with the topic?I´m sure that you have a certain knowledge about this CPU things, but my intension, when I´ve started this topic was a slightly other one. Thanks for giving me and us all here a tuition about the CPU, but please check my last post, I think you can answer is easily. ;-)

Thanks!Just downloaded CPU-Z, but I don´t knwo which data is the right one. In the "memory" section is written, that I do have 4096 MB RAM DDR2. Below that there is a row called "DRAM Frecquency" which is 480 Mhz. If I multiply this with my FSB of 1600Mhz, I get 768000. This can´t be right, I think.But there is annother section, called "SPD": There are some rows named "JEDEC#1", "JEDE#2" and "JEDEC#3" with also some MHz deteils below.Now I´m somehow confused, cause I don´t knwo which is the right data.

Post a screenshot of it.But if you say it's 480, then it's probably at 960mhz. And FSB is not 1600. :-)But to be sure, post a shot of it.