Subject:
|
Re: Light Sensor help
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 9 Apr 2002 20:47:14 GMT
|
Viewed:
|
557 times
|
| |
|
|
In lugnet.robotics, "T. Alexander Popiel" <popiel@wolfskeep.com> writes:
> In message: <GuB96o.CKA@lugnet.com>
> "John Barnes" <barnes@sensors.com> writes:
> >
> > The purpose of this post however, is to ask if anyone has done any timing
> > tests to find out what the byte code execution speeds are recently. Easy
> > enough to do, set up an empty loop that goes round say 10,000 times and time
> > it with a stop watch, and then insert different instructions into the loop
> > and check out how much longer the overall time increases by.
>
> Yes, I just recently did some timing tests, using that exact method.
> Each bytecode takes 2.9 +/- .2 ms to execute, as near as I can tell.
> This appears to be independent of which bytecode it is (though I did
> not test any that I really expected to be expensive (the multiply and
> divide codes, that is)). I specifically tested jmp, jmpl, chk, chkl,
> setv, addv, subv, out, and dir (using the NQC disassemble nomenclature).
> For setv and chkl, I tested sources 0 (variable), 2 (immediate), and
> 9 (cooked sensor). I did _not_ test source 36 (indirect).
>
> Also, calling a subroutine takes that same 2.9 +/- .2 ms for each of
> the call instruction and the return instruction (in addition to whatever
> else is in the subroutine).
>
> > I'd like to think that someone has already done this before, but I can't
> > seem to find a post anywhere and if it's that old, it probably wasn't on
> > vers 2.0 firmware.
>
> I did this on both 1.5 and 2.0, with no detectable difference.
>
> > It might be very insightful to know just how slow the interpreter is. I have
> > a nasty feeling that the effective code execution speed of NQC programs is
> > really slow.
>
> Actually, it's not too horrible... particularly if you drive your
> motors in a separate task from the sensor readings, and use one of
> the global variables to communicate between the tasks. You can get
> worst case response from sensor change to motor output in under 30ms
> without half trying.
>
> - Alex
Wow! That is very interesting. I wonder if the whole thing is synchronous
and based on the 3mS sensor read cycle? This would mean that every process
gets one of its byte codes "done" during this periodic 3mS spring-clean cycle.
I guess the timing should be done with and without a second process in a
tight loop just to see.
Personally, I think 330 byte codes per second is very slow. Any attempt at a
series evaluation of trig function would take seconds! It might also explain
why my array initialisation routine caused the RCX to go dead for a second
or so after pressing the run button. The routine to access each memory
location as a set of 8 two bit locations (for mapping purposes) required a
modest number of instructions per two bit access!
JB
|
|
Message has 2 Replies:
 | | Re: Light Sensor help
|
| (...) Yes, it all appears to be synchronous. However, only one bytecode instruction is run in any given 3ms; any active tasks interleave their instructions. If you have two tasks running, they will each be getting an instruction every other 3ms. If (...) (22 years ago, 10-Apr-02, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Light Sensor help
|
| (...) Yes, I just recently did some timing tests, using that exact method. Each bytecode takes 2.9 +/- .2 ms to execute, as near as I can tell. This appears to be independent of which bytecode it is (though I did not test any that I really expected (...) (22 years ago, 9-Apr-02, to lugnet.robotics)
|
9 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
