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 07:41, 12 August 2014
, 12 August 2014→Performance issues on non-high end computers
(→Performance issues on non-high end computers: - indentation) |
|||
| Line 75: | Line 75: | ||
:::::So, what of my mention earlier that the extra500 issues are not caused by the model, or by 'older' hw, but by the nasal code was not true? Nevermind the fact that this isn't about the extra500 or about nasal. And yeah, I have no clue on how to test stuff, I just pull figures and results out of thin air... (hint: the cube remark should have already shown you that I've tested the extra500 in various scenarios to reach my conclusion, although the cube was a bit superfluous as setting the draw masks already proved that the 3d-model had nothing to do with the performance issues). And, as clueless and trollish as I am I never bothered to check deeper what was going on, and I never saw that '''mark''' and '''reap''' are the two most frequent calls (followed by various naGC stuff)... wonder to which subsystem those belong to? Right, all, together, repeat after me: '''N A S A L'''. Oh, btw, you can get your nasal golden-boy into trouble just by using the scroll wheel to zoom in and out, and ignoring the evidence you stand here declaring that it's the next best thing since sliced bread... Is the GC part of nasal or isn't it (it is), will you run into GC issues sooner or later (you are), so keep it as "glue" between stuff, but please stop doing overly complex stuff in it, like reimplementing half of a FDM in it, and please stop claiming that it doesn't cause performance issues, as it does, and is one of the prime reasons FG has such poor performance (along with raw number of objects (drawables) in scene). | :::::So, what of my mention earlier that the extra500 issues are not caused by the model, or by 'older' hw, but by the nasal code was not true? Nevermind the fact that this isn't about the extra500 or about nasal. And yeah, I have no clue on how to test stuff, I just pull figures and results out of thin air... (hint: the cube remark should have already shown you that I've tested the extra500 in various scenarios to reach my conclusion, although the cube was a bit superfluous as setting the draw masks already proved that the 3d-model had nothing to do with the performance issues). And, as clueless and trollish as I am I never bothered to check deeper what was going on, and I never saw that '''mark''' and '''reap''' are the two most frequent calls (followed by various naGC stuff)... wonder to which subsystem those belong to? Right, all, together, repeat after me: '''N A S A L'''. Oh, btw, you can get your nasal golden-boy into trouble just by using the scroll wheel to zoom in and out, and ignoring the evidence you stand here declaring that it's the next best thing since sliced bread... Is the GC part of nasal or isn't it (it is), will you run into GC issues sooner or later (you are), so keep it as "glue" between stuff, but please stop doing overly complex stuff in it, like reimplementing half of a FDM in it, and please stop claiming that it doesn't cause performance issues, as it does, and is one of the prime reasons FG has such poor performance (along with raw number of objects (drawables) in scene). | ||
:::::[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 00:37, 12 August 2014 (UTC) | :::::[[User:I4dnf|I4dnf]] ([[User talk:I4dnf|talk]]) 00:37, 12 August 2014 (UTC) | ||
::: Like I said, the issue is not as simple as some make it sound. There's a thing we commonly call "GC pressure", i.e. the pressure that is put on the GC scheme by certain code. | |||
::: Some code is much more likely to increase GC pressure. I'm not sure where you read that I said you'd be wrong - quite the opposite actually, I believe this to be one of the few instances, where we have overlapping interests. | |||
::: As you may know (or not), I once documented our GC scheme, [[How the Nasal GC works]] - part of this also involved tinkering with different GC schemes, and generalizing the existing scheme such that new schemes could be implemented next to the existing one - so yeah, I guess you could say that I am a little familiar with the current GC scheme, so there's really no need to resort to polemics here. | |||
::: I am genuinely interested in understanding the problem, but not in an aircraft-specific context, but in a global context. And I am interested in providing a toolbox for aircraft developers that they can use to look "behind the scenes", which involves Nasal, but is certainly not restricted to scripting. | |||
::: As you may have also read elsewhere, we've also been playing with a generational GC scheme, a suggestion made by Andy Ross himself, which would just be a modification of the existing scheme, so not totally new - but it would decrease the workload for mark/reap considerably. | |||
::: However, like I said, the issue is not just a "black/white" one (hey, a real GC pun ...) - we've seen massive features implemented in Nasal that have almost negligible impact, while we've seen trivial code implemented, using naive algorithms, that basically blocked the whole main loop. | |||
::: So, believe it or not, I actually share some of your concerns here, but I believe in a different solution - I also find it unfortunate that some people used Nasal to do extensive systems modeling without ever benchmarking their code to find hot spots. But like we've previously said, that's primarily due to the core development bottleneck, and not because people generally want to write Nasal over C++ - C++ patches typically take many months to get discussed, reviewed and committed (some of my own merge requests have been up for months without anybody taking a look). | |||
::: Nasal is very much like JavaScript here, and isn't formally reviewed by others, which is why its accessibility is so much better, i.e. the entry barrier so much lower. Things like FDMs should probably not be implemented in Nasal - we've once toyed with OpenCL bindings that would be a much better choice here, without sacrificing any flexibility, and even superior to native C++ code, because main loop impact could be significantly reduced. | |||
::: People can misuse technologies, no matter if it's C++, GLSL, XML/property-mapped subsystems like JSBSim/YASim or scripting engines like Nasal - but even if we were to fix the GC within the next couple of weeks, there's still plenty of algorithmically-naive code in various places, no just Nasal, but also the core C++ code. | |||
::: For instance, many users have been reporting that FG/osgEarth performance is superior for them over our native scenery engine. And the "minimal startup profile" provides a fairly good starting point to gather a list of "heavy" subsystems. Seriously, Nasal is just a symptom here, because it's accessibility is so much better, so that non-coders can use it to implement features that don't have to go through the hassle of being peer-reviewed across months (if not years ...). And certain problems would remain, even if the GC were to be optimized tomorrow (which we know perfectly well how to do meanwhile). As I said previously, I once had to rip out Nasal entirely, and performance still wasn't very impressive back then. But I think providing such a startup mode (=zero Nasal) could actually be useful to help us better understand/troubleshoot and fix subsystem-specific issues - i.e. if performance without Nasal is so much better, the Nasal engine needs to be reviewed accordingly. | |||
::: This is something that we've been working towards, funnily via Initializing Nasal earlier and delegating bootstrapping to scripting space, which makes it straightforward to exclude many modules on a subsystem-specific basis, i.e. analogous to "Run-Levels". And things like the [[Interactive Nasal REPL]] can easily provide 400+ hz/fps with ~10 ms once a bunch of '''native''' C++ subsystems are completely disabled, using the existing mark/sweep GC BTW. | |||
::: I don't know just how familiar you are with various GC schemes, but the next challenge here is that things are not as deterministic as you want them to be, i.e. GC pressure can be increased by code that ran long before/after the actual GC invocation occurs. But like I said, fixing the GC isn't exactly rocket science, but it also isn't exactly exciting work, and it would be primarily "visible" in terms of improved frame rates/frame spacing that is GC induced. However, I feel, that would just be another step to keep on masking more pressing issues, such as getting rid of algorithmically-naive code, and using bindings to native C++ code for such purposes, or really OpenCL. | |||
:::But I really don't think that polemics will get us very far, or even just empty/unsubstantiated claims. I am sincerely interested in helping fix such issues, and think this is one -of the very few- opportunities where the two of us could team to come up with a subset of overlapping goals (better troubleshooting/debugging/profiling/performance). The patches I've posted on the forum make it possible to get a list of expensive callbacks for the whole session, i.e. by hooking into timer/listener callbacks. Likewise, another patch can measure GC impact - extending that to determine GC pressure per module (created/removed naRefs per namespace/submodule) would not be very complicated - ThorstenB put up patches doing this on a wider scale, tracking active/dead naRefs per module would help aircraft developers better understand how much workload they're adding. As you undoubtedly know, dumb code can be written in all languages, including even GLSL or assembly language. A language that is "closer to the metal" (like C++) will just help masking the problem until it adds up, as can be seen in the FG main loop meanwhile, which for many people still is CPU-bound. Then again, ripping Nasal out of the main loop would be another option here, but people would need to follow certain coding patterns to make that work. --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 07:41, 12 August 2014 (UTC) | |||
:::quote i4dnf: ''(Would it interest you if I told you I can run trees and random buildings at density 2.9 on an 8800GT with minimal framerate impact? Oh yeah, with dense 'grass' generated nearby too? This requires minimal changes to the source, but its not really prime-time ready yet)'' | :::quote i4dnf: ''(Would it interest you if I told you I can run trees and random buildings at density 2.9 on an 8800GT with minimal framerate impact? Oh yeah, with dense 'grass' generated nearby too? This requires minimal changes to the source, but its not really prime-time ready yet)'' | ||