NBC speed

[mattallen37]

Well, it's not so much the higher resolution that I was interested in, but more being able to time stuff with the number of OPCodes. Instead of checking the time, it would automatically know the time.

[linusa]

I think it is accurate to say that NXC only frees up the CPU during a wait if you are targetting the V1.28 (or higher) ENHANCED FIRMWARE. If NXC code is compiled for, and loaded onto, the standard firmware then I believe that you still get the busy wait.

Nope, I can confirm this new "not-busy-waiting" behavior for the standard firmware 1.28, too. I mean, I don't know how the firmware handles this thing internally, but the effect of using Wait() is that other tasks get more CPU. Having two tasks, with both a busy loop, and one task's loop just a "Wait(100)" in it, will give the other task nearly 100% CPU time. In the old 1.0x firmware, this would've been split to 50% : 50%.

I'm not sure whether this change in behavior was caused by a compiler change in NXC/NBC, but for me, it was coincidental with the new 1.2x firmware. And also, I think I could reproduce it for 1.0x and 1.2x with the same NBC version...

[muntoo]

Instead of checking the time, it would automatically know the time.

...

[linusa]

As far as I remember, there is no timing with a higher resolution than the millisecond precision of the firmware. However, you can use statistics to get sub-ms precision. You know when the firmware "ticks", i.e. when the "user-space" program gets interrupted to do processing of internals (like updating sensors, handling Bluetooth, etc.). You can gather data about multiple runs, and look at the frequencies of the firmware "ticks". I tried to do this with my NXC profiler, but I played around with it and can't remember how exactly I settled and what other possibilities there were. If you have a look here http://www.mindstorms.rwth-aachen.de/tr ... XCProfiler at the second example, last section, where it says "PROFILER_BEGINSECTION(5);". There you can see "> 1.0 ms (in 27%)" and "< 1.0 ms (in 72%)". Which means, the 1ms-tick (i.e. the change from one ms to the next) occured in 27% of the times this code block ran. This would suggest the code block took 270µs on average (or I messed up my statistics just now).


If you go a level deeper (firmware), there was/is this "task priority" setting. I remember Dick Swan and John Hansen having discussions about performance comparision between NXC and RobotC (don't want to bring up that topic again, btw.). Somewhere, I believe on Lugnet, there was also a thread about task priority and the number of opcodes being executed within 1ms. (Maybe this wasn't even related to the aforementioned discussion). I think, it said something like 20 opcodes per ms, but that number seems too low to me (especially when I think back to my NXC performance benchmarks). Anyway, I you dig out that articles, let me know...

[linusa]

Found it myself, here: "NXT-G/ROBOTC Firmware Scheduler and Clump Priority" http://news.lugnet.com/robotics/nxt/?n=924

[mattallen37]

Very interesting indeed. However, I think current tick should do just fine. Thanks for all that info