[Ffmpeg-devel] [PATCH] Machine endian bytestream functions
Wed Apr 25 11:09:24 CEST 2007
On Tue, Apr 24, 2007 at 11:18:03PM -0300, Ramiro Ribeiro Polla wrote:
> M?ns Rullg?rd wrote:
> >>> I'm thinking the unaligned16/32/64 macros from bitstream.h should be
> >>> renamed and moved here instead.
> >> I'll take a look.
> > This lets the compiler choose whatever access method is appropriate,
> > and saves us the trouble of maintaining a fragile list
> Is there a way for us to get that information off the compiler? (assume
> only gcc atm)
> I thought maybe compile a simple read with __attribute__((packed)) and
> another without the attribute. Then compare object files and assume that
> if they're equal, unaligned access are ok.
what exactly are you trying to do?
* all unaligned accesses should be through __attribute__((packed)) when
attribute packed is supported by the compiler (unless this is slower
in practice = needs benchmark)
* testing if unaligned accesses are possible isnt hard, just do a unaligned
access and if it doesnt crash and gives the correct value its ok
this of course wont tell you if its fast ...
* gcc does not know if bytewise acesses are faster than unaligned 16/32 bit
and gcc cannot know if unaliged access with byteswap is faster than bytewise
hell it doesnt even know how to do a byte swap optimally just look at
yesterdays patch about it, gcc is 200% worse, so i dont know why you
put so much faith in gcc ...
* if you want to find out if A or B is faster then write a benchmark
something like configure --benchmark which when run on an idle system
would print the likely (speedwise) optimal set of configure options
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel