[FFmpeg-devel] the future of fastmemcpy.h

[Robin Getz]

On Tue 22 May 2007 16:56, Michael Niedermayer pondered:
> On Tue, May 22, 2007 at 10:17:34PM +0200, Reimar Doeffinger wrote:
> > On Tue, May 22, 2007 at 09:53:59PM +0200, Alex Beregszaszi wrote:
> > > > Ronald brought up the subject of the fastmemcpy.h #includes that
> > > > we continue to have in a few source files.  fastmemcpy.h is part of
> > > > MPlayer and not FFmpeg.  Is the #include just old cruft or worth 
> > > > keeping? 
> > > > 
> > > 
> > > I thought today about moving fastmemcpy into libavutil.
> > 
> > Please don't without proper performance testing, it stops gcc from
> > replacing constant-size memcpys by an inlined builtin, causing both
> > valgrind problems and at least for lzo massive slowdown.
> 
> introduce a big_memcpy() and leave memcpy() as is ...
> 
> and yes it should be benchmarked

Is there a desire to introduce other styles of memcpy?

For example - on some hardware - you can jump into kernel space, start a 
memory to memory DMA, return and do computations on other things while the 
copy happens in the "background". Think of it as a non-blocking memcpy.

Depending on the overhead of getting to kernel space - this can have 
advantages for architectures where the buffer being copies is a small as 1k.

-Robin