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 minor. > However losing 15% decoding speed on i386 would be very bad.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?
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 can always change it if it turns out there is a better option. Riggs
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 can always change it if it turns out there is a > better option. > > RiggsWhat's wrong with something incredible simple, like: #define FLAC__BYTES_PER_WORD (sizeof(int)) ?