Dear Andy Green, In message <caafg0w7p6rvvamqsksc09yqnfpod08ydtbeh_mqrz6n+b4i...@mail.gmail.com> you wrote: > > > Instead of making assumptions on the performance of memcpy() and > > As I wrote, I measured the performance and got a very big gain, it's > 3x faster on my setup to use memcpy() then default memmove().
Yes, in your single test case of copying a Linux kernel image, i. e. a multi-megabyte file. > By calling that an "assumption" you're saying that there exist > platforms where 32-bit linear memmove() is slower than doing it with > 8-bit actions? No. I said you should not assume that memcpy() is always faster than memmove(); a system may use optiomized versions of either. > > adding the overhead of an additional function call (which can be > > expensive especially for short copy operations) it would make more > > I am not sure U-Boot is really in the business of doing small > memmoves, but okay... It's easy to avoid this overhead, and also get rid of the restrictions you built into it (otimizong only the non-overlapping case), so if we touch that code, we should do it right. > > sense to pull the "copy a word at a time" code from memcpy() into > > memmove(), too. > > > > On the other hand - if you really care about performance, then why do > > I spent several hours figuring out why our NOR boot performance was > terrible.... it's because this default memmove code is gloriously > inefficient for all cases. > > If you like it like that, no worries. Don't twist my words. I asked for a different, better implementation, that's all. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The only time the world beats a path to your door is when you are in the bathroom. _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
