Re: Modern compilers for ye olde architectures

On 2021-10-22, gah4 <gah4@u.washington.edu> 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

Return to the comp.compilers page.
Search the comp.compilers archives again.