Reorder the conditions according to the expected distribution of input
signal. This seems to make it almost as fast as the clz builtin using
the bsr instruction.
---
src/libFLAC/bitreader.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/libFLAC/bitreader.c
On Fri, May 04, 2012 at 11:22:00AM -0400, Cristian Rodríguez wrote:
El 03/05/12 12:19, Miroslav Lichvar escribió:
It makes the C function faster than the corresponding asm routine, so
if it's included I'd suggest to just drop the asm function to not keep
around more asm code than is
On May 7, 2012, at 06:11, Miroslav Lichvar wrote:
On Fri, May 04, 2012 at 11:22:00AM -0400, Cristian Rodríguez wrote:
El 03/05/12 12:19, Miroslav Lichvar escribió:
It makes the C function faster than the corresponding asm
routine, so
if it's included I'd suggest to just drop the asm
On Mon, May 07, 2012 at 09:19:52PM +0400, LRN wrote:
In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with
nasm enabled is about 7% faster in decoding than without nasm.
x86_64 build is about 2% faster than the i686 build with nasm
enabled.
Was that with -O2 or -O3?
Not
El 07/05/12 13:37, Miroslav Lichvar escribió:
On Mon, May 07, 2012 at 09:19:52PM +0400, LRN wrote:
In a test on a Core 2 machine with gcc-4.6.3, i686 flac build with
nasm enabled is about 7% faster in decoding than without nasm.
x86_64 build is about 2% faster than the i686 build with nasm
Cristian Rodríguez crrodrig...@opensuse.org wrote:
El 07/05/12 06:23, Miroslav Lichvar escribió:
On Sat, May 05, 2012 at 05:34:31PM -0400, Cristian Rodríguez wrote:
This has the advantage of being more efficient than the included
Btw, how much more efficient and on what hardware?
Based on
Miroslav Lichvar wrote:
Reorder the conditions according to the expected distribution of input
signal. This seems to make it almost as fast as the clz builtin using
the bsr instruction.
Applied. Thanks Miroslav.
Erik
--
--
El 07/05/12 16:19, Eric Wong escribió:
flac and metaflac do not use openSSL, only libFLAC does.
But since flac/metaflac use libFLAC, I suspect (IANAL) the relationship
can be transitive. (But being an optional dependency helps as distros
can avoid potential issues).
That's why it is
Attached is a patch that adds 5 missing FLAC__metadata_object_vorbiscomment_*
functions to the VorbisComment class. In my previous message I stated 8
functions were missing, but on closer inspection, 3 of those belong in the
VorbisComment::Entry class, and 2 of them already have equivalent
El 07/05/12 17:02, Bastiaan Timmer escribió:
Attached is a patch that adds 5 missing FLAC__metadata_object_vorbiscomment_*
functions to the VorbisComment class. In my previous message I stated 8
functions were missing, but on closer inspection, 3 of those belong in the
VorbisComment::Entry
While you are at it, can you check/fix the following warning
?
metadata.cpp:812:98: warning: narrowing conversion of
'strlen(((const
char*)string))' from 'size_t {aka long unsigned int}' to
'FLAC__uint32
{aka unsigned int}' inside { } is ill-formed in C++11
[-Wnarrowing]
Thanks !
11 matches
Mail list logo
