Re: [flac-dev] Residual bps and encoding speed
Martin Leese wrote: Would not a /* Do not remove */ comment be sufficient (and much less effort)? Less effort, but also less reliable. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Performance checks
On Wed, Jul 02, 2014 at 10:18:58PM +0200, Martijn van Beurden wrote: http://www.audiograaf.nl/misc_stuff/FLAC-performance-test-Linux-GCC-4.8.pdf http://www.audiograaf.nl/misc_stuff/FLAC-performance-test-Wine-MSVC-2013.pdf For the GCC 4.8 results, there is a*very nice 60% to 70% speed increase* when encoding with preset -8 between FLAC 1.3.0 and current git. That's indeed a significant improvement. I'm assuming most of it is from the SSE intrinsic code. Good job, lvqcl! -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] two patches of doubtful usefulness
lvqcl wrote: 1) lpc.c, FLAC__lpc_quantize_coefficients(): snip 2) There's the following code in stream_decoder.c: Like you, I don't see a lot of value in these. I think I'll decline these. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] two patches of doubtful usefulness
On Thu, Jul 03, 2014 at 04:21:59PM +0400, lvqcl wrote: Erik de Castro Lopo wrote: There's the following code in stream_decoder.c: Like you, I don't see a lot of value in these. I think I'll decline these. FLAC__lpc_restore_signal_asm_ia32_mmx compares 'order' argument with 4 and if it's greater then it jumps to FLAC__lpc_restore_signal_asm_ia32. I wonder why the same wasn't done for PPC/Altivec: why libFLAC compares 'order' and 8 in C code and not in asm. Perhaps because it's easier to do it in C than in asm? :) Wrapping the check in #ifdef will save few instructions on non-ppc archs, but in this case I think it doesn't really matter. It would make the code less readable and more likely someone will forgot about it in the future and break it for ppc. -- Miroslav Lichvar ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PPC asm is disabled since Jan 2005? Why?
lvqcl wrote: FLAC__lpc_restore_signal_asm_ia32_mmx compares 'order' argument with 4 and if it's greater then it jumps to FLAC__lpc_restore_signal_asm_ia32. I wonder why the same wasn't done for PPC/Altivec: why libFLAC compares 'order' and 8 in C code and not in asm. ...more about PPC ASM: http://git.xiph.org/?p=flac.git;a=commitdiff;h=63d489ae3140296419afdfc4cfc87cc2c7cb9faf http://git.xiph.org/?p=flac.git;a=commitdiff;h=3c8d2973cb87e318c11f3a487f2204bf0d673176 +AM_CONDITIONAL(FLaC__HAS_AS__TEMPORARILY_DISABLED, test yes = no) -if FLaC__HAS_AS +#@@ +if FLaC__HAS_AS__TEMPORARILY_DISABLED -CPUCFLAGS = -maltivec -mabi=altivec -force_cpusubtype_ALL +#@@ PPC optimizations temporarily disabled +CPUCFLAGS = -maltivec -mabi=altivec -force_cpusubtype_ALL -DFLAC__NO_ASM Does it mean that PowerPC/Altivec asm optimizations were disabled almost 10 years ago? ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] uint64 - double conversion
lvqcl wrote: Not quite ;) You missed the fact that this .vcproj file contains 2 different settings: one for Debug build and another for Release build. The patch that fixes Release build is attached. Thanks! I should have probably left that to you so you could test it. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
