20,741
edits
User talk:Hvengel: Difference between revisions
Jump to navigation
Jump to search
m
→Spinner animation
mNo edit summary |
|||
| Line 30: | Line 30: | ||
:: I think some apologies towards Hvengel are in order, for abusing his talk page. | :: I think some apologies towards Hvengel are in order, for abusing his talk page. | ||
::[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 14:34, 14 July 2014 (UTC) | ::[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 14:34, 14 July 2014 (UTC) | ||
::: Philosopher is right, the FDM in FG doesn't run in its own thread for the time being, it's just running interleaved with a few other subsystems (e.g. AP) - but FDM computations ARE part of the main loop. At the end of the day, Nasal is just a tool - which will normally be slower than C++, but easier to use for most people. It is true that many XML constructs are usually harder to misuse compared to Nasal, simply because most XML is directly mappped to C++ constructs and loops acting there like a "state machine" that is re-evaluated for each iteration cycle. | |||
::: But even the C++ code is often fairly naive and not particularly optimized, JSBSim script is fairly simple here - there's at least a dozen of possible optimizations to sneak out better performance last I checked, but it is much harder to introduce constructs that actually show up when profiling, because C++ is so much faster than Nasal obviously, and because it's not subject to GC. | |||
::: The extra500 is a different matter, there are various coding constructs & patterns in use that are known to be problematic, and it's also suffering from issues that were recently discussed on the forum (e.g. callbacks gobbling up, even copies of identical callbacks running, such as callbacks running FDM-interleaved even though they shouldn't). | |||
::: Overall, people still need to understand the tools they're using, especially when abstraction layers are involved - no matter if it's Nasal, XML or C++ - obviously, the latter two are usually faster, but there's lots of algorithmically-slow C++ code that doesn't need to be slow at all, it was just never optimized because it seemed "fast enough" - even though it's usually the combination of code interacting with other code that's becoming a challenge. The AI system has a ton of examples for this. I am all for favoring "faster" code, but in this instance it isn't exactly fair to blame it all on Nasal, because those performance issues are not primarily due to Nasal being slower than C++, but due to algorithmic issues, and inferior implementations. We've seen the same debate and uninformed arguments WRT using looping constructs like for/foreach/forindex in Nasal, and people were told to avoid them at all costs - despite the fact that the same problem remains once you run too many iterations of a loop in C++. | |||
::: I wouldn't say that Nasal is getting a lot of support, there are still a handful of very real issues related to Nasal - but the majority of challenges stem from the fact that we have so many people using it that have zero background in coding, so they're not aware of the implications of using certain coding patterns and constructs, or what is happening under the hood. | |||
::: But a few of us actually understand how to write sufficiently fast Nasal code for most cases - Thorsten is a great example for this, he's written some hand-optimized Nasal code that would often outperform existing/naive C++ implementations, but he's also religious about doing lots of testing and gathering statistics before he optimizes something. | |||
::: I understand that's also the method he's using in GLSL/effects. We've offered and provided feedback regarding the Nasal/Canvas side of the extra500, and even offered to get involved to help with certain things-so far, to no avail unfortunately-and now I am frankly spending my time where feedback, help & support are actually honored. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 14:51, 14 July 2014 (UTC) | |||
== Ubershader Issues == | == Ubershader Issues == | ||