similar to: libFLAC bitbuffer optimizations

Ok, here is a patch waiting for new CVS :). It works fine for me, but please check it before commiting... -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/bitbuffer.c.orig 2003-01-30 17:36:01.000000000 +0100 +++ src/libFLAC/bitbuffer.c 2003-01-30 21:53:18.000000000 +0100 @@ -51,6 +51,25 @@ */ static const unsigned FLAC__BITBUFFER_DEFAULT_CAPACITY = ((65536 - 64) *

Josh Coalson <xflac@yahoo.com> wrote: > thanks for the patch. No prob :) > also, if you have miroslav's patch again a more updated version > of bitbuffer.c that would be great. I have been meaning to get > around to applying it for a long time. This is Miroslav's patch, from the mailing list post I dug up in the archives: --- orig/src/libFLAC/bitbuffer.c +++

--- src/libFLAC/include/private/bitmath.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/libFLAC/include/private/bitmath.h b/src/libFLAC/include/private/bitmath.h index 61b0e03..d32b1a7 100644 --- a/src/libFLAC/include/private/bitmath.h +++ b/src/libFLAC/include/private/bitmath.h @@ -42,7 +42,7 @@ #endif /* Will never be emitted for MSVC, GCC, Intel compilers */

Hi, attached are patches that improve decoding speed a bit. The first patch improves the bit scan macro used for decoding unary values, the second one adds a GCC inline assembly for bswap and the third patch replaces the read_rice_block function. In my testing it turned out to be even faster than the _ia32_bswap function. If the code produced by MSVC is faster as well, I'd suggest to remove

----- Forwarded message from Don Armstrong <don@donarmstrong.com> ----- Date: Thu, 30 Sep 2004 16:19:41 -0700 From: Don Armstrong <don@donarmstrong.com> Resent-From: Don Armstrong <don@donarmstrong.com> To: submit@bugs.debian.org Subject: Bug#274301: libflac4 segfaults on corrupt flac files Severity: normal Package: libflac4 Version: 1.1.0-11 Running ogg123 on

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: +

thanks for the patch. also, if you have miroslav's patch again a more updated version of bitbuffer.c that would be great. I have been meaning to get around to applying it for a long time. btw how are you playing it on the ipod? not sure how to help out with lpc_restore_signal(). there are x86 and PPC versions of the routines in CVS that might be good references. it is basically a

This lpc_restore_order was partially inspired by Miroslav's affd, though my (not very great) ARM asm version resembled this, as well. The other two reduce CPU array indexing overhead in loops a little. Additionally, a request for help: My not very optimized lpc_restore_signal is at the below URL, I couldn't get the ldm* instructions to work as advertised, even though I've talked

--- src/libFLAC/bitreader.c | 445 +++++++++++------------------------------------ 1 files changed, 105 insertions(+), 340 deletions(-) diff --git a/src/libFLAC/bitreader.c b/src/libFLAC/bitreader.c index ae515a0..7ae086d 100644 --- a/src/libFLAC/bitreader.c +++ b/src/libFLAC/bitreader.c @@ -755,379 +755,144 @@ FLAC__bool FLAC__bitreader_read_rice_signed(FLAC__BitReader *br, int *val, unsig }

On Fri, Mar 14, 2008 at 07:36:31PM +0100, Miroslav Lichvar wrote: > attached are patches that improve decoding speed a bit. The first > patch improves the bit scan macro used for decoding unary values, the > second one adds a GCC inline assembly for bswap and the third patch > replaces the read_rice_block function. The third patch has a bug causing reading past input buffer, attaching

On Mon, Nov 5, 2012 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote: > For llvm-dwarfdump we need to handle relocations inside the debug info > sections in order to successfully dump the dwarf info including strings. > Nick sent out a partial patch that did this not too long ago and I've taken > it and gone in a bit of a different direction, but kept the same basic

For llvm-dwarfdump we need to handle relocations inside the debug info sections in order to successfully dump the dwarf info including strings. Nick sent out a partial patch that did this not too long ago and I've taken it and gone in a bit of a different direction, but kept the same basic architecture. In place of applying the relocations to the data we've read from disk I'm keeping

Hi all - I'm trying to generate lattice barchart graphs with missing values, and came across the following: This does not run. I would expect it to: library(lattice) D = data.frame(X=1, Y=factor(letters[2], letters[1:2])) barchart(~ X, D, groups=Y) Error in grid.Call.graphics("L_rect", x$x, x$y, x$width, x$height, resolveHJust(x$just, : invalid line type which is simply

This is a proposal to add strong GC reference types to LLVM. We have some local (downstream) patches that are needed to prevent LLVM's optimizer from making transforms that are problematic in the presence of a precise relocating GC. Adding a notion of a strong GC reference to LLVM will let us upstream these patches in a principled manner, and will act as a measure to avoid new problematic

Hi, I am having some trouble trying to plot a histogram in more than one colour. What I want to do is, plot two vectors in the same histogram, but with different colours, for instance: > x <- rnorm(1000,20,4); > y <- rnorm(1000,10,2); Then I'd like to have x and y ploted on the same hist (I can do that already doing w <- c(x,y) then hist(w)) but the bars

I would like to place the value for each bar in barchart (lattice) at the top of each bar. Something like the following code produces. library(lattice) mypanelfunc <- function(x, y, ...) { panel.barchart(x, y, ...) panel.text(x, y, labels=as.character(round(x,2)), ...) } myprepanelfunc <- function(x, y, ...) list(xlim=c(0, max(x)+.1)) mydata <- expand.grid(a=factor(1:5),

There are following functions in bitreader.c: FLAC__bool FLAC__bitreader_read_unary_unsigned(FLAC__BitReader *br, unsigned *val); FLAC__bool FLAC__bitreader_read_rice_signed(FLAC__BitReader *br, int *val, unsigned parameter); FLAC__bool FLAC__bitreader_read_rice_signed_block(FLAC__BitReader *br, int vals[], unsigned nvals, unsigned parameter); * function FLAC__bitreader_read_rice_signed():

First, I love R and am grateful to be using this free and extremely high quality software. Recently I have been comparing two algorithms and naturally I programmed in R first. It is so slow that I can almost feel its pain. So I decided to do a comparison with Java. To draw 500,0000 truncated normal, Java program takes 2 second and R takes 72 seconds. Not a computer science major, I find it hard

Hi Andy, Andrew Trick wrote: > Sanjoy, > > This looks very close to my understanding of the statepoint design trajectory when you first introduced it. It’s great that you followed through and took the time to formalize the IR semantics. It’s been a couple years since I’ve thought about it so I may ask some obtuse questions. > > I think he subject line is wrong though! Did

This patch adds support for other compilers and systems including MSVC, Intel C compiler etc.. --- src/libFLAC/bitmath.c | 48 ------------- src/libFLAC/bitreader.c | 54 ++------------- src/libFLAC/include/private/bitmath.h | 120 ++++++++++++++++++++++++++++++--- 3 files changed, 116 insertions(+), 106 deletions(-) diff --git a/src/libFLAC/bitmath.c