does multi core do anything for FS2004 performance?

[maniaspeed]

I'm not all that up to date on the pros and cons of multi core processors and am wondering if there is any benefit in using them with non-multicore optimised software, such as FS2004.

It's my understanding that FS is usually limited by CPU rather than graphics for performance, but it seems like the individual core speeds in today's mutlicore rigs haven't really gone much farther than the 3.x Ghz of the last P4 single processor systems. Also it seems like most of the systems I see, either dual or quad core, have individual processor speeds of 2.x Ghz.

So if I were to use FS2004 on one of these multi core 2.xGhz systems would it basically be stuck on only using one core - and if so would that mean that it would actually run slower than an older single core 3.2x system?

Also, what about 64 bit operating systems - does that pose a problem for FS2004? I know that 64 bit allows more RAM, but I'm thinking any benefit of that would depend on what the answer to the multi core question is. Just curious if it would give FS a new kick in the pants or if it just wastes the additional processing potential.

[ubersu]

FS9 doesn't know how to make use of multi-core processors. However, If you run addons that run as separate processes you can force them to one of the processors that isn't running FS9 and unload the FS processor a bit. This may or may not be a good thing depending on scheduling, cross process communications and synchronization, etc.

In general, the faster a processor runs the happier FS is - I run a Core2 Extreme system at 3GHz and have split the processes across three cores. In truth, there is no particular perceived increase over running them in a single processor of the same speed, except when ActiveSky is doing metar decoding and can run asynchronously.

64 bit OSs don't help FS9 unless the exe is patched to allow the use of up to 3GBytes of memory rather than be limited to two GBytes. You won't see a speed increase, but memory is used better.

DJ

[maniaspeed]

Thanks for the response. The addons I have are Ultimate Terrain USA, Ground Environment textures, some FSGenesis mesh and just addon aircraft. I don't think any of that runs as a separate process.

So it kind of sounds like in order to not lose any performance I'd have to get a multi core system with an individual core speed equal to what I currently have (P4 3.2).

Also, I wasn't aware FS9 was limited to 2GB ram. I actually have 3GB now. Is there an available configuration change that will allow it to work with the additional ram or was that a theoretical change?

[JSkorna]

Hi,

FS is not limited by RAM, but your 32 bit Operating System is. You need to use the 3GB switch with a 32 bit OS.

[arcueil]

Interesting but what do you mean by "switch"? I also have 3GB of RAM on my Core2 Duo, 32-bit OS. Does that mean that FS9 (and other apps) will only use 2GB of RAM unless I turn on some sort of button to tell my computer to use 3?

[azur]

I'm not all that up to date on the pros and cons of multi core processors and am wondering if there is any benefit in using them with non-multicore optimised software, such as FS2004.

<snip>

So if I were to use FS2004 on one of these multi core 2.xGhz systems would it basically be stuck on only using one core - and if so would that mean that it would actually run slower than an older single core 3.2x system?

Yes, and no. Remember - FS2004 will never be the only process running. You'll have countless system processes, anti-virus/firewall, firefox, addons like active sky, etc.

If you have a single core, all these applications are effectively competing for that single core's time. While Windows should schedule FS2004 well, the other processes still need to receive processor time eventually.

On the other hand, if you have a multiple core processor there's far less competition as multiple processes can run simultaneously, or one process can even be given a whole core while the others use the second core.

Further, there's more to a processor than just clock frequency so some of the newer dual cores will outperform an older processor with a higher clock frequency.

[ubersu]

All 32 bit applications are limited to a 2GByte address space unless compiled with a flag that makes them 'large address aware'. That flag allows them to use as much as 3GBytes of address space if the OS is told at boot time to allocate it if requested. FS was not compiled with the flag so there are several little patch programs on the web that will patch in the flag. Once that is done, you must modify the boot.ini file by adding two additonal flags to the 'operating systems' entry - /3GB /userva=2560. The userva entry is typical for a 512MByte graphics card system.

Some caveats:
Don't confuse virtual address space with physical ram; the two have nothing to do with each other - this flag works fine on systems with only 2GBytes of ram as well as larger.
AES will bomb if the /3GByte switch is used.
Other modules/programs may have problems with the flag, so it is a good idea to back up the original boot.ini file and use it when not running FS.
The flag will not make FS run faster - it will, however, put an end to most out of memory exceptions.

DJ

[arcueil]

I'm not having any kind of FS9 memory problem (or with any other program), so I'm interested in this simply from the tech point of view. Am I understanding this correctly though? Does a system with 3GB of RAM only use 2GB while the remaining 1GB does absolutely nothing (regardless of what 32-bit programs one is running) unless one tells the computer to do otherwise??? That sounds crazy, especially since most people would not even know about this. If this is true, then practically everyone with a computer with more than 2GB of RAM are just not using the resourses they actually have!

[ubersu]

The OS will load in the upper memory area - XP 32 and Vista 32 allow the use of 4GBytes of physical memory to load applications; any more is a waste.

Look, this isn't as simple as it may seem. Every running application on a Win32 based system is allowed a 2GByte virtual memory space (or address space - the terms are interchangeable) and is allocated a block of physical memory whose size will vary depending on system loading and numerous other fairly arcane factors- that block is typically much smaller since very few apps really require 2GBytes at all times and all procs running in the system require at least some physical memory to run at all. If an app requires more physical memory than the system is able to allocate at any moment, the paging file is used to free up ram to the extent possible. The 2GByte virtual address space is the range of addresses that the program can possibly get to - regardless of how much physical ram is available. If the OS detects an attempt by the program to get memory that it knows is outside of that range you get the infamous 'Out of Memory' error even if the physical ram is available to satisfy that request. There it is. Just to make it all more interesting, the modules (dlls) that are loaded by a program also run in its address space unless they are system modules like the kernel.

I can't possibly explain all of the intricacies of memory allocation in windows (or any other modern operating system) in the space we have here. I suggest that if you are really interested you go to the MS site and use the MSDN library - take a look at the /3GB switch article first and then browse around. If you are really, really, interested there are several books on Win32 internals that are worth a read.

DJ

[arcueil]

I understand now. Thanks for that info. It's highly unlikely that under normal circumstances one would need to use the 3GB switch, even for FS purposes (i.e. the patch that was mentioned); page filing would usually do the trick, and even then it's probably not used much, unless one has a lot of other processes going, a low memory computer, a scanner decided to fire up in the middle of a flight or a combination of those factors.