On March 16, 2017 5:41:24 PM Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote:
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.
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.
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.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
