PC for development (compiling and linking speed)

Started by
8 comments, last by frob 7 years ago

I'm going to upgrade my development computer soon, so I'm looking for suggestions.

What I desire: good compile and linking speed (C++, almost no libs used, custom engine), my convenience as a developer, fast running single core code.

What I don't need: keeping my computer specs similar to target players specs is not needed (I don't make resource intense games, besides I can test it on another comp); I don't need the OS to launch fast or other apps running fast, just care about my IDE and compiling my game.

Specific questions/ideas:

- do you think I should go for 3 monitors or just stick to 2?

- I was thinking for a big HDD for OS and apps and then a separate small but high speed SSD exculsively for compiler and source code (for quick linking times)

- CPU I think 8 cores maybe (for compile times)? But I would not want to sacriface single core performance since it helps me greatly when testing (the game launches and initializes faster, I'm using single core code in my games). What clock speed should I aim for?

- memory, 8 GB or 16 GB? Maybe 8GB but faster? Overall, should I bother with memory speed? Is it a bottleneck of any sort?

Stellar Monarch (4X, turn based, released): GDN forum topic - Twitter - Facebook - YouTube

Advertisement

It's my experience that link times dominate build times, at least for C-based targets (including C++). Linking eats memory. Everything else in a build can also be improved by throwing memory at it via the disk cache.

A good OS uses its disk cache wisely, negating most of the advantages of fast persistent storage (ie. SSD vs. spinning rust). The trick is disk cache needs plenty of free RAM.

Throwing more CPUs doesn't help much since linking is not easily parallelizable. It helps compile times, but with diminishing returns over multiple (>4) cores because of memory contention. A faster CPU might help build times, but if your fast CPUs are spending all their cycles waiting for memory fetches, you're wasting money. Memory speed dominates CPU speed in builds.

I would recommend getting a good-enough CPU with lots of cache, but I'd temper that with cost. I have never noticed the difference between an i5 and an i7 when building software, but your mileage may vary. If you're building a desktop, make sure there's plenty of cooling. I watch the governors regularly slow down my CPUs during a build as heat builds up because I misunderestimated that facet of my build. Cool your memory and SSD too.

I'd get an all-SSD system, but only because I like the lower power consumption, quiet, and reduced boot time (I reboot test machines a lot because I work on OS-level software), and the costs are similar to spinning glass for reasonably-sized disks. Backups are a different story and I stick to traditional disks for that. Partition you disks how you want, it's not important.

For software development performance, I would get as much of the fastest memory as possible. Stuff it in until the case bulges. 16 gigs of the fastest (high-quality) memory you can find, and make sure it stays cool.

I have also grown a fondness for local cloud builds, but only for CI and distribution building and testing. A stack of NUCs looks so cool on my desk. They don't help the edit-build-test cycle much but I can offload some of the build work.

Oh, and as to the number of monitors... I don't see how you can ever have enough and they can never be big enough.

Stephen M. Webb
Professional Free Software Developer

- do you think I should go for 3 monitors or just stick to 2?

3 seems overkill if you're not testing or making assets. with just two you can do remote debugging if needed. Even two is probably overkill for just coding and compiling and linking.

- I was thinking for a big HDD for OS and apps and then a separate small but high speed SSD exculsively for compiler and source code (for quick linking times)

i would put the OS, compiler, and code on a SSD, and everything else on a HDD.

- CPU I think 8 cores maybe (for compile times)? But I would not want to sacriface single core performance since it helps me greatly when testing (the game launches and initializes faster, I'm using single core code in my games). What clock speed should I aim for?

more cores is better for multi-thread compiling. it seems that at most one core or thread per source file is required for max performance. optimized link does not seem to be multi-thread. it seems clock cycles are what you want there. get the CPU with the highest base clock speed and overclock speed possible.

- memory, 8 GB or 16 GB? Maybe 8GB but faster? Overall, should I bother with memory speed? Is it a bottleneck of any sort?

i got 16. faster ram is nice if you're rich. 3 months ago i stepped up from an AMD E300 dual core @1.3Ghz, 3gig ram, onboard graphics chip, and HDD, to an i7-6700K 4 core 8 thread at 4.0 to 4.9Ghz w/ 16gig ram, a GTX1080 w/ 8 gig vidram, and SSDs. its spec'd out for testing, but used for both testing and development. if spec'd for development as well, i might go for more cores. on the old PC, compile times were on the order of 10 seconds for ~170,000 lines of code. link times were about 2 minutes. on the new PC, compile time is 1 second, and link time is about 10 seconds.

in short: you want SSDs and clock speeds - they seem to make the biggest difference. for just compiling and linking, more cores has much less impact than SSDs and clock speed.

Note that high clock speed chips trend to automatically come with large fast caches (L1, L2, L3).

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

One thing for compiling that hasn't yet been mentioned is that if you're not currently using precompiled headers, you should switch over to using them. You'll probably find that the performance gain is sufficient that you may not need to worry as much about other factors.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

The tasks you listed are mostly for build machines, not development machines.

- do you think I should go for 3 monitors or just stick to 2?

For a build machine, none.

If you are doing development on it, 2.

- I was thinking for a big HDD for OS and apps and then a separate small but high speed SSD exculsively for compiler and source code (for quick linking times)

For fast build times, keep the build on SSD if you can. Otherwise, use the hybrid drive technology that comes as part of your computer. Both AMD and Intel have technology and drivers that turn your SSD+HDD into a hybrid drive. That is, part of your SSD (e.g. 64GB) is reserved for caching, and stuff that is frequently accessed on the HDD gets mirrored in that portion of the SSD. On a cache hit the performance is the same as the SSD, but you still get the massive (terabyte+) storage capacity of the HDD. Also for SSD, get the kind that plugs into the system bus as a card, since that is faster than the ones on the SATA controller.

Even though both companies include it, a discouraging number of people with SSD+HDD systems never properly enable the functionality, and consequently never get the major performance boost that is sitting on the chips ready for use. All of my home computers and most of my work computers have that setup. Some of our work computers are mis-configured, and they have much slower average disk times in the typical case as a result.

- CPU I think 8 cores maybe (for compile times)? But I would not want to sacriface single core performance since it helps me greatly when testing (the game launches and initializes faster, I'm using single core code in my games). What clock speed should I aim for?

I'm not sure why you think more CPU cores would help your build system initialize faster. I'd get a modern i7 not because of the number of cores, but because of the cache sizes, or if you prefer AMD's architecture, the same for FX processor. It is a mix of raw cycles so a high clock rate, and also cache size. A cache miss is equal to about 50 CPU cycles, so if you can avoid cache misses with a larger cache it pays off quite well. Since the chip manufacturers understand this (more than most consumers) the high-end chips have both more cycles and more cache, and they cluster their offerings based on the combination of raw cycles and cache.

That is true if you're making a build machine, and even more important if you're making a machine to play high-end games. Basically get the highest numbers you can reasonably afford.

- memory, 8 GB or 16 GB? Maybe 8GB but faster? Overall, should I bother with memory speed? Is it a bottleneck of any sort?

16 GB of fast memory. YES it is a performance bottleneck, but less of a concern in a build machine. If you're also going to be playing high-end games, you'll want fast memory.

Something you did not mention is your motherboard.

They make a difference to. Not in computation and memory, the integrated memory controllers take care of that, but a modern PC is made up of more than just the CPU and memory chips. Motherboards these days have fully integrated Audio, LAN, USB, disk controllers, etc. Some people buy cheap motherboards that have crappy disk controllers then wonder why their high-end disk drives are sluggish. It won't need to be the ultimate high end board, but it can give a 5% or so performance difference in general, with variations between audio quality, USB performance, and the rest.

If you're planning on overclocking, your motherboard selection will also make a difference in how far you can push the box.

With all that in mind, none of it is REQUIRED. You can build and develop games on just about any stock off-the-shelf commodity PC. The $100 special at WalMart isn't the best computer in the world, but it better than you could find five years ago, and is more than enough for anything an individual will create.

I've got nothing to add in terms of machine spec, but I'll vote for getting as many screens as possible. I like three screen because at three, everything has a purpose-

Screen one has my ide/code/etc.

Screen two has my tools/engine/game/etc

Screen three has non-work stuff, spotify, maybe a browser, etc.

I like the idea of doing the work on one screen, seeing the result on a second, and keeping potential distractions on the third

The tasks you listed are mostly for build machines, not development machines.

Do you not commonly build on your development machine?

What I desire: good compile and linking speed (C++, almost no libs used, custom engine), my convenience as a developer, fast running single core code.

On an AMD FX 4170 (4 cores, 4.2 GHz), this is incredibly fast (Gcc, Linux 64 bits). And it was out 5 years ago (or even more).

So now I would go for an AMD Ryzen if you can afford (FX was very cheap compared to zen CPUs).

The tasks you listed are mostly for build machines, not development machines.

Do you not commonly build on your development machine?

Yes. Very often.

Stellar Monarch (4X, turn based, released): GDN forum topic - Twitter - Facebook - YouTube

Sorry, I'm used to different systems lately and forgot the audience. In large games a full build takes several hours. On my current project a full code build takes about 5 hours on a developer's system. On the project before that, a code build took about 8 hours. Data builds are measured in days, not hours. Individual developers build a library or component and link against the rest of the project. Build machines are completely different beasts than desktop machines.

Really, unless you are doing something that is unusually taxing then just about any commodity machine released in the past few years will do. Remember there is no need to get the latest and greatest. It is always fun to get the bleeding-edge high-end machine, but adequate here meaning an i7 or Fx chip produced within the last few years. If you really want that brand new Rysen X370 released in the past month or the 7700K released three months ago, you'll be paying a premium for them.

There is no question about the appeal of getting this month's best top-of-the-line processor. Just be prepared for the letdown when they release the next product a few months down the road, and yours is no longer the best or fastest. They are tools to get a job done, and "best" is often the enemy of "adequate".

This topic is closed to new replies.

Advertisement