#0: Faster builds by enabling Unity build for TTNN and tests

[sminakov-tt]

Ticket

Problem description

Currently build times are really slow. After this change, clean build of the whole repo with tests is about 2x faster.

What's changed

Enable Unity build for TTNN and tests
Fix all of the compilation issues, primarily missing #pragma once in headers and usage of anonymous namespaces.

Future work

According to my observation, build times can be improved significantly by merging a lot of single-cpp test binaries together and applying Unity builds to them. This is considered to be out of scope of this pull request.

Checklist

• Post commit CI passes
• Blackhole Post commit (if applicable)
• Model regression CI testing passes (if applicable)
• Device performance regression CI testing passes (if applicable)
• New/Existing tests provide coverage for changes

[tt-rkim]

@afuller-TT I'm good with the suggestions, but we should plan to keep an eye on the build artifact times over a period. (which is what you said)

@sminakov-tt

There is a change in some header, which is used everywhere - triggers a full rebuild, unity build is significantly faster.

I agree.

There is a change in a few isolated files - triggers a rebuild of a few merged .cpp files, which is extremely likely to be faster than a build without ccache

Faster than a build without ccache, yes, but then why would the rebuild of a few merged .cpp files (and remember, given our software size, these are probably going to be large TUs) be faster than re-building only the affected TUs with the others cached? Wouldn't we be compiling either an equal amount or more stuff fundamentally upon a ccache miss with unity build on, as opposed to ccache miss with unity build off?

And sure, we would have likely <N cache misses with unity build on, but these TUs are still quite large, so the cache entries are large. Re-building smaller parts of it via individual TUs rather than a larger merged one with files that may have no changes should take less time, regardless of how many less cache misses we have. As a thought experiment, what happens if we were to have only one giant TU? (obviously not the case but I'm just saying)

Again, given @afuller-TT 's response above, I think it's still worth trying to see what the effect is on main. But I still am having trouble understanding your last point.

[sminakov-tt]

@tt-rkim
Let me clarify. I was trying to make a point that we should have ccache + unity turned on on CI. Because:

1. If we turn off ccache on CI, small changes which touch a few files will get a significant slowdown.
2. If we turn off unity on CI, large changes (close to full rebuild) will get a 2x slowdown. It's likely that small changes (a few files) would get a bit faster, but I think with unity they are still "fast enough".

I also agree, let's just wait and see what's going to happen in practice.

[ayerofieiev-tt]

Lets go! 🚀

[afuller-TT]

These are kinda noisy and not related to the tests themselves. Does Unity trip up if we have it at file-scope instead of f'n scope?

[sminakov-tt]

Yes. Let's say we have two files which are being merged in unity build, and both of them define the same function within CMAKE_UNIQUE_NAMESPACE. If both of them do using namespace at the file level, it would result in both functions being visible at the same time and the call would be ambiguous.

[afuller-TT]

Yes. That makes perfect sense.

[afuller-TT]

Dead code removal 🔥

[eyonland]

Thanks for doing this.