doesn't check for null pointer returns

 

This is what separates people who are programmers from people who call themselves programmers.   

 

OK, that's not quite fair.  But how about, um,  the simmers from the gamers?  

 

To be really fair, like an Olympic skating performance, you can never get a perfect score, but memory management must be there for a program to obtain medals.  Every GUI, even a web page or a java app or a phone app, is affected by how much memory you have available in the environment that it is in.  Hardware is not even factor in most cases.   I have a 64bit OS with 32GB RAM and a single web view can crash my system.  It's funny how in this same forum you have people complaining about NVidia's new driver every 3 months.  It's all about managing resources at the scope you're in.

 

Good software development is not dreaming up pretty pictures and throwing all your dreams into the wood chipper that is the a modern CPU/GPU/OS and then complaining that your Picasso didn't come out the other side.  And it won't get prettier if your wood chipper can see 32bits more address handles.

 

You create objects and have complete responsibility for them after creating them, and by responsibility I mean how they live and die in the environment they are created, meaning the hardware and how the OS represents it, and the changing input and output (bottlenecks) parameters.

 

 

This is what separates people who are programmers from people who call themselves programmers.

 

But don't you dare call them sloppy!!   Besides, there may be valid reasons not to bother checking.  It's more likely that the malloc never actually gets called.

 

 

 

OK, that's not quite fair. But how about, um, the simmers from the gamers?

 

Even programming is a game.  One of the best there is.  It's a complex puzzle. 

 

Hook

 

 

To get around the shadow bug with the recent nV drivers I'm running shadows at 'Med' on the slider, but have edited the cfg to push the distance to 'Ultra'... and the above NI setting seem to work really well for me... not sure what this AA_MODE_REPLAY_SAMPLES_FOUR supersample mode is all about, but its working for me.

 

Thanks I'll give it a try.  Always good to hear of other success stories.  I think overall P3D V2.x has been experienced very positively and in a relatively short time meaningful improvements are coming along well.

 

 

This is what separates people who are programmers from people who call themselves programmers.  

 

Denali, you really crack me up ... Bill tried to explain to you, but apparently you still don't get it.

 

But here let me make a suggestion to you ... if you are looking for performance in code, you don't add a branch condition if you are never expecting to need it  -- that's called ... drum roll ... "efficiency" ... why, because a branch condition consumes precious processing cycles.

 

 

 

Good software development is not dreaming up pretty pictures and throwing all your dreams into the wood chipper that is the a modern CPU/GPU/OS and then complaining that your Picasso didn't come out the other side.  And it won't get prettier if your wood chipper can see 32bits more address handles.

 

Haha ... what on earth are you babbling about?

 

 

 

You create objects and have complete responsibility for them after creating them, and by responsibility I mean how they live and die in the environment they are created, meaning the hardware and how the OS represents it, and the changing input and output (bottlenecks) parameters.

 

Have you coded anything at all, ever?

 

 

 

Also, always remember OOMs are a unhandled errors.

 

OMG, this is getting ridiculous ... so why are you seeing the error if it's not being handled?  And more specifically, why is the error telling you to "adjust graphics settings" if it's NOT being handled?

 

 

 

You keep track of what your program is doing, know your limits, and keep within them.  Trim back, or um ... allow expert users to trim back with some sliders.  You don't make the call for memory in the first place.

 

Really, so every time an allocation is requested one should check for available memory, determine if it there is enough, if there isn't just don't load the batch of objects?  Ok, so now you've taken a huge performance hit on EVERY single allocation request and to further make this even more of a huge performance hit, you have many threads operating independently so that when one thread checks for "available" free space before allocation and it's good, but a few nanoseconds later another independent thread has just completed it's allocate of memory (because it thought it was free also) so the first thread check is working of an invalid free memory condition.  Multiply this problem by however many threads are operating independently ... so how on earth are you going to accurately and in any semblance of performance (think P3DV2 now operating at seconds per frame rather than frames per second) going to be able to do this?

 

Guess what, the OS does this for you ... it handles the allocation request, if it fails to allocate an exception is triggered, LM handles the exception with an error message presented to the user.

 

But hey, if you want your flight sim to be measured in seconds per frame, maybe you should pass along your coding tips to LM.

 

Cheers, Rob.

Very rare for me to say this .... but isn't it time to all cool down? As nobody here has access to the Pad source code, surely it is quite irrelevant to this topic?

 

Sent from my GT-N7100 using Tapatalk

Please explain to me how a VRAM memory of more than 4GB (or actually about 3.5GB accessible because some is lost to overhead) is accessed in a 32bit program?

 

There was once a day when RAM was nothing more than a way to speed up disk access - to make a copy of what was on disk in a place that it could be accessed faster.  That really hasn't changed.   32bit programs can communicate in parallel if you know how to do that.  That's what 64bit is, it isn't just more memory.

 

The video card doesn't handle data in the same way the system does. It has its own memory table that is independent of the process. It "schedules" memory according to priority. If you run out of VRAM, you wont get a OOM. Instead the low priority data will be moved out into the system memory (provided there is sufficient available) to make way for higher priority data. Whether the program is 32bit or 64bit doesn't matter since it cannot directly control the memory on the video card at all.

Yes, I'm a programmer.  Professionally.  Yes, I have written directx code.  I actually have some laying around here on this forum, by gosh. 

 

The OOMs our favorite FS programs are eliciting are coming from the OS, not from the FS.  (Ask the team, they'll probably admit it. They're also doing an excellent job navigating all these demands.) The OOM error is not "handled" very well, is it;  The program crashes?    When you write a program, you write the version you release, and you write one that you use to make sure you're doing it well.  Yes, the one you write for development is quite a bit bigger and runs a little bit slower ... but that's the intention ... so you can catch those threads.  I wrote that somewhere else in here actually.

 

One more time.  There is no point in addressing 3GB worth of VRAM with 64bit worth of memory handles.  Not in 2014.  It's rediculous.  You have people claiming their systems are pegged on both PUs and they want to have a larger hopper to throw more at it.  Don't you guys watch Gold Rush?  What happens when you put too much in the sluice box?  Does a bigger hopper get you more gold?  Wait at least until we can add a second or third sluice.  (did you know that sluice was spelled that way?)

Very rare for me to say this .... but isn't it time to all cool down? As nobody here has access to the Pad source code, surely it is quite irrelevant to this topic?

 

Sent from my GT-N7100 using Tapatalk

 

I have to agree with the above, can we maybe have the Amateur Developers Summit 64-bit Edition held somewhere else next time ?

 

You know, like, maybe somewhere it is actually relevant ? 

Thanks I'll give it a try. Always good to hear of other success stories. I think overall P3D V2.x has been experienced very positively and in a relatively short time meaningful improvements are coming along well.

 

It certainly works on runways, but I am getting a lot of shimmering with AGN veg... so it ain't perfect.  I only lose 1fps with this, so that's an advantage. I still think we need proper driver support, before we can tune AA properly.

 

 

 

 

 

 

I have to agree with the above, can we maybe have the Amateur Developers Summit 64-bit Edition held somewhere else next time ?

 

 

And yes, the battle of the 'pro' programmers is getting very boring :rolleyes:

It certainly works on runways, but I am getting a lot of shimmering with AGN veg... so it ain't perfect.  I only lose 1fps with this, so that's an advantage. I still think we need proper driver support, before we can tune AA properly.

I'm still not happy though w/ any water in 2.x, from REX4 options.  It's not bad now but it's very much lacking in reflectiveness in particular, though the moire effect and other horribleness is resolved also w/ these settings and I'm not sure exactly what will resolve that, be it new textures or a custom driver or what have you.  Since a big chunk of the planet is covered in the stuff I hope it's addressed as I think it will add a lot.

I have to admit... I have never seen so many threads where good news is trampled and spit on as often as here.  Sort of along the lines of snatching defeat from the jaws of victory...  :rolleyes:

 

As for me... I was first in line to purchase P3D 2.0 and was plagued by OOMs, hence my switch to the "other" sim.  Will be happy to have both co exist assuming this is the main OOM issue... still needs work, but they are getting closer... hope they can pull it off.  

 

 

You know, like, maybe somewhere it is actually relevant ?

 

This thread is about OOMs, so how can 32bit  and 64bit address space not be relevant?

 

 

 

And yes, the battle of the 'pro' programmers is getting very boring

 

A battle, not even a skirmish, more like a comedy.  I like to point out blatant inaccuracy so that other's aren't fooled by the jibber jabber.

 

 

The OOMs our favorite FS programs are eliciting are coming from the OS, not from the FS.

 

This tells me you haven't even read what P3DV2.1 OOM message displays and/or a complete lack of understanding.  Let me link you to someone else's thread that has a picture of the OOM message: http://forum.avsim.net/topic/435328-my-first-flight-with-p3d-v21/

 

So you really think this message comes from the OS ... the OS somehow knows to say "Please restart Prepar3D and select different graphics, scenery, or traffic settings" ... wow that's one magical OS, how does it know about traffic settings and scenery???

 

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.

it's not going to solve the OOM problem.

Nor is this discussion? Regardless if it takes code optimazation or 64 bit, there is very little, if anything, that a "user" can do about it. Makes for great philosophy discussion though I reckon!

I don't know, maybe because since P3Dv2 isn't 64 bit, and discussion of such is entirely irrelevant ? Not to mention, you all aren't even discussing OOM mitigation or anything even close to it.

 

The entire thread has turned into a measuring contest between self appointed experts, over an idea that doesn't matter in any way, shape, or form to anyone trying to use P3Dv2 today. 

 

Maybe, all of this expertise could be put to better use, say, over in the LM forums ? 

 

Or take it to PM ?

 

EDIT: Hey Mods, can we maybe have a moratorium on any post that has "but, 64-bit !" in it ? For maybe a year or so ? Would be great. This is becoming nearly as tedious as the EULA discussions at this stage.

 

 

Nor is this discussion?

 

Why?  Because you don't like the solution?

 

There are many many many threads about OOMs and how to avoid them.  I and other's have listed exact details of how we have avoided OOMs.  This has turned into just another "pick on LM" thread.

 

The solutions are (once again):

1.  64bit product (you'll have to wait for this one and hope LM stop responding to OOM questions)

2.  "select different graphics, scenery, or traffic settings" (where have I seen that before, hmmm, let me think ...)

 

Cheers, Rob.

I don't know, maybe because since P3Dv2 isn't 64 bit, and discussion of such is entirely irrelevant ? Not to mention, you all aren't even discussing OOM mitigation or anything even close to it.

 

EDIT: Hey Mods, can we maybe have a moratorium on any post that has "but, 64-bit !" in it ? For maybe a year or so ? Would be great.

 

Getting people to understand the need for 64bit is irrelevant?  Seems important to me, even more important for those that believe in some of the blatantly wrong information being posted in this thread ... that's definitely NOT helpful to anyone.

 

If the moderators are going to ban all 64bit threads, then they should probably ban all OOM and/or VAS threads also to be fair.  But there again, why try to get the moderators to ban 64-bit discussions in the first place ??