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 <= 0x8000/512) { /* 512: more or less optimal for both 16-
> and 24-bit input */
> #else
> if(mean <= 0x8000/8
On 29 December 2015 at 13:33, Rafaël Carré 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 <= 0x8000/512) { /* 512: more or less optimal for both 16-
>> and
Erik de Castro Lopo wrote:
> I see 6 posts from you in the last 12 hours.
Now I see them too.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
I wrote a patch that enables FLAC__BYTES_PER_WORD==8 in
libFLAC/bitreader.c and libFLAC\bitwriter.c.
The tests were done on an Intel Nehalem CPU, and flac was compiled
with CGG 4.9.x.
Average speed increase for FLAC__BYTES_PER_WORD change from 4 to 8:
Decoding speed:
ia32 architecture
Thomas Zander wrote:
> ... and this probably won't be the last time we'd need to handle special
> cases.
> Do we really need to handle this at all? Entangling CPU-arch-dependent
> #ifdefs with input sample size (see "tuned for N-bit input" a few
> lines below" seems weird.
> IMHO finding the rice
lvqcl wrote:
> The patch for alloc.h is self-explanatory, I hope.
>
> The patch for foreign_metadata.c replaces 0xu with 0x.
> Reason: there are many places with 0x constants, and only two
> (both in foreign_metadata.c) with 0xu. The patch will make
> the code more
lvqcl wrote:
> 1) FLAC supports only MSVS 2005 and newer, so (_MSC_VER >= 1400)
> is always true and can be removed.
>
>
> 2) The argument for FLAC__clz_uint32() is of FLAC__uint32 type, so
> FLAC__clz_soft_uint32() should have the same argument type.
>
>
> 3) The patch removes unnecessary par
Rafaël Carré wrote:
> That would need a special case for Linux x32 which is x86_64 with 32
> bits pointers
It won't be wrong for x32, just sub-optimal.
Please feel free to suggest a way to detect x32.
Erik
--
--
Erik de Castro
On 29 December 2015 at 17:16, lvqcl wrote:
> I agree that it's a good idea to test the speed of encoding.
> Maybe different code for 32-bit and 64-bit architectures
> is over-optimization.
I completely agree. With today's complicated CPUs it would be
extremely hard if not impossible to formulate
On 29 December 2015 at 17:10, lvqcl wrote:
> I wrote a patch that enables FLAC__BYTES_PER_WORD==8 in
> libFLAC/bitreader.c and libFLAC\bitwriter.c.
> The tests were done on an Intel Nehalem CPU, and flac was compiled
> with CGG 4.9.x.
If you want to share the patch, I am happy to repeat some test
Le 29 déc. 2015 20:31, "Erik de Castro Lopo" a
écrit :
>
> Rafaël Carré wrote:
>
> > That would need a special case for Linux x32 which is x86_64 with 32
> > bits pointers
>
> It won't be wrong for x32, just sub-optimal.
>
> Please feel free to suggest a way to detect x32.
>From https://sourcewar
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.
On 12/29/15 11:31 AM, Erik de Castro Lopo wrote:
> Rafaël Carré wrote:
>
>> That would need a special case for Linux x32 which is x86_64 with 32
>> bits pointers
>
> It won't be wrong for x32, just sub-optimal.
>
> Please feel free to suggest a way to detect x32.
>
Shouldn't these tests be in conf
Rafaël Carré wrote:
> From https://sourceware.org/glibc/wiki/x32
>
> x86-64 C/C++ compiler predefines macro__LP64__ while x32 C/C++ compiler
> predefines macro __ILP32__.
What compiler defines these? GCC? Clang? The Intel compiler?
Erik
--
--
Dave Yeo wrote:
> Shouldn't these tests be in configure and at worst x32 can be passed as
> target.
Indeed!
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
flac-dev mail
15 matches
Mail list logo
