bugman wrote in Wed Mar 07, 2018 9: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_worksNow, 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#l35And 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/Pui2canvasJames 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 ...