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
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
