Code Efficiency and Speed.

Brian Fairchild

I have a project currently running on an Atmel AVR which I'm thinking of porting to the Propeller. It currently consists of around 1,000 active lines of AVR C (ie lines which actually generate code). When compiled it turns into around 6,000 instruction words. So lets call that an efficiency of 1:6. Doing some test compilations of SPIN code would seem to indicate that each line of SPIN generate around 2 instruction longs. So an efficiency of 1:2.

Does anyone have any figures for Propeller C code sizes vs line counts?

I'm assuming that it might be slightly more efficient than the AVR but how much? At the moment, if it was the same efficiency then I'd be filling 6k longs of the propeller's 8k which leaves me tight on data space and with no real room for expansion. I could rewrite in SPIN but I'd make a big sacrifice in throughput. I've seen figures of 100k SPIN lines per second. I process data every 10mS which would give me 1,000 lines of SPIN to process the data which is tight. The processing doesn't really lend itself to being partitioned across multiple COGs and rewriting the application in PASM isn't an option.

heater

I suggest you download ImageCraft's free/demo (Whatever their deals are, I have not checked) C compiler for the Propeller and get your code compiled with it. Then you will know for sure what you are going to get.

I can't really speak of "efficiency" in such general terms. Much will depend on the complexity of the lines in your code which is a question of your coding style.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Brian Fairchild

The trouble is, by the time I've ported over my code from one processor to another so it'll compile then I've done the transition anyways [noparse]:)[/noparse] Ah, the joys of portable languages!

I was hoping someone might have some prop C code they could post the metrics on.

My coding style would be described as clear and simple. In a previous life I spent a long while looking at compiler outputs and realised that denser code gives you no gains in size or speed. All it did was increase the chance of obscure compiler bugs biting you or the risk of introducing strange errors in your logic. KISS all the way.

hippy

Brian Fairchild said...
The trouble is, by the time I've ported over my code from one processor to another so it'll compile then I've done the transition anyways [noparse]:)[/noparse]

You could just do a small subset test program. Perhaps the simple flash a LED routine ( "Hello World" for single cellular lifeforms ). See how those compare. Maybe try with some short code where you already know efficiency is an issue ?

heater

Ah, Brian, there is the trick. I didn't actually say "port" the code I said "get your code compiled". I have from time to time taken a very "animal" approach to this sort of thing. Try to compile the code, if it fails remove or hack around stuff until it does. Never mind that the resulting code does not do anything useful as long as it has got the bulk of your logic in there. Perhaps much of the AVR specific stuff has been chopped or stubbed out at this point.

Should not take more than an hour or so for 1000 lines and will give you a very good idea if you are in the game or not.

"KISS all the way" so it should not give you too much trouble.

By the way, do let us know what your results are. I have yet to play with C on the Prop.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Brian Fairchild

Thanks heater.

OK, a quick and dirty exercise...

Take some C and get it to compile under ICCPROP. The end result is 684 lines in the editor of which 212 generate code. I'm still getting to grips with what the compiler reports but I think...

The total code size is 7744 bytes or 1936 longs
The kernel seems to occupy 2136 bytes or 534 longs
My 212 lines of code occupies 3828 bytes or 957 longs
Then there is what I think is the CLIB interface which takes 1780 bytes or 445 longs

So on my measure of code efficiency I'm getting a ratio of 1:4.5 (957/212)

If we assume that the LMM and CLIB overhead is fixed at around 1000 longs that gives us 7000 longs for code or around 1,500 lines of 'active' C.

Mike Huselton

Please post the research results. Commented code is great, but an English functional description helps everyone to grok the intent and methodology.
Yes, more work, but posterity will thank you.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH