884
edits
Talk:North American P-51 Mustang: Difference between revisions
Jump to navigation
Jump to search
Talk:North American P-51 Mustang (view source)
Revision as of 12:57, 12 August 2014
, 12 August 2014no edit summary
(Answer to Hal) |
No edit summary |
||
| Line 112: | Line 112: | ||
::: 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. | ::: 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. | ::: 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) | :::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) | ||
::::Hooray, | |||
::::some times I think the way nasal scripts used by some authors are like the way you are writing: much too much, and far away from what is really needed. | |||
::::Why using nasal coded filters, when we already have cheap filters? (example: alternative camera...) | |||
::::I often wishes Melchior Franz would be back. | |||
::::i4dnf, me and others know what wonderfull tool nasal is and what can be achieved with it. But the usage of it gives me big headaches: it has the same origin like other overdone aircraft like 777 or sceneries. Having a powerful "super" machine and now they wants it all and already maxing it out. But forgetting that only few people have such a machines. And forgetting that there are a lot more features beside their work which wants to be used. | |||
::::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) | |||
==[OT: trees and random buildings]== | |||
:::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)'' | ||
:::and how much is the impact on RAM? I remember that random buildings at their beginning had been very dense and framerate had been really good- but RAM usage was horrible. | :::and how much is the impact on RAM? I remember that random buildings at their beginning had been very dense and framerate had been really good- but RAM usage was horrible. | ||