Fwd: [basicstamps] BS2p Speed
Archiver
Posts: 46,084
Hi,
As for the test we used to determine average execution speed:
We wrote a few sample programs consisting of a loop containing, for
example, almost all instructions which have a deterministic time delay that
is "Stamp-centric." By this I mean we didn't use any instructions that
need to "wait" for external input (such as SERIN, RCTIME, PULSIN, etc) and
we didn't use any instructions that intentionally slow down the Stamp for
the specified purpose (SEROUT, FREQOUT, etc). The latter is because those
command's execution speed is mostly a factor of the baud rate, duration,
etc. that it must perform at. The Write command is another example of
this... the Write command has to wait for apx 5 ms for the EEPROM to finish
writing its data.
At the beginning or end of the loop there is a single command that gives us
feedback as to the Loop's execution speed, for example... a TOGGLE
command. Then we simply run the program and monitor the high and low
signals on the I/O pin being toggled, measure the time between transitions
and divide that by the number of instructions contained within the loop.
I say we wrote a "few" sample programs because the average can not be well
determined by simply one program. The "average" is only as good as it is
close to an "average" spread of instructions in a program. Another extreme
is simply a two line loop containing a TOGGLE command and a GOTO
command. This loop will execute at a higher average instruction speed
because the TOGGLE command takes very little time, relatively, to execute.
All that data we gathered, averaged together, is how we came up with the
"approximate" average instruction execution speed.
Please note, there are other factors that will affect the speed.
One of them is the type of values you use for an instruction. For example,
if you use a simple variable (bit, nibble, byte or word), the Stamp will
execute the instruction faster than if you used an indexed variable (an
element within an array), such as: Temp(5). Also, if the index within an
array is a constant, the Stamp will generally execute the instruction
faster than if the index was another variable that it has to resolve at
runtime, ie: Temp(5) vs. Temp(Idx).
Another case is with constants themselves. Since the BASIC Stamp 2 (and
higher) use bit-level tokens (rather than byte-level), to keep to code size
compressed, even the constants you use are compressed. For example, the
pin number in the following command, TOGGLE 1, is a small constant that
takes very little space (in terms of used bits, within the program. This
results in less time for the Stamp to retrieve the entire instruction. If
you were to use a larger constant, TOGGLE 65521, it would still do EXACTLY
the same thing (toggle I/O pin 1), because the Toggle command really only
looks at the lower 4 bits of the Pin argument (which happen to be %0001 in
this case) but it would take the Stamp much longer to read the instruction
from the EEPROM because that number can't be compressed into as few bits as
are used by the number 1. As a side note: the tokenizer does not optimize
the constants (for any situation like this) because that would
unnecessarily complicate the tokenizer code and may lead to unexpected
situations, where the user really DID want to use a larger number in an
equation because he/she was, perhaps, using tricky binary methods for
certain calculations.
So, since there are so many variables to consider, it is difficult to
pinpoint how long a routine will take to run without actually testing
it. It can be estimated, but that's the best that can be done. If someone
really needs to know the timing of a routine or program, we always suggest
writing the code then adding a simple command, like TOGGLE, at one point
that represents your desired iterative loop, and use an Oscilloscope to
measure the loop's execution speed.
--Jeff Martin
Engineering Manager
Parallax, Inc.
> >Due to the structure of variable-length tokens and data in the Stamp, it's
> >very difficult to come up with an exact figure. Any, yes, mathematics
> >generally take longer. Since PBASIC is a specialized embedded language,
> it's
> >not possible to use "standardized" tests.
> >
> >-- Jon Williams
> >-- Parallax
> >
>
>i understand that you can't use a standard test to measure the speed, but
>an attempt should be made to provide more meaningful data. how did
>parallax come up with the figures they boast?
>
>John Butera
>pepsi@c...
>
>
>
>To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
>from the same email address that you subscribed. Text in the Subject and
>Body of the message will be ignored.
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Jeff Martin
Engineering Manager
Parallax, Inc
www.parallaxinc.com
www.stampsinclass.com
As for the test we used to determine average execution speed:
We wrote a few sample programs consisting of a loop containing, for
example, almost all instructions which have a deterministic time delay that
is "Stamp-centric." By this I mean we didn't use any instructions that
need to "wait" for external input (such as SERIN, RCTIME, PULSIN, etc) and
we didn't use any instructions that intentionally slow down the Stamp for
the specified purpose (SEROUT, FREQOUT, etc). The latter is because those
command's execution speed is mostly a factor of the baud rate, duration,
etc. that it must perform at. The Write command is another example of
this... the Write command has to wait for apx 5 ms for the EEPROM to finish
writing its data.
At the beginning or end of the loop there is a single command that gives us
feedback as to the Loop's execution speed, for example... a TOGGLE
command. Then we simply run the program and monitor the high and low
signals on the I/O pin being toggled, measure the time between transitions
and divide that by the number of instructions contained within the loop.
I say we wrote a "few" sample programs because the average can not be well
determined by simply one program. The "average" is only as good as it is
close to an "average" spread of instructions in a program. Another extreme
is simply a two line loop containing a TOGGLE command and a GOTO
command. This loop will execute at a higher average instruction speed
because the TOGGLE command takes very little time, relatively, to execute.
All that data we gathered, averaged together, is how we came up with the
"approximate" average instruction execution speed.
Please note, there are other factors that will affect the speed.
One of them is the type of values you use for an instruction. For example,
if you use a simple variable (bit, nibble, byte or word), the Stamp will
execute the instruction faster than if you used an indexed variable (an
element within an array), such as: Temp(5). Also, if the index within an
array is a constant, the Stamp will generally execute the instruction
faster than if the index was another variable that it has to resolve at
runtime, ie: Temp(5) vs. Temp(Idx).
Another case is with constants themselves. Since the BASIC Stamp 2 (and
higher) use bit-level tokens (rather than byte-level), to keep to code size
compressed, even the constants you use are compressed. For example, the
pin number in the following command, TOGGLE 1, is a small constant that
takes very little space (in terms of used bits, within the program. This
results in less time for the Stamp to retrieve the entire instruction. If
you were to use a larger constant, TOGGLE 65521, it would still do EXACTLY
the same thing (toggle I/O pin 1), because the Toggle command really only
looks at the lower 4 bits of the Pin argument (which happen to be %0001 in
this case) but it would take the Stamp much longer to read the instruction
from the EEPROM because that number can't be compressed into as few bits as
are used by the number 1. As a side note: the tokenizer does not optimize
the constants (for any situation like this) because that would
unnecessarily complicate the tokenizer code and may lead to unexpected
situations, where the user really DID want to use a larger number in an
equation because he/she was, perhaps, using tricky binary methods for
certain calculations.
So, since there are so many variables to consider, it is difficult to
pinpoint how long a routine will take to run without actually testing
it. It can be estimated, but that's the best that can be done. If someone
really needs to know the timing of a routine or program, we always suggest
writing the code then adding a simple command, like TOGGLE, at one point
that represents your desired iterative loop, and use an Oscilloscope to
measure the loop's execution speed.
--Jeff Martin
Engineering Manager
Parallax, Inc.
> >Due to the structure of variable-length tokens and data in the Stamp, it's
> >very difficult to come up with an exact figure. Any, yes, mathematics
> >generally take longer. Since PBASIC is a specialized embedded language,
> it's
> >not possible to use "standardized" tests.
> >
> >-- Jon Williams
> >-- Parallax
> >
>
>i understand that you can't use a standard test to measure the speed, but
>an attempt should be made to provide more meaningful data. how did
>parallax come up with the figures they boast?
>
>John Butera
>pepsi@c...
>
>
>
>To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
>from the same email address that you subscribed. Text in the Subject and
>Body of the message will be ignored.
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Jeff Martin
Engineering Manager
Parallax, Inc
www.parallaxinc.com
www.stampsinclass.com
Comments
constant have 4 bits showing their length followed by the value, but if the
first bit after the size is 0 it uses the size^2 this lets all perfect
powers of 2 be expressed in 5 bits
size constant
0110 0 = 64
0110 1000001 = 65
0111 0 = 128
0111 10000001 = 129
A better method would have been to drop the MSB of the constant and let the
interpreter assume that first 1 bit.. then EVERY constant is encoded by one
less bit except for 0 and 1
size constant
0110 000000 = 64
0110 000001 = 65
0111 0000000 = 128
0111 0000001 = 129
this method would require a couple extra cycles on the interpreter, but if
you still use serial eeprom, the extra cycles would take less time than
reading another bit from the eeprom
if someone wrote a (theoretical) program had 65536 lines of "w4 = n" with n
being a consant from 0 to 65535, parallax's compression would save 120
bits, the way i suggested would save 65534 bits (accounting for 0 and 1
which cant be compresed)
just my 2 cents
John Butera
pepsi@c...
>Hi,
>
>As for the test we used to determine average execution speed:
>
...
>Another case is with constants themselves. Since the BASIC Stamp 2 (and
>higher) use bit-level tokens (rather than byte-level), to keep to code size
>compressed, even the constants you use are compressed. For example, the
>pin number in the following command, TOGGLE 1, is a small constant that
>takes very little space (in terms of used bits, within the program. This
>results in less time for the Stamp to retrieve the entire instruction. If
>you were to use a larger constant, TOGGLE 65521, it would still do EXACTLY
>the same thing (toggle I/O pin 1), because the Toggle command really only
>looks at the lower 4 bits of the Pin argument (which happen to be %0001 in
>this case) but it would take the Stamp much longer to read the instruction
>from the EEPROM because that number can't be compressed into as few bits as
>are used by the number 1.
>
...
>
>--Jeff Martin
>Engineering Manager
>Parallax, Inc.
>
>
>> >Due to the structure of variable-length tokens and data in the Stamp, it's
>> >very difficult to come up with an exact figure. Any, yes, mathematics
>> >generally take longer. Since PBASIC is a specialized embedded language,
>> it's
>> >not possible to use "standardized" tests.
>> >
>> >-- Jon Williams
>> >-- Parallax
>> >
>>
>>i understand that you can't use a standard test to measure the speed, but
>>an attempt should be made to provide more meaningful data. how did
>>parallax come up with the figures they boast?
>>
>>John Butera
>>pepsi@c...
>>
>>
>>
>>To UNSUBSCRIBE, just send mail to:
>> basicstamps-unsubscribe@yahoogroups.com
>>from the same email address that you subscribed. Text in the Subject and
>>Body of the message will be ignored.
>>
>>
>>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>Jeff Martin
>Engineering Manager
>Parallax, Inc
>www.parallaxinc.com
>www.stampsinclass.com
>
>
>To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
>from the same email address that you subscribed. Text in the Subject and
>Body of the message will be ignored.
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/