[Ffmpeg-cvslog] r8420 - trunk/libavcodec/dv.c

[Måns Rullgård]

Rich Felker <dalias at aerifal.cx> writes:

> On Sun, Mar 25, 2007 at 11:43:40AM +0100, M?ns Rullg?rd wrote:
>> Rich Felker <dalias at aerifal.cx> writes:
>> 
>> > On Sat, Mar 24, 2007 at 09:17:47PM -0700, Roman Shaposhnik wrote:
>> >> > it's a matter of what the calling
>> >> > code does. Thus all you can ever assume on x86 is 4. In order to be
>> >> > correct, the compiler must generate code to fully align the stack in
>> >> > any function that depends on the stack being aligned. gcc does not do
>> >> > this, so it's broken. Either they should fix this or document the fact
>> >> > that alignment attributes do not work on automatic variables.
>> >>  
>> >>   In Sun Studio compilers we've decided to do a combined approach
>> >> now -- we honor requests for alignment of the automatic variables 
>> >> up to the ABI requirements (although, it seems to be safe to assume
>> >> 8 on Pentium+ these days for obvious reasons) and we issue a warning
>> >> if the requested alignment is higher. I believe it was suggested that
>> >> gcc guys do the same -- but they don't seem to be interested.
>> >
>> > I hope you only assume 8 if -march=586 or similar is used. I always
>> > build with vanilla i386 except for really rare cases like mplayer.
>> 
>> No wonder you're complaining about things being slow.
>
> -march gives at most a 1-5% increase in performance, which is useless
> in anything except a movie player or action game or similar realtime
> app. Also the programs that most need performance are the ones where
> it helps least, since they've already had the critical parts written
> in asm.
>
> I really don't think it helps for the 1% of /bin/ls spent in userspace
> to be 1% faster... On the other hand, it's been quite nice being able
> to swap drives into ANY i386 hardware when I had sudden hardware
> failure, which would not have been possible if I'd uselessly built
> everything with -march. Thus I'll continue to build everything but
> ffmpeg/mplayer as plain 386 code, and flame the gentoo ricers with
> their 100+ character CFLAGS...

Suit yourself.

>> > Most likely alignment doesn't matter for pre-586 anyway, but I suppose
>> > someone could be using it for evil hacks like storing extra data in
>> > the low bits of pointers... :)
>> 
>> Lisp interpreters tend to do such things.
>
> Yes, I was thinking of emacs.. :) However it only uses global static
> objects and malloc, none on the stack. The problem would go away
> anyway if they just stored the type of the lisp object as the first
> word pointed to, instead of trying to store it in the pointer itself.
> No one really cares about one wasted word per object...

One memory access less per operation can soon start paying off in
terms of speed.  Also keep in mind that many of these programs were
originally written in the days when memory was measured in kilobytes
and CPU cycle times in microseconds.

-- 
M?ns Rullg?rd
mans at mansr.com