Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Kaz Kylheku <480-992-1380@kylheku.com> Newsgroups: comp.compilers Subject: Re: Modern compilers for ye olde architectures Date: Fri, 22 Oct 2021 17:28:19 -0000 (UTC) Organization: A noiseless patient Spider Lines: 48 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <21-10-038@comp.compilers> References: <21-10-007@comp.compilers> <21-10-012@comp.compilers> <21-10-015@comp.compilers> <21-10-024@comp.compilers> <21-10-034@comp.compilers> <21-10-037@comp.compilers> Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="54542"; mail-complaints-to="abuse@iecc.com" Keywords: optimize, history Posted-Date: 22 Oct 2021 14:36:45 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:2745 On 2021-10-22, gah4 wrote: > I suspect that there is no interest in bringing FREQUENCY back to Fortran, > or any other language, though. GNU C has built-in primitives for expressing the likelihood of branches being taken: __builtin_expect and __builtin_expect_with_probability. Plus other builtins related to optimization such as that you can request cache prefetch with __builtin_prefetch. Goto labels can have attributes which indicate the likelihood of their use: again: /* we jump back here all the freakin' time */ __attribute__((hot)); ... err: /* oh crap! this happens, though rarely */ __attribute__((cold)); These things are smartly out of the way in a protected namespace, so you can easily use macros to write code that takes advantage of these things yet remains portable. > [Legend says that in at least one compiler, FREQUENCY was implemented > backward and nobody noticed. -John] The problem is that programmers sometimes optimize things just as a fun chrome plating exercise, and not as a change to the code accompanied by a unit test which somehow proves that the change had the required effect. It's hard to do and annoying; you can't test absolute speeds of anything because machines change. The test case may have to locally duplicate and preserve the old version of the entire module of code, and compare its performance to the new version. Then if things change in that code, that test is going to be annoying to maintain; its reference now has to be a fictitious old version of the code that never existed which doesn't have the optimization, so you can keep proving that the optimization provides a testable benefit. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal