[MPlayer-users] rant

[Andrew Suffield]

On Tue, Oct 09, 2001 at 03:30:01PM +0200, Gábor Lénárt wrote:
> On Tue, Oct 09, 2001 at 10:26:59AM +0100, Andrew Suffield wrote:
> > On Mon, Oct 08, 2001 at 10:38:51PM +0200, Gábor Lénárt wrote:
> > > It does not worth to support! If you can select between functions optimized
> > > for various CPUs it would take much more memory and a bit more CPU time
> > > (function pointers). If you make dynamic loadable "plugins" it would
> > > decrease performance about between 10 and 20 percent (afaik). The latter
> > > because on x86 relocation information should be kept in a register (and
> > > shared objects are this kind of thing ..). 
> > 
> > Uhh, this is complete nonsense. If written in any reasonable manner it 
> > will be no slower. Also, mplayer already links against half a dozen 
> 
> P*L*E*A*S*E! Don't flame me, I was probably coding much more x86 assembly
> than you. These are the facts! Please read some dox, learn more because it's
> very lamer attitude to say "complete nonsense" even if you're not right :)

Then get the facts straight. There is no magic fairy that makes code
slower just because it is loaded after the main binary. There aren't
any function pointers involved after it's started, either - you call
through one pointer when you start the decoding core (or whichever
chunk of code you happen to be selecting), and that's it.

You don't even need to delay loading, it's quite possible to build all
versions into the main binary - even easier to setup, but increases
the virtual image size (which doesn't matter much on a system with a
non-broken paging system).

If you have any actual facts to back up that "10-20% assertion",
please post the patch you used to test it and a script of the
benchmark run.

> > shared libraries, and dynamically loads dvd support at run time as 
> > necessary. You don't even need to use any shared code, that's just the
> > neatest solution.
> > 
> > > Our world is not perfect. Usually modularity is against the performance ...
> > 
> > Usually it makes no impact on runtime performance, only on load time. 
> > That's why unix-like systems have been modularly designed for the last 
> > 20 years or so.
> 
> Arghhhh! Please again! And again. Maybe I know much more on Linux kernel
> than you.

If you did, you would know that it has nothing to do with the
kernel. mplayer runs in userspace, as does the dynamic linker
(ld-linux.so, dlopen() in libc, or whatever your obscure system of
choice uses).

> > Then quit getting users. Sloppily compiled binaries are rare unless you use 
> > redhat; user error is extremely common. There are plenty of other 
> > opportunities for a user to screw up. Live with the users or unsubscribe 
> > from the list.
> 
> Nice :) Maybe YOU should unsubscribe and learn SOMETHING on human manner.
> I was explaining my opinion only then you started this personal flame against
> me. Imho you would unsubscribe before I will ever do it :)

You appear to have completely missed my point. You subscribe to the
mplayer-users list by choice; if you don't like hearing from users,
unsubscribe. Otherwise, don't complain about the users you hear
from. If you want to get bug reports from users, you have to be
prepared to get invalid reports from people with no clue.

Incidentally, you appear to have some weird opinion that this is a
personal flame. I have no idea who you are, and I don't care. I am
merely correcting some incorrect assertions.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :                         | Dept. of Computing,
 `. `'                          | Imperial College,
   `-    http://www.debian.org/ | London, UK