20,741
edits
Talk:North American P-51 Mustang: Difference between revisions
Jump to navigation
Jump to search
m
Talk:North American P-51 Mustang (view source)
Revision as of 22:23, 13 August 2014
, 13 August 2014→Impact of Nasal scripts: not quite ...
(As the title says, the Talk is about the model of the North American P-51 Mustang, which doesn't suffer from any nasal scripts perfomance issues, that's why it is OT. Point.) |
m (→Impact of Nasal scripts: not quite ...) |
||
| Line 121: | Line 121: | ||
::::So that's the real problem behind: devs completely forgetting their users, completeley being in a mania. | ::::So that's the real problem behind: devs completely forgetting their users, completeley being in a mania. | ||
--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 12:57, 12 August 2014 (UTC) | --[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 12:57, 12 August 2014 (UTC) | ||
:: I don't quite agree with you here, I tend to agree more with i4dnf in this case. Filters are obviously a straightforward example, but the main issue here is that native code isn't currently sufficiently exposed to Nasal (yet) - TorstenD was originally planning to expose the corresponding AP/PID logic to scripting space[http://forum.flightgear.org/viewtopic.php?f=66&t=15189&p=149376&hilit=#p149376] - that was in the pre-[[Canvas]], and thus, pre-[[Nasal/CppBind]] days. | |||
::Meanwhile, it should be a fairly straightforward optimization to get rid of such scripting space workarounds, but there's still a certain overhead involved in porting existing legacy code. [[FGCamera]] obviously has to work around existing limitations, so cannot rely on patches or optional features. But given the quality of the code involved there, I am sure that its developer would be happy to adopt native code (if/once available). I do agree that it would be good to have a Nasal reviewer, but this is a clear case where existing Nasal code should be made obsolete and re-implemented on top of existing C++ code, like i4dnf suggests, and like it is being done with [[Canvas]]-some core developers are actually working towards doing this in other areas, including the geo.nas module which is increasingly used/important, and which should really be using native C++ code, instead of re-implemented algorithms in scripting space [[Plan-zakalawe]]. I don't think it's fair to suggest that people don't use more efficient techniques as long as those are not made available, i.e. as long as the corresponding patches are not reviewed/committed. Scripting-space workarounds for filters, PID controllers or even geodetic calculations are also a workaround IMO, no matter just how sophisticated they are-ThorstenR even implemented fairly advanced quadtrees in scripting space a few years ago, and they did work very well - but obviously cannot beat the performance offered by native code. Nasal is just a tool, and people don't need to know much about coding to use it and to come up with working features - unfortunately, at the cost of performance more often than not. The main issue here is not that "devs" are forgetting about end-users and their horsepower, but rather that middleware developers have no good way to tell just how expensive certain features/coding constructs are - there are very few contributors who actually understand how to benchmark/profile a piece of Nasal code, and how to tell where/why certain things are indeed slow - ThorstenR, i4dnf, AndersG, Philosopher, TheTom and a few others come to mind as counter-examples. | |||
:: But usually, people have no clue how to tell where/why a certain piece of code is slow. Usually, you need to have a background in computing, absent that, you need to have at least a background in statistics/maths and run dozens of benchmarks to come up with figures for different coding constructs/combinations of features to better understand what's going on. The number of people able to interpret Nasal internals, and scripting-induced slowness, is very low, probably not even half a dozen. And I would hope that it is left to them to decide if/how to address certain problems - aircraft developers have been demonstrating for years that they cannot be expected to properly manage scripting resources, including timers, listeners and memory. | |||
:: I am not trying to put words in mfranz's mouth here, but I have zero doubt that he would agree with these sentiments based on his track record, i.e. code/contributions and his postings on the devel list. | |||
:: Overall, the majority of aircraft/middleware developers seem just ill-informed when it comes to writing fast code - for understandable reasons, and we wouldn't be in a much better situation with a different programming language, such as Lua, Perl or JavaScript. There are simply certain algorithmic issues involved here, in combination with technical restrictions on the FlightGear side of things. There are very few people who are able to write fast code, and the few that do, happen to be core developers/contributors, or at least have some form of background in computing, so that the language used to solve a problem, usually doesn't matter at all. | |||
:: People complaining about the degree of Nasal usage should keep in mind that Nasal usage is really just a symptom that's contributing to a deeper issue here, i.e. pace/lack of core development in comparison to base package development - i.e. there's more manpower on the base package side of things, and it's the kind of manpower that is difficult to harness/educate otherwise. It is pretty safe to say that all aircraft developers would love their aircraft to perform sufficiently well - so nobody wants degrade performance - but what's happening is that core development cannot keep up with base package development. Just look at native C++ code that is getting phased out currently (HUD, 2D panels, [[Map]], GUI, KLN89, wxradar, agradar etc): often, it's been in the works for years, usually unfinished and unmaintained, and things like Gijs NavDisplay are now making stuff obsolete that hasn't been touched in years, all within just a few months. And this has nothing to do with Nasal or scripting in general, it's mainly about accessibility, i.e. barriers to entry. | |||
:: Previously, such features would be developed by core developers within 18-24 months, and left in the source tree, where base package developers couldn't easily extend existing features - now, such things are exposed to scripting space, and it's obvious that manpower to continue developing such features is indeed available. People can condemn technologies like [[Nasal]] or [[Canvas]], but the only thing these technologies are proving is that we simply have more "unskilled manpower" in the base package department than we have "skilled manpower" in the core area. Which kinda is the whole reason for introducing top-level frameworks that serve as wrappers for native code integrated via cppbind. From then on, it's the less-experienced department, i.e. base package developers, that actually need to adopt such best practices, or their way of contributing "naive" solutions in scripting space will continue to slow down the simulator, simply because more efficient coding paths are never leveraged - we've seen that in the whole AP/RM area, where aircraft developers like omega95 were really frustrated with all the progress that had been made, which meant that existing aircraft/code had to be ported due to the non-generic nature of the corresponding code - which put a lot of stress on core developers, but it really is the right thing to do - and I have no doubt that even i4dnf will agree with this sentiment, even though people are usually part of the problem without even realizing it, i.e. by rejecting frameworks that people are providing in order to localize functionality that can be easily wrapped/replaced via native code eventually. This is one of the main issues preventing the extra500 from being up to 1.5-2.5 X faster probably - and here, the main challenge is not a technical one, but simply inertia. But like I said, I'd rather have this discussion with people who have demonstrated an understanding of the underlying issues, because we cannot possibly expect to turn aircraft developers into software engineers (or vice versa!). | |||
:: Likewise, if I were to do a JSBSim FDM or a GLSL shader, I might very well only use a tiny subset of the features offered by the FDM/GPU, and my constructs would be fairly inefficient - it probably wouldn't matter to me (but just work well enough), but once we have dozens of people contributing in a similar fashion, things (=slow code) will obviously add up and add some point cripple overall performance. So this is not a Nasa specific issue - it comes with "de-skilling", and can even be seen outside scripting, i.e. in XML expressions, AP/PID/JSBSim systems and even GLSL shaders. And there's a ton of Nasal code written by very knowledgeable people like mfranz, but even most of that code should probably be wrapped/replaced using native code these days - simply because use of scripting has grown so rapidly over the years (bombable, local weather, FGCamera, Canvas etc) that having "slow" scripting code may add up quickly, because a module written 5+ years ago (such as e.g. the geodinfo API) was never designed to handle use-cases that people have meanwhile come up with. So this is not just about "reviewing" Nasal code, but more about identifying optimization opportunities, and about '''enforcing''' best practices by rejecting certain contributions until they're sufficiently reviewed. It is pretty safe to say that [[A local weather system]] probably would have never stood a chance of being committed if it had been reviewed/dissected by mfranz - still, it's become one of the most popular features added "recently" - but the developer who wrote it, was also learning about FlightGear scripting back then, and he even agrees that the structure would be very much different if he had to write the same system today. So there's pros & cons here, a stringent code review of a new Nasal addon might have very well alienated a new contributor a few years ago - these days, even mediocre/inferior implementations may be committed, and given time to improve. And in the case of the LW/AW system, one of the most active FGData committers has evolved meanwhile, without him ever having touched a single aircraft AFAIK. So quality standards are a double-edged sword obviously. What we're seeing is not a problem introduced by "developers" per se, but by aircraft developers becoming "programmers" in a new environment where the barrier to entry, due to Nasal, is very low. | |||
:: If the same people had to deal with raw memory management and threading (i.e. by writing C or C++ code), we would not just see a slow-ish simulator, but one having '''even more''' segfaults than we have already... And having/supporting a more mainstream-scripting language like Lua, Python or Perl/Ruby would simply mean that the problem would be magnified tremendously because the barrier to entry would be even lower than it is already, and we'd see a ton of proprietary/platform-specific extensions (libraries/DLLs) being used by a huge community of "modders", where features may only work for certain platforms/operating systems. Nasal being a "niche" language isn't exactly problematic from that standpoint, because it helps streamline contributions, without us having to ship all sorts of scripting frameworks. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 22:23, 13 August 2014 (UTC) | |||
==[OT: trees and random buildings]== | ==[OT: trees and random buildings]== | ||