Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Tue, 10 Sep 2024 12:47:37 +0200
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <vbp849$2trde$1@dont-email.me>
References: <vasruo$id3b$1@dont-email.me>
 <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me>
 <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me>
 <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me>
 <vb00c2$150ia$1@dont-email.me>
 <505954890d8461c1f4082b1beecd453c@www.novabbs.org>
 <vb0kh2$12ukk$1@dont-email.me> <vb3smg$1ta6s$1@dont-email.me>
 <vb4q5o$12ukk$3@dont-email.me> <vb6a16$38aj5$1@dont-email.me>
 <vb7evj$12ukk$4@dont-email.me> <vb8587$3gq7e$1@dont-email.me>
 <vb91e7$3o797$1@dont-email.me> <vb9eeh$3q993$1@dont-email.me>
 <vb9l7k$3r2c6$2@dont-email.me> <vba26l$3te44$1@dont-email.me>
 <vbag2s$3vhih$1@dont-email.me> <vbbnf9$8j04$1@dont-email.me>
 <vbbsl4$9hdg$1@dont-email.me> <vbcbob$bd22$3@dont-email.me>
 <vbcob9$dvp4$1@dont-email.me> <vbd174$eulp$1@dont-email.me>
 <vbm67e$2apse$1@dont-email.me> <vbmkln$2cmfo$1@dont-email.me>
 <vbni3u$2h7pp$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 10 Sep 2024 12:47:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="164517e557401dcf9b3aeffde6d063fe";
	logging-data="3075502"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18WtWVRZ349r/BlYV4zeGKRg8BiNg8BYrs="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:uyYXSZtCrQDWeqPb79KhGml29Y8=
In-Reply-To: <vbni3u$2h7pp$1@dont-email.me>
Content-Language: en-GB
Bytes: 4898

On 09/09/2024 21:25, Brett wrote:
> David Brown <david.brown@hesbynett.no> wrote:

>> Of course the fine line between "smart code" and "smart-arse code" is
>> somewhat subjective!
>>
>> It also varies over time, and depends on the needs of the code.
>> Sometimes it makes sense to prioritise efficiency over readability - but
>> that is rare, and has been getting steadily rarer over the decades as
>> processors have been getting faster (disproportionally so for
>> inefficient code) and compilers have been getting better.
>>
>> Often you get the most efficient results by writing code clearly and
>> simply so that the compiler can understand it better and good object
>> code.  This is particularly true if you want the same source to be used
>> on different targets or different variants of a target - few people can
>> track the instruction scheduling and timings on multiple processors
>> better than a good compiler.  (And the few people who /can/ do that
>> spend their time chatting in comp.arch instead of writing code...)  When
>> you do hand-made micro-optimisations, these can work against the
>> compiler and give poorer results overall.
> 
> I know of no example where hand optimized code does worse on a newer CPU.
> A newer CPU with bigger OoOe will effectively unroll your code and schedule
> it even better.

I would agree with you there.  For the same object code, newer CPUs 
(with the same ISA) are typically faster for a variety of reasons. 
There may be the odd regression, but it is hard to market a newer CPU if 
it is slower than the older ones!

However, my point was that "hand-optimised" source code can lead to 
poorer results on newer /compilers/ compared to simpler source code.  If 
you've googled for "bit twiddling hacks" for cool tricks, or written 
something like "(x << 4) + (x << 2) + x" instead of "x * 21", then the 
results will be slower with a modern compiler and modern cpu, even 
though the "hand-optimised" version might have been faster two decades 
ago.  You can expect the modern tool to convert the multiplication into 
shifts and adds if that is more efficient on the target, or a 
multiplication if that is best on the target.  But you can't expect the 
compiler to turn the shifts and adds into a multiplication.  (Sometimes 
it can, but you can't expect it to.)

> 
> It’s older lesser CPU’s where your hand optimized code might fail hard, and
> I know of few examples of that. None actually.
> 
>> This is especially the case
>> when code is moved around with inlining, constant propagation,
>> unrolling, link-time optimisation, etc.
>>
>> Long ago, it was a different matter - then compilers needed more help to
>> get good results.  And compilers are far from perfect - there are still
>> times when "smart" code or assembly-like C is needed (such as when
>> taking advantage of some vector and SIMD facilities).
>