Re: [Flac-dev] libFLAC bitbuffer optimizations
Josh Coalson <[EMAIL PROTECTED]> wrote: > Eric, I finally got around to your patches after Miroslav's. > the first one (the memcpy/memset replacement) I had problems > with, one because the buffers can overlap so I had to use > memmove (is this usually assembly in libc too?) and also the > endpoints looked wrong, for my full patch see below. speedup > for me was around 3% memmove is based on memcpy in uclibc for ARM, and I'd imagine so for other platforms as well. I had memmove originally, but was convinced at the time they wouldn't overlap. > the second patch got another 2%. a question though, why do > you have: > > + *(++vals); > > in two places instead of just ++vals; ? Lack of sleep :) -- Eric Wong signature.asc Description: Digital signature ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] libFLAC bitbuffer optimizations
Eric, I finally got around to your patches after Miroslav's.
the first one (the memcpy/memset replacement) I had problems
with, one because the buffers can overlap so I had to use
memmove (is this usually assembly in libc too?) and also the
endpoints looked wrong, for my full patch see below. speedup
for me was around 3%
the second patch got another 2%. a question though, why do
you have:
+ *(++vals);
in two places instead of just ++vals; ?
Josh
Index: bitbuffer.c
===
RCS file: /cvsroot/flac/flac/src/libFLAC/bitbuffer.c,v
retrieving revision 1.55
diff -u -r1.55 bitbuffer.c
--- bitbuffer.c 25 Jan 2005 02:37:08 - 1.55
+++ bitbuffer.c 25 Jan 2005 02:39:52 -
@@ -228,11 +228,27 @@
/* first shift the unconsumed buffer data toward the front as much
as possible */
if(bb->total_consumed_bits >= FLAC__BITS_PER_BLURB) {
- unsigned l = 0, r = bb->consumed_blurbs, r_end = bb->blurbs +
(bb->bits? 1:0);
+#if FLAC__BITS_PER_BLURB == 8
+ /*
+* memset and memcpy are usually implemented in assembly
language
+* by the system libc, and they can be much faster
+*/
+ const unsigned r_end = bb->blurbs + (bb->bits? 1:0);
+ const unsigned r = bb->consumed_blurbs, l = r_end - r;
+ memmove(&bb->buffer[0], &bb->buffer[r], l);
+ memset(&bb->buffer[l], 0, r);
+#elif FLAC__BITS_PER_BLURB == 32
+ /* still needs optimization */
+ const unsigned r_end = bb->blurbs + (bb->bits? 1:0);
+ unsigned l = 0, r = bb->consumed_blurbs;
for( ; r < r_end; l++, r++)
bb->buffer[l] = bb->buffer[r];
for( ; l < r_end; l++)
bb->buffer[l] = 0;
+#else
+ FLAC__ASSERT(false); /* ERROR, only sizes of 8 and 32 are
supported */
+#endif /* FLAC__BITS_PER_BLURB == 32 or 8 */
+
bb->blurbs -= bb->consumed_blurbs;
bb->total_bits -= FLAC__BLURBS_TO_BITS(bb->consumed_blurbs);
bb->consumed_blurbs = 0;
__
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
On Mon, Jan 24, 2005 at 05:43:04PM -0800, Josh Coalson wrote: > because of the mess and since there have been API changes and > additions in both libFLAC and libOggFLAC since 1.1.1 I plan on > bumping all the libtool numbers as follows: current++, revision=0 > age=0. if this will cause problems please let me know. That should resolve the issues. Thanks. -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
--- Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > On Mon, 10 Jan 2005, Ralph Giles wrote: > > As such it's an incompatible change, for which you should also > > zero the 'age' field. So 1.1.1-beta1 should have been 2:0:0, > > not 2:0:1. > [...] > > Yes, I agree. The numbering is all about coexisting installs of the > > > various versions. > > Ok. I need to know what to do about this... is 1.1.2 with fixed > sonames > just around the corner? What should we do to fix sonames in Debian? OK, I am going to do a 1.1.2 earlier than I wanted in order to fix this. anyway there are some bug fixes and speedups that will be of benefit. because of the mess and since there have been API changes and additions in both libFLAC and libOggFLAC since 1.1.1 I plan on bumping all the libtool numbers as follows: current++, revision=0 age=0. if this will cause problems please let me know. I'll try to get this ready as soon as possible. Josh __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
