I've just checked out a performance test on phoronix comparing windows 8, ubuntu, xfce and kwin. Turns out that kwin is the slowest one , by far.
http://www.phoronix.com/scan.php?page=article&item=intel_windows8_kdexfce&num=1

http://blog.martin-graesslin.com/blog/2 ... rformance/

http://blog.martin-graesslin.com/blog/2 ... enchmarks/

http://blog.martin-graesslin.com/blog/2 ... mpositors/

and I was very close to write another blog post today.

ngativ wrote:I've just checked out a performance test on phoronix comparing windows 8, ubuntu, xfce and kwin. Turns out that kwin is the slowest one , by far.

if you're going to reference an article it would be appropriate to provide a link to it

google01103 wrote:

ngativ wrote:I've just checked out a performance test on phoronix comparing windows 8, ubuntu, xfce and kwin. Turns out that kwin is the slowest one , by far.

if you're going to reference an article it would be appropriate to provide a link to it

please don't. we don't want to encourage linking to Phoronix. It's bad enough that he does incorrect benchmarks to get money. Let's not support it further. I have seen the benchmark already yesterday and as written it almost motivated me to write a blog post about it (and I would not have linked it).

google01103 wrote:

ngativ wrote:I've just checked out a performance test on phoronix comparing windows 8, ubuntu, xfce and kwin. Turns out that kwin is the slowest one , by far.

if you're going to reference an article it would be appropriate to provide a link to it

Thanks, i don't know how i missed that!!!!

mgraesslin wrote:http://blog.martin-graesslin.com/blog/2012/02/about-compositors-and-game-rendering-performance/

http://blog.martin-graesslin.com/blog/2012/09/why-i-dont-like-game-rendering-performance-benchmarks/

http://blog.martin-graesslin.com/blog/2012/09/the-relevance-of-game-rendering-performance-benchmarks-to-compositors/

and I was very close to write another blog post today.

OK!, then no gaming for KDE i guess (or openGL software for that matter).

Since you apparently didn't read Martins links:

Moronix benchmarks and an empty bag are about as much worth as the bag.

Do you understand the "benchmark"?
No? (No, you don't, hence your topic title.)

Nevermind - neither does Michael!

Have a look at the dramatic overall drop on OpenArena 0.8.8 ./. 0.8.5 - Explained? No, of course not.
Wondered about the relatively en par performance on nexuiz? Or esp. why "Ubuntu 13.04" does significantly worse here than in the openarena "benchmarks"?
Why are KDE & XFCE ahead on the XGA openarena "benchmark" but KDE significantly drops on WXGA?

And seriously: in OpenArena 0.8.8 (which got optionally many FX he apparently activated w/o mentioning what) Win8 is 0.8 of KDE on XGA but 1.3 on WXGA? (reverting the conditions!)

WTF? Because of the additional 256k size?
Could that slightly imply he might be running into something "texture" size related limiting?
Could the reason be the amount of cached windows - open windows altogether?
Or is it just a random result depending on some random state of the overall system?

Explanation? Details? Theory? Knowledge? Hypothesis? Countertest? Control? Reproducibility? CONTROL?
Please don't bother me with facts!

Michael L. pushes "stuff" into his "benchmark" and the gets "numbers" which describe "things" and publishes them uncommented and unreflected - w/o any details, theory or even explanation.
He has no deeper insight in his "testsuite", its HW demands, limitation, invocation - nor in the system he tests ... on what hypothesis excatly?

Now here's a guess on the "benchmark" (but that holds pretty much everytime he does anything)
------------------
The GPU is rather weak (it's an Intel HD IGP); Nexuiz is rather GPU restricted (at least if you count that IGP as GPU) and OpenArena 0.8.5 is clearly CPU restricted (in the basic setup it's Q3 from 1999, for gods sake)

-> Something else operated on his notebook while he ran that benchmark, sucking CPU (nepomuk indexing or god knows what plasmoid ran wild, maybe his torrent porn found a good seed - "controlled environment"? please! it's not science, is it?) and controlling the results.

This g** d*** f****** i**** gets different results with each of his so called wannabe benchmarks and NEVER BOTHERED TO WONDER WHY - not even the "tested" system did not encounter any significant change (what he does not know because he doesn't care anyway)

He then prints the so called results and actually every month finds a new noob who doesn't know moronix yet, shows up and presenting the "facts" they do understand or question as little as their leader. Today it's apparently you. Don't worry. Next year you might be in my position.


You care about maximum performance?

Suspend compositing (press shift+alt+f2 or setup a rule for the game. not just for fullscreen windows ... what gets void when Michael gets a tooltip..) to free all GPU resources (like ... GPU memory...!) and check that there's no background activity (CPU, I/O)

Best: run a naked X11 server and SIGSTOP cron since the moment your box starts a scheduled background job (ideally i/o intense like updating the mandb or performing a logrotate) your performance will drop! The more CPU and I/O depending your game is, the worse the impact.

And just FTR:
I said pretty much the same when Moronnix came up with "compiz is worse than kwin", "mutter is worse than compiz", "kwin is worse than mutter" - because it's epic **** everytime - and nothing more.

/rant, sorry everyone.

The end result is that KWIN is slower than the others. , and by far. You don't like it, you don't want to accept it, that's your problem. IT seems to be a problem when the maintainer itself does't care about performance .

"Suspend compositing (press shift+alt+f2 or setup a rule for the game. not just for fullscreen windows ... what gets void when Michael gets a tooltip..) "

WELL!, if that setting doesn't works as it should , then is a fail. I was expecting that "suspend for fullscreen windows " setting should work for any fullscreen application, thanks for the tip, i didn't know it was broken.

ngativ wrote:The end result is that KWIN is slower than the others. , and by far. You don't like it, you don't want to accept it, that's your problem. IT seems to be a problem when the maintainer itself does't care about performance .

Ah yes, Michael's rules of accepting benchmarks. We are now in the what's it called "DENIAL" stage. Well check my blog posts, they were written when we "won" the benchmark. Decided to question the results when we win, because nobody could say that we deny the results.

It's btw. pretty smart by Michael to come up with the rules, because it allows him to publish anything without getting questioned. Whenever one questions the results he is just denying the results. That's extremely smart - the smartest thing I have ever read from him.

Well I just cannot accept the results, because I worked in one of Germany's largest research facility over the last two years. I learned a lot about how you produce results which are correct and can be verified. If Michael can setup a benchmark which holds up to very simple rules of science (let's say a grade d journal would accept the data), I would start to somehow consider them as maybe some truth. But as long as he only tests on one system and only on Ubuntu, I don't care about the results, because they don't show that KWin is slow, but that in that one specific test KWin was slow (whether that's actually the case or some external limitation as Thomas pointed out we don't know).

I also have read benchmars on Phoronix about other stuff in the past. It looked quite random, weird things were happening without any explanation (or even consideration!) of what might cause such behaviour, or even what exactly was tested and how. Being interested in science myself, I can say that it clearly didn't look like what you'd expect from a scientific experiment (repeatability, statistics!). The only thing which was done with much effort was fancy plots. I think Martin summarized this well in his blog posts.

Trust the KWin devs, they're the more competent people by far here. If you don't, then I suggest you do your own benchmarks, and document them properly, and then the results can be discussed here.

Greetings,
Sven

Part of my job involves statistics and crunching data. There's no way I could trust Phoronix's benchmarks: it's not enough to show that X is slower than Y, you have to show that it's not due by chance. There are statistical tests for this, which would work, but of course I haven't seen these applied by Larabel.

The end result is that KWIN is slower than the others. , and by far. You don't like it, you don't want to accept it, that's your problem. IT seems to be a problem when the maintainer itself does't care about performance .

You either seriously didn't read what i said or you're a troll.
Those "benchmarks" say two things:

1. Michael L. got a number which reflected the conditions during his singleton test.
2. Darwin is still right, but the idea that evolution would lead to improvement is a misunderstanding.

If you do a "benchmark" you start with a defined question ("What do i want to test") then you check "How to test this" and then you have to carefully get rid of any variable not related to that question. The you test. Again and again. And you record this. And in the end you get a lot of data which either stresses or denies your original thesis. Then you conclude.
The ratio would be around 95% data, 4% analysis and 1% illustrating bars.
Not 98% bars and 2% merely unrelated comments.

Michaels implicit question is "What funky number will i get during the next five minutes" and precisely that question he gets answered - and nothing more. Not the least.
Where would you know to assign the result to sth. specific like the WM at all when there're even different desktop environments included? Not to mention the undefined and unrecorded rest of the system.
If the window is unredirected (and that it will be, if Michael didn't get a tooltip...) the WM is completely out of the game on screen updating, so what would make it cause differences?

Seriously, by pointing Moronix "benchmarks" you'll only embarrass yourself - nothing more is to gain there.

That's not about "like the results or not" but about "the results are worth nothing" and "Michael L is a shame for serious benchmarking, let alone professional research or science. Or nature."

WELL!, if that setting doesn't works as it should , then is a fail. I was expecting that "suspend for fullscreen windows " setting should work for any fullscreen application, thanks for the tip, i didn't know it was broken.

There is nothing broken, it does work for any fullscreen WINDOW (as it states) and to be more precise only if that window is on the fullscreen LAYER (ie. at the very top of the screen, otherwise the unredirection would lead to a visually uncomposited desktop) and worst of all: it tends to make the intel driver crash.

Just even if it would work and guessing out of Phoronix' loose data:
it does not free the system from the present GL context, thus from the need to switch contexts on concurrent access or swap memory on lack.

That's not even suggested. A script that suggests exactly this is available here:
http://kde-look.org/content/show.php/Ga ... ent=156659

And now stop trolling.

As this thread neither holds a problem nor a solution but a rather (heated) discussion, moving it to the correct place. And while i am at it i remind everyone of the CoC