On 17 March 2017 at 00:21, Dylan Baker <dylan@xxxxxxxxxxxxx> 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. >> >> 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 ;-) >> 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, and Meson is not a thing on neither BSD(s), Solaris (and derivatives) nor Android :-\ 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'll repeat my earlier request - your python skills/knowledge will be greatly appreciated in existing parts of Mesa. Speaking of which - you last work doesn't seem to have landed. What's blocking it ? Thanks Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
