Re: Time to refresh my hardware

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 9 Oct 2019 at 23:09, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> wrote:
My C++ compiles are getting longer. It's time to get new hardware, but I'm 
having some difficulty finding Fedora-friendly hardware, that's slightly 
above average grade, such as dual CPU and spinning rust (I haven't gotten 
quite aboard the SSD train, with its built-in expiration date).

SSD should greatly reduce compile times for large codes.

You can greatly extend the SSD expiration date by not allowing them to fill
up.   Before I retired I working with a group that did remote sensing, which 
involves large amounts of data.  Mechanical drives routinely failed on or
about the end of warranty, showing that the manufacturers have very good
understanding of the lifetime under heavy use.   This makes stripped disk 
arrays for better thruput very reliable during the warranty.  SSD's should 
be even better understood, and the failure modes should be easily monitored, 
so self-testing and reporting should be better than for mechanical drives.

In general, multiple CPU's only make sense if you need more cores than you
can get (or afford) on one CPU.   The exception might be cases like compiles 
where there are lots of independent processes and you benefit from double 
the cache, but you can also get CPU models with more cache.   There are 
extra costs for sockets, cooling, etc for 2 CPU systems, so in most cases 
you will be better off with at least one SSD and a higher-end (more cores and 
more cache) single CPU.   Intel is like automakers who try to get you to buy
features you don't really need.  They can charge more for higher CPU clock 
speeds than the increase thruput warrants.   For the remote sensing workloads
it was better to buy cheaper CPU's and spend more on mass storage.

Phoronix.com has lots of linux benchmark results that include compiles.

--
George N. White III

_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux