[FFmpeg-devel] [PATCH] split-radix FFT

[Michael Niedermayer]

On Tue, Jul 29, 2008 at 09:47:40PM +0300, Uoti Urpala wrote:
> On Tue, 2008-07-29 at 20:02 +0200, Michael Niedermayer wrote:
> > On Tue, Jul 29, 2008 at 07:14:02PM +0300, Uoti Urpala wrote:
> > > > > And how does using MANGLE improve things? 
> > > > 
> > > > It makes the code run faster and makes it smaller, but i said that already.
> > > 
> > > As would just omitting -fPIC, without the ugliness of MANGLE. 
> > 
> > First this is not always possible (x86-64 and distro policies)
> > Second the ugliness is actually debateable
> > 
> > "mov "MANGLE(cos_pi)", %%eax"
> > 
> > is actually more readable than
> > 
> > "mov %7, %%eax"
> > 
> > because cos_pi makes sense and %7 requires one to check what it is actually.
> 
> Using named asm arguments would give better readability. Of course when
> talking about named asm args you claim that using the "%d" names is no
> readability problem and even if it were macros could be used to give
> them symbolic names equally easily - nobody just ever does that...

named args are more readable than %d, but using them means droping support 
for several compilers or using macros, One cannot have all.
People dont seem to like the macro idea and i as well as others
dislike the idea of droping several supported compilers.
Its a tradeoff, one has to weight the advantages and disadvanatages and then
choose what is overall best. In the past we preferred to keep the old
compilers supported. If that changes and the majority of developers would 
prefer to use named asm arguments then i surely wont oppose using them and
thus droping support for the old compilers with the affected asm().


> 
> > > But my
> > > question was about the distribution case. I'll rephrase it if if the
> > > original wasn't clear enough:
> > > You said that MANGLE helps with distributions that have a policy that
> > > requires using -fPIC. How does it actually help? 
> > 
> > You misunderstood my intention, what i meant was MANGLE helps the users
> > of the binary package of distributions as the application (ffmpeg) is faster.
> > Which is an advantage for the user.
> 
> So you think the distros will be OK with textrels or fill fail to notice
> them as long as the command line nominally says "-fPIC".

I think they will be ok with textrels.
If they will fail to notice them, thats
something i do not know, i suspect many of the package maintainers are
subscribed and are aware of the existing textrels already since a long time.


[...]
> > It was you IIRC who equated -fPIC with no textrels in one of our previous
> > "discussions".
> 
> I'm not sure what kind of "equating" you mean. IIRC no interpretation of
> any formal outside policy was discussed. The closest thing I can think
> of is an argument along the lines that if the user really doesn't want
> textrels then forcing their use is wrong; and if the user is OK with
> textrels then just don't compile the file with -fPIC.

Most users who add -fPIC either do it
* because of some policy, boss, rule, ...
* because they think it improves performance, be it free mem or other
* because they do not understand it at all and it was in a example they copied

None of them really wants to avoid a very small number of textrels at
the cost of a possible noticeable speedloss IMHO. At least ive never seen one
who complained about the textrels, something like "i want to disable all
textrels i know it will be 5% slower and need more memory on my desktop but
i still want it, how can i do it?" ;)

The ones that have a little
clue do it for increased performance (theoretically less memory needed)
i really do not think they would want a 1-2% speedloss for maybe the few
kb of non shareable memory.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080729/502a371e/attachment.pgp>