Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Faster Than Ninja

build2.org

Post reply on HN
Print view View original

11–20 of 41 posts

Re: Faster Than Ninja

#11

Post by zamalek »

> Let's see if we can go even faster. Next, we disable compression in the file cache. We will discuss the file cache in more detail a bit later but for now let's just say that by disabling compression we trade temporary disk space usage for speed:

Something is wrong here. Which compression algorithm is being used here and how much has it been tuned? A core hypothesis of the likes of zram is that disk access is so slow (even NVME), that you can often beat it with the bit-rate of decompression.

1. Is something slow like gzip being used?

2. Is the compression effort over-tuned for size? Do some space benchmarks and make sure that you aren't saving a few dozen MB on GBs of data.

zstd, with 1-3 effort (you may even find negative is a overall win), and a trained dictionary (your data does all look identical) is probably a good start.

Re: Faster Than Ninja

#12

Post by evmar »

Orphis wrote: post #7
evmar wrote: post #4

[Ninja author here] Nice post, cool to see the deep dive! I also appreciate the details on how they produced their numbers. As they observe, Ninja gets to be fast mostly by cheating: it avoids a lot of work by saying many things are just out of scope for Ninja to do, and that means it is a useful a target to race against. (Funny thing: when I wrote Ninja I was misremembering how fast an earlier build system was so I…

Simple CMake projects using the Ninja generator are very efficient, unless you create generated files. And if they are in their own targets, they are not really an issue (they would serialize everything that depends on them as you'd expect), but if you have them in a library grouped with other files to compile, then the whole library compilation is serialized. And obviously worse if you also have to build the generat…

Yes, I don’t remember the details but vaguely remember that CMake tends to group things together that could in principle be made more parallel, as you mention with generates files in a library. On the other hand if build2 makes it easier for authors to express these kinds of patterns without the serialization then I count that as a win for build2!

Re: Faster Than Ninja

#13

Post by quotemstr »

shevy-java wrote: post #9

Great that there are performance benefits, but one thing that I think both meson/ninja and cmake (or cmake/ninja) got wrong, and GNU configure got right is "./configure --help". Why do neither of these tools simply add --help here? Yes, their syntax is different, but the issue is not only about --help. Often I could disable documentation or man page via --disable-man or --disable-doc or something like that. I recentl…

I wish that when people posted a performance win, they would include a theory explaining it. Unexpected speedups are usually noise, bugs, or harness issues. No program is faster due to the superior manly virtue of its programmer. Every effect has a cause.

When, from first principles, something shouldn't be faster, yet it is, you dig and dig until you understand. You don't just say your shit rules and the other thing sux0rz. If you do, you'll regret it: if you don't understand how you got a win, you don't understand how to keep it.

Re: Faster Than Ninja

#14

Post by bluGill »

Cmake spend 15 seconds to generate this project? I find it unlikely build2 is doing the same work as cmake is. Now I will grant cmake is single threaded and slow, so there is a lot of room to do the things it does better (the language sucks, and is part of what forces single threaded). It also wouldn't surprise me if cmake is doing things that are not really needed (odds are the default compiler works - most of the time it isn't valuable to check the version)

Re: Faster Than Ninja

#16

Post by boris »

evmar wrote: post #4

[Ninja author here] Nice post, cool to see the deep dive! I also appreciate the details on how they produced their numbers. As they observe, Ninja gets to be fast mostly by cheating: it avoids a lot of work by saying many things are just out of scope for Ninja to do, and that means it is a useful a target to race against. (Funny thing: when I wrote Ninja I was misremembering how fast an earlier build system was so I…

[build2 author here] Thanks for the feedback! Some additional details:

> The first one is a criticism of CMake, not Ninja (?), so I don't think it can be why.

Fair enough. The point I was making is that if you want to compete with Ninja, you cannot leave any potential performance gains on the table.

> The second reason given is doing some work like header dependencies in multiple threads. This is the most plausible reason to me but it still feels unlikely.

We are talking about ~2% performance difference here. Parallelizing even a small amount of work across 24 threads rather that doing it serially saving a percent or two feels plausible to me.

> There is some hand waving about file access patterns but I am skeptical; if the end-to-end build time is 3 seconds then the project is small enough to all fit in kernel caches.

It fits into the system's file cache unless there is memory pressure, like one would expect from having 24 C++ compiler jobs running in parallel. We actually measured this in isolation (with more detailed results in the linked article) and it has a measurable effect.

> They also mention doing other things like invoking the compiler to get version information. This seems like it would dwarf any performance gain from number 2.

I measured this, it costs 70ms or ~2% of the overall time.

Re: Faster Than Ninja

#17

Post by sramsay »

shevy-java wrote: post #9

Great that there are performance benefits, but one thing that I think both meson/ninja and cmake (or cmake/ninja) got wrong, and GNU configure got right is "./configure --help". Why do neither of these tools simply add --help here? Yes, their syntax is different, but the issue is not only about --help. Often I could disable documentation or man page via --disable-man or --disable-doc or something like that. I recentl…

I think what you're talking about is part of a much larger pattern. Autotools imagines that the most important thing is the "user" in a world where people want to download your software and build it on their machine. They don't care (as much) about fast build times, the semantic clarity of the build files themselves, the ease with which one may change or extend the build sequence, test harnesses . . . Those are all developer worries.

They do care that the code can compile on their (possibly old) machine. They do care about the ability to include some features and not others (including their ability to not have to make decisions on this if they don't want to). And they certainly want documentation that helps them to achieve their goal (which, again, is to build the software).

The newer tools make substantial inroads in making the developer's life easier. If your software is not of the sort where people download it and try to build it (because it only ships as a closed binary, is entirely internal, etc.) then maybe that makes sense. But until all these fancy gadgets start seriously caring about the use case above, I'm going to stick with autotools.

Re: Faster Than Ninja

#19

Post by bellowsgulch »

evmar wrote: post #4

[Ninja author here] Nice post, cool to see the deep dive! I also appreciate the details on how they produced their numbers. As they observe, Ninja gets to be fast mostly by cheating: it avoids a lot of work by saying many things are just out of scope for Ninja to do, and that means it is a useful a target to race against. (Funny thing: when I wrote Ninja I was misremembering how fast an earlier build system was so I…

Thank you for your work on Ninja. It's just really good.

Re: Faster Than Ninja

#20

Post by Orphis »

bluGill wrote: post #14

Cmake spend 15 seconds to generate this project? I find it unlikely build2 is doing the same work as cmake is. Now I will grant cmake is single threaded and slow, so there is a lot of room to do the things it does better (the language sucks, and is part of what forces single threaded). It also wouldn't surprise me if cmake is doing things that are not really needed (odds are the default compiler works - most of the t…

Xerces is an old library, probably ported from autotools and will do a lot of autotools like checks which for CMake means: creating a CMake project with the probe, generating the build files from it, building it, gathering results. Once for each test. It's SLOOOOW.

I recently (a few weeks ago) made a project to batch those type of commands together and parallelize tests as much as possible. You can check a merge request for CMake upstream here: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/1226... and the associated issue for more details.

In general, CMake is fast enough, the only slow bit on the critical path is detecting the toolchain. The rest is quick, but if your build scripts are using slow serialized functionality, you'll be paying that price. But only once as the slow results are cached, so next incremental run should be pretty fast!

Post reply on HN