RAM and CPU speed

GlitchyDot

GlitchyDot

Does ram and cpu speed affects make world build world all the worlds and other stuff much ? Trying to get myself thinkpad workstation and i can save 100$ + from generations but want to know how it would affect my usage. I will not compile packages on my workstation as i have freebsd vm inside proxmox so it would be done there but for general usage and FreeBSD stable update/upgrade i will use my workstation.
 
What about disk speed?

Fast disks would make a bit of a difference, though, right? Especially if you're talking about a physical spinning disk versus a solid state. Once files are cached in RAM, then the disk speed won't matter too much.
 
tOsYZYny said:
What about disk speed?

Fast disks would make a bit of a difference, though, right? Especially if you're talking about a physical spinning disk versus a solid state. Once files are cached in RAM, then the disk speed won't matter too much.
Click to expand...

Not really, just for `make clean` and incremental builds. I still do `make world` on magnetic HDs and even over NFS and it doesn't slow down a full make too much. There is a lot for the compiler to do. Just make sure you have a memory filesystem /tmp.
 
GlitchyDot said:
Does ram and cpu speed affects make world build world all the worlds and other stuff much ?
Click to expand...
Most source files are small enough that they easily fit entirely in the disk cache (for all but the most crippled machines). So, multiple passes over it see no real speedup from ADDITIONAL memory -- nor faster disks. Ditto for the tools that are bsing used.

The real "reuse" is header files that are commonly #included in (virtually) every file. And, even these are relatively small (see above).

RAM can be used to speed up repeated accesses to disk. So, a machine with a slower disk and more RAM can mimic the performance of a faster disk with less RAM (meaning the amount that can be cached is reduced so another disk access is required to reaccess material that was in memory moments earlier).

The big win for fast disk is random, single accesses. Like processing a query in a database -- the DBMS may have to jump around the file to gather up the information of interest; each jump collects a bit (or a few bits) of information before it flitters off to find something else.

In production settings, where the DBMS may be poked frequently (e.g., continuously), gobs of RAM can effectively pull much of the "database" into memory (without the user needing to explicitly copy it onto a RAM disk) to allow for repeat accesses without actually going out to the physical medium.
 
You must log in or register to reply here.
Back
Top