OOM/VAS threads are relevant.

 

Philosophical discussions on the pros/cons of 64 bit, and how much better a job certain "experts" here would do in LM's shoes, is not.

 

I'm not really sure how that could possibly need further explanation, but if it does, someone else can do so. Why don't the three of you start your own thread, that the rest of us can then avoid, instead of derailing this one, among many others ?

 

EDIT: As a side note, I mostly agree with your points Rob, I just don't understand what the entire discussion is doing in this thread, and also don't understand why you need waste time on the silliness posted by others in it. I'd rather lose all 64-bit discussion than have to read through this tripe every time the VAS topic comes up.

 

Anyway, I've said my piece. I can't say I care enough to say much more.

 

 

I just don't understand what the entire discussion is doing in this thread, and also don't understand why you need waste time on the silliness posted by others in it.

 

The why is because it's false accusations of sloppy programming towards LM without knowing anything about the source code, OS memory manager, the design along with other blatantly wrong information that could be used as fuel (even if hopelessly inaccurate) in more endless threads on LM's forums about OOMs/VAS.

 

The current solution is in the error message ... I'm wondering if anyone has actually read the OOM error message?

 

But I do agree, why are we at page 5 of this thread when the solution is IN THE ERROR MESSAGE

But I can understand other's points, at some point this comedy isn't funny. The only way out of the OOM problem is with a 64bit code path, if people want to keep believing in 32bit then by all means lets just repeat the same problems that were started back in 2006. Like I said, the 32bit vs. 64bit is nothing to do about technology and all to do about money and people's existing expenditures in 32bit. The debate against 64bit is really just a desperate desire to hang onto that money spent on 32bit platform.

 

 

 

This thread (and the many others like it) have a solution, it's 64bit ... by all means keep telling LM they have memory leaks, they are crappy programmers, their code is inefficient, etc. etc. -- it's not going to solve the OOM problem.

 

The main reason P3D 2.0/1 didn't go 64-bit is the legacy code of FS in FSX/ESP. This complicates the conversion process. Unlike languages like C and C++  where much of this (not all) conversion is done for you in the compiler, A portion of FSX/ESP contains assembler code (How much there is only LM and Microsoft knows.). This code must be rewritten in another higher level language before P3D can be moved to 64bit. This s a tedious time consuming exercise to root out all of it's tentacles and rewrite, and test to make sure the new code works the same way (or better) with the sim. How long it takes depends on how much of it, and what other code in the application addresses it. If LM concentrated on that this release cycle, one we'd probably still be waiting for it, and it probably wouldn't have any new features,, or we'd have to wait even longer. (I'm not talking a few weeks here, possibly months, or maybe even more than a year delay.) This probably wasn't a primary priority, for their targeted customers (Remember  we aren't them) so the decision was made  to concentrate on DX11 which opens the door to much greater graphic features then DX9. Then work on 64-bit conversion for P3D 3.0.  (Or maybe a later 2.X release)

 

 

A portion of FSX/ESP contains assembler code (How much there is only LM and Microsoft knows.). This code must be rewritten in another higher level language before P3D can be moved to 64bit.

 

I think I recall LM stating somewhere that v2.0 (and the resulting dx11 gpu workload shift) required quite a bit of legacy assembler code to be rewritten in C++. Who knows how much... but I guess they've started to get their hands dirty.

This probably wasn't a primary priority, for their targeted customers (Remember  we aren't them) so the decision was made  to concentrate on DX11 which opens the door to much greater graphic features then DX9. Then work on 64-bit conversion for P3D 3.0.  (Or maybe a later 2.X release)

 

I know that is the publicly stated position but I think the market, worldwide, for desktop 'pilots' might be larger than the commercial/training market.   In my mind also I would think ultimately the 64-bit conversion might be as apropos to the needs of the commercial market as it is to the desktop, but maybe not over the near term.   I'm pretty amazed at how much the hot fix added to help w/ OOMs and didn't think that was supposed to be much of the agenda for the hot fix..  Perhaps it's mainly helping add ons (like the QW757) that apparently have some quirky code behavior that was manifested in the 2.1 version of P3D over the 2.0 version.   My sense is that ultimately there is service life for 32-bit P3D but as mentioned this stalls the incentive to purchase 3P content that presumably will not function when they finally go to a 64-bit core.   

OK, for some reason something I said posted twice

 

 

he main reason P3D 2.0/1 didn't go 64-bit is the legacy code of FS in FSX/ESP. This complicates the conversion process. Unlike languages like C and C++  where much of this (not all) conversion is done for you in the compiler, A portion of FSX/ESP contains assembler code (How much there is only LM and Microsoft knows.). This code must be rewritten in another higher level language before P3D can be moved to 64bit.

 

Yes there is no more assembler code, LM dealt with that for V2.x releases.  But I agree, moving to 64bit is definitely NOT trivial, it does make sense to get a 32bit product out with DX11 now ... it'll be the path many stay with for many years even after a 64bit product is released.

 

I completely agree with LM's logic and path, DX11 upgrade and many other upgrades is the right choice given resources available ... it will buy them time to develop a 64bit product and hold over many customers and help get them "established" with a larger user base.

 

Some have suggested that 64bit is a complete re-write, it doesn't have to be at all ... IMHO a complete re-write is 6X greater scope (and time) than doing a migration of 32bit to 64bit.  The good news is that the 32bit product keeps those not ready or wanting to move to 64bit a viable option for them, while others would are ready to move to 64bit can enjoy the benefits it brings.  Who knows, maybe 32bit development will not stop while 64bit product is developed ... but my hunch is it will given resources available ... but that's just a guess ... maybe LM will keep both 32bit and 64bit paths active (seems unlikely but ya never know).

 

Cheers, Rob.

Nail Meets Head, Nail Goes Deep.

 

 

 

A portion of FSX/ESP contains assembler code (How much there is only LM and Microsoft knows.). This code must be rewritten in another higher level language before P3D can be moved to 64bit. This s a tedious time consuming exercise to root out all of it's tentacles and rewrite, and test to make sure the new code works the same way (or better) with the sim.

 

I have never accused LM of being "sloppy".  If you read most of my comments over time you will recognized I am acknowledging that their load is VERY heavy up P3D Mountain but they are going up the right path and doing it very well.  For me it is like watching a sports team play very well. 

 

One more time, for clarity.  The OOM is an UNHANDLED ERROR.  It's not handled.  Our favorite message is not an error handler.  It's an error message.   This is not LM's sloppyness.  It's LMs workload, and they are already experts at scheduling, in both senses.   They are planning to go 64bit when it makes sense and not sooner.

 

The good news is that with all the thread optimizing going on they've become so intimate with the code that they could probably do the 64bit conversion in their sleep.  And if they're making/taking good notes now they'll have it debugged very quickly when they're shaken awake.

(So I read here that they've cleared the assembly code?  Nice.  That's why things are flying now, it's readable)

I know that is the publicly stated position but I think the market, worldwide, for desktop 'pilots' might be larger than the commercial/training market.   In my mind also I would think ultimately the 64-bit conversion might be as apropos to the needs of the commercial market as it is to the desktop, but maybe not over the near term.   I'm pretty amazed at how much the hot fix added to help w/ OOMs and didn't think that was supposed to be much of the agenda for the hot fix..  Perhaps it's mainly helping add ons (like the QW757) that apparently have some quirky code behavior that was manifested in the 2.1 version of P3D over the 2.0 version.   My sense is that ultimately there is service life for 32-bit P3D but as mentioned this stalls the incentive to purchase 3P content that presumably will not function when they finally go to a 64-bit core.   

 

By the numbers, you are probably correct with regards to "number of pilots". By revenue, not even close. A single Government flight simulation installation, with 7x24 support, will garner LM a ton of money per year (I hesitate to state a number - it would just become a target of objections). Whatever the revenue figure is, that one single installation represents a LOT of $60 "student" licenses... And I wager that OOM problems are immediately tuned out of said installations. No Orbx products for the young Starfleet cadets, to be sure!!!

 

 

One more time, for clarity. The OOM is an UNHANDLED ERROR. It's not handled. Our favorite message is not an error handler. It's an error message. This is not LM's sloppyness. It's LMs workload, and they are already experts at scheduling, in both senses. They are planning to go 64bit when it makes sense and not sooner.

 

This isn't necessarily correct. Say the APP calls for allocation of of a 50MB address space, You have 300MB VAS available but the largest contiguous space available is only 48MB. (Remember VAS must be contiguous) The OS will respond to the APP with an error code indicating out of address space . The APP, can then either terminate, (possibly cleaning up before, ie: closing open files) with a message similar to what ROB posted, or attempt to do some housekeeping to free up address space and try again. These are handled errors which may appear to the user as a OOM. If the APP was truly out of address space then you would get an OS Out of memory error, or possibly a kernal error resulting in a CTD. These would be considered unhandled.

The OS OOM would present itself through the OS, but it is handed to a in-house handler/message.   The message could be all you see, but instead you still get a crash, just the forced exit kind.   Kernel errors deal with interrupts, so you're not going to see one of those, as I don't think there is incompetency going on here in the slightest.  It's just development plan time constraints.  It's just my experience that if you don't handle ALL memory issues completely responsibly and comprehensively, mapped out through a memory plan/architecture, and with it's own testing defines to make sure the pistons actually fire in the correct order and in a nice rhythm, you will have problems solving problems, and you will have more of them.   Unfortunately this takes time, more time than people that don't develop can understand, because it is like writing another codebase around the release codebase.   Often there are a couple of people devoted to just that purpose.  

By the numbers, you are probably correct with regards to "number of pilots". By revenue, not even close. A single Government flight simulation installation, with 7x24 support, will garner LM a ton of money per year (I hesitate to state a number - it would just become a target of objections). Whatever the revenue figure is, that one single installation represents a LOT of $60 "student" licenses... And I wager that OOM problems are immediately tuned out of said installations. No Orbx products for the young Starfleet cadets, to be sure!!!

Intuitively, I wouldn't think there were all that many government flight simulators or similar applications, but I don't really know.  I do believe the market for an evolved high quality simulator, especially one that is well-supported by the 3P content community, for desktop use will likely be significantly greater than for the troublesome unsupported FSX platform that required users to become PC wizards to get decent results.   You could be right but I wonder whether this is essentially a guess or you have something more solid to base this on?

Heya Noel, 

 

   I certainly don't have exact numbers, but let's go ahead and do a what-if scenario.

 

   Currently, there are 137,133 members of AVSIM. Of that, how many would you speculate are historical versus active members?Let's say we have 100K active members (a generous amount). On top of that, I would estimate that only a small fraction have moved to P3D, either V1 or V2. Many members still enjoy FS9(2004), most are on FSX, with a small cadre of members for XP10 and P3D. If you follow the P3D threads, there is a small and recognizable group of contributors. So, let's say we have 1,000 members that are flying P3D, of roughly 1% of active AVSIM members. And maybe three quarters of these 1,000 are "students" @ $60 a pop, and 250 are Professionals at $200 a pop. Average revenue to LM based on these numbers is 750 * 60 + 250 * 200 = $95,000, rounded up to an even $100K.

 

   Now, let's take a "typical" government installation. Lockheed Martin is one of the largest government suppliers, and that is not because they work on the F-35. It is because they also manage many (MANY) government data centers, from stem to stern, where even the annual budget for paper (for crying out loud) can be worth a *really* well funded retirement account. 

 

   So, let's envision a flight simulation school for new cadets. Not only does LM supply the software, at a nominal rate of $2300 per seat, but they provide all the hardware, the desks, the chairs, and yes, the paper. That is where the real money lies - not in individual licenses, but in the whole package. A single such installation for say, 100 cadets, is $230,000 in software alone. Add in the support license (likely 25-percent of license cost per year), the computers/monitors/keyboards,  the desks, the chairs, the facilities to house everything (don't forget the paper!), and you have a cool million smackeroonies for a single installation. And that is LM profit, not cost. Cost would be much higher - running a "center", of any kind, is expensive, but if you do it right (and LM has a lot of practice), extremely profitable as well.

 

   Going back to the AVSIM populace, it would take 10% of *all* active members to sign on for P3D to equate to a million bucks, and I seriously doubt there are that many running P3D of either flavor.

 

   Sound reasonable? No real hard numbers, but it is easy to see how the "law of large numbers" make is apparent that the government/military installations are way more profitable than a bunch of civilians grousing about AA, backward compatibility, and PMDG...  

 

   By the way, my company does "4-walls support" for big data centers, and it is indeed a good business to be in. It just becomes that much more "gravy-licious" when working on a US Government account.

 

John Howell

   Sound reasonable? No real hard numbers, but it is easy to see how the "law of large numbers" make is apparent that the government/military installations are way more profitable than a bunch of civilians grousing about AA, backward compatibility, and PMDG...

 

Yes, sounds reasonable especially right now, but if they continue to evolve the platform into something that can be used by more folks then as I say the market goes up, and maybe considerably.   Right now you have the incomplete, needs lots of customization, XPlane 64 w/ its various features missing, and P3D V2.x, which is FSX improved nicely so far, but still far away from an essentially plug and play comprehensive solution.  Maybe it won't get there, w/ there being something much more solid than what is happening now.  In due time if that is accomplished the following for it will grow as word slowly spreads the P3D is really, I mean really a great simulator.   It may be the 64-bit version w/ more control over content quality that will take the product down that pathway, and so getting the desktop, home pilot involved added beta testing & development contribution, while planting the seeds for a bigger financial piece going forward.   Well, we like to think so anyway!  My real hope is that a new civil aviation sim will bloom out of the likes of Outerra or something similarly innovative, and move away from LM completely.  The whole issue of the non-entertainment clause is fundamentally a blight on the product in some ways and I'm sure most everyone would enjoy not having to tread lightly around the subject of the E__A.    I rest my case!

 

 

It may be the 64-bit version w/ more control over content quality that will take the product down that pathway, and so getting the desktop, home pilot involved added beta testing & development contribution, while planting the seeds for a bigger financial piece going forward.

 

I think you are close, Noel, but not quite there with respect to "control over content quality". IIRC one of the explicitly stated directions from LM was to open the API so that *entire* aircraft, weather systems, AI systems, et al, could be modeled "outside" the direct control of P3D. If anything, I think LM is counting on the terrain/weather/aircraft vendors to build upon their foundation. I, personally, think this is a very wise move. It would be very hard to improve upon Earth Simulations or Orbx for terrain, not to mention the specialty airport designers. Opus, REX, and ASN are terrific weather engines that are essentially bolted on the core simulator. And I can see where aircraft designers may be able to exploit the API to provide added function outside the core simulator.

 

I have only been in this flight simulator hobby for a year, and am 1) amazed at how much has happened in that short year (I have a pretty good bone-yard of older technologies), and 2) astounded at the persistence and patience of the "old guard", guys like Tom, Paul, and others that have seen (and shepherded) this hobby along for so long. LM has opened the gates to a new era, one with active support (damn, what a concept!), willingness to listen to feedback, and a pretty clear vision. I really look forward to my second year!!!