On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> On March 16, 2017 5:41:24 PM Emil Velikov <emil.l.veli...@gmail.com> > wrote: > >> On 17 March 2017 at 00:21, Dylan Baker <dy...@pnwbakers.com> wrote: >> >>> Hi Emil, >>> >>> Quoting Emil Velikov (2017-03-16 16:35:33) >>> >>>> While I can see you're impressed by Meson, I would kindly urge you to >>>> not use it here. As you look closely you can see that one could >>>> trivially improve the times, yet the biggest thing is that most of the >>>> code in libdrm must go ;-) >>>> >>> >>> Perhaps I wasn't clear enough, I don't really expect this to land ever. >>> I sent >>> it out more because I'd written it and it works and is a useful >>> demonstration of >>> meson+ninja performance. Obviously 20 seconds -> 5 seconds isn't a huge >>> deal :); >>> but in a larger project, consider that a 4x speedup would be 4 minutes >>> to 1 >>> minute, and that is a huge difference in time. >>> >>> You are still failing to see past your usecase. As said before - if >> there's any need to improve things say so. >> Note that you simply cannot apply the 1000x speedup in any situation. >> > > Yes, you can't just linearly apply any scaling factor. However, when you > build mesa on a machine with a decent number of threads (I think our build > machine for the CI system has 32 threads), autotools+make is slow as mud. > Also, there's very little you can do to speed up configure since it's a > pile of shell and perl that inherently runs single-threaded and is fairly > complex due to mesa's complicated dependencies. > > As the port is not 1:1 wrt the autoconf one, the performance numbers >>>> above are comparing apples to oranges. >>>> >>> >>> I fail to see what I'm missing from meson that would have an effect on >>> the >>> times I reported. There are some files that are installed by autoconf >>> that I >>> didn't bother to install with meson (because I don't expect this to >>> land). Since >>> I didn't time installs, I don't see how it isn't an apples to apples >>> comparison. >>> >>> You already (explicitly) mentioned some differences. Admittedly not a >> deal breaker. >> >> I understand that libdrm is a pessimal case for recursive-make since most >>> sub folders contain < 5 C files, However, even if you were to flatten >>> the make >>> files meson+ninja would still be faster when you consider that meson >>> configures and builds faster than autotools configures. >>> >>> That's correct. If is so concerned - they should slim down the >> configure.ac ;-) >> > > There are real limits as to what you can do there. > > If you/others are unhappy with the build times of libdrm - poke me on >>>> IRC. I will give you some easy tips on how to improve those. >>>> >>>> You have some good python knowledge - I would kindly urge you to >>>> improve/rewrite the slow and/or hacky python scripts we have in mesa. >>>> This is a topic that was mentioned multiple times, and a part where >>>> everyone will be glad to see some progress. >>>> >>>> Thanks >>>> Emil >>>> >>> >>> The real goal here is to do mesa (in case I didn't make that clear >>> either), and >>> the advantage for mesa is not just performance, it's that meson supports >>> visual >>> studio on windows; which means that we could hopefully not just get >>> faster >>> builds, but also replace both autotools and scons with a single build >>> system. >>> >>> Yes that was more than clear. Yet it won't fly, I'm afraid. >> >> The VMWare people like their SCons, >> > > How much? I would really rather the VMWare people speak on behalf of > VMWare. Meson is the single best shot we've ever had for replacing both > with one build system. I'm sure the VMware people would like to have a > build system that gets maintained by the community as a whole. > Sure, I'd like to see one build system instead of two. Meson supports Windows so that's good. But the big issue is our automated build system. Replacing SCons with Meson could be a big deal in that context. It would at least involve pulling Meson into our toolchain and rewriting a bunch of Python code to grok Meson. I'd have to go off and investigate that to even see if it's a possibility. Maybe next week. -Brian > > and Meson is not a thing on neither BSD(s), Solaris (and derivatives) nor >> Android :-\ >> > > I have trouble bringing myself to care. The BSDs need to stop using 10 > year old compilers. It can be made to work on Solaris and BSD if someone > bothered to put a little work into it. Besides, given that large chunks of > GNOME are switching they're going to have to make it work some day soon > anyway. > > Android is a bit unfortunate. Mesa is one of the few projects that let's > the Android people carry their build system in-tree and I would like to > keep that going if it were practical. Dylan and I have talked about this a > decent bit and one potential solution is to see if the meson people would > accept an Android back-end. Then we would be down to a single build system > (wouldn't that be nice). > > If there's something "slow" say what/where and we can improve upon >> things. You seems to be rewriting $world because someone sold you that >> A is the holy grail. >> > > I don't think that's fair. No, Meson is not the holy grail but it is the > closest anyone has yet been able to come to a viable autotools replacement. > > Speed is only one aspect to this. Unifying the Linux and windows builds > is also a significant advantage. Also, autotools is objectively terrible > and having a build system that's modifiable be mere humans without the need > for hours of pouring over documentation only to find that you did it wrong > anyway is a definite plus. > > > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
