[Mplayer-cvslog] CVS: main/DOCS/tech TODO,1.9,1.10

[Nick Kurshev]

Hello, Michael!

On Thu, 13 Dec 2001 19:28:35 +0100 you wrote:

[snip]
> >
> > My issues:
> > 1) cache pollution due function inlining (significand for any cpus)
> yes if they are inlined  but the compiler shouldnt do that and the code is 
> full of memcpy() calls which it isnt afaik
> 
I'm not sure about gcc - but if we'll group cpu depended code in one logical place
then we'll get that not native code will be swapped out from cache and cache will
be filled only with usefull code. and calling memcpy through pointer will be
gladly accepted in this case.
extern (*fastmemcpy_ptr)()
#define fastmemcpy (*fastmemcpy_ptr)
> >    else you'll get dramatically performance losing. (As you write - 50 cpu
> > cycles) 
> well dramatic is perhaps a bit too dramatic ;) but it would be suboptimal 
> indeed, 50 is not realistic ... noone calls memcpy to copy 1 byte 
> and they shouldnt be inlined as i said allready
> 
copying of 1 byte is much better through standard memcoy function ;)
MMX version is better only since 64 byte (on K6-2) and only since 800 byte (on P1-PII)
> > 2) wrong prediction in 75% of cases
> >    due uncached code and data
> ehh 75%? even a random number generator would do better ;)
> 
agree ;)
> > 3) just not elegant solution
> rewrite it if u like, if urs is not slower and looks more elegant iam happy 
> 
I'm not against of your stuff - I'm justly trying to improve this new stuff from my point.
> [...]
> 
> Michael
> _______________________________________________
> Mplayer-cvslog mailing list
> Mplayer-cvslog at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-cvslog
> 


Best regards! Nick