V12 wrote in Wed Feb 19, 2020 10:36 pm:Where in the Your graphs are Nasal jobs, AI management jobs etc ?
We have Oracle database for realtime production process monitoring with write data rate around 1000 values per second. No problem. I can monitor all subprocesses via SQL queries, make online graphics visualization of material flows etc. With good commit policy You never fall into problems.
Richard wrote in Thu Feb 20, 2020 11:44 pm:There are aircraft (777, A320) that require a lot of Nasal and canvas and these can put a heavier load; but also I think I've shown that it is possible to make a lot of improvements within the aircraft model as the F-15 used to also be heavy because of Nasal and canvas.
Hooray wrote in Fri Feb 21, 2020 11:52 am:...with a corresponding background, Nasal and Canvas can be heavily optimized - but that's not the point: the majority of aircraft developers don't have a 10+ year track record of contributing to FlightGear, and they rarely have a degree in software engineering, computer science or maths/physics.
Hooray wrote in Fri Feb 21, 2020 11:52 am:Just saying that all performance issues are due to the current scenery/terrain scheme, and that LOD will make everything better is far too simplistic
Richard wrote:As a separate activity it certainly would be nice to get some of this logic running on another CPU thread - but that's even more complicated than optimising Nasal/Canvas - I don't think that it is something we can hope to do in the core any time soon because of the lack of thread safety.
Hooray wrote:[...]there is a thing called the global property tree, and that there is a single global scripting interpreter. The bottleneck when it comes to Nasal and Canvas is unnecessary, because the property tree merely serves as an encapsulation mechanism, i.e. strictly speaking, we're abusing the FlightGear property tree to use listeners that are mapped to events, which in turn are mapped to lower-level OSG/OpenGL calls - which is to say, this bottleneck would not exist, if a different property tree instance were used (per Canvas (texture)).
This, in turn, is easy to change - because during the creation of each canvas, the global property tree _root is set, which could also be a private tree instead.
Quite literally, this means changing 5 lines of C++ code to use an instance-specific SGPropertyNode_ptr instead of the global one.
At that point, you have a canvas that is inaccessible from the main thread (which sounds dumb, but once you think about it, that's exactly the point).
So, the next step is to provide this canvas instance with a way to access its property tree, which boils down to adding a FGNasalSys instance to each Canvas - that way, each canvas texture would get its own instance of SGPropertyNode + FGNasalSys
Anybody who's ever done any avionics coding will quickly realize that you still need a way to fetch properties from the main loop (think /fdm, /position, /orientation) but that's really easy to do using the existing infrastructure, you could really use any of the existing I/O protocols (think Torsten's ajax stuff), and you'd end up with Nasal/Canvas running outside the main loop.
The final step is obviously making the updated texture available to the main loop, but other than that, it's much easier to fix up the current infrastructure than fixing up all the legacy code ...
[...]
telling the canvas system to use another property tree (SGPropertyNode instance) is really straightforward - but at that point, it's no longer accessible to the rest of the sim.
You can easily try it for yourself, and just add a "text" element to that private canvas.
The interesting part is making that show up again (i.e. via placements).
Once you are able to tell a placement to use such a private property tree, you can use synchronize access by using a separate thread for each canvas texture (property tree).
But again, it would be a static property tree until you provide /some/ access to it - so that it can be modified at runtime, and given what we have already, hooking up FGNasalSys is the most convenient method. But all of the canvas bindings/APIs we have already would need to be reviewed to get rid of the hard-coded assumption that there is only a single canvas tree in use.
Like you said, changing fgfs to operate on a hidden/private property tree is the easy part, interacting with that property tree is the interesting part.
Also, it would be a very different way of coding, we would need to use some kind of dedicated scheduling mechanism, or such background threads might "busy wait" unnecessarily.
Richard wrote in Thu Feb 20, 2020 11:44 pm:Fast, lock free, sharing of data between real time threads is a fundamentally hard problem to solve.
Hooray wrote in Fri Feb 21, 2020 6:47 pm:Under the hood, the property tree isn't much more than a simple LDAP-like key/value database.
So, there's that, too - even though, the approach would still look very different to dBase-style 90s code
Users browsing this forum: No registered users and 3 guests