Hi Bruce
re-entrant...yeah I saw, around the kiss fft work function....
makes for stack compression. First thing to go will be the kiss-fft.

Quite a few expensive operations elsewhere anyway. No criticism. I know having someone capable  walk through your code is like walking down the street naked. In code, there is much personal style, and not necessarily wrong.

I suspect if it breaks with -O1 then -O0 isn't really working as I expect. Usually it is volatiles breaking things but I don't think so here. Something I have screwed up.

My application is 'high quality' - 3200. but I will run some 1200 numbers for those interested.
Codebase is from about Jan this year.


Still , encouraging, and the first time I have got deep intot he code. Should be able to get 2x improvement at same clock as M4 and existing codebase once I am done. I need to run full duplex.

The "216MHz" STM32 F7 claim is a bit of a longbow. Really you can only run the thing at M4 speeds, like 168 megs unless you burn a bunch of extra power,  start decoupling the peripheral and various clocks, which is not hard but the whole chip doesn't scale from 168 (STM32F4)  >> 216 MHz .
But my experience on a couple of M7 projects so far is in general a 30 to 50% improvement over same clocked F4 on "general purpose code".  Many developers who have not used/ don't understand the implications of cache will go backward in their performance.  (That's something I read about in my spare time- cache architectures and programming impacts)

g
 


On 15/09/2016 5:14 AM, Bruce Perens wrote:
> and OK now this is totally untouched code apart from removing all the mallocs

Please mind that the code remains re-entrant.

    Thanks

    Bruce

------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Reply via email to