similar to: FLAC__BYTES_PER_WORD==8 test results

Thomas Zander wrote: > If you want to share the patch, I am happy to repeat some testing on > Sandy Bridge and Core2 with clang. The patch changes many files, libFLAC/bitwriter.c and test_libFLAC/bitwriter.c among them. So now I wait for the decision for patches #3 and #4 that I posted yesterday. > The slower decoding speed for 24 bit content on x86_64 seems > surprising, but

Here is the patch that allows to set FLAC__BYTES_PER_WORD to 8. This is disabled by default though. To test FLAC__BYTES_PER_WORD==8: open src/libFLAC/bitreader.c, src/libFLAC/bitwriter.c, src/test_libFLAC/bitwriter.c and change '#if 1' to '#if 0'. The value of FLAC__BYTES_PER_WORD must be the same in src/libFLAC/bitwriter.c and src/test_libFLAC/bitwriter.c. OTOH, their value in

On Dec 30, 2015, at 3:09 AM, Thomas Zander <thomas.e.zander at googlemail.com> wrote: > On 29 December 2015 at 21:50, lvqcl <lvqcl.mail at gmail.com> wrote: >> So, does it make sense to #define FLAC__BYTES_PER_WORD (in bitreader.c) >> as 4 for 32-bit and as 8 for 64-bit targets? > > Your tests so far imply this is a sensible default. > I'd say go ahead. We

Erik de Castro Lopo wrote: > The think in and ideal world we would a: > > * Make it work correctly FLAC__BYTES_PER_WORD == 8 and compare the performance > with FLAC__BYTES_PER_WORD == 4. > * If there is an statistically measurable performance, keep it, otherwise > remove the FLAC__BYTES_PER_WORD == 8 code all together. I'll try to do it, but I don't have a deep

There are preprocessor definitions in bitreader.c and bitwriter.c: /* Things should be fastest when this matches the machine word size */ /* WATCHOUT: if you change this you must also change the following #defines down to SWAP_BE_WORD_TO_HOST below to match */ /* WATCHOUT: there are a few places where the code will not work unless uint32_t is >= 32 bits wide */ #define

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

--- src/libFLAC/bitreader.c | 4 ++-- src/libFLAC/bitwriter.c | 4 ++-- src/plugin_xmms/plugin.c | 2 +- src/share/utf8/charset.c | 1 + src/test_libFLAC++/encoders.cpp | 8 ++++---- src/test_libFLAC/decoders.c | 4 ++-- src/test_libFLAC/encoders.c | 8 ++++---- 7 files changed, 16 insertions(+), 15 deletions(-) diff --git a/src/libFLAC/bitreader.c

On Sun, Dec 20, 2015 at 01:30:57PM +0300, lvqcl wrote: > Erik de Castro Lopo wrote: > > > The think in and ideal world we would a: > > > > * Make it work correctly FLAC__BYTES_PER_WORD == 8 and compare the performance > > with FLAC__BYTES_PER_WORD == 4. > > * If there is an statistically measurable performance, keep it, otherwise > > remove the

Dagobert Michelsen wrote: > There compilation on Solaris 10 Sparc with Sun Studio 12 gives the following compile errors: > > > CC bitreader.lo > > "bitreader.c", line 494: warning: implicit function declaration: MIN > > CC bitwriter.lo > > "bitwriter.c", line 273: reference to static identifier "bitwriter_grow_" in extern

On 14 March 2016 at 09:02, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > commit a9f84425cfd5d1dbfb564730ca80d0b588cb4f24 > Author: Erik de Castro Lopo <erikd at mega-nerd.com> > Date: Mon Mar 14 18:14:31 2016 +1100 > > libFLAC/cpu.c: Use `sigemptyset` instead of `__sigemptyset` > > The former is POSIX while the later is a GNU

Pending positive confirmation in http://llvm.org/PR2886, I'd recommend that r57974 and r57976 be pulled into the 2.4 release branch and configure regenerated there. Begin forwarded message: > From: Gordon Henriksen <gordonhenriksen at mac.com> > Date: October 22, 2008 08:40:40 EDT > To: llvm-commits at cs.uiuc.edu > Subject: [llvm-commits] [llvm] r57974 -

Hello. When i run llvm-config --libs jit bitreader bitwriter ipo linker engine i get: -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMX86Info -lLLVMLinker -lLLVMArchive -lLLVMipo -lLLVMBitWriter -lLLVMBitReader -lLLVMJIT -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine

On 31-Dec-15 09:00, Erik de Castro Lopo wrote: > Brian Willoughby wrote: > >> What's wrong with something incredible simple, like: >> >> #define FLAC__BYTES_PER_WORD (sizeof(int)) > The fact that it actually is not correct. We want to determine > the size in bits of the CPU registers. > > Here's what I know: > > sizeof(int)

Ben Allison wrote: > As mentioned before, this removes some of the 'inline' from the bitreader > and bitwriter functions that were used in another translation unit. I'm > surprised that this code works on other platform. It must be a bug in > GCC, or maybe deliberately non-standard behavior. See 6.7.4 of the C99 > spec for details. I've read section 6.7.4 from

Hi all, The latest pre-release is here: http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre3.tar.xz but there will probably need to be at least one more. I've tested this on x86_64-linux powerpc-linux i386-openbsd5.2 i386-freebsd9 The majority of changes since the last pre-release is the addition of Janne Hyv?rinen's utf8 I/O functionality. Janne's

2013/5/15 Ulrich Klauer <ulrich at chirlu.de> > Felix Homann wrote: > > > Yes, HAVE_SYS_PARAM_H is set in config.h: > > OK ... Yet still I don't see how a change in > src/libFLAC/include/private/macros.h could affect src/flac/utils.c in > any way. > > Anyone got an idea? I haven't spend too much attention to the errors when bisecting, sorry! The

On 29 December 2015 at 13:33, Rafa?l Carr? <funman at videolan.org> wrote: > On 12/28/2015 08:35 PM, lvqcl wrote: >> In stream_encoder.c there's the following code: >> >> #if defined FLAC__CPU_X86_64 /* and other 64-bit arch, too */ >> if(mean <= 0x80000000/512) { /* 512: more or less optimal for both 16- and 24-bit input */ >> #else >>

Op 02-02-16 om 16:54 schreef lvqcl: > BTW, 64-bit flac can benefit from 64-bit words in > bitreader/bitwriter routines. Currently it requires > --enable-64-bit-words switch in ./configure parameters. It > would be interesting to test its effect, especially on ARM. Okay, I might test that as well. I've checked performance with the brand new laptop my employer gave me, which is

I'm using the LLVM C++ API to create code on-the-fly for execution. This works fine. But what if I want to save this code to disk, quit, relaunch my app at some later time, reload the previously generated code off disk, and execute it? How can I do that? Can somebody point me to some documentation or examples? Thanks. - Paul

Hi, Once again, I did some performance testing. Results are here: http://www.audiograaf.nl/misc_stuff/Comparison on 32-bit ARM (Raspberry Pi B).pdf http://www.audiograaf.nl/misc_stuff/Comparison on 64-bit Linux (2008 Intel).pdf I'll add some results for 64-bit Windows (2014 Intel with AVX2) in a few days. Results look nice, a 20% speedup on my x86_64 platform for the slowest mode. Not