Jump to content

Sign in to follow this  
Mace

FSX Design Priorities Flawed

Recommended Posts

Guest AirbusFlyer

There have been many threads regarding the poor framerates of FSX, as well as a few concerning dual core CPUs and the promises of DX10. I have read them all, including tdragger's now famous blog regarding (the lack of) dual-core support.Although I respect their accomplishments, I am shocked that the ACES team's design priorities did not include multi-core support. If the only improvement in FSX over fs9 was support for multiple cores, FS flyers would have been overjoyed. I suspect that if the sim had two main threads (simulation and display), FSX could have gained as much as a factor of 2 improvement in framerates (depending on GPU speed).Yes, it would not have had all of the new eyecandy that MS has provided (that most current and future CPUs can't handle anyway). But third-party developers would have had a field-day with the extra headroom available to them. And fs11 could have followed with DX10 support and all of the eyecandy (and more) that is currently coded into FSX.But without this architecture change, FS is likely at a dead-end. Unless a miracle happens (knock wood), CPUs will not be appreciably faster in the near future. And third party developers will be stymied because their addons will further reduce framerates and increase user dissatisfaction.Although I will certainly buy FSX (have it on preorder), I am truly disappointed with this development.Frans Kes

Share this post


Link to post
Share on other sites
Guest AirbusFlyer

Considering that the usage of the second core is barely noticeable, the ACES response seems to reinforce the concept that multi-core usage was not designed into FSX. It rather seems an after-thought during the code optimization phase.Frans Kes

Share this post


Link to post
Share on other sites
Guest nem

>for multiple cores, FS flyers would have been overjoyed. I>suspect that if the sim had two main threads (simulation and>display), FSX could have gained as much as a factor of 2>improvement in framerates (depending on GPU speed).There already is a dedicated core for "display". You even mention it. (Hint: it's the third acronym in the quote above.)Regards,http://www.bremmekamp.com/img/misc/avsim.jpg

Share this post


Link to post
Share on other sites

>There have been many threads regarding the poor framerates of>FSX, as well as a few concerning dual core CPUs and the>promises of DX10. I have read them all, including tdragger's>now famous blog regarding (the lack of) dual-core support.>>Although I respect their accomplishments, I am shocked that>the ACES team's design priorities did not include multi-core>support. If the only improvement in FSX over fs9 was support>for multiple cores, FS flyers would have been overjoyed. I>suspect that if the sim had two main threads (simulation and>display), FSX could have gained as much as a factor of 2>improvement in framerates (depending on GPU speed).Complete and utter conjecture. Are you a game programmer?I've compared the single and dual core (and the 32 and 64 bit) versions of Far Cry on my machine and you guys are just massively overestimating how much of a performance gain is actually to be had from this stuff.You can't just split a program into "threads for simulation and display" as if it's some simple task - there are only certain types of processes within the code that will benefit from multi-threading. You can't just take any piece of code and go "run on two CPUs" and have it work. A very simple example: process X running in code feeds its output into process Y as its input variable - what happens if you put this sort of sequential processing on two different cores but then X finishes before Y needs it or vice versa? Now you're actually slowing things down by having things sitting there idle.People really need to start trusting what the ACES team posts - a new version of FS is never going to run at a high framerate maxed-out on current hardware at the time of release. It was the same for every single previous version and FSX is no different. If there was a way to do that's so easy that armchair developers on AVSIM have it all figured out, don't you think they'd have done it already?

Share this post


Link to post
Share on other sites
Guest SilverCircle

Sorry, but...It seems you don't have the slightest idea of how complex these things can be from the programmers point of view. Multithreading and all its side effects is always one of the most complex things when writing good software and its even harder when developing a game or other application which MUST (or at least, SHOULD) deliver steady performance, at least in one of its threads (the thread which does all the rendering and is responsible for the visible frame rate).Read the thread which was posted here in #1 reply as this has some very good points and explains quite nicely, why a dualcore CPU won't just magically "double your frame rate".I'am sure that the devs have taken multithreading into account where it does make sense and maybe there is room for future improvements. But saying they didn't care is just plain wrong.BTW: There is no such thing like "dual core support". Its just a matter of writing robust multithreaded code w/o screwing up with the overhead needed for synchronization and other evil things. This sounds simple, but can really give you a big headache.The rest will be done by the operating system as its job is to distribute the load among the available resources.

Share this post


Link to post
Share on other sites
Guest JohnEGPF

I,m no programmer but Why Have Intel and AMD invested in Dual core technology if it brings little to the table performance wise?.Just one point when I bought FS9 at time of release I got single Digit FPS on my mid range AMD PC, the next week I upgraded my PC to a new shiny Northwood CPU@3 gig I at least doubled the performance in FS9..still using the same PC today ( apart from the GPU).Times have changed,can I do the same for FSX next week?Will the new Dual core CPU's say with a 7900GT let me spend my way to double FPS increase? please say yes:). I'm not blaming ACES or MS ( FSX is Probably the biggest change graphics and sound wise I have seen over the years, the work involved especially in composing and making the new 1M textures fit and look right must have been immense ,a true work of art). Perhaps Dual core can be utilized more in the future or DX10 will come charging over the hill to save us.. exciting times:).John

Share this post


Link to post
Share on other sites

>I,m no programmer but Why Have Intel and AMD invested in Dual>core technology if it brings little to the table performance>wise?.>Because AMD and Intel have "hit a wall" where with current manufacturing processes, (90nm, 65 nm, etc.) you can only clock the chip so high before failure and heat bring you down.The solution? Put two cores on one die. Put four cores on one die.Until there is some major advance in architecture, or a major change in the way chips are made (lower process, or even radical developments like photronic processors, or laser processors) you will NOT see any major raw speed improvements in CPU's. This is the reality we face for the next 1.5 to 2 years. You'll see speedier cpus due to architecture (mem bus, cores, etc.), but not raw speed.RhettAMD 3700+, eVGA 7800GT 256, ASUS A8N-E, PC Power 510 SLI, 2 GB Corsair XMS 3-3-3-8, etc. etc.

Share this post


Link to post
Share on other sites
Guest SilverCircle

>I,m no programmer but Why Have Intel and AMD invested in Dual>core technology if it brings little to the table performance>wise?.Well, who says it doesn't?It really depends on the task. If you have 2 separate processes or threads which can do their jobs independently from each other, a dual core (or dual CPU) system will give you (almost) factor 2.Many applications will benefit from multiple cpu cores. Image processing, sound processing, 3d rendering - all that stuff can benefit a lot, because it is possible to divide such a job into predefined sections and then use a single thread per task to do the job.All kind of server applications (web servers, database servers) are also good candidates for seeing huge improvments from multicore processors. Unfortunately, games are a different thing, because they are required to deliver steady performance (means: a constant framerate). Nobody really cares, when the thread #20 of a webserver needs 100 microseconds longer to server a request than the thread #10 needs to do the same job.But the renderer (the entity which renders the images of a game) runs in a single thread. It is basically a loop running forever and rendering a single image per pass and doing all the "gameflow" calculations required. In a multithreaded environment, the #1 rule is that you cannot assume anything. When you offload work to a second thread which may (or may not) run on a different cpu or core, you cannot assume that this thread will have finished its work (e.g. loading a set of textures) when your main thread has to render the next frame. Other processes running on the system can "steal" cpu time, low memory conditions could generate a lot of pagefaults which would in turn slow down the thread, another process may access the harddisk, slowing down I/O and many more things.So, a game can only offload low priority things, that is, things which would not hurt the gameflow when they complete later than they actually should. It's simply not possible to divide that running games into independent sections and let each of these sections run on a single cpu core.The "blurries" are a good example what happens when the background thread was not able to complete its job in time. It simply means, that it wasn't able to load the hires textures needed by the main thread to render the frame in all its glory, so the renderer will use lower res textures. It's annoying and somewhat disturbing, but it's not going to destroy the game.If you offload other things (e.g. calculating flight paths of AI traffic) - things would be different. An AI airplane may just "disappear" or stop in front of you, because the background thread wasn't able to complete its job and calculate the new position for that plane, so the renderer would still have to use the old position.

Share this post


Link to post
Share on other sites
Guest 2002cbr600f4i

>>I,m no programmer but Why Have Intel and AMD invested in>Dual>>core technology if it brings little to the table>performance>>wise?.>>Well, who says it doesn't?>>It really depends on the task. If you have 2 separate>processes or threads which can do their jobs independently>from each other, a dual core (or dual CPU) system will give>you (almost) factor 2.>>Many applications will benefit from multiple cpu cores. Image>processing, sound processing, 3d rendering - all that stuff>can benefit a lot, because it is possible to divide such a job>into predefined sections and then use a single thread per task>to do the job.>>All kind of server applications (web servers, database>servers) are also good candidates for seeing huge improvments>from multicore processors. >>Unfortunately, games are a different thing, because they are>required to deliver steady performance (means: a constant>framerate). Nobody really cares, when the thread #20 of a>webserver needs 100 microseconds longer to server a request>than the thread #10 needs to do the same job.>>But the renderer (the entity which renders the images of a>game) runs in a single thread. It is basically a loop running>forever and rendering a single image per pass and doing all>the "gameflow" calculations required. >>In a multithreaded environment, the #1 rule is that you cannot>assume anything. When you offload work to a second thread>which may (or may not) run on a different cpu or core, you>cannot assume that this thread will have finished its work>(e.g. loading a set of textures) when your main thread has to>render the next frame. Other processes running on the system>can "steal" cpu time, low memory conditions could generate a>lot of pagefaults which would in turn slow down the thread,>another process may access the harddisk, slowing down I/O and>many more things.>>So, a game can only offload low priority things, that is,>things which would not hurt the gameflow when they complete>later than they actually should. It's simply not possible to>divide that running games into independent sections and let>each of these sections run on a single cpu core.>>The "blurries" are a good example what happens when the>background thread was not able to complete its job in time. It>simply means, that it wasn't able to load the hires textures>needed by the main thread to render the frame in all its>glory, so the renderer will use lower res textures. It's>annoying and somewhat disturbing, but it's not going to>destroy the game.>>If you offload other things (e.g. calculating flight paths of>AI traffic) - things would be different. An AI airplane may>just "disappear" or stop in front of you, because the>background thread wasn't able to complete its job and>calculate the new position for that plane, so the renderer>would still have to use the old position.Also a programmer here... (Java primarily...) I write multithreaded code all the time. And everything you said here is certainly true. Writing multithreaded code IS difficult. Debugging it is even MORE difficult. Most importantly, the problem that you're coding a solution to must be something that can work in a highly discrete parallel nature to really take advantage of multithreaded approaches. Also, as was stated earlier, the x86 processor market really has hit a bit of a wall. The "free ride" of quick easy improvements to x86 processors are over. We saw a period of explosive performance growth between 1990 and 2005 because of the combination of smaller fab processes, but more because of architectural improvements such as superscalar architectures, out of order execution, etc. All of those "easy" advances have been done. All the improvements on the books to the core designs will have small effects, not large ones like we've seen. Finally, consider this - Dual core processors have only been out for a little over a year. Now, if you take into account the number of PC's sold in the past 3 years (which would cover most of the machines people on this board use right now) only like 5% of what's out in the wild are dual core processors (that number will change drastically over the next 2 years, but right now, it's a small %.) As a game developer, are you going to taylor your game to be optimal on 5% of the population's machines or on the other 95%? And let's not forget, the more threads you add into a program that you try to run on a single core machine the more you're going to kill performance. You either code for single threaded or multithreaded. You don't get good performance on both.Personally, I expect to see FS11 to be highly multithreaded. But it certainly didn't make sense for ACES to go that route with FSX.--2002cbr600f4i

Share this post


Link to post
Share on other sites
Guest JohnEGPF

Would like to see some benchmark to see what impact dual core CPU's have in FSX, Maybe someone could disable one core and compare results if that's possible?.John

Share this post


Link to post
Share on other sites
Guest SilverCircle

>Would like to see some benchmark to see what impact dual core>CPU's have in FSX, Maybe someone could disable one core and>compare results if that's possible?.It almost certainly will. Not only because FSX itself will be able to distribute its load somewhat better, but also because other processes (and possibly add-ons) won't steal as much time from FS as they do on a single core CPU. The exact numbers are probably not easy to figure out, but I'am sure we are gonna learn them at some time. I would be suprised, if the actual improvement would be more than 20% though (if a 2nd core would improve it by more than 20%, then I would say the devs have done a very good job).I still think that the fastest single core CPU available may run it better than a moderate dual core processor, simply because such a processor will run the most important main thread faster. When I look at many FPS results for FS9, I always figure that my slightly more than 2 years old Northwood P4 EE can hold up surprisingly well (it still is one of the fastest single core pentiums).

Share this post


Link to post
Share on other sites

>>I,m no programmer but Why Have Intel and AMD invested in>Dual>>core technology if it brings little to the table>performance>>wise?.>>>Because AMD and Intel have "hit a wall" where with current>manufacturing processes, (90nm, 65 nm, etc.) you can only>clock the chip so high before failure and heat bring you>down.>>The solution? Put two cores on one die. Put four cores on>one die.>>Until there is some major advance in architecture, or a major>change in the way chips are made (lower process, or even>radical developments like photronic processors, or laser>processors) you will NOT see any major raw speed improvements>in CPU's. This is the reality we face for the next 1.5 to 2>years. You'll see speedier cpus due to architecture (mem bus,>cores, etc.), but not raw speed.>>>Rhett>>AMD 3700+, eVGA 7800GT 256, ASUS A8N-E, PC Power 510 SLI, 2 GB>Corsair XMS 3-3-3-8, etc. etc.so..Basically Flight sim has no hope of putting all the sliders to the right. Now or in the next few years?What about Piling on Addons like we did in FS9?:)

Share this post


Link to post
Share on other sites

>Would like to see some benchmark to see what impact dual core>CPU's have in FSX, Maybe someone could disable one core and>compare results if that's possible?.>>>John>>You can see it in the task manager... core 2 is used around,...2%? while Core 1 is used 98%?

Share this post


Link to post
Share on other sites
Guest BOPrey

RE: You can't just split a program into "threads for simulation and display" as if it's some simple taskAs a programmer for 10 years, a software architect in real time control for 15 years, and went on to start my own software company 8 years ago, I can tell you that it is just as simple as that, a thread for simulation and a thread for display. To take it further, a thread for simulation, a thread for display, a thread for ATC, a thread for AI, a thread for player input. Why, because in real live, these are independent things happenning at exactly the same time. The way I look at it, the ACES spent a lot of time creating a mission engine, reinventing the terrain engine, adding capabilities so addons can be easily develop. Just the SDK alone can cost a lot of time and resources. From MS's point of view, also my point of view, the ACES team did the right thing. In the software business, time to market and a stayable product out weights a fast running product. These days, if the software is too slow, you can always get a faster machine, which doesn't exactly take too much time. Not the same can be said about re-architecting a software product.Just my 2c.

Share this post


Link to post
Share on other sites
Guest SilverCircle

>RE: You can't just split a program into "threads for>simulation and display" as if it's some simple task>As a programmer for 10 years, a software architect in real>time control for 15 years, and went on to start my own>software company 8 years ago, I can tell you that it is just>as simple as that, a thread for simulation and a thread for>display. To take it further, a thread for simulation, a thread>for display, a thread for ATC, a thread for AI, a thread for>player input. Why, because in real live, these are independent>things happenning at exactly the same time. You can do that if you have a much more predictable environment, maybe a well defined hardware with realtime abilities and maybe a rt operating system. Then yes, it *could* be that simple.That approach might even work on a game console like the XBox where the hardware and software environment is well defined and the software can be tested in that well-defined environment so that developers can be sure their software will exactly behave like on their testing systems on any other system out there.Unfortunately, a PC is far away from being such an environment. So that approach wouldn't ever work.

Share this post


Link to post
Share on other sites
Guest BOPrey

I agree with you one hundred percent. However, flight simulation is an exception. It is probably one of those few simulations that can take advantage of massive multi-threading. For instance, the simulation of aircraft movements (I am not talking about display here) is totally independent of ATC which is independent of player's aircraft simulation. You know what, if MS can just give us a terrain program with a programming interface to insert the player's plane and all the ai planes. Third party devs will create the physics simulation themselves. Also, third party devs will come up with the ATC as well.

Share this post


Link to post
Share on other sites
Guest

it seems like ACES was dragged into the design room by Microsoft, and told to concentrate on 90% eye candy while refusing to accept that not everyone is going to want to upgrade a system they just upgraded a year ago. I can pop in any other game and run full settings and it almost always plays perfectly. FS is a different story. I understand the huge scope of the game, but it seems Microsoft doesnt care about hardcore simmers, they know they can sell tons of copies off the name only, and these casual gamers make up their biggest market. So they push off all the hard work to addon developers who have to make complicated scenery and airplanes for this engine will still catering to the people with slower systems even though MS doesnt have to do that.like all talented developers, ACES kept trying to add to the feature list instead of fixing as much as was broken in the last version

Share this post


Link to post
Share on other sites

>Personally, I expect to see FS11 to be highly multithreaded.I agree. If the ACES team reads this I would like to say this...I am quite willing to wait longer than the usual 2 years between new versions. If that's what it takes to rewrite as much of FS as possibleto take advantage of the new multicore processors so be it.Your FlightSim has moved well beyond a "game". It's more like a way of life! :-) I can't believe the friends I have made through MS FlightSim.I will buy every new version until I'm too old to use a joystick.FaxCap

Share this post


Link to post
Share on other sites
Guest Derek D

I personally don't know how MS came up with their bizarre marketing strategy. They design each version of FS so that it won't run very well on current machines, but will scale up as new technology is released over the course of a couple years. This is a common strategy for a number of games because they want to remain competitive well into the future--but that paradigm doesn't work well for FS because they release a new version every couple of years! There is no need to "design for the future" when you are re-releasing a brand on a regular basis.If you consider that during any given FS release approximately 95% of the population is using computers below the de facto requirements, that is 95% of the population that can be considered as lost sales during the "hype period" which is the most profitable sales period for a game release.In my opinion, MS should seriously consider sliding their compatibility curve a year or so to the left for future versions of FS. This may mean that the next version of FS won't be as dramatic in its feature set, but at least it would run great on most computers out-of-the box with all sliders to the right. It is also going to become more essential when you consider that processor speeds haven't really improved in the past few years.

Share this post


Link to post
Share on other sites

Did anyone actually READ traggers article?It states quite clearly WHY FSX is not able to utilize the second core to a great degree.Some terrain features have been offloaded to the second core, so there is SOME benefit, just not a lot.

Share this post


Link to post
Share on other sites

Hmm,...it is quite amusing, reading threads like this.I said it before, and I say it again....People was sent to the moon with computers 1969,...yes 1969...But it seams impossible to make a Flight Simulator Game program stutterfree 2006 for a "normal" computer system. :-rollYou can flame how much you want,..but I am positivly sure that MS is very capable in making a stutterfree program, like FSX today. The reason they don

Share this post


Link to post
Share on other sites

When FS9 came out.. It may not have run well on machines owned by 95% of the people, but if one had the latest PC at that time, it would have given them a 74FPS. So the solution at that time was..to go buy the latest PC at that time. So...No, FS9 was not out of sync with the H/WThis time its different. And that is because of the track deviation HW manufactueres took. They have moved from increasing the single core speed to dual and quad core. We have been requesting for FSim to follow that Multi Core HW track, but they have said, (thats my understanding) that its not viable for FSim. Fsim is mostly a singly threaded app. Hence the disconnect. Manny

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...