On Wed, 30.07.08 15:00, Nick Thompson (rextanka at comcast.net) wrote: > Patches will be forthcoming for this, however we are still on 0.9.8, I > am hoping we'll have made the move to 0.9.10 this week, so I hope we > can send you stuff in a couple weeks once we are happy they are tested > well. The patches will be for 0.9.10 so help in getting that merged > with the latest would be handy, though I'd suspect these routines are > not so much in flux at the moment? Nope, except for optimization patches I see not much changing in this code. > With regards to the vectorization stuff, that can be used, although it > would make the arm code very specific to a certain subset of ARM > implementations. It brings a philosophical question, since I'd > suspect a generic ARM implementation is a better open source solution, > having the optimized cases for cortex-a8/NEON processors would be > useful, but it would add to the build complexity, and potentially > would be frustrating for someone with a different ARM processor. I'm > not sure I understand open source well enough to decide this. That > being said we'll probably optimize for our case and that any patches > will likely be somewhat system dependent. Worst case is it gives > someone else something to build on, I guess. We can always #ifdef things for specific processors. I am interested in SSE support for x86, for that stuff I'd probably ship multiple compiled version of at least some parts of libpulsecore which are then loaded dynamically depending on what features the CPU has. glibc actually contains support for this already for some cpu features (tls, and sse I think), and I would assume something similar is available for ARM too? Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4
