6 ms·

As already said by others, Phoronix has some compilation benchmarks. I have recently bought a 3900X. Some things about compilation I would note is that it heav

As already said by others, Phoronix has some compilation benchmarks. I have recently bought a 3900X. Some things about compilation I would note is that it heavily depends on your programming language and tooling. And that you would note is that you get most benefits on clean builds of big projects, which scale very well per core. On incremental builds or smaller projects it is however not uncommon to see < 25% of the CPU being used. That is especially with Rust, where a single compilation unit (crate) is compiled in a single-threaded fashion. Might be better with C or C++. But then again linking might also be blockers. It's all nice and fast, but on day to day use you likely won't see a 100% speed increase compared to a 3600.

zlynx 7y ago
Beside clean builds is Git branch checkouts. I hit this at least twice a week. Finish a feature branch and push it. Check out master. Pull master. Make new feature branch. Get an urgent bug fix request, switch to release branch, make a bugfix branch. Now go back to the new feature. During this I may end up doing large rebuilds because Git changes modification times even if you end up back with the same header file you started with. On a Thinkpad T540 the rebuild can take 30 minutes. It's less than 5 on a 3900X.
- namibj 7y ago
  Use a build system that works with input-hashes. djb's redo is an example.
- nwallin 7y ago
  ccache solves this fairly well if you're on *nix.
- boring_twenties 7y ago
  Do you know about `git worktree`? You may not want a separate one for each branch you work on, but at least one for master and one for release would help you I think.
  - zlynx 7y ago
    There are problems with worktree. But yes, I often do use multiple checkout directories. When you do the git clone using the --reference option it gets most of the objects from the referenced directories. But this still results in slow compile times because the less used release directories get stale, have to be pulled up to date and often mostly rebuilt anyway. If I remember to actually use the second checkout directory, it does save on needing to rebuild the master/feature branches afterward.
mtone 7y ago
Another potential area might be unit testing. As an example, I've been running a test suite on a C# github project (xUnit and mocking libraries) with ~1.5K tests. The CPU is at a solid 100% cpu usage all the way through. In higher-level languages, running tests often takes considerably more time than building. A prosumer CPU like this would bring nice day to day improvements.

zlynx 7y ago

Beside clean builds is Git branch checkouts. I hit this at least twice a week. Finish a feature branch and push it. Check out master. Pull master. Make new feature branch. Get an urgent bug fix request, switch to release branch, make a bugfix branch. Now go back to the new feature. During this I may end up doing large rebuilds because Git changes modification times even if you end up back with the same header file you started with. On a Thinkpad T540 the rebuild can take 30 minutes. It's less than 5 on a 3900X.

namibj 7y ago
Use a build system that works with input-hashes. djb's redo is an example.
nwallin 7y ago
ccache solves this fairly well if you're on *nix.
boring_twenties 7y ago
Do you know about `git worktree`? You may not want a separate one for each branch you work on, but at least one for master and one for release would help you I think.
- zlynx 7y ago
  There are problems with worktree. But yes, I often do use multiple checkout directories. When you do the git clone using the --reference option it gets most of the objects from the referenced directories. But this still results in slow compile times because the less used release directories get stale, have to be pulled up to date and often mostly rebuilt anyway. If I remember to actually use the second checkout directory, it does save on needing to rebuild the master/feature branches afterward.

mtone 7y ago

Another potential area might be unit testing. As an example, I've been running a test suite on a C# github project (xUnit and mocking libraries) with ~1.5K tests. The CPU is at a solid 100% cpu usage all the way through. In higher-level languages, running tests often takes considerably more time than building. A prosumer CPU like this would bring nice day to day improvements.