Why all these optimizations? (mplayer)

iBertus · 2005-07-25 01:24:53

This is almost funny now!

T-Dawg · 2005-07-25 01:39:31

iphitus wrote:

Mods? Lock? Anyone?

heh. I though about moving it to off-topic since its becoming a joke. I'd rather not lock this unless it really gets personal.
Oh well. He's probably jumped to another distro by now anyways.

iBertus · 2005-07-25 05:06:33

Off-topic sounds like a good place for this thread. Anyway, I'm giving up.

Snowman · 2005-07-25 05:32:53

Maybe putting it in dust-bin? IMHO, this thread isn't really off-topic: it's the same arguments repeated over and over.

iBertus wrote:

Anyway, I'm giving up.

Really? I gave up a long time ago. I must say that iBertus and iphitus impressed me with their patience.

phrakture · 2005-07-25 16:24:30

jko: you have a right to you opinion and continued investigation, but let's please keep it civil...

The fact of the matter is as follows (I may be reiterating others responses, but I didn't feel like reading the entire thing due to snide remarks made by some of the players):

mplayer takes advantage of SIMD instructions to do video processing. SIMD instructions come in various flavors - MMX, SSE, SSE2, etc. When mplayer is compiled, the configure script detects which flavors your processor supports. Now, Arch is made to support all i686 processors. Not all i686 processors support SSE, SSE2, and other streaming instruction flavors. Therefore, if I compile mplayer with SSE enabled, it will not work on, say, a Pentium 2.
In order to get around this, runtime cpu detection is enabled. What runtime CPU detection does, is that it performs this check for the SIMD flavors when it is initialized. This check takes negligable time to execute, and only causes a delay on initialization. The video/audio stream will then run as if it were compiled with support for what your processor supports.

Dusty · 2005-07-25 16:31:42

Sorry, I wasn't reading this thread. One more uncivil comment and it will be locked. (Advisors, take note)

phrakture · 2005-07-25 16:38:23

http://bbs.archlinux.org/viewtopic.php?p=45880#45880

jko · 2005-07-28 22:37:00

phrakture wrote:

In order to get around this, runtime cpu detection is enabled.

*sigh*. Again: Apparently some processors are unable to deal with this
feature-request. The mere "detection" is causing the processor to crash.

The author's warning

"Compiled with runtime CPU detection - WARNING - this is not optimal!"

gives a "subtle" hint on this issue. Maybe I've misread it, though.

phrakture wrote:

What runtime CPU detection does,

Am I giving you the impression that I don't know what this feature is supposed
to do? OK, once again: Yes, I do understand that the runtime detection is
supposed to enable special features at runtime which are supposed to improve the
performance of the program (mplayer). Nevertheless, some processors (like mine)
don't seem to support this feature (runtime detection) itself. Result: it
crashes the system.

I'm not surprised, though, as I've read the author's warning:

"Compiled with runtime CPU detection - WARNING - this is not optimal!"

Therefore, for the 123rd time: I don't understand why a generic i686 distro
should support runtime detection (with mplayer) by default, although common i686
tend to crash on it. Especially when considering the author's note:

"Compiled with runtime CPU detection - WARNING - this is not optimal!"

iBertus · 2005-07-28 22:44:59

/me: comes back form ignoring this thread.

You answered your own question here - we use runtime detection because Arch is a generic i686 distro.

paranoos · 2005-07-28 22:55:53

jko wrote:

Therefore, for the 123rd time: I don't understand why a generic i686 distro should support runtime detection (with mplayer) by default, although common i686 tend to crash on it.

ok, now i see why this argument has gone on for so long. common i686 do NOT tend to crash with runtime cpu detection. it's actually a very simple procedure. if you want to know what extensions your cpu supports, simply look at /proc/cpuinfo.

now, the author says this is not optimal because runtime detection takes a little bit of time to do when mplayer is starting, and you can get around that by compiling mplayer for your specific cpu. however, like we've said many times, arch is a generic i686 distro, so we want a single compile to run on all i686 hardware, and yet give optimizations for those cpus that do support them, to improve performance. like i said, runtime cpu detection does NOT crash on common i686, so please stop arguing if you want to make that claim, then please prove it.

phrakture · 2005-07-28 23:04:14

jko wrote:

I'm not surprised, though, as I've read the author's warning:
"Compiled with runtime CPU detection - WARNING - this is not optimal!"

That has nothing to do with crashing... if the author was telling you that it could crash the warning would look more like "WARNING - this could crash!", but it doesn't - it says "not optimal". That is because compiling the app with pre-detected CPU parameters is faster (more optimal) than detecting it at runtime.

jko wrote:

Therefore, for the 123rd time: I don't understand why a generic i686 distro
should support runtime detection (with mplayer) by default, although common i686
tend to crash on it.

That's absolutely, 100%, verifiably wrong. If "common i686 tend to crash on it", then why has no one reported an issue like this before... you'd think if it was really the common case *someone* would have noticed it.

Therefore it's not the common case - your machine is the exception, not the rule. Runtime CPU detection works beautifully on all 6 Arch machines I have at home, and I'd assume most of the people here have never had an issue.

What processor are you even on?

jko · 2005-07-29 00:11:10

paranoos wrote:

common i686 do NOT tend to crash with runtime cpu detection.

1. mine does
2. I never claimed that the rt cpu detection is actually the cause for the crash on my system.
I just made a (qualified) guess based on the output of "mplayer --version"
The cause for the crash may be something entirely differnt. I never doubted that.
I've just stated that a standard compile from source does not lead to this kind of error (and that the author discourages from rt cpu detection. For whatever reason. No need to elaborate on this).

What you've obviously failed to discuss is whether my standard compilation from source qualifies as a i686 optimized compilation. The rt cpu detection is certainly no valid criteria for a generic Arch i686 package. As you (or someone else) have previously admitted: Some i686 may not me able to deal with it.

BTW: has the maintainer voiced himself in the meantime?
BTW2: Is there a bug-tracking system for Arch at all?

paranoos wrote:

if you want to know what extensions your cpu supports, simply look at /proc/cpuinfo.

Done. Look at the first page.

paranoos wrote:

like i said, runtime cpu detection does NOT crash on common i686, so please stop arguing if you want to make that claim, then please prove it.

Won't stop arguing. I'll make you redifne your notion of "stubborn" ;-)
Seriously: like I said before: I don't claim that rt cpu detection is the cause for the crash. *Never* claimed that. I just made a guess and then all you Dodos felt the urge to explain to me what rt cpu detection actually is all about and that I should be lucky to have gotten it (mplayer) running at all by compiling from source and that I'm just about to be *banned* *locked* *tortured* and *dissed*.

Why? All because I dared to ask why a package seems to suck big time.

iBertus · 2005-07-29 00:22:10

There is obviously a lack of understanding here! Without runtime cpu detection mplayer will only run on the type of CPU that was present in the compiling machine. That doesn't do the greater community much good. If the maintainer has an AMD and you have an Intel, then you are screwed in that instance.

There isn't any point in continuing this thread. Doing so could only result in more insults and argument.

jko · 2005-07-29 00:26:27

phrakture wrote:

That has nothing to do with crashing... if the author was telling you that it could crash the warning would look more like "WARNING - this could crash!", but it doesn't - it says "not optimal". That is because compiling the app with pre-detected CPU parameters is faster (more optimal) than detecting it at runtime.

Stop nitpicking. The author is free to put it the way he likes. There is no standard for warning/error messages. He might say:

"If you do this, I'll meet you in the afterlife!"

or

"I wouldn't be too happy with you doing this"

or ... That's ridiculous.

phrakture wrote:

jko wrote:
Therefore, for the 123rd time: I don't understand why a generic i686 distro
should support runtime detection (with mplayer) by default, although common i686
tend to crash on it.
That's absolutely, 100%, verifiably wrong. If "common i686 tend to crash on it", then why has no one reported an issue like this before... you'd think if it was really the common case *someone* would have noticed it.

jko · 2005-07-29 00:30:55

iBertus wrote:

There is obviously a lack of understanding here! Without runtime cpu detection mplayer will only run on the type of CPU that was present in the compiling machine. That doesn't do the greater community much good. If the maintainer has an AMD and you have an Intel, then you are screwed in that instance.

"You seem to have set aside a special time to humilate yourself in public."

iBertus, I don't meen to be rude, but: you're clueless.

iBertus wrote:

TThere isn't any point in continuing this thread. Doing so could only result in more insults and argument.

Yeah, right.

T-Dawg · 2005-07-29 00:45:43

Enough of the insults. Locking.

Arch Linux

#26 2005-07-25 01:24:53

Re: Why all these optimizations? (mplayer)

#27 2005-07-25 01:39:31

Re: Why all these optimizations? (mplayer)

#28 2005-07-25 05:06:33

Re: Why all these optimizations? (mplayer)

#29 2005-07-25 05:32:53

Re: Why all these optimizations? (mplayer)

#30 2005-07-25 16:24:30

Re: Why all these optimizations? (mplayer)

#31 2005-07-25 16:31:42

Re: Why all these optimizations? (mplayer)

#32 2005-07-25 16:38:23

Re: Why all these optimizations? (mplayer)

#33 2005-07-28 22:37:00

Re: Why all these optimizations? (mplayer)

#34 2005-07-28 22:44:59

Re: Why all these optimizations? (mplayer)

#35 2005-07-28 22:55:53

Re: Why all these optimizations? (mplayer)

#36 2005-07-28 23:04:14

Re: Why all these optimizations? (mplayer)

#37 2005-07-29 00:11:10

Re: Why all these optimizations? (mplayer)

#38 2005-07-29 00:22:10

Re: Why all these optimizations? (mplayer)

#39 2005-07-29 00:26:27

Re: Why all these optimizations? (mplayer)

#40 2005-07-29 00:30:55

Re: Why all these optimizations? (mplayer)

#41 2005-07-29 00:45:43

Re: Why all these optimizations? (mplayer)

Board footer