Displaying 20 results from an estimated 2000 matches similar to: "FLAC__BYTES_PER_WORD==8 test results"
2015 Dec 29
2
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
2015 Dec 31
1
[PATCH] Support 64-bit brword/bwword
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
2015 Dec 30
2
FLAC__BYTES_PER_WORD==8 test results
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
2015 Dec 20
2
about word size in bitreader/bitwriter
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
2015 Dec 16
2
about word size in bitreader/bitwriter
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
2008 Mar 14
2
bitreader optimizations
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
2017 Jan 19
4
[PATCH] Fix cppcheck warnings
---
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
2016 Jan 04
0
about word size in bitreader/bitwriter
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
2013 Apr 07
2
flac 1.3.0pre3 pre-release
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
2016 Mar 14
2
Broken build on musl libc
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
2008 Oct 22
2
[LLVMdev] r57974 & r57976 for PR2888
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 -
2011 Mar 09
1
[LLVMdev] Discrepancies between bin/llvm-config --libs and LLVM_LINK_COMPONENTS in CMake.
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
2015 Dec 31
1
FLAC__BYTES_PER_WORD==8 test results
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)
2013 Mar 11
3
flac 1.3.0pre2 pre-release
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
2013 Apr 01
17
flac 1.3.0pre3 pre-release
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 May 15
2
FLAC currently won't compile for Android [bisected]
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
2015 Dec 29
2
How to check for 64-bit CPU?
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
>>
2016 Feb 02
2
Performance tests
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
2012 Sep 19
1
[LLVMdev] Saving code for later execution
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
2016 Feb 02
2
Performance tests
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