Board index FlightGear Development Nasal

the real cost of the Nasal Garbage Collector

Nasal is the scripting language of FlightGear.

the real cost of the Nasal Garbage Collector

Postby hamzaalloush » Tue Nov 24, 2015 1:30 am

So i had an idea, why not measure the impact that Nasal as a system, had on Flightgear as a whole, My approach was simple, simply delete all .nas modules in the root Nasal/ folder that does not cause Flightgear to sigfault(which leaves me to gui.nas only), along with the whole folder of AI/, Scenery/, and gui/, then measure before/after GC stats(using Torsten B's patch), along with an FPS/ms table written to a log, i used a minimal setup, and a pure JSBSim aircraft such as the ogeL(except it had some livery update Nasal scripts that i deleted).

One interesting thing about GC stats, is that deleting Canvas and Failure Manager modules had the biggest impact on the reduction of the GC stats, i then proceeded to use a powerful machine so i won't be fill-rate limited when i tested for FPS/ms, the GC numbers you will see are from a Linux machine running under similar test conditions, while the FPS/ms log was gathered from my Windows machine, this is because i couldn't bother patching FG on a Windows machine for Torsten B's GC stats patch.

Here goes.

fgfsrc:

Code: Select all
   

    --enable-fullscreen
    --aircraft=ogel
    --airport=oejn
    --timeofday=noon
    --runway=34L
    --disable-hud-3d
    --disable-fgcom
    --disable-sound
    --disable-clouds
    --disable-clouds3d
    --visibility=5000
    --prop:/sim/rendering/draw-mask/aircraft=0
    --prop:/sim/rendering/draw-mask/clouds=0
    --prop:/sim/rendering/draw-mask/models=0
    --prop:/sim/rendering/random-vegetation=0
    --prop:/sim/rendering/random-buildings=0
    --prop:/sim/rendering/random-objects=0
    --prop:/sim/menubar/visibility=false
    --prop:/sim/ai-traffic/enabled=false
    --prop:/sim/rendering/quality-level=0
    --prop:/sim/rendering/shaders/quality-level=0
    --prop:/sim/sceneryloaded-override=1
    --prop:/sim/rendering/draw-mask/terrain=0
    --config=C:\Users\Hamza\Documents\FlightGear\mylog1.txt



log xml placed in $FG_HOME:

Code: Select all
   

    <PropertyList>
      <logging>
        <log n="0">
          <enabled type="bool">true</enabled>
          <interval-ms type="long">50</interval-ms>
          <filename>fg_log.txt</filename>
          <delimiter> </delimiter>
          <entry n="0">
            <enabled type="bool">true</enabled>
            <title>frameSpacing</title>
            <property>/sim/frame-latency-max-ms</property>
          </entry>
          <entry n="1">
            <enabled type="bool">true</enabled>
            <title>actualFPS</title>
            <property>/sim/frame-rate</property>
          </entry>
        </log>
      </logging>
    </PropertyList>



now comes the fun part:

Nasal GC stats after initialization with all .nas modules:
**** Nasal garbage collection statistics: objects: 19164, references: 71059

Nasal GC stats after initialization with minimal .nas modules to keep FG running:
**** Nasal garbage collection statistics: objects: 3389, references: 7700


here is FPS and latency in ms, taken on a similar time range:

Full Nasal:

Code: Select all
   

    Time frameSpacing actualFPS
    26.8167 16 1711
    26.8583 16 1711
    26.9083 16 1711
    26.9667 16 1711
    27.0167 16 1711
    27.0667 16 1711
    27.1083 16 1711
    27.1583 16 1711
    27.2167 16 1711
    27.2667 16 1711
    27.3167 16 1711
    27.3583 16 1711
    27.4083 16 1711
    27.4667 16 1711
    27.5167 16 1711
    27.5667 16 1711
    27.6083 16 1711
    27.6583 16 1711
    27.7167 16 1711
    27.7667 16 1712



Minimal Nasal:

Code: Select all
   

    Time frameSpacing actualFPS
    26.8083 16 2120
    26.8583 16 2120
    26.9083 16 2120
    26.9667 16 2120
    27.0167 16 2120
    27.0583 16 2120
    27.1083 16 2120
    27.1583 16 2120
    27.2167 16 2120
    27.2667 16 2120
    27.3083 16 2120
    27.3583 16 2120
    27.4083 16 2120
    27.4667 16 2120
    27.5167 16 2120
    27.5583 16 2120
    27.6083 16 2120
    27.6583 16 2120
    27.7167 16 2120
    27.7667 16 2120
    27.8083 16 2094





Conclusion: on an uncapped machine, Nasal robs me 408 FPS, that's just run-time Nasal that starts with FlightGear, we are still not talking about Canvas implementations(remember this is the ogeL aircraft).

P.S: I could get as less as 5ms on my Linux machine, so the 16ms is a Windows thing, probably caused by the compositor not acting well with an OpenGL application.
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: the real cost of the Nasal Garbage Collector

Postby MIG29pilot » Tue Nov 24, 2015 2:20 am

408 fps? Is this a hint to streamline Nasal files?
User avatar
MIG29pilot
 
Posts: 1465
Joined: Tue May 19, 2015 5:03 pm
Location: 6 feet under Snow
Callsign: MIG29pilot
Version: 2020.1.3
OS: Windows 10

Re: the real cost of the Nasal Garbage Collector

Postby hamzaalloush » Tue Nov 24, 2015 2:40 am

If by streamline you mean fix, then yes. The GC has to be fixed for it to be useable on all machines without a penalty, this is our only scripting language and it is limiting, this just the evidance.

Also i'm annoyed about the fact that the most expensive Nasal run-time (Canvas) has to be running regardless if i use or not.

Also some of our own(i guess Thorsten's) expensive code like advanced weather is ran in Nasal. I'm sure we would invite efforts for a substitute to it using C++ instead.
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: the real cost of the Nasal Garbage Collector

Postby Thorsten » Tue Nov 24, 2015 8:49 am

I frankly don't care whether you have 2120 fps or 1711 fps displayed somewhere, because your screen is going to display only 60 fps in any case and as long as the CPU uses less time than these 0.0166 seconds to complete a frame we're doing fine.

So the true conclusion is that you're in fact very far from being CPU limited.

Otherwise, it's a truism that doing things costs performance - AW will slow you down whether you run it in C++ or Nasal (currently, it's structured that way that all expensive stuff is done by calling C++ functions from Nasal, the Nasal part just makes the high-level decisions).

The relevant question is whether any of this creates a bottleneck somewhere. And if not, if you have performance to spare (which you clearly have till you're down to 60 fps) then maintainability, ease of access and inability to segfault make Nasal a very good tool.

(Making your argument a bit more extreme - you could re-write AW directly in assembler - that'd be even a bit faster than C++ if you design it well, but make it completely un-maintainable).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: the real cost of the Nasal Garbage Collector

Postby stuart » Tue Nov 24, 2015 10:16 am

Hi Hamza,

That is quite interesting. I think it might be worth digging into whether Canvas can be made to have less impact when not in use. Also whether running this on a less powerful machine, or one running perhaps a more complex FDM has a different impact.

Regarding Nasal as a scripting language and AW, I'm hopeful that the work I'm doing on HLA will allow us to run Nasal in a separate thread from the FDM and display, so Nasal GC no-longer can impact frame-rates. It would also allow for writing a weather simulation completely external to the FlightGear instance, which could be quite neat.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: the real cost of the Nasal Garbage Collector

Postby hamzaalloush » Tue Nov 24, 2015 10:34 am

Hi Stuart,

I'm glad you found my research interesting, i hope this will inspire ideas to improve FG as i intended it to be informative and factual.

And yes, Nasal run-time modules placed in /Nasal tend to increase GC statistics measured, even not used as i illustrated.

Regarding FDM that's another topic, the exclusion of an FDM to one that relies on external data for its flightpath is by far the less demanding, not counting how the 'flight' sub-system actually behaves.

Good luck on the HLA work, looking forward to it!
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: the real cost of the Nasal Garbage Collector

Postby Richard » Tue Nov 24, 2015 10:54 am

The original measurements may be skewed by measurement accuracy.

However this is definitely worth investigating - so I commented out line 856 of NasalSys.cxx

Code: Select all
//initNasalCanvas(_globals, _context);


Test conditions [1]

* F-15C (as in FGAddon)
* I picked a location with no terrain (well actually I didn't so much as pick it but terrasync timed out.
* Terrasync disabled
* ALS disabled
* no vsync
* R9 290
* i7 2600

I then ran FG once with the commented out line and second time with the line back in.
Image
Results
--------------
1. (No nasal) Maximum frame rate (no canvas) looking at the sky 276fps
2. (No nasal) Cockpit view filling the screen 76.5fps
3. (No nasal) Normal cockpit view 91 fps
4. (No nasal) Monitor system properties shows Nasal at 0.00
5. (Nasal) Cockpit view filling the screen - canvas devices powered down 75fps
6. (Nasal) Cockpit view filling the screen - canvas devices running and updating 51.3 fps

The results are interesting; as the only time we drop below 60fps is when Nasal is active, and the canvas displays are powered on and updating; in which case the frame rate drops to 51.3fps. If anything the maximum effect I'm seeing is a drop from 91fps to 75fps in comparable situation when Nasal is unloaded.

I'm aware that the way I've written the update logic for the displays is not really optimised as it simply updates everything each time the method is called. Although it does call the method less often if the frame rate drops below 15 - which did make a difference on my laptop (which has a decent i7 but only HD graphics)

On an unscientific note the FPS does bounce around a bit more when Nasal is loaded; which may be Nasal GC - but in my view more work needs to be done to prove that this is actually an issue, whereas we know that LOD and not being multithreaded are an issue.

I haven't made too many tests with Nasal active as anyone can do that (adjust paths to have no terrain if necessary).

But most of this becomes less relevant with the HLA changes that Stuart's working on.

---------------------
[1] --aircraft=f15c --airport=ZUBD --fg-root=e:/temp/fgdata --fg-aircraft=c:/Users/Richard/dev/flightgear/aircraft;c:/users/richard/documents/flightgear/aircraft;c:/Users/Richard/dev/SpaceShuttle --fg-aircraft=C:\Users\Richard\Documents\FlightGear\Aircraft;I:/fgaddon/branches/release-3.6.0/Aircraft --fg-scenery=C:\Users\Richard\Documents\FlightGear\TerraSync --console --fov=85 --timeofday=morning --callsign=Richard --disable-fgcom --texture-filtering=2 --httpd=5500 --prop:/sim/rendering/vsync-enable=false --prop:/sim/rendering/rembrandt/use-color-for-depth=false --geometry=1280x920 --prop:/sim/rendering/multithreading-mode=DrawThreadPerContext --disable-rembrandt --disable-terrasync --enable-hud-3d
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: the real cost of the Nasal Garbage Collector

Postby Hooray » Tue Nov 24, 2015 11:26 am

First of all, thanks to all the people posting their numbers/results here - I am hoping to comment in more detail later on - so just briefly: "globals" is basically a hash with all important symbols. The GC itself can be understood to be a recursive for-loop that marks all active references, so the overhead of the GC is proportional to the number of active references/objects (stuff that can be reached).

In summary, it is because we are dumping basically "all" Nasal code in $FG_ROOT into the global namespace, while some stuff should be optional, and only loaded on demand. While that can be accomplished using Nasal submodule residing in a corresponding sub-folder, the other bad assumption we are making is that all underlying C++ subsystems will always be available (think sound, fdm, ai, canvas etc) - this applies especially to Nasal code that leverages C++ code (think tanker.nas).

Last year, we discussed how to fix this, and also posted patches, see:
Subject: FGCanvas Experiments & Updates

Hooray wrote:
Philosopher wrote in Tue Jul 08, 2014 5:50 am:I guess my preference wrt extensions is just leave out the symbols, so that we can use contains(globals, "geodinfo") (or some subsystem-enabled predicate) and it won't crash FG. I know of few extension functions that check that the corresponding subsystem is available – they usually assume the pointer is non-NULL.


It occurred to me that the same "dependency" problem we have already WRT properties that depend on other subsystems.
For that, core developers extended SGSubsystem to provide bind() and unbind() methods, where property-tying would normally take place:
http://docs.freeflightsim.org/simgear/c ... 9145a9565f
Acquire the subsystem's property bindings. This method should bind all properties that the subsystem publishes. It will be invoked after init, but before any invocations of update.

And for unbind() it says: "This method should release all properties that the subsystem publishes. It will be invoked by FlightGear (not the destructor) just before the subsystem is removed."

thus, bind() & unbind() are automatically invoked by the subsystem manager. So that is basically where our subsystem-specific Nasal APIs could be registered and released, we'd only need to keep track of all added symbols/namespaces, so that we can easily release them in unbind() later on. Stuff like geodinfo() would then be managed via the tile manager's bind()/unbind() methods.

While initNasalPositioned() would be moved to the NavDB subsystem's bind() method.
It's not as much work as it may sound, because we can keep the code where it is (i.e. in $FG_SRC/Scripting), we only need to move the initNasalFoo() calls from FGNasalSys::init() to the corresponding subsystem's bind() method for now.

That way, all subsystem-dependent APIs will be ONLY ever registered if the parent subsystem is available.

For releasing APIs, we'd need to check cppbind to see if it can be easily extended to maintain a vector of symbols to get rid of them later on.
As far as I can tell, this would only affect a handful of bindings:

  • initNasalCanvas(_globals, _context);
  • initNasalPositioned(_globals, _context);
  • initNasalPositioned_cppbind(_globals, _context);
  • initNasalAircraft(_globals, _context);
  • initNasalHTTP(_globals, _context);

Most others only have dependencies to subsystems that will be required either way (e.g. timers -> events, clipboard -> canvas

Tom has already added getters to acquire the globals/context to FGNasalSys - so, C++-wise would could use this method to initialize Nasal much earlier, even prior to the Canvas system. Probably, shortly after props, input, logging etc
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: the real cost of the Nasal Garbage Collector

Postby Thorsten » Tue Nov 24, 2015 11:55 am

as Iintended it to be informative and factual.


Really?

Why then do you feel you need to write strong recommendations like this (emphasize by myself):

If by streamline you mean fix, then yes. The GC has to be fixed for it to be useable on all machines without a penalty, this is our only scripting language and it is limiting, this just the evidance.

Also i'm annoyed about the fact that the most expensive Nasal run-time (Canvas) has to be running regardless if i use or not.

Also some of our own(i guess Thorsten's) expensive code like advanced weather is ran in Nasal. I'm sure we would invite efforts for a substitute to it using C++ instead.


I honestly don't know why I ever spent time explaining the pitfalls of benchmark tests.

First, quoting like 'X costs me 400 fps' is a bad metric, because fps is a quantity that's 1/duration, and duration is the thing you really want to measure. If a routine costs 2 ms to execute and you have 5 ms execution of a frame without it, it 'costs' you some 58 fps, whereas if you have 1 ms execution time of a frame without it, it 'costs' you 667 fps. Yet the execution time of the routine you're investigating is the same.

Second, the alleged 'problem' is that a counter goes from 2120 to 1711. There's no change whatsoever to what you see or experience in the simulation otherwise, nor would there be if a counter would drop by a factor 10 to 171. Your screen would still only display 60 fps - and even if your screen would be able to show 1000 fps, your eyes would be quite unable to see them. So the actual simulation experience won't change - and it won't change if you run on HLA and get 10.000 fps. So unless it is terribly important to see this counter (which doesn't influence what you see on the screen) climb, I can't see a 'we must' anywhere.

Third, if you delete nearly all Nasal scripts, you're not only changing what the GC does, you're also... not executing the scripts you deleted. So you're measuring an effect of both GC and scripts no longer running, yet you assign all you see to the GC.

Fourth, in order to say something is slow or fast, you need to have a reference or a default expectation - what numbers would you expect to see? Naturally not running an FDM is faster than running an FDM, not running a Nasal script is faster than running it, and not rendering anything is faster than rendering something. However the actual point of running subsystems is that we want them to do things, i.e. you get something for the performance spent. There is little meaning stating that FG without FDM runs faster.

Fifth, if you run AW, you have a strong performance impact. However, the vast majority of that is from the fact that you tend to create clouds - which then influence the workload of the renderer a lot (I suppose similarly with canvas). The renderer however doesn't care what system gave the order to create clouds - you'd get the same impact from C++ code generating clouds (in fact, Nasal just tells the C++ code to generate clouds). If you measure (almost instruction by instruction) where AW itself (i.e. code without rendering anything) burns performance, you'll find that a good 90% is used in executing C++ functions called from Nasal (geodinfo() is one of the most expensive statements to write into a Nasal code - you can execute a Nasal-internal loop a 10.000 times for the pricetag of a single geodinfo call in hires scenery).


So - is there any evidence that Nasal (i.e. specifically Nasal. not things we need to render because a high-level Nasal routine said so) creates a bottleneck (i.e. drags a system that's not limited by anything else below 60 fps) anywhere?

Let me state this again: I believe many setups these days are rendering-limited - typical tell-tale is framerate dependence based on what you look at. Offloading Nasal, the FDM or whatever you like to a different thread via HLA will not change the framerate a bit on these systems - it'll just increase the time the CPU can idle while waiting for the graphics card to compute the next frame.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: the real cost of the Nasal Garbage Collector

Postby Hooray » Tue Nov 24, 2015 12:12 pm

James, ThorstenB and others have been wanting to move the Nasal subsystem to a separate thread precisely to eliminate the GC from showing up in the main loop. Given how GC patches have so far fared, it seems much more straightforward to do that - because all that is needed is to ensure that calls to FG APIs (fgcommands, extension functions, property tree, cppbind bindings) are serialized (which will happen implicitly if you are using HLA for this).

For troubleshooting/benchmarking purposes it is useful to eliminate modules, and even whole subsystems, form the equation to see if/how this impacts the rest of the simulation.

Making loading of Nasal bindings optional by using the corresponding subsystem's bind() unbind() methods to load/unload the bindings is straightforward to do. Ensuring that Canvas is entirely optional is also easy to do. Making Nasal itself entirely optional is also possible, while doing so would obviously "cripple" the simulator - it will help us come up with other bottlenecks, beyond scripting & Canvas, because those subsystems would not even be running by then.

I have posted a follow-up in the canvas sub-forum, including the suggestion to support osg::switch at the Canvas element/placment level for more fine-grained benchmarking, which will allow us to selectively disable RENDERING of certain Canvas elements, without affecting other functionality of the sim (think disabling all MFDs, but letting the UI remain active).

One problem we are facing with Canvas is that it is tightly coupled to Nasal, and that people /have/ to use Nasal timers and listeners to update their Canvas elements - it would be better to make property rules available for such purposes, which would mean that most Canvas textures could be updated/animated using pure C++ code - basically, we could allow a PropertyRule node to exist for each canvas (or even element), and only configure that using Nasal.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: the real cost of the Nasal Garbage Collector

Postby hamzaalloush » Tue Nov 24, 2015 1:14 pm

Thorsten wrote in Tue Nov 24, 2015 11:55 am:
as Iintended it to be informative and factual.


Really?

Why then do you feel you need to write strong recommendations like this (emphasize by myself):



I don't understand what you're trying to say here, i intend to be informative and provide factual data with my methods clear to all.

Thorsten wrote in Tue Nov 24, 2015 11:55 am:
If by streamline you mean fix, then yes. The GC has to be fixed for it to be useable on all machines without a penalty, this is our only scripting language and it is limiting, this just the evidance.

Also i'm annoyed about the fact that the most expensive Nasal run-time (Canvas) has to be running regardless if i use or not.

Also some of our own(i guess Thorsten's) expensive code like advanced weather is ran in Nasal. I'm sure we would invite efforts for a substitute to it using C++ instead.


I honestly don't know why I ever spent time explaining the pitfalls of benchmark tests.

First, quoting like 'X costs me 400 fps' is a bad metric, because fps is a quantity that's 1/duration, and duration is the thing you really want to measure. If a routine costs 2 ms to execute and you have 5 ms execution of a frame without it, it 'costs' you some 58 fps, whereas if you have 1 ms execution time of a frame without it, it 'costs' you 667 fps. Yet the execution time of the routine you're investigating is the same.


yes, so we can't talk in percentages(because different computers have different execution time for frame without the said routine), big deal, does not negate that there was a difference in frame rates with and without the routine.

Thorsten wrote in Tue Nov 24, 2015 11:55 am:Second, the alleged 'problem' is that a counter goes from 2120 to 1711. There's no change whatsoever to what you see or experience in the simulation otherwise, nor would there be if a counter would drop by a factor 10 to 171. Your screen would still only display 60 fps - and even if your screen would be able to show 1000 fps, your eyes would be quite unable to see them. So the actual simulation experience won't change - and it won't change if you run on HLA and get 10.000 fps. So unless it is terribly important to see this counter (which doesn't influence what you see on the screen) climb, I can't see a 'we must' anywhere.


my screen might only display 60 fps and my eyes can only perceive this, not an excuse for sloppy implementation. we have 120hz 4k displays knocking on the door now, we need efficiency everywhere.

Thorsten wrote in Tue Nov 24, 2015 11:55 am:Third, if you delete nearly all Nasal scripts, you're not only changing what the GC does, you're also... not executing the scripts you deleted. So you're measuring an effect of both GC and scripts no longer running, yet you assign all you see to the GC.


It would make for a good comparison to how much costly the GC gets on the sim given an increasing/decreasing number of object.

Thorsten wrote in Tue Nov 24, 2015 11:55 am:Fourth, in order to say something is slow or fast, you need to have a reference or a default expectation - what numbers would you expect to see? Naturally not running an FDM is faster than running an FDM, not running a Nasal script is faster than running it, and not rendering anything is faster than rendering something. However the actual point of running subsystems is that we want them to do things, i.e. you get something for the performance spent. There is little meaning stating that FG without FDM runs faster.


There IS value in attributing cost to sub-systems running, this answers the question 'how good can we make it? what's left on the table?'

Thorsten wrote in Tue Nov 24, 2015 11:55 am:Fifth, if you run AW, you have a strong performance impact. However, the vast majority of that is from the fact that you tend to create clouds - which then influence the workload of the renderer a lot (I suppose similarly with canvas). The renderer however doesn't care what system gave the order to create clouds - you'd get the same impact from C++ code generating clouds (in fact, Nasal just tells the C++ code to generate clouds). If you measure (almost instruction by instruction) where AW itself (i.e. code without rendering anything) burns performance, you'll find that a good 90% is used in executing C++ functions called from Nasal (geodinfo() is one of the most expensive statements to write into a Nasal code - you can execute a Nasal-internal loop a 10.000 times for the pricetag of a single geodinfo call in hires scenery).


I don't think impact of AW is 100% related to only rendering, am i wrong to see logic of clouds written in the .nas files of local_weather and lots of Nasal listeners included? I would love to do another topic on local weather.

Thorsten wrote in Tue Nov 24, 2015 11:55 am:So - is there any evidence that Nasal (i.e. specifically Nasal. not things we need to render because a high-level Nasal routine said so) creates a bottleneck (i.e. drags a system that's not limited by anything else below 60 fps) anywhere?


Nope, but we are talking about its implementation in the main loop, which contradicts what you said about HLA not increasing frame rate because even you don't have evidence against that(do you know weather or not running Nasal in a seperate thread, it will still not help systems that are rendering limited or release frame rate that are caused by GC?)
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: the real cost of the Nasal Garbage Collector

Postby Hooray » Tue Nov 24, 2015 1:24 pm

@Hamza: Let's try to keep this constructive: suffice to say that a number of core developers definitely do care about getting >= 60 fps out of the rendering loop, and moving Nasal into a separate thread/process (HLA federate).

Some of your results are a little odd, i.e. are not yet interpreted properly - but the underlying data/findings are interesting.

For instance, it is to be expected that /every/ module loaded into the Nasal VM will increase the GC footprint, because the GC has to "search" all modules - regardless if they are active or not.

I have written a very detailed summary about the Nasal GC scheme, and worked together with Philosopher on Nasal engine internals - so I understand where, when and why the GC kicks in.

And like I said above, I also provided patches last year to help address the problem of cluttering the VM/GC symbol space with unnecessary symbols.

You don't need Thorsten's agreement to pursue with this (matter of fact, Thorsten also does not agree with all core developers, and vice versa), but you may benefit from Thorsten's help interpreting the data that you come up with.

Thus, my suggestion would be to focus on just posting data points, and let the interpretation of the data up to others, those more familiar with the corresponding subsystems.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: the real cost of the Nasal Garbage Collector

Postby Thorsten » Tue Nov 24, 2015 1:30 pm

Nope, but we are talking about its implementation in the main loop, which contradicts what you said about HLA not increasing frame rate because even you don't have evidence against that(do you know weather or not running Nasal in a seperate thread, it will still not help systems that are rendering limited or release frame rate that are caused by GC?)


Yes, I actually know that easing CPU load won't do anything if shader execution on the GPU is the bottleneck. I don't even need to test this.

I guess I'm done here, it's just a repetition of a common theme 'Nasal is so slow', 'the GC slows everything down' without any data on where the real bottlenecks are - I'm not interested in that.

I don't think impact of AW is 100% related to only rendering, am i wrong to see logic of clouds written in the .nas files of local_weather and lots of Nasal listeners included?


Yes, you are. Spend a few months understanding how AW burns performance like I did, and I'll take you halfway seriously.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: the real cost of the Nasal Garbage Collector

Postby hamzaalloush » Tue Nov 24, 2015 1:33 pm

Thanks Hooray, i will.
hamzaalloush
 
Posts: 631
Joined: Sat Oct 26, 2013 10:31 am
OS: Windows 10

Re: the real cost of the Nasal Garbage Collector

Postby Hooray » Tue Nov 24, 2015 1:34 pm

last I checked, clouds are written/updated using a fgcommand interface that Stuart added a while ago, so they don't use Nasal internally - it's just to build the fgcommand strings (props.Node object) and then it's C++ code from there
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Next

Return to Nasal

Who is online

Users browsing this forum: No registered users and 3 guests