Hi Glen,

On 18.09.2016 03:12, glen english wrote:
> Hi Danilo
> Good thoughts and points.
> while on the RAM subject : require reading for every serious programmer :
> "Memory"
> https://lwn.net/Archives/GuestIndex/#Drepper_Ulrich
> read all 7 parts, 100 pages, but if you only have an hour, just read 
> "part 2 - cache"
> On the fft:
> I am not surprised that the ARM lib  hand optimized assembler is that 
> much faster.
> more that 2x faster.... in fact.
As I said on the m4 kiss fft and arm dsp are on par, not much difference.
And using RAM vs. flash makes a lot of difference on the mcHF M4 Code
for code which uses tables heavily. We gained a lot from removing the
need to go to flash twice in the fir_filter vs. fir_filter2.
Maybe the mcHF startup configuration is not enabling all the caches.
Will check that.
> I don't think kiss-fft is particular suitable for this sort of platform, 
> either, I'll hold back what I really think :-) .
> The 5WS on flash (actually 6WS I am running @ 168M) does not really 
> affect the performance too much.  In fact I can vary the WS count +/- 2 
> without much change- the ART and the prefetch and the instruction and 
> data caches are doing their job, so there is very little difference with 
> the const values in ram or cache.
> In fact, most  FFT implementations are very tough on a machine with cache .
> Have you read the paper on how FFTW works ? It is very cache aware- and 
> adaptive to the architecture- that is why it does trial runs and picks 
> the best.
> The M7 is very impressive. It is certainly impressive work by ARM.
> However, the M4 is what all of you have to work with so we can stay 
> focussed on that.
> I think also the ram usage will be significantly less with the arm FFT 
> because of the re-entrant Kiss-fft behaviour.
> The m4 is quite a different beast, and no D-cache can improve 
> performance over the M7 for some (inaptly) written applications (not 
> this one- but as a generalization for applications grabbing a byte from 
> memory randomly and all over a large dataset)
> Large matrix operations are where cache machines fall over- that is once 
> the dataset is bigger than the cache....
> The question is how much optimization is enough. I am tempted NOT to 
> optimize any more, although I feel (just by looking at it )  I can get 
> another 2x out of it..... Why- well there is no real pressing need. 
> Going too far away from the reference code will island the code a bit.
> However, if you run out of modem cycles/ modem ram, then we can probably 
> get a bit more...
> cheers
Yes, unfortunately we have a M4 at hand, so a little more RAM would be
nice :-(

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

Freetel-codec2 mailing list

Reply via email to