[MPlayer-users] rant

[Gábor Lénárt]

This is my last letter here PLEASE continue this thread in private if
you whish and please NO NOT REPLY to the list, I think it's out of the
borders of this list, it's not an MPlayer user issue.

On Tue, Oct 09, 2001 at 06:14:05PM +0100, Andrew Suffield wrote:
> 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.

Watch, an example:

greet     push ebx              ; we'll use EBX for GOT, so save it
          call .getgot
.getgot:  pop ebx
          add ebx,_GLOBAL_OFFSET_TABLE_ + $$ - .getgot wrt ..gotpc
          mov eax,[ebx+integer wrt ..got] ; [14]
          mov eax,[eax]
          inc eax
          mov [ebx+localint wrt ..gotoff],eax ; [14]
          mov eax,[ebx+commvar wrt ..got]
          push dword [eax]
          mov eax,[ebx+localptr wrt ..gotoff] ; [13]
          push dword [eax]

Inside a shared object, you must keep track GOT which will take a register
away. Since x86 hasn't got tons of registers this will cause some slowdown.
Also you must more complex addressing modes. OK, modern CPUs may not waste
additional clock cycles but it's harder to pair instructions inside pipelines.
And the problem about less registers remains ... Of course you can hold GOT
in memory, but every data access you need GOT, so it's not a good move.

The slowdown I described in my last letter wasn't my original idea, it's
documented in many dox. First I was surprised like you (when I wasn't
capable of many my current skills) but then I got the point. You should
take a look deeper inside the system as well, imho.

If I want to be honest, I can say that the slowdown value is not messured
by me, but I read values about between 5 and 20 percent in many dox. Of
course it's higly depends on the code you run.

> > 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).

It's another topic, I only marked that the design of UNIX (including
kernel as well - this was only an example from me) is known by me.
"The way of UNIX" is a "life style" ;-) and it can be found many-many places
inside a UNIX like OS (including kernel as well). But you're right, it's
another question ...

> > > 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

You subscribed the list by choice as well, didn't you?

> from. If you want to get bug reports from users, you have to be
> prepared to get invalid reports from people with no clue.

Of course. But you can make SOMETHING to reduce them!
MPlayer is in state of rapid changing and we have no time to read
and answer stupid questions. However if you mention that binaries
can't be disctributed and bugreports on them won't be accepted then
most of users at least got the point. Because if a user send a bug report
on a distributed binary and ask on the list and we reply that it's not
our busines he can think that we ignore him. But if we point that it's
written in the dox (that this kind of distribution is not supported by us)
he may not think this, only say: "ah, yes, ok". Maybe not :)

But this thread of us is useless: it's NOT my policy, it's the policy of
the development group!!! I only summarized the 'official' opinion in this
topic for you. Even if I wanted mplayer to become true GPL software at his
moment (I would like to do it! but not now ...) then I can't do anything,
because I'm not the only developer of MPlayer.
 
> 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.

But please ... it's not a correct assertion correcting :) mood that you
say "it's stupid". You should write technial facts, like I wrote you
the problem of slowdown in case of shared elf objects. This was the reason
I realized your letter as a personal flame. It's a personal flame when you simply
say "it's stupid". It's NOT a personal flame when you say: "it's not correct,
becuse [... some source code, URL, technical data, benchmarking etc follows]".

- Gabor

-- 
 --[ Gábor Lénárt ]---[ Vivendi Telecom Hungary ]---------[ lgb at lgb.hu ]--
 U have 8 bit comp or chip of them and it's unused or to be sold? Call me!
 -------[ +36 30 2270823 ]------> LGB <-----[ Linux/UNIX/8bit 4ever ]-----