Question on code performance
tdahbura
Posts: 6
I am wondering if anyone has any benchmarks on spin code versus assembler code performance on the propeller. I know this is not something that is easily compared but was curious if anyone had taken a simple problem and coded it in spin and assembly to see how it performs....
I am not real up to speed on spin assembly to write two equivalent programs.
Thanks,
Tony
I am not real up to speed on spin assembly to write two equivalent programs.
Thanks,
Tony
Comments
repeat
outa[15] :=1
outa[15] :=0
When speed becomes a concern, assembly can be peppered into a project to deal with speed intensive tasks while Spin can act to coordinate/supervise activities.
you might want to have a look at PropBasic, because with this tool you can write programs in Basic language, which are compiled to assembler and can be executed directly like assembler. If needed, you can use the inline assembler later too.
Christof
-- http://www.parallax.com/portals/0/propellerqna
As JonnyMac mentions Spin can do much more accurate timing than it should be able to by using the WAIT* functions, as long as that timing isn't ultra-fast. Spin has been shown to be fast enough to implement a passable serial UART at 19200 baud (see the SimpleSerial object), but PASM can implement four of them at several hundred kilobaud in one cog.
Creative use of the counter/timers can also make it possible for Spin to generate much higher frequency PWM and other pulse phenomena than would normally be possible with a language of its latency.
I decided to get my feet wet in some propeller assembly and was able to get sample programs working. Tried some timing code for the spin interpreted language and came up with a similar method to what was mentioned in the Q&A.
Now I need to try some different examples out and record the results. If I can get enough concrete samples I will post them to the forum.
Thanks,
Tony
I wrote an ADC IC driver in SPIN it was only able to do 26 samples per second (albeit, it was early on in my Propeller career, so it might not have been the most optimized bit of software, but it wasn't poorly written). Now I have a PASM driver that has way more features, and it can run at almost 2400 samples per second. Again, over 90 times faster, but if I stripped away the additional features so it ran like the SPIN version, it would likely be close to 2800 samples per second.