similar to: Performance checks

On 28-05-13 19:38, Miroslav Lichvar wrote: > I'm always interested in performance tests :). In that case I hope you saw the previous one, because the decoding speed-up was credited to be one of your patches, according to some people over at HydrogenAudio: http://lists.xiph.org/pipermail/flac-dev/2013-March/003856.html Really, great stuff ;) > I think if you are setting CFLAGS you

Miroslav Lichvar wrote: > Well, this reverts the commit 18e0154. How is the user supposed to set > CFLAGS without getting -O3 -funroll-loops there? (e.g. to minimize the > size of the compiled binaries) Is it -O3 or -funroll-loops that you have a problem with? Or both? What would you prefer to see as the default optimisation level? I'm sure there is a solution to this. Lets find

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07.05.2012 17: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

Martijn van Beurden wrote: > op 25-07-14 19:32, Scott Brown schreef: > > ./configure -enable-static -disable-shared CFLAGS=" -isysroot > > /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6" > > make > > Well, the use of CFLAGS 'disables' the -O3 and unroll-loops > optimisation. I'm quite sure that's the culprit. Add -O3 to your

On 31.5.2013 13:04, Miroslav Lichvar wrote: > On Wed, May 29, 2013 at 04:08:57PM +0200, Martijn van Beurden wrote: >> I was surprised to see that the Windows compile on wine actually >> outperformed the native Linux one. Probably GCC 4.6 optimized a little >> better or something very weird is going on in wine, I don't know. The >> assembly optimizations work very

On Sat, Jun 01, 2013 at 02:33:55PM +0300, Janne Hyv?rinen wrote: > On 1.6.2013 14:24, Janne Hyv?rinen wrote: > > I can confirm. I see 10% speed improvement with that change on Core i7. > > Decoding a 1h18min38.133s long test FLAC -8 encoded file takes with > > normal asm optimizations 7.656s (speed: 616,266x realtime) and with that > > tiny change 6.937s (speed: 680,140x

The current llvm/llvm-gcc-4.2 2.6 branch passes all of the Polyhedron 2005 benchmarks built with its gfortran. The results compare as follows... Compile Command : gfortran -ffast-math -funroll-loops -msse3 -O3 %n.f90 -o %n benchmark gcc-4.2.4 llvm-gcc-svn llvm-gcc-2.6 llvm-gcc-2.6 at -m32 20081031 -m32 at -m32 at -m64 ac 18.30

On 28.5.2013 21:06, Martijn van Beurden wrote: > On 28-05-13 19:38, Miroslav Lichvar wrote: >> I'm always interested in performance tests :). > In that case I hope you saw the previous one, because the decoding > speed-up was credited to be one of your patches, according to some > people over at HydrogenAudio: >

On Fri, May 04, 2012 at 05:53:23PM +0200, Miroslav Lichvar wrote: > The most interesting part of the patch is the rewrite of the > FLAC__bitreader_read_rice_signed_block function, which in the git repo > seems to have only couple lines changed since 1.2.1. Here is that part of the patch rebased against current git. In a quick test it gives a 10% speedup in decoding. -- Miroslav Lichvar

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 necessary. With current compilers it is very likely that those routines are already superflous.

On Thu, Sep 12, 2002 at 10:54:04PM +0200, Miroslav Lichvar wrote: > I tried tagging using metaflac with some iso-8859-2 chars, but these > chars were replaced by '#' chars, something wrong is here. Ok, here is simple patch, it works for me, but I'm not familiar with this stuff. BTW, metaflac --list prints comments in raw utf8, it can screw terminal easily. -- Miroslav Lichvar

--- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > On Sat, Nov 09, 2002 at 06:02:33PM +0100, Miroslav Lichvar wrote: > > On Fri, Nov 08, 2002 at 07:12:35PM -0800, Josh Coalson wrote: > > > Yeah, it's useful, so now there is a > > > FLAC__seekable_stream_decoder_get_decode_position() and > > > FLAC__file_decoder_get_decode_position(). I

Ok, what about enabling the 3dnow function in libFLAC by default? I think time has shown the function is bugfree... :) -- Miroslav Lichvar

Hi all, The past few weeks I've been busy comparing lossless audio codecs to update the comparison.html page on the FLAC website (and because I wrote a comparison for Hydrogenaudio in the past) and its ready now. Because the patch is pretty large, I've placed it here: http://www.icer.nl/misc_stuff/update-comparison-and-fix-IE-news.patch.zip The reason to do this is because the

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 >>> enabled. >>> >> Was that with -O2 or

There's an entry in the changelog: "Improved decoding efficiency of all bit depths but especially so for 24 bits (lvqcl)" A couple of comments: 1) The patch that improves encoding for all depths was proposed by Miroslav Lichvar <http://git.xiph.org/?p=flac.git;a=commit;h=4eab6313cd2198b5647d925bdb3847590505fa21> 2) "Performance checks" graph posted by Martijn van

On Thu, Dec 11, 2014 at 11:12:25AM +0100, Martijn van Beurden wrote: > Op 11-12-14 om 10:53 schreef Martijn van Beurden: > > Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > >> but I'd rather see the real seeking bug fixed instead > > > > I think I might have a fix [...] So the problem is that FLAC__stream_decoder_process_single returns error before it finds a

On Tue, Dec 17, 2002 at 01:01:08PM -0800, Josh Coalson wrote: > --- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > > Ok, what about enabling the 3dnow function in libFLAC by default? > > I think time has shown the function is bugfree... :) > > Yeah, I just haven't done it because I don't remember hearing > feedback from others about using it (or

El 03/05/12 12:19, Miroslav Lichvar escribi?: > Hi Josh, > > nice to see you here again. > > On Wed, Apr 25, 2012 at 04:26:05PM -0700, Josh Coalson wrote: >> (Jumping in again, maybe at the wrong point since this doesn't seem >> to involve encoding, but here goes.) >> >> Miroslav's patches have always been high-quality for sure. But >>

Early this past week, Miroslav Lichvar suggested for me: > Ok, you need 0.04% improvement, that should not be a problem. Try > flac --lax -e -p -l 32 -r 10 --no-padding Thank you again, Miroslav. I tried that, and it took almost two full days (surprisingly, Windows ME stayed up that long without crashing) to re-encode the entire set on my 266-MHz machine. After all, in the help file