>>FS9 is multi-threaded,>>No it is not.>Yes, it is.>> In an HT processor, there are not two physical CPUs on>>the chip, but rather a couple sets of registers that share>the>>CPU circuitry and are triggered on opposite edges of the>clock>>cycle.>>It is not quite that simple. They share the same execution>core. As a single thread can't keep the entire execution core>filled allowing a second thread to use remaining time slots in>the execution core can give a higher performace (or less,>depending on the two treads). What did you think I meant when I said they share the CPU circuitry????>>> But one problem with HT is that the multiple virtual>>CPUs are still sharing a common cache, which quite often>>creates bottlenecks that deny any performance increase.>>Not to mention - they share the entire CPU core.Yeah, sure wish I'd thought to mention that they share the same CPU circuitry.>>And worse, if you have any application that needs to call in>>the 16-bit subsystem (ntvdm), like the RealityXP Garmin nav>>units as a good example, then you can really see performance>>tank as ntvdm does not necessarily play well with other>>processes in a multithreaded environment.>>Obviously outdated technology will not perform optimal. You>have to be pretty stupid to do anything in 16 bit these days.Stupid or not, the Garmin 430/530 trainers, upon which the RealityXP Garmins depend, are 16-bit programs. Lots of FS users use it...and for all of us that do, it's an issue.Bob ScottATP IMEL Gulfstream II-III-IV-V L-300Santiago de Chile

Actually, the latest v5.x of the Reality XP GNS is Hyper Threading aware and do manages the HT CPU in order to not have any HT issue.In any case, most users have noted that disabling HT in the BIOS (or at the FS9 exe level), shows a greater overall FS9 performance regardless of the Reality XP GNS consideration.Hope this helps!

While I'm a big fan of AMD, don't discount Intel in the next round. The Core E series (what

>>>FS9 is multi-threaded,>>>>No it is not.>>>>Yes, it is.Sorry, I was not precise enough here. It might create multiple threads, but the main game loop is one thread only (using fibers) and there are hence not any noticable performance gain from multiple CPUs. Hence I refer to this as a single threaded application because this is how it behaves and is programmed. We might not agree with what we call multi-threaded/single threaded and that is fine.>>>> In an HT processor, there are not two physical CPUs on>>>the chip, but rather a couple sets of registers that share>>the>>>CPU circuitry and are triggered on opposite edges of the>>clock>>>cycle.>>>>It is not quite that simple. They share the same execution>>core. As a single thread can't keep the entire execution>core>>filled allowing a second thread to use remaining time slots>in>>the execution core can give a higher performace (or less,>>depending on the two treads). >>What did you think I meant when I said they share the CPU>circuitry????The way I read your comment was as if you thought that for each clock cycle the processor would first process an instruction from thread 1, then one from thread 2 - which is not how HT works as there quite simply wouldn't be any noticable performance gain from this. HT is about executing instructions from the two threads simultanious hence using a higher percentage of the execution pipelins at any given moment. It is still not clear to me if you are aware of this.>>>>>> But one problem with HT is that the multiple virtual>>>CPUs are still sharing a common cache, which quite often>>>creates bottlenecks that deny any performance increase.>>>>Not to mention - they share the entire CPU core.>>Yeah, sure wish I'd thought to mention that they share the>same CPU circuitry.Again, the way I read your comment was as if the processor simply alternates which thread to execute the next instruction from, and hence the shared cache was the main problem. Sorry I did not pay enough attention to you mentioning "one problem".>>>>>And worse, if you have any application that needs to call>in>>>the 16-bit subsystem (ntvdm), like the RealityXP Garmin nav>>>units as a good example, then you can really see>performance>>>tank as ntvdm does not necessarily play well with other>>>processes in a multithreaded environment.>>>>Obviously outdated technology will not perform optimal. You>>have to be pretty stupid to do anything in 16 bit these>days.>>>Stupid or not, the Garmin 430/530 trainers, upon which the>RealityXP Garmins depend, are 16-bit programs. Lots of FS>users use it...and for all of us that do, it's an issue.I did not say it wasn't used. I said you would be stupid to use it (I think of developing something using 16 bit, not users of their products). Obviously as a user you should take this into consideration when buying a product (again, I am not saying you should NOT buy it, just consider it will not perform optimal), but I somehow doubt a manufacturer would remember to use the "Outdated technoligy inside" sticker on the box. :)