And why would Lockheed Martin bother with optimising memory usage when they have 192GB of VAS?

 

Enlighten me, how are they NOT optimizing memory?  Details please ... not assumptions.  And be sure to give those details to LM so they can address them

 

64bit address space provides considerably more than 192GB, FYI.

 

And finally, please tell me exactly how "we programmers" get lazy when not restricted to a 32bit address space?

Enlighten me, how are they NOT optimizing memory?  Details please ... not assumptions.  And be sure to give those details to LM so they can address them

 

64bit address space provides considerably more than 192GB, FYI.

 

And finally, please tell me exactly how "we programmers" get lazy when not restricted to a 32bit address space?

 

Firstly, I have no idea whether they're optimising memory management or not, but the results show that either they're doing nothing at all, or whatever they're doing doesn't work.

 

Secondly, I know that 64-bit provides a much bigger VAS than 192GB, but that's the limit of Windows 7 x64 (which is the most popular OS so far) and we're still not close to having systems with more than 192GB of RAM.

 

Thirdly, please point me to where exactly he talked specifically about you (I assume you're a programmer) or all programmers in general. He said that programmers "tend to get lazy", that obviously doesn't apply to all programmers. Because there are programmers that don't get lazy when they don't have restrictions, but there are many who do, and that's evident in many modern games. Which means that what he said is not nonsense at all.

 

 

It's been pointed out to YOU before. What part of the YES that he wrote did you / do you not understand

 

 

 

See here:

http://www.prepar3d....iewtopic&t=5094

 

Then simply state was written  Lockheed Martin and put this matter to rest.

 

The latest statement I have is from Wes Bard on January 20, 2014, 16:33 which states "We haven't announced anything on a 64bit version yet, just that we're looking into it..."  

 

Has any got a latest statement?

 

 

I'd rather they fix feature memory bleeds on a 32 bit platform than deal with sloppy programming on a 64 bit platform. Programmers tend to get lazy when resources are plentiful

 

 

Where did this NON-SENSE come from? Maybe this thread should be locked, this is just an absurd statement.

 

Um, Rob?  As a retired professional programmer, I have to say I agree with him.  Get the memory problems sorted before going to a system where they don't matter at all.  They might actually be able to solve everything and still retain the 32 bit code.  That would be better than having to give up virtually every addon you have, wouldn't it? 

 

Only when the memory problems aren't solved and too many addons are still causing OOMs, THEN migrate.  Migrating too soon will certainly fix the problem with addons causing OOMs if you can't use any of them.

 

While it may be that most addons won't be affected by going to 64 bits, are you willing to bet all your addons on it?

 

Hook

Then simply state was written  Lockheed Martin and put this matter to rest.

 

The latest statement I have is from Wes Bard on January 20, 2014, 16:33 which states "We haven't announced anything on a 64bit version yet, just that we're looking into it..."  

 

Has any got a latest statement?

Still beating that same drum, eh? On January 17th he said "Yes" with regards to whether they would (eventually) do a 64bit version.

 

A few days later, on January 20th, he qualified the previous bare statement by saying "They haven't announced anything yet..." the which is simply nothing other than the bare truth. They haven't "announced" it, yet.

 

For someone who's Mother Tongue presumably is the "Queen's English" you sometimes seem remarkably obtuse... :LMAO:

 

 

The choice are yours and I think as long as we support an application that in the sense of memory handling,limited you in what can be achieved, the developers will not care about us and continuing selling products that is a potential time bomb waiting to go off and explode in everybody's face's.

 

I withdraw that statement after reading this thread:

 

http://www.prepar3d.com/forum-5/?mingleforumaction=viewtopic&t=5094

Um, Rob?  As a retired professional programmer, I have to say I agree with him.  Get the memory problems sorted before going to a system where they don't matter at all.  They might actually be able to solve everything and still retain the 32 bit code. 

 

My comment was more focused on the sweeping generalization that 64bit coding implies programmers get lazy.  I don't know Beau nor Wes, do you know these programmers personally?  64bit or 32bit is memory allocation, precision, and type differences ... these in themselves don't promote memory leaks or bad programming practices.

 

Garbage collection (recovering released resources) in managed or unmanaged state doesn't ensure resources are released ... this is NOT entirely under the control of the consuming program/sim/application, much is at the mercy of the OS.  I was confronted with this problem and I knew it was an issue with managed code (.NET framework) but was also surprised to see it was an issue with unmanaged code.  Both managed/unmanaged can continue consuming memory long after that memory has been requested for release.  Now add threading into this mix and the complexity grows even more.

 

Any program can be optimized further, it's a matter of how much time and resources you want to toss at it and what are the benefits ... there is a point of diminishing returns - LM could spend 2 years trying to squeeze the last drop of memory out of the 32bit address space and it may only net them a 100MB gain ... in other words not enough to really make a difference.  

 

 Given that FSX/ESP uses object tree approach (which is common for Global world type of simulations) I can certainly understand it's limitations in a 32bit address space.  Also, bare in mind that ESP supports an SDK (3rd party developers) ... this introduces a certain level performance compromises to support an "open" architecture.  For example the BGL files are in no way optimized for rapid I/O, same for .cfg, and .XML ... they exist for the purpose of the SDK and 3rd party support.

 

If I were coding a flight simulator that is highly optimized I would NOT use XML files, they're slow, they're self-describing -- many repeated sections, sub-sections, variable name, value syntax that has to be read, converted and then applied to internal code structures.  A far more efficient file would be any bit position binary file -- consumes far less space and reads considerably faster with no conversion necessary.  XMLs exist because they provide a level of ease of use for the SDK and 3rd party support, but again not optimal, a performance compromise.  BGLs are a little different, but again I wouldn't consider their format optimized at all, that format exists for the benefit of the SDK and 3rd party content providers.  Heck the base file structure and how all the files are laid out is another big compromise but again, we have a "layer" system to support and the SDK.  Could LM change this to squeeze out better VAS/performance, sure they can ... but it is effectively the same as going to 64bit because NO 3rd party products would work.  Sure P3D or FSX could be better optimized, but they wouldn't be easy for anyone else to work with and certainly would not be open.

 

Personally, I think some here are in denial ... at some point in time, all our existing 3rd party products are going to have to go away IF we want to realize a more realistic simulation that lives in a 64bit address space.  Calling programmers lazy or saying 64bit promotes lazy coding process that is not optimized is really just pulling straws out of a hat ... unless you are working with the ESP source code and have a complete grasp of every aspect of it and were on the teams that produced the code, then you really have NO basis for such statements.

 

Would I give up all my existing 3rd party add-ons for a 64bit product, in heart beat Yes I would ... why, because I look at the long term picture of where I want my simulation to be, not what I spent in the past.  BUT the fact is, even with a 64bit product, I don't have to give up anything, I can still use my old 32bit product, nothing stopping me retaining the value of those products.

 

Rob

paulpenney ,on p3d forum submitted to replace autogen folder from 2.0 to fix blurries and it WORKS ...

Rob, just as an aside, I agree with your observations regarding XML. In fact, so did the old ACES team, who had planned to substitute Lua in lieu of XML for FSvNext, the version they were very close to having ready for a round of late Alpha testing.

 

All of that developed source code was very carefully Archived by a couple of ACES employees during a few weeks work after the formal closure of the ACES Studio. Presumably this was a "just in case we change our minds someday" step.

Any new sim in the future will be mainly reserved for the wealthy elite class! personally, I dont see that great of an improvement to give up what Ive built in FSX. Even with a 64bit sim. Ive seen The other 64bit sim. Opinion only.

Ok! Its game over for me. I have had enough of P3DV2.whatever.

V2.0 was far better than V2.1 which makes me think that LM fixed

most of the stability issues by going backwards. The autogen load

radius is tiny, the popup is no better than FSX. I never see bluries in

FSX anymore and the bluries are significant in P3DV2. I am sick of fiddling

around with it and I have no interest in being a beta tester.

 

After trying to get it to run well and having reinstalled it 4 times I tried

the default setting with all the controllers disconnected flew the default flight, the only

change I made was setting the frames to unlimited. I used the mouse yoke to fly

and despite a frame rate of 120fps constant micro-micro stutter are discernible.

 

Did see the bigger stutters too but strangely at higher graphical setting where the Micro-micro

stutters where gone.

 

Anyway took a flight in the NGX from FSDT KLAX to FB KFSO to take a brake.

In FSX of course :lol: and though what the hell am I doing!

 

On my Haswell system with addons like REX, ORBX, ASN etc. and frames locked at 30 using the 1/2 refresh rate for Vsync FSX today is plan superior to P3DV2. It does look a bit like LM are leading us all on a merry dance!

Anyway that likely counts as my biggest waste of $200 of Flight Sim money to date.

 

I have a bad feeling that NickN is going to have his I told you so moment :unsure:

lly it just looks dull to me by comparison!

 

If you tinker with Sweetfx, it's as real as its gets with FSX. P3D does not even come close, and HDR is way too dark imo.

 

FSX+Sweetfx is simply incredible when tweaked right. Pictures added cause pics are cool.

Ok! Its game over for me. I have had enough of P3DV2.whatever.

paulpenney ,on p3d forum submitted to replace autogen folder from 2.0 to fix blurries and it WORKS ...

Edited February 17, 201412 yr by n4gix
Removed excessive quote and move reply outside of the quote box!

You guys do realize that a hobby is something you're supposed to actually *enjoy*, right?

Where did this NON-SENSE come from?  Maybe this thread should be locked, this is just an absurd statement.

 

I don't know if you're fishing for an emotional response from me, you won't get it

 

I've been in software research and development since the mid 80's and a preliminary observation that I can safely make is that the 2.1 patch should have been tested for at least another month. The autogen bleed, whatever its source (XML vs compiled XML) should have been picked up by proper quality assurance efforts.

 

When they can prove that they can properly manage 4Gb of VAS, they can move on to 64 bits

You guys do realize that a hobby is something you're supposed to actually *enjoy*, right?

 

For me, this is the ultimate fun  Just turn off the autogen and enjoy until its fixed