Deutsch English Français Italiano |
<vg6h0e$1hal$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Don Y <blockedofcourse@foo.invalid> Newsgroups: sci.electronics.design Subject: Re: OT: Programming Languages Date: Sat, 2 Nov 2024 17:43:46 -0700 Organization: A noiseless patient Spider Lines: 45 Message-ID: <vg6h0e$1hal$1@dont-email.me> References: <vg3575$3bio0$1@dont-email.me> <vg383n$3c25s$1@dont-email.me> <vg3m01$3e15j$2@dont-email.me> <vg3mnf$3egtc$1@dont-email.me> <14qaij9n9tjnr6gc1lfu4o69hb68gtcguf@4ax.com> <vg5pe4$3t3ve$1@dont-email.me> <vg6376$3ui18$2@dont-email.me> <vg6912$3vsuf$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 03 Nov 2024 01:43:59 +0100 (CET) Injection-Info: dont-email.me; posting-host="c3a05cd320d8ef4946849504d2aaa35c"; logging-data="50517"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+R8tk+xAXxmsFDC/iocxJ+" User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cancel-Lock: sha1:IoX9nN1Vj58Y8YhZ/VslCbP4BUs= Content-Language: en-US In-Reply-To: <vg6912$3vsuf$1@dont-email.me> Bytes: 3622 On 11/2/2024 3:27 PM, Dennis wrote: > On 11/2/24 15:48, Don Y wrote: >> On 11/2/2024 11:01 AM, Martin Brown wrote: >>> Most compilers these days are smart enough to move loop invariants outside >>> of a loop and then dispose of the loop. You must have side effects in any >>> code that you want to benchmark. Optimisers can be *really* smart about >>> rearranging code for maximum performance by avoiding pipeline stalls. Only >>> the very best humans can match them now. >> >> You need a few more asterisks stressing "really"! What's most amusing >> is how the folks who write "clever"/obscure code fragments THINKING they >> are "optimizing" it just annoy the compiler. On any substantial piece >> of code, "you" simply can't outperform it. Your mind gets tired. You >> make mistakes. The compiler just plows ahead. EVERY TIME IT IS INVOKED! >> > Over a decade ago I hand optimized some vector code on the CELL processor. I > then compiled some C++ code doing the same operations in nested loops with > vector optimization turned on. The compiler was faster by a cycle when they > found a load that could be done in parallel that I had missed. > > I didn't bother doing assembler code after that. A (good) compiler is like having an extra person on your team to "sweat the details". And, "he" works for very low pay! :> [I am always amused when folks bitch about the costs of tools: "Really? And how many of your PAID hours does that tool's cost translate to?"] The biggest advantage is that it frees you to "write what you want to do" instead of having to worry about finding the "fastest" (smallest?) way of doing it. If you can concentrate on clearly expressing the algorithm that you want to implement, it also helps The Next Guy who may not perceive all of the subtleties in your "cryptic" implementation. [The Reading Machine had a 16 word (!) boot PROM. If you looked at the code (just 16 instructions), you were left asking lots of questions like "Why is the program image being loaded at 014623 and not something 'nicer'?" Ans: because 014632 is the code for one of the 16 instructions that are going to be executed so why waste one of those 16 locations in the PROM to store some "nicer" address?? Does the code really care what address it loads at?!]