Subject:
|
Re: Light Sensor help
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 9 Apr 2002 23:01:46 GMT
|
Viewed:
|
487 times
|
| |
|
|
"T. Alexander Popiel" <lego-robotics@crynwr.com> wrote in message
news:20020409200644.A3009F4BE@cashew.wolfskeep.com...
> 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).
I did some similar tests and found similar results. The results held up
well
up to about 3 tasks, but by the time we were doing work in all 7 tasks,
the execution time went up. I say about 3 tasks, because I did this
research
over 9 months ago.
Kevin
>
> 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
>
|
|
Message has 1 Reply:
 | | Re: Light Sensor help
|
| (...) Hrm. Looks like I need to be more thorough with my multi-task timing tests... my results (which seemed to show only one task getting run in any given timeslice) differ from yours. Unfortunately, I didn't keep good notes of all my measurements, (...) (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
|
|
|
|
