SPIN execution speed

Ken Peterson

Can someone tell me if there are some guidelines for spin execution speed?· For instance:· how many clock cycles to do outa[noparse][[/noparse]0]~~?· Just trying to get some ideas for maximum bus driving speed possible with spin.

Thanks!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


The more I know, the more I know I don't know.· Is this what they call Wisdom?

deSilva

My often given experience is:

- A "simple" SPIN construction ( as OUTA:= $FF or REPEAT) takes 5 us @ 80 MHz

There is no very reliable rule to what a "simple construction" is: most operations, indexing, IF,....
You could possibly count the number of bytes of the interpreted code... using the SPIN dis-assembler e.g.

- * and / take longer of course ...around 20 us

When hand translating SPIN to assembly you will generally get a speed-up of 80 (of course not when * or / is involved)

With exceptions not much above 10 kHz is possible in SPIN; the hardware timers and the video logic extends that of course for special cases!

Post Edited (deSilva) : 9/7/2007 10:53:14 PM GMT

Chuck Davis

This is VERY unscientific, but I wrote a benchmark test that I have used from time to time on various BASIC stamps and clones from other manufacturers (e.g. BASIC Atom). The program varies for each chip of course, but is basically the same equivalent code for each.

This is just a dumb program that executes 20 instructions of various types in a loop that executes 50,000 times, making a million instructions total. It turns a light on and off so you can clock it with a stopwatch to computer the rate.· The instructions are just basic math and logic things like x=y*z, etc. that I considered "representative" of a typical program.

The good news is that the Propeller ran the fastest time of any of the stamp-type micros, around 80,000 instructions per second, or roughly 13 microseconds per instruction. This was running on just one cog of course, so if your software can do some valuable work on 8 cogs at once, you could multiply that by 8 and say the Prop runs at about 640,000 instructions per second.

I recently wrote a program that needed to clock out bits at the rate of one every 58 microseconds and found that I could squeeze between 3 and 4 SPIN instructions between each bit, but with careful coding I was able to make it work just fine at that rate.

More speed would always be welcome, but a lot of useful work can be done at 80,000 IPS, especially if you can divide the workload among multiple cogs and/or run high bandwidth devices like video and serial ports via assembler software.·

deSilva

@Chuck: Your benchmark fits nicely!
As the SPIN compiler is not "optimzing" things, you can generally speed-up raw-SPIN-programs by a factor of 2, by more clever (but also more unreadable!) constructions (e.g. running loops backwards down to zero; systematic factoring of common subexpressions, substituting indexing by dereferencing, postfix operations, using constant(..),......)

Chuck Davis

Has anyone published a list of timings for various statements, and/or a list of the various "tricks" that will speed up execution?

It would be very helpful to those not as familiar with the language. For example, I would have never thought of running loops backwards to save time.

deSilva

I am sure there is nothing systematically...
http://forums.parallax.com/showthread.php?p=658575 give some figures; I remember a thread I do not find immediately where optimizing a MAX/MIN formula, I made mesurements myself...

You see: SPIN is so slow it makes no sense - with exceptions - to even think about it. Wen you need speed you have to use machine code with a speed up of 80. The rules of thumb are:
- SPIN 10 kHz
- machine code: 1 MHz
- hardware (video, counters) 10+ MHz

Post Edited (deSilva) : 9/9/2007 3:21:53 PM GMT

Ken Peterson

Thanks for the input, gentlemen! I think what I might try is to do various code sections and save the system clock before and after the critical operations to see how many clocks they take. If I do a large enough section I should be able to get a good idea of the average figuring in the cost of the statement to save the clock.

Ken

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


The more I know, the more I know I don't know.· Is this what they call Wisdom?

Chuck Davis

de Silva,

I disagree that spin is so slow that it makes no sense - it depends entirely on the application.· I developed an application to run an entire model railroad museum layout·on a stamp-like (not Parallax) computer that ran half the speed of the Prop. It controls 10 trains, dozens of signals, crossing gates, and other automation, all·via a serial interface to some specialized control boards.·

I would say that assembler is so slow it makes no sense in many applications.· Slow to develop and debug that is....

After 30 years of writing in assembler language - for me, it's still the last resort only when nothing else will do.

deSilva

Chuck Davis said...
I disagree that spin is so slow that it makes no sense

I should also disagree This was not my point:

deSilva said...
SPIN is so slow it makes no sense - with exceptions - to even think about it.

I have been ambiguous.. I was referring to the EXACT timing of SPIN instructions. I can live happily with whether an assignment takes 2 or 20 us. When I need speed, I know I have to use a timer or the video logic or machine code. In that case it can be important to know the SPIN timing.
E.g. PMW can be very precisely timed from SPIN but the main frequency is limited. To what exactly? Well this is where my "rules of thumb" apply.

Ken Peterson

Both your arguements are valid. What deSilva says is not that SPIN is so slow to be worthless, but that it's so slow that it makes no sense to use it when you need precise timing. I'm not trying to get very precise timing with SPIN, just trying to determine what the minimum execution time is for certain things so I can know when it is necessary to resort to using assembly.

Here's an example of what I'm trying to do. It's a scheme for allowing the Propeller to reboot itself from one of two EEPROMS:

I have a D Flip Flop and I'm trying to clock it and control the data input both with one pin on the Propeller. I'm using the flip flop to select the EEPROM that the propeller boots from, so I need to have it keep its state after a reboot instruction. I have an RC delay on the D input to the flip flop, so if I pull the line high for t > RC and then clock it, I can set the flip flop. If I pull the line low for t > RC, and then clock it, I can reset the flip flop.

I just need to know how long RC needs to be so that D remains valid while clocking it (in SPIN). It's a simple algorithm, not worth launching another cog for it. I can control R and C to make it slow enough for SPIN, but I need to know how slow SPIN is in this case.

Ken

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


The more I know, the more I know I don't know.· Is this what they call Wisdom?