good. well that would seem if a 1200 decode+kissfft is taking about 14mS on your kit (GCC 5.4) , and decode1200+armcfft is taking 12.34mS on my kit (GCC 4.9) , then we have won at least 2mS based on that.... which is worthwhile. (and a fair bit of RAM) . improvement likely to be greater if I ran GCC 5.4
g On 18/09/2016 4:00 PM, Danilo Beuche wrote: > Hi Glen, > > I just verified, the cycle counts for true 16Mhz are within 1% of the > 8Mhz operations (but measurements now take half as long :-) ) > > Danilo > > > Am 18.09.2016 um 07:15 schrieb glen english: >> Hi >> OK. >> well, anyway, decode 1200 (40mS) takes 12.34mS on my kit, and 19.86 >> using kiss-fft. >> I think you approximated about 14.4mS for a decode 1300 on your kit >> >> so, I will be interested to see what you come up with using cfft >> >> My codec 2 codebase is AUGUST 2015 >> >> cheers >> >> >> >> >> >> On 18/09/2016 2:58 PM, Danilo Beuche wrote: >>> Hi Glen, I would not worry to much: >>> >>> - Maybe gcc 5.4 vs 4.9: difference is ~-20% (depending from which end >>> you are looking). It is a lot but not unexplainable. >>> >>> - Maybe it is my test data. I don't know how much jitter in the kiss_fft >>> algorithm is, when different data is presented. I am running >>> "artificially" generated audio input (digitally captured codec2 frames >>> from a single 750Hz sine way also generated digitally).- >>> >>> - Maybe it is my strange way of running the mcHF firmware: the mcHF >>> Hardware has a 16Mhz XO, but the discovery board which I have here for >>> testing has a 8Mhz XO. I didn't bother to reconfigure the PLL. So >>> everything takes twice the time. If the flash would asynchronously >>> coupled, which I doubt (otherwise no need for explicit wait state >>> settings), it would have an influence. But here I am quite sure, this >>> is not the case. If the caches are asynchronous: Maybe. Maybe I should >>> remeasure with fixed PLL setup so that the processor runs at true >>> 168Mhz. Will do that later and get back with updated numbers. >>> >>> Danilo >>> >>> >>> >>> >>> >>> On 18.09.2016 06:35, glen english wrote: >>>> Using environment Rowley CrossStudio for ARM 3.6.4 . GCC 4.9 >>>> >>>> using cycle counter (yes) >>>> >>>> interrupt overhead : (irrelevant, most likely in my setup) (asm) irqs >>>> only set off flags... >>>> >>>> for kissfft 5ws F4, I wonder why you have 112500 cycles and I have >>>> 141000. Something for me to look at . >>>> >>>> hmm >>>> >>>> -O2 but I also have a bunch of debug symbol stuff in there dunno I think >>>> it is only symbol data at DB2 which pushes up the image size. >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Freetel-codec2 mailing list >>>> Freetel-codec2@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Freetel-codec2 mailing list >>> Freetel-codec2@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >>> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Freetel-codec2 mailing list >> Freetel-codec2@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > ------------------------------------------------------------------------------ > _______________________________________________ > Freetel-codec2 mailing list > Freetel-codec2@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
