[MPlayer-users] MPlayer-1.0pre4 bug with divx4 multipass filter

[D Richard Felker III]

On Wed, Sep 15, 2004 at 09:50:02AM +0400, Vladimir Mosgalin wrote:
> On Mon, 13 Sep 2004, D Richard Felker III wrote:
> 
> DRFI>- omission of asm instructions from inline asm
> DRFI>- ICEs
> DRFI>- other code generation errors with pure C code.
> DRFI>if you don't believe me, do the research or install an old redhat and  
> DRFI>try it. i'm not going to spend my time looking up the exact version
> DRFI>where it was fixed.
> 
> I do believe you. But I was talking about completely difference issue.
> There were enough smart people who knew about this problems even before
> mplayer's troubles with 2. 96; just because they knew that x.0 redhat
> versions are always overflowing with all kinds of problems. They made
> clever decisions, told people to do the same and had very little
> problems both with compiler and such. I guess that by the time redhat
> started to use 2. 96 to compile kernel instead of kgcc (old egcs port),
> it happened in 7.2 or 7.3, I guess, gcc 2. 96 was stable enough.

i seriously doubt it. just no one complained because it happened to
compile the kernel (mostly?) ok.

> DRFI>> The only reason we all have usable, fast and compatible gcc 3.x right
> DRFI>
> DRFI>rotfl?!?! gcc3 is "fast", "compatible", and "usable"!?!? i don't even
> DRFI>think this deserves a response, but i'll give it one:
> DRFI>- gcc3 runs 50% slower or worse than gcc 2.95 
> 
> Slower, yes. Worse, no. It supports much more features.

"features" like c++ variable declarations... :(

> DRFI>- gcc3 generates at best marginally faster code than 2.95, and at  
> DRFI>  worst MUCH SLOWER code than 2.95 (10% slower on my k6).
> 
> I can't confirm this. On my p166mmx, gcc 3.1 was faster than 2. 96,   
> which was faster than 2.95. On my current system.. well, I can't really
> test, I have only 3.3 & 3.2 versions installed, but gcc 2.95 wasn't even
> supporting sse optimizations..

sse optimizations for what? they're basically useless. all they affect
is the use of floats in c code, which no one sane would use in
performance code anyway...

> And it sure never heard of athlon cpus.

and it doesn't matter...

> DRFI>- half the gcc3 releases are full of compiler bugs (ICE & spilled
> DRFI>  register crap).
> 
> gcc3 has bugs, but for some reasons I don't remember that I ever
> suffered from them. Even 3.2, which was considered buggy by mplayer
> developers, never had the any problems on my system - because the bugs
> were fixed in my distro.

i really doubt that..

> That's what they exist for, to fix numerous
> bugs in vanilla gcc/kernel/etc...

this is absurd... i understand that this is what it's come to, but
distros "fixing" all the kernel bugs and gcc bugs is the reason that
horrible buggy releases are made. the developers rely on distro
maintainers to fix all their broken crap, and in the process screw
everyone who doesn't want to deal with the bloat and limitations of a
distro.

basically _every_ release of linux is unstable nowadays. they assume
distros will fix the broken stuff when integrating it. they neglect
releasing a new version after serious vulnerabilities for weeks or
months because they assume the distros will fix it. this is completely
unacceptable and running linux's reputation into the ground...

> DRFI>no, we'd be the same as 2.95 was at the time, i.e. much faster and
> DRFI>much more compatible.
> 
> First time I recompiled mplayer with new compiler, it became faster. I
> wasn't expecting this, but it really became 5-10% faster.

perhaps we should profile which functions were improved and rewrite
them in asm, if there's really any c code that can make a 5-10%
difference to performance... ideally less than 1% of the cpu time
should be spent in the c code.

> DRFI>> I used to think that lavc is better too, before I tried xvid for
> DRFI>> real and it cured all my problems. But if you want to take on
> DRFI>> that bet, you must force yourself to download xvid 1.0.2 and
> DRFI>> recompile mplayer.  Actually, it's even easier than to compile
> DRFI>> mplayer with lavc (not to mention faster).
> DRFI>and it decodes 50% slower...how useless.
> 
> Useless for capture, but who cares if it gives 20% better quality for
> dvd rips?

i said decodes. not talking about encoding. i agree performance is
irrelevant for encoding.

> DRFI>(this stat comes from one of the xvid developers, i didn't just
> DRFI>make it up!)
> 
> Actually, I can't agree with you. With a lot of quality-improving

again you just misread what i said.

rich