On 8 July 2011 12:24, James Morris <[email protected]> wrote:
> So I'd thought I'd compare the execution time of 7000 items passing
> through the two 32-item ring buffers, with the execution time 7000
> items passing though 32-item jack-ringbuffers. details to come,
> probably to throw all this out the window.
>
MSG_BUF_SIZE = 32,
MSG_COUNT = 700000
JACK RING BUF:
[sirrom@scrapyard msg_test]$ time ./msg_test
msg_test.c: 164 main(): read
back loop count:700032
real 0m0.136s
user 0m0.260s
sys 0m0.003s
[sirrom@scrapyard msg_test]$ time ./msg_test
msg_test.c: 164 main(): read
back loop count:700032
real 0m0.136s
user 0m0.263s
sys 0m0.000s
[sirrom@scrapyard msg_test]$ time ./msg_test
msg_test.c: 164 main(): read
back loop count:700032
real 0m0.142s
user 0m0.273s
sys 0m0.003s
MY RING BUF WITH ATOMIC POINTERS
[sirrom@scrapyard msg_test]$ time ./msg_test
msg_test.c: 286 main(): read
back loop count:702657
real 0m0.169s
user 0m0.330s
sys 0m0.000s
[sirrom@scrapyard msg_test]$ time ./msg_test
msg_test.c: 286 main(): read
back loop count:738329
real 0m0.173s
user 0m0.337s
sys 0m0.000s
[sirrom@scrapyard msg_test]$ time ./msg_test
msg_test.c: 286 main(): read
back loop count:753976
real 0m0.171s
user 0m0.333s
sys 0m0.000s
A very simple data integrity check was used, (note: pointers to data
were stored in the rbufs rather than data), the main thread set the
items data to point to the item itself. the integrity check was that
it should come back intact, still pointing to itself. success in both
instances.
JACK's ringbuf, as most will have undoubtedly known all along, is
faster, and the test code required 50000 iterations less than when
using my ring buf. maybe somewhere, the atomics are required?
james.
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
