Craig, It would be the main config.h generated by 'configure'. It is used to disable the routine in big-endian mode.
Vince On Wed, 2009-03-25 at 17:39 -0600, Craig Matsuura wrote: > Which config.h are you refering to in the armasm_memcpy.S? > > > > Craig > > > > On Wednesday 25 March 2009 12:55:07 pm Craig Matsuura wrote: > > I took the new armasm memcpy patch and applied it to my > DirectFB-1.1.1 and > > ran it on my davinci based system using gcc-3.4 and real libc. And > it is > > now faster than the libc. Nice job, the original patch actually > slowed > > things down. > > > > Thank, > > Craig > > > > On Wednesday 25 March 2009 2:50:35 am vince wrote: > > > Niels, > > > > > > Here is a new version of the patch with the second version of > memcpy and > > > a conditional to remove big-endian. > > > > > > Let me know if you have any trouble with it. > > > > > > Regards, > > > > > > Vince > > > > > > On Tue, 2009-03-24 at 16:36 +0100, Niels Roest wrote: > > > > Hi John, > > > > thanks for the comments, > > > > just want to mention 1 or 2 things too. > > > > > > > > The testing routines do have a single cold, unmeasured, run > first to > > > > rule out previous cache state influence. > > > > > > > > The test itself is in fact really simple - a continuous copy of > a large > > > > region. So no repeats. This does focus on the use case that is > most > > > > obvious for DirectFB, namely copying chunks and lines of > graphics > > > > between surfaces, which will normally lead to cache misses > anyway. I am > > > > most concerned about alignment, since this is really > unpredictable. > > > > > > > > I am not sure if we will benefit much from shuffling the code or > using > > > > different memory regions; you have to remember that the testing > > > > routines produce a single score only, so these will need to be > fine > > > > tuned a lot, and we may even need to revert to multiple memcpy > routines > > > > which are optimised for multiple use cases. This might be an > > > > interesting approach, it is one I will follow if performance > > > > measurements show that we can expect a proper benefit from this > - > > > > forgetting that DirectFB is mainly about hardware acceleration > anyway. > > > > > > > > For me I am very happy with the changes that Vince made, thanks > Vince, > > > > and if I have a BE/LE lock, I will include the patch. > > > > > > > > Greets > > > > Niels > > > > > > > > John Williams wrote: > > > > > Hi Vince, > > > > > > > > > > On Wed, Mar 25, 2009 at 12:57 AM, vince <vi...@bluush.com> > wrote: > > > > >> Ive change my benchmark to invalidate the cache before every > test. > > > > >> My result are the same. Attached is my test program. > > > > > > > > > > No worries - just wanted to make sure we weren't missing the > obvious! > > > > > > > > > > Might also be worth shuffling the sequencing of the tests > (armasm, > > > > > armasm2, libc), see if that has any impact. I'm not intimate > with > > > > > ARM cache details, but with a write-back cache you could be > stalling > > > > > on cacheline evictions later in the test. > > > > > > > > > > Another safety would be to perform the tests in different > memory > > > > > regions, with a complete cache flush and invalidate between > each run. > > > > > > > > > > Not saying there's anything wrong with your code, just know > its easy > > > > > to get false results from simple benchmark code. Memory tests > are > > > > > another one where the obvious approach is often wrong. > > > > > > > > > > Cheers, > > > > > > > > > > John > > > > > _______________________________________________ > > > > > directfb-dev mailing list > > > > > directfb-dev@directfb.org > > > > > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > > -- > > > > > > ______________________________________________________________________ > > > Craig Matsuura - Principal Engineer > > Control4 > 11734 South Election Road - Suite 200 > Salt Lake City, UT 84020-6432 > PH: 801-523-3161 > FX: 801-523-3199 > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
