Since I don't follow the 'rule' by coding 10.000+ lines in Nasal, I
suppose that is partially thrown into my direction. From where I stand,
there are good reasons to use Nasal - first of all the userbase which
regularly compiles their own code is small, whereas people do install
addon
FYI I'm currently looking at adding support for creating a 3D shader
cloud
using Nasal, to bypass the need to have XML wrappers etc. I'm hoping
that this can off-load some of the low level quad-tree work you
currently
have to do.
That's absolutely splendid news! If there's a hard-coded
For the time being, we'll have to live with this. We should just be
aware, that introducing too complex data structures and too
heavy/complex computations in Nasal isn't a good idea. Even when their
average execution time looks ok, they will eventually trigger noticeable
frame rate jitters.
On Sun, Mar 27, 2011 at 1:17 PM, Thorsten Renk wrote:
But if people feel that things inside e.g. the Local Weather package (or
somewhere else) should be ported from Nasal to C++ - by all means do so,
don't just complain :-) You have the Nasal code available, I for one am
entirely willing to
Hi,
here's a few more comments/hints/warnings on Nasal and simulation
performance in general.
First of all: it's not meant _against_ anybody. It's great to have a
tiny scripting engine in FG. It's great to have an option for custom
extensions. And we're certainly seeing very nice examples
On Sat, Mar 26, 2011 at 6:27 AM, Robert dogg...@googlemail.com wrote:
Indeed the jitter is caused by Nasal's garbageCollect method. Simple
test: add a printf (apply attached patch to simgear) and you should see
the stutter is synchronized with it.
True! The text is printfed with every jitter.
On 26.03.2011 06:27, Robert wrote:
However, the garbage collector does a complete scan of all Nasal
objects to detect and remove unreachable elements. So, the more
Nasal data elements we have, the worse the jitter gets. Large
Nasal data structures will eventually break every
On 26.03.2011 10:03, Tim Moore wrote:
Reference counting doesn't provide a strong performance advantage over
conventional garbage collection, and a reference-counting scheme can
take an unbounded amount of time. Reference counting schemes that do
have real-time or bounded behavior are very
On Sat, Mar 26, 2011 at 6:27 AM, Robert dogg...@googlemail.com wrote:
Indeed the jitter is caused by Nasal's garbageCollect method. Simple
test: add a printf (apply attached patch to simgear) and you should
see
the stutter is synchronized with it.
True! The text is printfed with every
On Thu, 24 Mar 2011 14:33:45 +0100, Robert wrote in message
AANLkTi=ev_fsxjcvn8jj7+aiav6hzj6pq6spbyrnn...@mail.gmail.com:
--prop:/sim/rendering/multi-sample-buffers=true
..this segfaulted on my 3 day old git, will retest with todays.
This maybe a problem with your graphics
Indeed the jitter is caused by Nasal's garbageCollect method. Simple
test: add a printf (apply attached patch to simgear) and you should see
the stutter is synchronized with it.
True! The text is printfed with every jitter.
Well, there is a workaround! Use a faster CPU :). I see a jitter
With Thorstens patch I have identified the subsystem that causes that prob.
It comes up at exactly the same rates that I posted earlier.
It's the EVENTS subsystem.
Timing summary for events.
- mean time: 0.15 ms.
- min time : 0.08 ms.
- max time : 18.21 ms.
- stddev : 0.81 ms.
Is event_mgr.cxx the right place to look at?
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of
* Robert -- Thursday 24 March 2011:
Is event_mgr.cxx the right place to look at?
Well, the main purpose of the event manager is to handle
Nasal's settimer() code. So you better look for slow recurring
Nasal code. You can redefine settimer() and let it output the
time spent. I can't test that at
Argh, no. Of course you want to know how much time the execution of
the function took, not the settimer call itself. So it'll be more
like this:
var orig_settimer = globals.settimer;
var globals.settimer = func(fn, interval, mode = 0) {
var where = caller(1);
On Thu, 24 Mar 2011 03:05:28 +0100, Arnt wrote in message
20110324030528.55839966@celsius.local:
On Wed, 23 Mar 2011 05:56:49 +0100, robert...@web.de wrote in message
AANLkTimUGMjCn2y=FWw4Avt6tx_5d3M=ywxsetz6w...@mail.gmail.com:
..maybe Robert can tell us the FG command line etc recipe
--prop:/sim/rendering/multi-sample-buffers=true
..this segfaulted on my 3 day old git, will retest with todays.
This maybe a problem with your graphics drivers. This option turns on
Antialiasing. As I can see you use the R300 graphics drivers.
Have you tried AMD's/ATI's proprietary
On 24.03.2011 14:33, Robert wrote:
Timing summary fornasal.
- mean time: 0.04 ms.
- min time : 0.00 ms.
- max time : 2.05 ms.
- stddev : 0.24 ms.
I don't think we have to dig into nasal code like Franz suggested
(please correct me if I'm wrong)
you should still look at Nasal. The event manager handles timers, and
that's almost exclusively used by Nasal. Almost all the Nasal code runs in
timers (except for property listeners). So read events as the total
execution time for Nasal (timers).
The timing data shown for the subsystem
On 24.03.2011 23:54, Robert wrote:
As you can see Nasal scripts aren't used at all.
No, there are several generic Nasal scripts loaded independently of any
aircraft configuration files.
I checked my system and saw timers from the mp_broadcast.nas (which is
also active when MP is disabled),
I investigated further into the stuttering issue.
I tried the UFO like ThorstenB suggested.
Then I tried some other planes and found something interesting.
There is regular stuttering with every plane I tested.
But the interval between the stutters differs with every plane.
See my results:
C172p
Hi,
I've pushed an update to sg/fg/fgdata which enables a (so far well
hidden) feature of our subsystem manager to capture timing statistics.
It''s now configurable at run-time. Use Debug - Toggle Subsystem
Statistics to enable/disable. It prints min/max/average and
std-deviation for each of
On Wed, Mar 23, 2011 at 11:38 PM, ThorstenB bre...@gmail.com wrote:
I've pushed an update to sg/fg/fgdata which enables a (so far well
hidden) feature of our subsystem manager to capture timing statistics.
I have found that feature earlier :)
Also I have actually removed some subsystems, but
On 23.03.2011 23:42, Csaba Halász wrote:
I have found that feature earlier:)
Also I have actually removed some subsystems, but to no avail.
Let's see if somebody can produce other results.
Yes, let's see what people come up with :).
I actually see one submodule which produces some jitter. But
On Wed, 23 Mar 2011 05:56:49 +0100, robert...@web.de wrote in message
AANLkTimUGMjCn2y=FWw4Avt6tx_5d3M=ywxsetz6w...@mail.gmail.com:
..maybe Robert can tell us the FG command line etc recipe
he uses to provoke the 1Hz stuttering?
My machine specs are:
Athlon64 X2 5200+
Samsung HDD
On 22.03.2011 05:24, Robert wrote:
Ingame (insim) I notice a small stutter that happens once every second.
Did anybody of you guys notice the same thing?
What can we do about it?
I thought it might be something like a timed task. (reading from hard
disc + malloc)?
Please, could someone tell
On Tue, Mar 22, 2011 at 5:24 AM, Robert dogg...@googlemail.com wrote:
Ingame (insim) I notice a small stutter that happens once every second.
Did anybody of you guys notice the same thing?
Yes I also see it on both of my machines (amd+ati, intel+nvidia)
I have AI local traffic, traffic manager
On Tue, 22 Mar 2011 16:54:52 +0100, Csaba wrote in message
aanlktiksitdwffpudx_vjnuk+8npwhemwbfofoik7...@mail.gmail.com:
On Tue, Mar 22, 2011 at 5:24 AM, Robert dogg...@googlemail.com
wrote:
Ingame (insim) I notice a small stutter that happens once every
second. Did anybody of you guys
..maybe Robert can tell us the FG command line etc recipe
he uses to provoke the 1Hz stuttering?
My machine specs are:
Athlon64 X2 5200+
Samsung HDD
Radeon HD 6850 (Had nvidia 8800 GTS before with the same stuttering issues)
Debian unstable/experimental
Kernels tested: 2.6.32 to 2.6.38 (no
29 matches
Mail list logo
