Originally posted by starshipeleven
View Post
Announcement
Collapse
No announcement yet.
Debian To Seek A General Resolution Over Their Init System Policy
Collapse
X
-
Originally posted by andyprough View PostDebian Buster is beating Ubuntu and Fedora performance in benchmarks pretty easily these days. Have to wonder if there's some performance issue with how different systems approach the system-D problem.
Unless otherwise proved, I'm inclined to believe Ubuntu just takes most of it as-is from Debian.
Comment
-
Originally posted by andyprough View PostDebian Buster is beating Ubuntu and Fedora performance in benchmarks pretty easily these days. Have to wonder if there's some performance issue with how different systems approach the system-D problem.
- Likes 4
Comment
-
Originally posted by L_A_G View Post
Apparently you either missed or don't seem to understand the word "functionally" as I've used it every time I've described my issue with the way they have loads of unnecessary dependencies back and forth across the project. So while it technically isn't monolithic, the back and forth dependencies means that you have to use the whole bloated mess and as they're suffering from an ongoing case of feature creep the mess is only getting more and more bloated as time goes on. Also, as I've explained to you before those internal APIs are what's known as "unstable" APIs, i.e they're subject to constant change meaning that they're useless to any outside projects that may want to replace, fix, de-bloat or extend functionality.
In outer words; While it's not technically monolithic, the way it's implemented as a rat's nest of back and forth dependencies using unstable APIs it may just as well be because from the perspective of anyone on the outside, it's what's known as a "Distinction without a difference".
The "internal API" is also just a D-Bus interface and if you check the list at https://www.freedesktop.org/wiki/Sof...tabilityChart/ you can clearly see that "Covered by Interface Stability Promise" is "yes" on all except for "udev session switch ACL properties".
Originally posted by L_A_G View PostIt's about as separate an issue as a regular drunk driver driving on bad tires. Both are bad, but when combined they only make each other worse.
Comment
-
Originally posted by starshipeleven View PostThat's a load of bullshit. Init systems have no relevance for application performance.
Comment
-
Originally posted by andyprough View PostIt's not the init system itself. It's all the work-arounds that have to be in place to keep running despite the system-D problem. That's probably where the performance regressions lie.
- Likes 2
Comment
-
Originally posted by andyprough View PostIt's not the init system itself. It's all the work-arounds that have to be in place to keep running despite the system-D problem. That's probably where the performance regressions lie.
Otherwise, provide examples of such workarounds that may cause performance regressions.
I don't expect many differences in IO or network, since systemd mostly do setup for these (except resolved, but I believe none of those distributions use it by default), so it shouldn't interfere in operation.
I also tend to believe Ubuntu uses most of it as is, simply because the whole point of being a Debian derivative is to avoid pointless duplication of effort, which removing the workarounds would probably be, and even in this case, Debian is the most likely to work around things because Debian is the one that doesn't explicitly tie to one particular system, and I'd expect workarounds to slow down things, not to speed them up.
Point being, just asserting "it did better on benchmarks" without linking to them won't convince anybody.
- Likes 2
Comment
-
Originally posted by mrugiero View Post
Provide the said benchmarks and then we can have an informed opinion.
Otherwise, provide examples of such workarounds that may cause performance regressions.
I don't expect many differences in IO or network, since systemd mostly do setup for these (except resolved, but I believe none of those distributions use it by default), so it shouldn't interfere in operation.
I also tend to believe Ubuntu uses most of it as is, simply because the whole point of being a Debian derivative is to avoid pointless duplication of effort, which removing the workarounds would probably be, and even in this case, Debian is the most likely to work around things because Debian is the one that doesn't explicitly tie to one particular system, and I'd expect workarounds to slow down things, not to speed them up.
Point being, just asserting "it did better on benchmarks" without linking to them won't convince anybody.
That's a load of bullshit. Init systems have no relevance for application performance.
- Likes 3
Comment
-
Originally posted by mrugiero View Post
Provide the said benchmarks and then we can have an informed opinion.
Otherwise, provide examples of such workarounds that may cause performance regressions.
I don't expect many differences in IO or network, since systemd mostly do setup for these (except resolved, but I believe none of those distributions use it by default), so it shouldn't interfere in operation.
I also tend to believe Ubuntu uses most of it as is, simply because the whole point of being a Debian derivative is to avoid pointless duplication of effort, which removing the workarounds would probably be, and even in this case, Debian is the most likely to work around things because Debian is the one that doesn't explicitly tie to one particular system, and I'd expect workarounds to slow down things, not to speed them up.
Point being, just asserting "it did better on benchmarks" without linking to them won't convince anybody.
Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
There are more if you want to look around the site. Clearly the sloppy/messy scripts that are complained about so much on this thread have had no negative effect, and in fact are probably helping the system as a whole to run better than the vanilla system-D distros.
Comment
-
Originally posted by andyprough View PostI think nearly any 2019 benchmark comparisons on Phoronix that included Buster have shown a better performance than Ubuntu and certainly than Fedora. Here are a couple I spotted:
Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
https://www.phoronix.com/scan.php?pa...01-intel&num=7
So, let's start, test by test, what a way more relevant change may there be. Hint: it will most certainly be packages versions, I'll only look them up in the relevant (Buster wins by far) cases.
1. Selenium: Firefox.
Version on Buster[0]: 60.6.3
Version on Ubuntu 18.04[1]: 70.0
Version on Ubuntu 19.04[1]: 70.0
Version on Fedora 30[2]: 69
Sources:
[0]: https://packages.debian.org/search?keywords=firefox
[1]: https://packages.ubuntu.com/search?keywords=firefox
[2]: https://fedoramagazine.org/firefox-6...ble-in-fedora/
What should matter the most, here? The actual application that had quite a lot of room to change, or a script run at boot time?
2. Compile Bench:
I won't bother, since Buster loses hard.
3. SQLite is more or less on par, except from OpenSUSE sucking for some reason.
Same version for everytone, according to the graph's title.
4. ParaView. Same version for everyone, the only cases where Debian comes up first are quite marginally so.
5. DaCapo. Buster is on the middle, losing towards all of the ones you named.
6. Renaissance, ditto, except from two being second to Clear Linux, although by a big margin.
7. John The Ripper. Last.
8. SVT-AV1. middle of the table, not much difference with the worst ones. Fedora doesn't appear, Ubuntu 18.04 loses, 19.04 wins.
9. x265 v3.0. Second to Clear Linux by ~25%, with both Ubuntus head to head.
10. Stockfish 9. Debian just after the SUSEs, but there doesn't seem to be a big difference in any case.
11. LLVM Compilation. Debian is second to Ubuntu 19.04, so let's check versions again. This is unclear as to what compiler suite they use, so I guess I'll be checking GCC and Clang.
Buster: Clang=1.70 GCC=4.8.3.0
Ubuntu 18.04: Clang=6.0 GCC=7.4
Ubuntu 19.04: Clang=8.0 GCC=8.3
Fedora 30: Clang=8.0 GCC=9
12. XZ Compression v5.2.4. Buster does better than the aforementioned (SUSE and Clear win, tho). I'm unconvinced that init script have any effect on this, since it's quite standalone. It's most likely related to either libc or faster IO.
13. Hackbench. Buster is third to last. Fedora sucks hard for some reason. I have no idea what this bench is about, so I won't search.
14. libjpeg-turbo. Fedora, Ubuntu 19.04 and Buster are first, within standard deviation of each other. Makes sense since most of it is manually optimized SIMD, and is the same version.
15. Stress-NG. Buster is consistently at the middle of the table or below. I have no idea what it does, tho.
16. IndigoBench. Buster does better than the previous. It seems to be some sort of rendering? I fail to see any reason why init scripts would affect this.
From now on I'll just state results because I got severely bored.
17. Blender. Middle tier.
18. Appleseed. Middle and up.
19. PHPBench. Done quite good, although not as good as Clear.
The point of this long post is:
1. Correlation does not imply causality.
2. When lacking enough evidence, we should either avoid making any judgement at all, or at least go for the simpler ones first.
3. I still don't see a "beats Fedora and Ubuntu easily" from these results. It's not like it's consistently 10% faster or anything.
I recommend the following video on performance: https://www.youtube.com/watch?v=r-TLSBdHe1A
Originally posted by andyprough View PostThere are more if you want to look around the site. Clearly the sloppy/messy scripts that are complained about so much on this thread have had no negative effect, and in fact are probably helping the system as a whole to run better than the vanilla system-D distros.
- Likes 2
Comment
Comment