Reducing the cost of autodecoding

Johan Engelen via Digitalmars-d digitalmars-d at puremagic.com
Thu Oct 13 01:57:07 PDT 2016


On Thursday, 13 October 2016 at 01:26:17 UTC, Andrei Alexandrescu 
wrote:
> On 10/12/2016 08:11 PM, Stefan Koch wrote:
>> We should probably introduce a new module for stuff like this.
>> object.d is already filled with too much unrelated things.
>
> Yah, shouldn't go in object.d as it's fairly niche. On the 
> other hand defining a new module for two functions seems 
> excessive unless we have a good theme. On the third hand we may 
> find an existing module that's topically close. Thoughts? -- 
> Andrei

There could be some kind of "expect" theme, or a 
microoptimization theme. Functions that have no observable 
effects and that provide hints for optimization (possibly 
compiler-dependent implementations of those functions).

Besides providing the expected value of an expression, other 
"expect"/microopt functionality is checking explicitly for 
function pointer values (to inline a likely function), that I 
wrote about in [1]:
```
/// Calls `fptr(args)`, optimize for the case when fptr points to 
Likely().
pragma(inline, true)
auto is_likely(alias Likely, Fptr, Args...)(Fptr fptr, Args args) 
{
     return (fptr == &Likely) ? Likely(args) : fptr(args);
}
// ...
void function() fptr = get_function_ptr();
fptr.is_likely!likely_function();
```

A similar function can be made for "expecting" a class type for 
virtual calls [1].

Other microopt thingies that come to mind are:
- cache prefetching
- function attributes for hot/cold functions

cheers,
   Johan


[1] 
https://johanengelen.github.io/ldc/2016/04/13/PGO-in-LDC-virtual-calls.html


More information about the Digitalmars-d mailing list