5 Jul
2021
5 Jul
'21
9:17 p.m.
Larry McVoy wrote in
<20210705144314.GV817(a)mcvoy.com>:
|On Mon, Jul 05, 2021 at 02:23:36PM +1000, George Michaelson wrote:
|> Forgive me a side note, but has it not been shown for some time that
|> apart from a very gifted few people, hand-crafted machine-code is
|> usually slower than the best optimising compilers these days? With out
Some *BSDs moved from such to plain C code for strlen() for
example, a couple of years back, yes.
|> of order instruction stuff, side effects (inter-core locking) cache
|> coherency &c it isn't hard to wind up using "simpler" machine
code
|> which performs worserer.
|
|I dunno where my team sat on the "gifted" scale, I like to think they
|were pretty good. We ran our code through Intel's fancy C compiler and
|it made less than a 1% difference vs GCC. We cared about performance
|and had already done the by hand work to make the critical paths go fast.
Funnily just a couple of months ago at least FreeBSD (but i think
also DragonFly BSD, a tad different) moved back, on at least
x86_64.
(I personally no longer look nor care that much, as (a) i cannot
help it anyway, (b) there are so many CPU etc. models out there.
Why try to go backward because Cyrix is so good there, use code
alignment of X for processor A and Y for processor B? That is
just a tremendous maintenance mess, and that for free and with so
few time. No. Fun fact is that my one NVME disc can read/write
1.3 gigabytes per second doing "btrfs scrub", that is i think at
least four times the speed of the main memory the mentioned Cyrix
had available.)
--End of <20210705144314.GV817(a)mcvoy.com>
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)