Board index FlightGear Development New features

FGPython an propose for Python as an nasal alternative

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Tue Mar 06, 2018 5:08 pm

The question remains, what are the "goals and no-goals" here - i.e. if this is supposed to provide sufficient infrastructure to implement subsystems in fgfs, this will inevitably have to use the SGSubsystemMgr interface, and maybe SGThread in some places. Thus, the benefits are marginal at best - if this is about out-of-process subsystems, people will inevitably need an IPC mechanism (maybe JSON/AJAX for straters, possibly Emesary - ideally, something like HLA/RTI).
Apart from that, running Python (or Nasal) out of the main loop is a no-brainer obviously, the key challenge is making scripts talk to the rest of the sim - which is done using extensions functions int the case of Nasal, which are executed in the main loop (with very few exceptions using asynchronous signalling, i.e. the equivalent of promises executed after a background thread has finished)

Personally, I find it far more ambitious to provide FGPythonSys as a means to implement subsystems that are currently implemented in C++, than providing another in-sim scripting solution, analogous to Nasal - even though that in and of itself may cause interesting challenges.

Based on my understanding of the fgfs main loop, the SGSubsystemMgr interface (but also pseudo subsystems not even using this simplistic API!), as well as the FGNasalSys subsystem in particular, I find it pretty hard to imagine how FGPythonSys is supposed to work for implementing such subsystems without suffering from the exact same limitations that FGNasalSys is facing, unless a suitable IPC mechanism is provided and widely used/adopted, at which point the lowest hanging fruit would be updating FGNasalSys to get rid of timer/listener-based paradigm to implement whole subsystems inside the main loop.
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby Thorsten » Tue Mar 06, 2018 6:04 pm

The footprint and performance of python on modern computers (as well as a rich ecosystem of support libraries) makes it attractive and compelling.


In the mean time, I can add the experience of running some heavier numerical problem with a python-based software, and I'm not impressed - the crash rate is suspiciously high, the same task sometimes runs and sometimes not.

Also, I have a direct benchmark of standalone C++ against Nasal run threaded out of the main loop - anyone wants to guess by what factor Nasal is slower? It didn't overly impress me either.

So my take-away message is - if you're running real numerics, do it in C++, if you're running scripting in FG, take the light-weight option we already have, it's way fast enough for everything else.
Thorsten
 
Posts: 11106
Joined: Mon Nov 02, 2009 8:33 am

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Tue Mar 06, 2018 6:31 pm

In general, there is no code optimization being done when it comes to Nasal. The code generator that converts the Nasal source code into Nasal op codes for its VM is rather simple and "dumb". The garbage collector is an obvious issue, because it's single-threaded, and due to the way Nasal is integrated in the main loop via timers and listeners, and "long" GC runs will inevitably affect frame rate/spacing. Unlike Python (which has a so called "global-intepreter lock" (GIL)), Nasal can do GC without a GIL.

However, in general, GC issues are symptomatic of poorly-structured code, other performance issues are primarily due to I/O functions that end up calling other parts of FlightGear within the same "main loop".

When it comes to Nasal, from a performance standpoint, the lowest-hanging fruit would be getting rid of props.nas by porting it to use cppbind instead (native C++ code bridging/providing SGPropertyNode bindings). Apart from that, it would make sense to identify subsystems that are commonly called by Nasal code and see if those can be threaded out - James mentioned that several times already when he talked about "proxying Nasal scripts [...] by requiring them to only interface via the property tree".

And then there's stuff like Canvas (which has to do tons of property I/O because it's a complete API that is modeled on top of the property tree via listeners)- conceptually, it would not be such a stretch to provide each Canvas (texture) with its own private SGPropertyNode instance, so that each Canvas has its own property tree. Those would not have to show up in the global property tree at all - but could be trivially updated/manipulated from a background thread running a separate Nasal context, without being subject to main-loop framerates/constraints - which would also nicely map to OSG's support for concurrent rendering. If people wanted to, the private property tree could be sync'ed/replicated via message-passing in a "mounted" fashion

Only the canvas placement code (which ends up making a Canvas show up in the main scene as part of the cockpit/livery/dialog etc) would have to sync with the background thread to fetch the latest texture.

This would obviously mean that such Nasal code would only get access to a heavily reduced globals namespace, i.e. only able to access its thread-specific context, and only getprop() stuff from the main tree via message passing (think Emesary or even just Torsten's existing JSON/AJAX support).

Another obvious thing that could be done is fixing the GC or integrating another one (there are standalone GCs available that can be integrated in a language like 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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Wed Mar 07, 2018 8:08 am

The point of it all is to do something interesting and different, while learning the very deep details of Python and learning a bit of C++, all while having fun. Anything you can do in Python, you could also do in Nasal. For example I have implemented the property tree as a nested set of Python objects, i.e. a pure OO design. The same could technically be done on the C++ side of Nasal so that you don't need the getprop() and setprop() functions. Technically, I have shifted these functions onto the C++ side as helper functions for the Python property tree object classes.

One real advantage of Python is that there are RTI interfaces already written, whereas it would be a massive task resting on the FlightGear developers shoulders to implement an RTI interface for Nasal. RTI is already built into the fgfs binary, but I don't think we use it yet. The fgfs binary runs as a monolithic single-thread system. The subsystem infrastructure is hard-coded into this monolithic design, it is not compatible with parallelised execution (threads, MPI, RTI, etc.). The monolithic design is not bad though as the FlightGear limitations are generally on the GPU or on poorly written Nasal code. There are a lot of FG developers who believe that parallelization is a waste of time, which strangely conflicts with the goals of the RTI/HLA initiative.

One other advantage with this little experiment is that Python could be used as a benchmark against which to optimise Nasal, especially with garbage collection (GC). However such bottlenecks would probably be eliminated by well written uses of the Python "del" command or Nasal "del()" function.

Regards,
Edward

P. S. Hooray, your idea about simply replacing the GC code in Nasal with something else is rather far fetched! That would be an insane amount of work. And we don't have a reproducible set of Nasal GC bottlenecks to benchmark or work towards resolving.
bugman
Moderator
 
Posts: 1710
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: FGPython an propose for Python as an nasal alternative

Postby Thorsten » Wed Mar 07, 2018 5:54 pm

There are a lot of FG developers who believe that parallelization is a waste of time, which strangely conflicts with the goals of the RTI/HLA initiative.


Which just goes to show that it's not Curt's dictatorship after all...
Thorsten
 
Posts: 11106
Joined: Mon Nov 02, 2009 8:33 am

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Wed Mar 07, 2018 6:19 pm

bugman wrote in Wed Mar 07, 2018 8:08 am: Hooray, your idea about simply replacing the GC code in Nasal with something else is rather far fetched! That would be an insane amount of work.


I am not sure where your usual notion of "insane amount of work" (Nasal GC) "mammoth task" comes from this time ?

I am also not sure if you have any relevant background knowledge about scripting language internals (codegen, VMs, GCs) in general, but even if that's the case, it sure doesn't seem like you are familiar with the Nasal GC implementation, or with mark/sweep collectors in general.

The Nasal GC is a rather self-contained, and tiny, module implemented in pure C. It's roughly 500 lines of code, spread across a handful of functions that serve as the GC's "interface" to the rest of the world (Nasal VM). Under the hood there is the equivalent of getprop() and setprop() provided implemented on top of a simple "pool" of pre-allocated memory objects. Each supported Nasal type has its own "pool" of memory (basically a linked list with naRef pointers)

Thus, anybody who's familiar with basic C/C++ syntax can look at the gc.c module and see exactly what it is doing - there is no fancy 3D maths, there's merely a few data structures, a pool and a few getters/setters. That's really all that is used by the rest of the Nasal VM.

Thus, replacing the GC implementation - or even just fixing up/changing the existing implementation is primarily a matter of providing an alternate version that has the same external interface.

This is all extensively documented in the wiki: http://wiki.flightgear.org/How_the_Nasal_GC_works

Now, I realize that this is the point where you'll come up with the excuse that you're really just "putting up a challenge" for me (or others).
But let's be real here, this is 500 LOC - that would not even have to be touched - the file could be copied and adapted as needed to integrate another GC scheme (without having to code the GC algo at all). Compared to some of the real mammoth tasks we've been seing juggled here by some folks (weather subsystems, ALS, space shuttle, FG1000 etc), the work ahead is really straightforwarad and not exactly rocket science.

As a matter of fact, it would be far less work to integrate alternate GC schemes than coming up with HLA/RTI or Python support.

Which is to say, if someone were to spent 6+ months integrating Python (JavaScript, Lua, Perl or whatever else) - a single person could address all Nasal GC issues during a few weekends of spare time hacking, without even having to understand what a GC is doing or how it is working under the hood, at the mere cost of copying gc.c - stripping all code from it, and mapping the external interface to an existing GC library (or possibly several).

You don't have to believe me, but we've previously had the same discussion on the devel list - and even the people who actually looked at Nasal's GC module came to the same inclusion (see comments from James, ThorstenB or AndersG).

And we don't have a reproducible set of Nasal GC bottlenecks to benchmark or work towards resolving.

That is also wrong, and a red herring, too - Andy Ross'es repo at github does provide GC benchmarks.
That being said benchmarking the GC or its performance is not the point of a generational (incremental) scheme is adopted, or a concurrent one - because at that point, you can suspend the execution of the GC and re-schedule it to be continued at a later point in time, or things asynchronously.

Finally, I realize that you belong to the camp of people who don't particularly appreciate quoting on the wiki, but had you actually looked at the Nasal GC docs, you might have learned a few things to make more informed statements here, i.e. by referring to comments made by core developers who've already looked at Nasal's GC.

As things are standing now, the whole thing was considered straightforward at the time by many, but not a priority, due to HLA/RTI's reputation for being "around the coorner", which would have meant that the whole Nasal interpreter could have been moved to a different thread, so that its mark/sweep collector would be irrelevant anyway.

You don't have to believe me obviously - but if you have a working knowledge of C, I'd suggest to take a look at the gc.c module: https://sourceforge.net/p/flightgear/si ... l/gc.c#l35
And then, ask yourself, how much time it is going to take to bring FGPythonSys up to par with SGSubsystemMgr (or FGNasalSys) - and then, imagine what might happen next, if someone were to come up with an adapted version of gc.c linking in an existing GC implementation (e.g. Boehm GC).

Besides, let's keep in mind that you have repeatedly shown remarkable perseverance discouraging people (forum users) from pursuing Nasal related efforts, calling such ideas a dead ends or a mammoth task, without ever checking your facts properly.

And that was only to be proven wrong later on, when the only core developer intimately familiar with the issue at hand (replacing PUI via Qt5) spoke up stating quite clearly that he was concerned a Nasal/Canvas based solution may be more viable, and popular, int the near-term - disagreeing with everything you said on the forum/devel list about this being a "mammoth task", when you were still claiming that the "core developer positon on Qt5 would still be evolving (in favor of Qt5)", whereas the opposite took place (just to provide a context around your choice of words and your tossing around of acronyms) :

http://wiki.flightgear.org/Pui2canvas
James Turner wrote:https://sourceforge.net/p/flightgear/ma ... /29584988/
I'm even more convinced now that we should move the 2D panel and HUD rendering over to this approach, since that would get rid of all the legacy OpenGL code besides the GUI.

https://sourceforge.net/p/flightgear/ma ... /35150746/
I would be delighted if someone is serious about working on the Canvas-based UI, replacing PUI and so on. If there’s people really interested in that, I would much rather help them out, than duplicate their efforts in my limited spare time.

https://sourceforge.net/p/flightgear/ma ... /36195299/
I’m not especially invested in a QQ2 UI - it’s my ‘day job’ work - but obviously I also know the technology. What I don’t want to feel, is that I’m forcing my approach on the community if people think a Canvas-based solution (or a Phi-based one or anything else) would be easier and also deliver a long-term basis for our UI.

https://sourceforge.net/p/flightgear/ma ... /36197666/
my basic feeling is to step back and say, let’s see if a pure Canvas UI will work

https://sourceforge.net/p/flightgear/ma ... /36199572/
My impression is that if [Thorsten] makes a Canvas UI option, the Qt based solution will be still-born almost by default - because I won’t be able to create any enthusiasm or interest around it.

Maybe I’m wrong about that, but for sure Canvas based approaches attract a lot more support and man-power very easily. And my guess each person who works on the Canvas based Ui is one fewer who might ever help out with the Qt based one. (That is not probably 100% true, but I guess there is some correlation)



https://sourceforge.net/p/flightgear/ma ... /36199712/
let’s say the Qt UI is 1/4 of my time per week spent on FG (might be a little more, but I have lots of other things to work on), vs Thorsten’s time and 4 or 8 enthusiastic people he can recruit - I’m obviously going to fall massively behind in comparison - within three or six months they might build a complete replacement UI.





PS: I may be wrong here, but I never got the impression that Curt was pushing for HLA/RTI adoption - it seems that the "official policy roadmap" document was primarily put together by people more or less involved in the project (at the time), but as far as I can tell, Curt has always been giving soapbox speeches discouraging the use of multi-threading in general, and he only began making references to HLA/RTI when Mathias and Stuart were seemingly making progress in the area, and other were hoping that it would magically solve all our main-loop related problems.
What's happened instead is that Mathias was never able to actually release the RTI (called SimKit) - c.f. Stuart's comments in the archives.

That is one of the key reasons why it is good for an open source project to pursue different approaches, because we can never know beforehand whether a certain approach/technology stack is going to work out in the long term (Nasal would be a good example, too - but more a positive one than being a negative one - PUI would be a different beast ...)

Anyway, this is just to say that I really didn't get the impression that Curt had any particular say regarding the "policy roadmap" document.
The situation seems more akin to the times when everbody on the devel list and their dog was hoping to get rid of the default renderer and go all in on "Rembrandt", and we all know how that turned out ...
Last edited by Hooray on Wed Mar 07, 2018 6:40 pm, edited 1 time in total.
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby Richard » Wed Mar 07, 2018 10:07 pm

bugman wrote in Wed Mar 07, 2018 8:08 am:There are a lot of FG developers who believe that parallelization is a waste of time, which strangely conflicts with the goals of the RTI/HLA initiative.


The main problem is not whether the developers think it is a waste of time or not[1], it's the sheer difficulty of getting C++ multi-threaded code to be stable - and I know because I've had to do it a few times; it's especially difficult with an existing architecture. There are more ideas that I've been considering for a good while about how to do this in baby steps - but it is unlikely I'll be able to get anything stable even if I get around to doing it. My initial research[2] shows that there is a benefit to the frame rate but more importantly having the simcore and the rendering free running can help with various other things such as MP latency, control during frame drops etc.


--------------------
[1] after all if it could be possible it doesn't really matter what anyone else thinks - it measuring the benefits that will count.
[2] I ought to finish my write up about this...
Richard
 
Posts: 716
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Wed Mar 07, 2018 10:25 pm

the long standing proposal regarding fgfs parallelization has been to use a process-based strategy in conjunction with message-passing (e.g. via sockets for starters) - and to be able to wrap up the whole thing to run in a bunch of background threads inside the same process that use shared memory for IPC purposes. This is in line with the original proposal, but also with the plans that Mathias' subsequently communicated on the devel list when he talked about HLA/RTI.

Later on, a number of folks realized that HLA/RTI was nowhere close to being around the corner, and suggested to equip certain subsystems (low-hanging fruits) with their own private property tree instances, while "mounting" their own instance in the main/global tree to implement a simple MPI-like system on top of a handful of distributed property systems, where getrop()/setprop() would only ever get/set messages.

James and others came up with a number of proposals relating to that (if in doubt, refer to the edit histories of such articles or the links pointing back to the original discussions):

http://wiki.flightgear.org/Property_threading
http://wiki.flightgear.org/Distributed_ ... FlightGear
http://wiki.flightgear.org/Remote_Properties
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Wed Mar 07, 2018 10:35 pm

@Richard: I'm well aware of the fun of threading. As well as other multi-core solutions. If you missed that old discussion on the mailing list, my thoughts were that the subsystem manager could be parallelised so that each subsystem is its own thread. But the subsystems are so brittle that this would take a lot of work to prevent them from crashing.

Regards,
Edward
bugman
Moderator
 
Posts: 1710
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: FGPython an propose for Python as an nasal alternative

Postby bugman » Wed Mar 07, 2018 10:43 pm

@Hooray: The mammoth task of GC is that GC is highly solution dependent. What works well for one piece of software might be terrible for another. So for Nasal embedded in fgfs, you would probably need to compare different techniques by implementing each, and then finding bottlenecks. Then comparing to Python's unique reference counting approach (almost 2000 lines of code, see https://github.com/python/cpython/blob/ ... gcmodule.c) would still be beneficial. You may also have to provide new interfaces for a different GC scheme, as those currently provided by Nasal's current GC implementation may not be enough.

Regards,
Edward
bugman
Moderator
 
Posts: 1710
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Wed Mar 07, 2018 10:57 pm

No, the key benefit is either making the GC incremental or getting the GC out of the main loop (ideally, both obviously).
Because right now the mark/sweep collector will run entirely in the main loop, which is where and why it may cause lag.
Patches posted by AndersG and ThorstenB have already demonstrated that it is possible to move some aspects of the GC to a background thread, depending on the circumstances. No "insane amount of work" involved here (if in doubt, check back with their original comments)

The GC bottleneck is not the real issue, it took roughly 10 years for the GC to become an actual issue anyway (and that's still largely due to poorly structured code).

Your last point is valid though, and it is something that we completed ~5 years ago in the canvas-hackers team clone, when we generalized the GC interface.
Some of which can still be found online, in a branch named nasal-gc-interface

SGSubsystemMgr can really only run self-contained subsystems in a thread, and if they are not self-contained because they use the property tree or other global data structures.
Simple stuff would be a property sampling system, e.g. the logger or the flight path history subsystem - because those only read from the global tree but don't actually write to it.

Like I said previously, even complex subsystems like Canvas could be moved to a separate thread that way. But I would certainly tinker with really simple ones ("history", "logger").

Besides, if you had looked up the history of the Nasal GC and discussions related to it, you'd know that Python's reference counting has been previously discounted by both, TIm Moore and ThorstenB.

And again, AndersG's patch didn't make it because it came up at a time when the Canvas system got added, which is adding tons of naGhost objects wrapping C++ pointers that may belong to OSG/rendering stuff, which was rather fragile (poor timing).
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby AndersG » Thu Mar 08, 2018 7:16 pm

Hooray wrote in Wed Mar 07, 2018 10:57 pm:And again, AndersG's patch didn't make it because it came up at a time when the Canvas system got added, which is adding tons of naGhost objects wrapping C++ pointers that may belong to OSG/rendering stuff, which was rather fragile (poor timing).


OTOH, I think James quickly fixed that problem by handing the naGhosts back to the main thread for destruction. I still use that (James') version of the patch. The main issue with that approach is that since the Nasal GC isn't incremental it can still stop the main thread when one GC cycle (mark + sweep?) takes too much time. I have both my old version and James' version of the patch on my website - but unfortunately it is currently off-line while we await getting attached to the local access network again (which may entail waiting for the ground to thaw first..).
Callsign: SE-AG
Aircraft (uhm...): Submarine Scout, Zeppelin NT, ZF Navy free balloon, Nordstern, Hindenburg, Short Empire flying-boat, ZNP-K, North Sea class, MTB T21 class, U.S.S. Monitor, MFI-9B, Type UB I submarine, Gokstad ship, Renault FT.
AndersG
 
Posts: 2444
Joined: Wed Nov 29, 2006 9:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Fri Mar 09, 2018 2:59 pm

Okay, thanks for clarifying - since you are among a few people to have successfully touched the Nasal gc module, what is your opinion - i.e. is it indeed a "mammoth task" to modify the existing mark/sweep collector and/or integrate another (optional) one to experiment with alternate schemes ?

My impression is that we've seen a handful of folks who have come up with gcc related changes, it's just that those were never integrated (not even in an optional way).

And like I said previously, I also suppose that modifying Nasal's GC would be much more straightforward than integrating FGPythonSys in a fashion that brings it up to part with FGNasalSys or even the SGSubsystemMgr interface in general (speaking about HLA/RTI and other acronyms used here).

As far as I remember James was actually considering to add your patch at the time, at least to provide an option - and a few months ago, you also said something along the lines that those patches should/could be revisited ?
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: FGPython an propose for Python as an nasal alternative

Postby AndersG » Fri Mar 09, 2018 8:15 pm

I think the amount of work needed to replace the Nasal GC depends very strongly on what you want to replace it with. I am certainly no expert on GCs but I think concurrent and possibly incremental schemes need to wrap pointer reads and writes to GC owned memory in user code to capture changes that happens while the GC is running. That might not be so difficult in interpreted or JITed code (I think a typical Java or .NET virtual machine does it) but is much worse in C/C++ library code as it would need to be manually inserted there (or need special compiler support).

It might be that a GC that is only incremental (still stops the world - but for shorter periods) can be done without that kind of instrumentation, but I don't know. If it is so that would be the best bet for Nasal in FG - there probably are parts of each main loop where no Nasal needs to run so an extra thread on a spare core could advance the GC state without blocking main loop progress.
Callsign: SE-AG
Aircraft (uhm...): Submarine Scout, Zeppelin NT, ZF Navy free balloon, Nordstern, Hindenburg, Short Empire flying-boat, ZNP-K, North Sea class, MTB T21 class, U.S.S. Monitor, MFI-9B, Type UB I submarine, Gokstad ship, Renault FT.
AndersG
 
Posts: 2444
Joined: Wed Nov 29, 2006 9:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: FGPython an propose for Python as an nasal alternative

Postby Hooray » Fri Mar 09, 2018 8:44 pm

In general, the mark/sweep algo is considered to be the most basic and most straightforward GC algorithm.

The lowest hanging fruit from an optimization standpoint is usually converting a mark/sweep algo into a tri-color GC scheme: https://en.wikipedia.org/wiki/Tracing_g ... or_marking

Andy himself suggested the use of generations in response to ThorstenB's findings:
http://www.mail-archive.com/flightgear- ... 37385.html
Andy Ross wrote:allocating objects into generations and only mark/reaping from the most recent one on most iterations is a straightforward optimization and will definitely make things faster.


A generation could basically be an array of a naPool here

Regarding existing C++ library code (extension functions), that's a good point - but I believe it could be addressed by wrapping all naRef handling so that reads/writes (updates) only ever take place using the equivalent of setters/getters
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to New features

Who is online

Users browsing this forum: No registered users and 0 guests