[FFmpeg-devel] [PATCH] RoQ video encoder, take 2
Mon May 28 16:24:45 CEST 2007
On Mon, May 28, 2007 at 03:19:29PM +0200, Michael Niedermayer wrote:
> On Sun, May 27, 2007 at 06:23:11PM +0200, Reimar D?ffinger wrote:
> > I disagree, the int_fast*_t types are useless, they rarely are related
> > to reality. E.g. int_fast8_t on x86 is 8 bit, but that will be significantly
> > slower when used as e.g. array index. Even if not it won't really be any
> submit a bugreport to the responsible red^H^H^Hgnu toolchain devels
If anything the bug is in the C spec for giving it a name that promises
something that can't be done. Something like uint_native8_t would be
closer to reality (though uint_native_if_possible8_t would be necessary
if you want to be more correct. And even here you do not yet specify for
what kind of operations the type should be native - addition or
multiplication, address operations,...).
Which data type is fast depends on both architecture and what you do: do
you use it as index? Is size relevant due to e.g. memory bandwidth
considerations? And many more details.
Though I admit for RISC architectures it probably is often possible to
define it in a way that makes sense in 90% of cases.
More information about the ffmpeg-devel