Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 May 2020 20:48:38 +0200
From:      Ralf Mardorf <>
Subject:   Re: Which version of freebsd Is faster: amd64 or i386?
Message-ID:  <20200505204838.5b92ee09@archlinux>
In-Reply-To: <>
References:  <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
All those generalized question related to performance and speed are
moot. Better questions are probably, why is hardware migrating from
32bit to 64bit architecture? What is the purpose of swap? Why are there
new versions of file systems?

A nice example, for faster is not always better:

		     Do	not update the file access time
when reading from a file.  This option is useful on file systems
where there are large numbers of files and performance is more
criti-cal than updating the file access time (which is rarely
ever important). This option is currently only supported
on local file systems." -

              Update  inode  access times relative to modify or change
time.  Access time is only updated if the previous access time was
earlier than the current modify  or  change time.   (Similar  to
noatime, but it doesn't break mutt or other applications that need to
know if a file has been read since the last time it was modified.)" -

Are such mount options still useful when using SSDs instead of spinning
drives? It unlikely makes a noticeable difference when file access time
gets always updated, nor would it seriously shorten lifetime of a SSD.
OTOH after migrating from HDD to SSD, why editing fstab, if those
options worked well for the old HDDs, while they don't have a negative
impact on SSDs?

You could overclock the CPU, play around with PCI latency and other
critical things, to get a faster but unstable machine. You could use a
text-based web browser instead of a GUI web browser, to waste less
resources of a computer but to suffer from the limitations of a
text-based web browser.

Experts could speed up a machine by tweaking a few things, but even for
experts the golden rule is "less is more" and it usually requires a lot
of trial and error. Staying with less optimal defaults could save time.

Ok, you want to learn, so you are asking a few questions. But IMO your
questions are way too abstract. What is your domain?

On one of my Linux DAWs unbinding USB ports that shared an IRQ with
something important did improve performance, on the machine I'm using
now it's impossible to do it, but even shared IRQs don't have a
negative impact on that new machine.

A shorter and quicker path could improve performance a lot, but maybe
at the cost of being more vulnerable to Meltdown and Spectre.

Performance is always related to the hardware and the domain. A video
entertainment machine, a server ...

Want to link to this message? Use this URL: <>