Does enabling hyperthreading help with FSX? My computer has that capability but I do not have it enabled.

On my FSX machine, which has a P4 2.8GHZ HT, I get 100% use on the first processor (while it really isn't a seperate processor, to the OS it looks like it), and 20% usage on the second. I have seen other posts on here (and I believe from the ACES team) that the game was designed to specifically do that.So, if you have a HT proc, I would just try it and see if you get any benefit with FSX.

I have heard the exact same thing, 100/20 usage. While I myself don't have a multiple core processor, the technology is only now starting to come of age. I don't trust these video demos of technology I might add, for a few reasons.1) These demos tend to show off the technology at its finest.2) These demos were intentionally made to show how well it could run, without giving proper utilization of techniques and game coding. They are built from the ground up to LOOK amazing. This is why demos from ATI and NVidia tend to be amazing graphics wise, but have little to no actual replication on a "working" system under real loads.3) They are concept demos.While we all know that potentially things will improve, software developers have to play catch up and redesign how they code games. This means literally a shift in how things will be run business wise in some aspects as companies have been gears towards processing power (read, MHz). This is one of the main reasons I have not wasted my money on a dual core processor as of yet. Yes, I honestly do think it is a waste of money in some respects, as very FEW programs (games namely) utilize the cores as intended. Perhaps in the future, but until I see a time that it becomes mainstream and the bugs have been worked out, I won't bother. This is EXACTLY why I won't be a first generation purchaser of Vista and a DirectX10 card. Until the technology comes to fruition, we are wasting our money... and by the time they DO become mainstream and useful, your first generation cards/cpus will need upgrading anyways.I will tell you all what I have been telling everyone I have been building computers for in the last 3 years... Focus more on MHz then dual core CPUs. If the processor you want has a dual core WHILE having a high MHz value, then all the more better, but don't be sold on this technology just yet, especially if you plan to upgrade.We all want our games to run fast, but are we willing to look at it conservatively, or are we just willing to throw our money away at technology that has not yet been utilized properly? This alone is one reason why I am achieving phenomenal performance from FSX while only having an AMD 3500+. BTW, I think the same can be said about 64 bit technology...

SimFan71Very nicely put - I teach multi-threaded programming at a UK university and it is always interesting to watch students reactions when they first meet threads. I lot of their previous assumptions get thrown out the window. As you mention, it is all fine and well if you want to create multiple independent threads - this is very easy in most programming languages and I am very sure that ACES can do this stuff in their sleep. The trouble comes with managing the interaction of threads such that they don't spend most of their time 'busy waiting'. Any threaded system which has chains (or even worse, loops) of interdependencies can turn into a can of worms if you are not very careful. Flight sims are just the kind of programs where this can happen and I don't blame ACES one bit for being careful about this. By its very nature, FSX strikes me as a very difficult program to efficiently utlize multiple processors except for some obvious areas like setting up textures. FSX already caters for this since it gives you the results of what its got, even if its not completely finished sorting things out (i.e. the blurries). I suspect ACES have been very practical about what they have done regarding threads - I personally prefer to have FSX now rather wait another couple of years for a fully threaded and multicore compliant version. I get 2 more years of amusement than I would have got. I guess if I had a huge number of payware add-ons for FS9 then things might be different but if that's the situation you are in and you think FS9 is better, that's fine. I guess the frustration here is you might like things to have 'moved on' from the position you are in (with the add ons) but I think the vast majority of users are not like that (sampling from this forum would not give a representative example).What I find interesting here is that very few people seem to be wishing there were faster processors and have just gone with the trend for more cores. IMHO, we are actually at a fairly fundamental shift in focus for processors. People have got used to Moore's law and now expect the increased speed associated with it to be the norm. At present the only way AMD/Intel can meet that expectation (which they need to so that they can sell more processors), is to introduce more cores. This is not the same step in performance that we have got used to and will not provide the results people might be expecting - unless you are running a server farm / grid processing system, it which case it's great. For my research work in genetic algorithms and evolutionary computation, multi-core systems available across a local grid are great news - each of my processing jobs are relatively small and independent, it's just that I start hundreds of them. We have labs full of multicore PCs and I can send jobs to all them without having to deal with interactions.I think, at the very least, there is going to be a slow down for a year or two as software struggles to catch up with the new direction hardware is taking. I also suspect that Moore's law might need a bit of a clarification for some people. He didn't say anything about a doubling in speed, he just predicted that transistors would double every 2 years. Doubling the number of cores every two years kind of keeps you in the running but the associated increase in speed we have got used to doesn't necessarily follow, at least with a lot of the software that's currently out there.Just my pennies worth, I shall now keep a low profile in case I get singed by the flames that will probably come my way...Edit: Just noticed Valkyrie posted while I was writing this - I couldn't agree with you more ;)

LOL, indeed CocoLoco. Gamers need to be more informed if they wish to really get their games to perform as they intend. Things as you have said are changing, understandably so. What frustrates me is how this technology is being marketed towards us gamers. While I cannot deny the benefits of algorithms and other various applications that can utilize multiple cores effectively, this kind of utilization simply does not exist in the gaming world as of present.So, to all you people looking to purchase a new quad core processor hoping for improved framerates in video games... dream on. In reality, these lower clock setting processors may DEGRADE your performance in gaming. Right now, my money is on the processor that has the highest MHz value (or for that matter how many processes can be actually transmitted, much like AMD has kept up with Pentium but by having lower clock speeds...). Go for speed, RAM, Video Cards, fast hard drives and good motherboards. The money spent on a quad core, which will probably require an upgrade in a few years anyhow would be better spent making your system work good NOW. We ALWAYS invest in technologies that could help us in the future, but the future always requires a new upgrade. One of the FEW ventures into new technologies that has paid off for me was the purchase of PCI-E technology when it first came to the market. It promised a lot, and delivered... however my first PCI-E motherboard was 8x, so even after investing in the motherboard I found I needed an upgrade 2 years later anyways to support my new GPU so it didn't bottleneck it.Anyways, I have been a bit long winded. I just don't want to see a thread that says "I purchased a new quad core processor and FSX STILL SUCKS! I HATE ACES AND FSX!" You are only shooting yourself in the foot.

>Unfortunately, creating games to run on multiple>cores/processors is very tricky, since the problem is that>everything in games relies on every other thing. Not for FS. If you seperate FS into ATC, Simulation, Rendering, etc, data is only going one way most of the time. From simulation (postion data) to ATC, from simulation (position data & player instrument data) to rendering. ATC can send commands to AI (simulation), but that doesn't require a real time response. Does a real pilot do what ATC tells him/her in miniseconds? > Sure you can write the AI to run on one>core, the graphics engne to run on another, the bit that>updates the instruments and handles the flight model (say in>FSX), but the catch is they interact, and since they are>inherently dependant on each other, running them in seperate>threads/processes gets difficult, because everytime one needs>some information from the other, the particular thread>requiring the information has to go into a wait state, thus>halting it's processing until the other thread is ready. This>is called contention (or at University what they called the>class consumer-producer problem!). It's a real problem on>real time systems, and requires some very smart programming to>optimize it to reduce wait times on threads. Too many wait>conditions would actually degrade performance!I don't see any of those subsystems in FSX can content with one another. > Games are a>problem, since they inherently require everything to run>togethor, that is update completely each program cycle (in>other words, it's what we call a serial application).>Yes. Games are a problem, but not flight simulation. Flight simulation involves total discret independent systems. The same thing cannot be said about a FPS game.At this point, I think the core of FSx is made so unstructured all these years that it is almost imposible to adopt it for a multiprocessing (note: I said multiprocessing, not multiprocessor) environment. Only a complete rewrite can save the day. Well, who's willing the put up the money.

Hi BOPrey,I agree with you that some things don't need to be perfectly real time, like ATC, and texture loading could be done by prefetching data so it's ready at the time it's required (of course at the expense of memory) - but real time programming is a very complex issue, and the catch is, when things get out of sync (say you are prefetching textures, and it gets behind) - then you are in deadlock. However you do it there will be interactions to some extent.Yes, I think certain things in FS do lend themselves to multi-threaded programming more than in other types of games, and I 100% agree with your comment that FS having been built on an ever expanding platform over it's many years would take a lot to fix, basically close to a total rewrite - and yep, it all comes down to man hours which equals $!

Even if FSX multi-threaded things like ATC, how in the world would we see a performance increase? It really wouldn't be much different IMO than what we currently have. It comes down to core coding like how many buildings you have on the screen at once.

CocoLoco Thanks for the reply - and I totally agree, it is easy to open a can of worms trying to make any game run in a multi-threaded environment, especially something complex as FSX.There are definately certain areas it 'could' be done, but the problem with a program like FSX is, when you do get a deadlock, and the sim hangs for a few seconds that kind of spoils the experience, and lets face it, there's enough complaints about that already!In business applications, the examples you give work great, especially for things like billing systems that handle things in batches, and even web farms, where we can run many servers and use load balancing - but even then, certain things deadlock, since ultimately it all goes to the same database! Enterprise systems sure get fun, why I love it! LOL :)Ah yes Moore's law - that really says it perfectly, I've done chip level design (I'm an electronics engineer too - in fact I went to University in the UK, that's where I'm originally from, moved to the USA about 8 1/2 years ago) and it's true, while the number of transistors doubles, the speed increase is usually far short of that, and made worse in the light of the way much software is written!I don't want this to turn into a flaming match either (which I don't think it is doing, been a good discussion so far) - I just more wanted to make people aware that to really make a game like FSX really benefit from the power of multiple-core processors isn't as easy as just splitting it up a bit!

Exactly - ATC is such a small part of FSX in terms of the processing required to run it, the benefit really wouldn't be noticable (might even be a bit worse).And I'm with you, really most of the performance comes down to how many 'objects' the simulation is handling - for many the bottlenecks are not enough RAM or not having a good enough graphics card (which is sort of my limiting factor, since I only have 128MB or RAM on it).

>Hi BOPrey,>>I agree with you that some things don't need to be perfectly>real time, like ATC, and texture loading could be done by>prefetching data so it's ready at the time it's required (of>course at the expense of memory) - but real time programming>is a very complex issue, and the catch is, when things get out>of sync (say you are prefetching textures, and it gets behind)>- then you are in deadlock. FSX current takes care of this with blurries. No dead lock.> However you do it there will be>interactions to some extent.>In the case of flight simulation, it will be minimal.

Yes, but it does it all in one process - deadlocks only occur when you start trying to split it into lots of discrete parts with all the inter-process communications that involves.

But think of the ATC you could have with a whole core devoted to it! That would be amazing. Of course, MS is "going another direction" and ATC probably won't be updated at all in the future...Take care,--Tom GibsonCal Classic Propliner Page: http://www.calclassic.comFreeflight Design Shop: http://www.freeflightdesign.comDrop by! ___x_x_(")_x_x___

Building/tree/autogen objects can be prepared seperately and independently. By the time that it needs to put a frame on screen, if any of those threads didn't finish preparing their respective object, so be it. There will be one less building/tree/autogen in the scene. FSx is already doing that to textures for all these years. If you move too fast or you have a slow machine, there will be blurries.

That is EXACTLY the problem BO. These issues require other processes to be completed for their information, which means spreading the information over several cores rather than independently setting their parameters. Buildings on screen is dictated by location, terrain, speed, elevation and a plethora of other nuances in the coding and simulation environment. This IS the hard part!