++People from both the Arch and non-Arch camps are just making themselves look like asshats,
--so please quit it.
Please don't.
Arch rocks your socks.
Wow, stop trying to make yourself sound dumb. First Linux wasn't invented until 1991. Second, you spelled engineer wrong. Third, a high school district's IT person wouldn't know real big iron unless it bit him in the ass. Your the troll.
People from both the Arch and non-Arch camps are just making themselves look like asshats, so please quit it.
++People from both the Arch and non-Arch camps are just making themselves look like asshats,
--so please quit it.
Please don't.
Arch rocks your socks.
Your babbling is unbearable. Cant you read between lines? Are you colour blind or what? I OBVIOUSLY meant Ive been using UNIX since more than 20 years. Can u say the same? How many farms have you build? Oh, thats right, NONE. You are just sitting in your basement playing WoW pretending to be a seasoned system administration. That explain why you cant tackle my arguments and just attack me ad hominus. If you knew anything you would be able to tell whats going on with your beloved arch. In x264 encoding ALL the distros BUT arch scored scored 9.06-9.46 FPS, and arch had 6.06. Whatever braindead thing arch devs did its obviously causing L1 cache misses. But dont take the word of a high school IT guy, take it from the main x264 dev:
Got that? Let me explain it for you: 1231/790=1.558, and 1.558*6.06=9.441. THATS RIGHT, if arch didnt have cache misses it would perform exactly the same as the other distros! Honestly I dont care how crap arch can be, but my guess is the scheduler or the reactance, I can care less. YMMV.Here’s some numbers which express how powerful this effect is. [...] x264 rounds the predictors for the motion search to fullpel to avoid interpolation during predictor checks. However, halfpel pixels are cached, so it shouldn’t require significantly more work to round to halfpel instead of fullpel. But doing so increases the cycle count of predictor checking from 790 to 1231! This almost entirely comes from extra L1 cache misses, since the halfpel data is 4 times as large as the fullpel data and is stored in 4 separate planes.
This fanboy flamewar is so idotic...
What is more important is to understand why this issue occurs (in particular the x264 test) because it could happen to ANY linux distro! Is it a configuration issue, or as I pointed out earlier a scheduler (and maybe yotambien has the correct esxplanation, although this is just an hypothesis). It is possible this is linked to some gcc regression too.
It would be a lot more intelligent to find out what's happening instead of insulting each other, as if distributions were using different kernels.
I think arch gets the best and worse of the Linux community. Its a shame as i think that the knowledge base in arch is great. But surely you have to agree that most arguments seem to arise with arch missionaries.
I for one like Ubuntu, i agree with canonicals approach, not all the time, but enough to support them.
Benchmarks like this would be better served with forums discussions than dick measuring.
[notsoseriouspart]
This one was just too good to not reply to.
First of, as you said: "BIG IRON, kid" You work at the largest highschool in the state, but still spell even worse than me. (and I'm famous for my horrible spelling)
Secondly, you claim to be using Linux since 4 years before Linus announced it to the world. Please explain how you managed to do that. Is the history wrong? Was it you that wrote Linux, and Linus just stole your work and put his name on it? Please enlighten me.
[abitmoreseriouspart]
Here is just my personal experience with arch, in relation to the benchmark:
When it comes to x264, it's been just as fast as in any other distro. (faster at times) But then again I've only used it on a 64bit install, witch unlike the "stock" i686 packages, have been compiled wtih sse2 and friends enabled. One of
The ati M6 (really a radeon 7000 card) being horrible slow at times, but not really because I'm running arch, but because of the large changes that the ati/mesa stack have been going trough. Some time ago a lot of people had the same problem with intel cards. Can't really blame the distro for what upstream decides to do, specially since many of the other distroes was also hit by it to some degree, depending on what versions they went for.
Sometimes the rolling release policy works to your advantage, sometimes it doesn't. Arch won't usually hold back on a upstream release unless there is something seriously wrong with it, that will break the system for a large group of users. And halved speed in openGL apps does not count as "breaking the system".
It all more or less boils down to a totally different desing goal. I have no problem with accepting that arch at times will be slower at some things than <insert distro here>. I have no problem with accepting that sometimes some <insert app here> will be more or less unusable either. It's just a side effect that you have to accept as the cost of running the "latest greatest" "vanilla" apps from upstream.
I don't have any issues with the result of the benchmark, but people reading it should be aware that it only shows a tiny part of the whole story, and that it really is comparing apples to hammers.
And to all the fanboyz and haterz, calm down, you are only making yourself look stupid.
[notsoseriouspart]
This one was just too good to not reply to.
First of, as you said: "BIG IRON, kid" You work at the largest highschool in the state, but still spell even worse than me. (and I'm famous for my horrible spelling)
Secondly, you claim to be using Linux since 4 years before Linus announced it to the world. Please explain how you managed to do that. Is the history wrong? Was it you that wrote Linux, and Linus just stole your work and put his name on it? Please enlighten me.
[abitmoreseriouspart]
Here is just my personal experience with arch, in relation to the benchmark:
When it comes to x264, it's been just as fast as in any other distro. (faster at times) But then again I've only used it on a 64bit install, witch unlike the "stock" i686 packages, have been compiled wtih sse2 and friends enabled. One of
The ati M6 (really a radeon 7000 card) being horrible slow at times, but not really because I'm running arch, but because of the large changes that the ati/mesa stack have been going trough. Some time ago a lot of people had the same problem with intel cards. Can't really blame the distro for what upstream decides to do, specially since many of the other distroes was also hit by it to some degree, depending on what versions they went for.
Sometimes the rolling release policy works to your advantage, sometimes it doesn't. Arch won't usually hold back on a upstream release unless there is something seriously wrong with it, that will break the system for a large group of users. And halved speed in openGL apps does not count as "breaking the system".
It all more or less boils down to a totally different desing goal. I have no problem with accepting that arch at times will be slower at some things than <insert distro here>. I have no problem with accepting that sometimes some <insert app here> will be more or less unusable either. It's just a side effect that you have to accept as the cost of running the "latest greatest" "vanilla" apps from upstream.
I don't have any issues with the result of the benchmark, but people reading it should be aware that it only shows a tiny part of the whole story, and that it really is comparing apples to hammers.
And to all the fanboyz and haterz, calm down, you are only making yourself look stupid.