On 17/03/17 02:28, Brian Paul wrote:
On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand <jason@xxxxxxxxxxxxxx
<mailto:jason@xxxxxxxxxxxxxx>> wrote:
On March 16, 2017 5:41:24 PM Emil Velikov <emil.l.velikov@xxxxxxxxx
<mailto:emil.l.velikov@xxxxxxxxx>> wrote:
On 17 March 2017 at 00:21, Dylan Baker <dylan@xxxxxxxxxxxxx
<mailto: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 <http://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.
I don't have any experience with Meson. But for the record I don't have
much love for SCons. I long stopped using SCons for anything but Mesa.
And my have good experience with cmake + ninja/msvc is positive. So
tools with similar architecture sound good overall.
In fact, knowing what I know now, if I could go back in time, to when I
evaluated CMake and SCons, I'd chose CMake.
BTW, it seems that newer SCons will drop Python 2 support [1], which
might force us to rewrite a lot of SConsfiles/scripts any way. So
perhaps that's a good time to evaluate migrating to something else.
That said, moving to another build system is always a herculian task.
Thought the benefit of having a single build system is appealing and
might save time down the line.
But there are many questions I have about Meson: how confident are we
on Meson? Are big projects using it? How sure are we that it won't
become abandonware in a few years time? How does it compare with other
newer gen build systems?
We also have special requirements: one is cross-build from Linux to
MinGW, which on Mesa case requires building portions of the tree twice
-- once for host -- another for cross-mingw.
Jose
[1] http://scons.org/scons-251-is-available.html
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
