Thorsten

Testing continues

> > Concorde has of the order of 6000 lines of active code, and yes, it
> > displays exactly the same discontinuities as Advanced Weather (approx.
> > 10,000 lines of code). So far, I have not found any other examples.

> Just to idly continue my list - the A380 has in excess of 8000 lines of
Nasal, the
> 777 has about 3500 lines, ... I don't know what you usually fly, but the
> modern, more complex aircraft tend to accumulate a lot of Nasal when
> aircraft makers start to care about systems.

A380 - broken
Mig 15bis - broken
B777 - works - framerate is adversely affected and stutters a bit, but
acceptable. Notably, it increases the time spent in the Events sub-module,
but only by approx. 10ms, or 2 times.

> I have just tried to start Flightgear without the Advanced Weather module
> loaded, disabling all weather, using the ufo to minimize any Nasal impact.
The
> bottom line is, no matter what I do, as soon as I actually move around I
> always get spikes in the frame delay raging from 30 to 45 ms, i.e. I never
have
> a smooth framerate even if I throw out basically everything.

The ufo is far from a Nasal-free zone. Compare it with the Seahawk? It has
no pooh traps.

> So I can't ever get to the smooth state you apparently have on your
system,
> which means I can't meaningfully test what makes a difference. I can only
> suggest that you try disabling the loops I suggested and play with the
loop
> timings. If you think letting loops run per frame helps, by all means try
- with
> the possible exception of the tile management, I'm fairly certain the rest
can
> run per frame without bad side effects - the times are chosen to give the
> best performance on my system, but this may not work the same way for
> you.

Nil weather is very smooth in basic weather with shaders on but veg, obj,
and bldgs off. Tried METAR. Basic weather now shows some stutter. Now set
all Advanced Weather settime() to 0.0 and retest with METAR. Wow!!!
Improvement, not as good as Basic Weather , but much better. Worst fps is
stable at 24, av. is still unstable.  

That's the good news - the bad news is that Emilian does not see an
improvement. 

Conclusion: don't try to optimise, particularly for a poor system - you
might make it better for that system, but more likely you will make it worse
for everyone else. 

> If you can find a working combination, I'll make it an option in the GUI
and
> see if it helps others.
> 
> > Yes, I was around when Nasal was introduced to Flightgear. Up to now
> > it's been a few 100s of lines, not many 1000s. We have long been aware
> > that GC could cause problems, but haven't fixed it because the effects
> > weren't too bad while Nasal was small and framerates were low, and we
> > had no obvious solution.
> 
> You know what really bugs me? The direction fingers are pointing.

Well, as Gene Buckle pointed out: if you point a finger, then 3 are pointing
right back at you.
 
> We have an implementation of Nasal which dumps all the GC into a single
> frame and is apparently sensitive to the total amount of code, regardless
if
> the code is actually run or not. This fact has historically not been
widely
> advertized or explained. That turns out to be a problem.

We were aware that "GC was a problem". We also avoided dumping nasal into
the Nasal folder because "everything in there runs".  Too much stuff is
either buried in obscure Wiki pages or are simply part of the hive memory;
there are fewer worker bees than there were and the memory grows weaker.

> The way this usually comes across is 'Advanced Weather causes stutter'.
But
> it actually doesn't really (or at least that remains to be shown) - what
causes
> stutter is mainly the GC, and Advanced Weather just happens to trigger
this.
> The range of suggested solutions in the past included almost everything,
> from avoiding Nasal to porting code to Nasal to hacking around the problem
> to loading things on-demand - except fixing the actual cause of the
problems.

To be honest, I think there are design difficulties with Advanced Weather.
There should only be one loop - the "update loop" - running at main frame
rate which activates/deactivates the various sub-modules as required. I
think I have done enough work here to demonstrate that this is a viable way
forward.
        
> I don't honestly know how complex code to collect garbage across many
> frames is, but somehow I doubt that in terms of man-hours the effort beats
> porting the existing large-scale Nasal codes to C++. Just my 2 cents in
any
> case.

> Sorry, this really had to get out. Now, back to being constructive. As I
said, I
> try to do what I can in terms of getting old code out and streamlining the
rest
> - hopefully we get some improvements.

Right now, with Advanced Weather we have a weather simulator with a
FlightSim attached. We're spending 10 (yes 10!) times as long in the Events
Sub-module with Advanced Weather than in Basic, and 5 times as long as we
spend in Flight.  It would be a good design aim to get this all more in line
with the B777. Less is good. Perhaps we can get this Nasal to work "well
enough" without porting to C++.

Design Heuristics (ver2)

        Nasal is bad. Big Nasal is worse, small Nasal is not so bad. Garbage
Collection is evil. Nasal scripts affect GC even if they are not running.
 
        For loops are bad - in C++ as much as in Nasal.  For loops hold up
the  execution of the main loop, even when they do very little. 
 
        Execution of loops at other than main loop rate is bad. If the
deferred loop does a lot then this will show up as a stutter, if it does not
do much,
        then it isn't needed. Deferred loops can interact unpredictably with
other loops (a bit like waves in the ocean) to produce a rogue stutter. 

        "Optimising" code is bad. You might make it better for your system,
but make it worse for everyone else. OSG/OpenGL do a pretty good job all by
themselves

        Writing data to the Property Tree is bad.  This one is not evidence
based, but from memory that we avoided doing so when writing AIBallistic to
maintain a reasonable framerate. At the very least, it will cut down the
number of lines of code. (Less is Good).

        Framerate Throttle is bad . At best it has little affect, otherwise
it makes things worse. It is papering over poor design.
  

Progress at last!

Vivian 



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to