On Thursday, 27 January 2022 at 16:46:59 UTC, Ali Çehreli wrote:
>
> What I know is that weak symbols can be overridden by strong symbols during linking. Which means, if a function body is inlined which also has a weak symbol, some part of the program may be using the inlined definition and some other parts may be using the overridden definition. Thanks to separate compilation, they need not match hence the violation of the one-definition rule (ODR).

But the language requires ODR, so we can emit templates as weak_odr, telling the optimizer and linker that the symbols should be merged _and_ that ODR can be assumed to hold (i.e. inlining is OK).
The onus of honouring ODR is on the user - not the compiler - because we allow the user to do separate compilation. Some more detailed explanation and example:
https://stackoverflow.com/questions/44335046/how-does-the-linker-handle-identical-template-instantiations-across-translation/44346057

-Johan

On Thursday, 27 January 2022 at 18:12:18 UTC, Johan Engelen wrote:
> But the language requires ODR, so we can emit templates as weak_odr, telling the optimizer and linker that the symbols should be merged _and_ that ODR can be assumed to hold (i.e. inlining is OK).

Thanks! This was also my impression. But the problem is that Iain Buclaw seems to disagree with us. He claims that template functions must be overridable by global functions and this is supposed to inhibit template functions inlining. Is there any independent source to back up your or Iain's claim?

> The onus of honouring ODR is on the user - not the compiler - because we allow the user to do separate compilation.

My own limited experiments with various code snippets convinced me that D compilers actually try their best to prevent ODR violation, so it isn't like users can easily hurt themselves: https://forum.dlang.org/thread/cstjhjvmmibonbajwbbl@forum.dlang.org

Also module names are added as a part of function names mangling. Having an accidental clash of symbol names shouldn't be very likely in a valid D project. Though I'm not absolutely sure whether this provides a sufficient safety net.

On Thursday, 27 January 2022 at 20:28:40 UTC, Siarhei Siamashka wrote:
> On Thursday, 27 January 2022 at 18:12:18 UTC, Johan Engelen wrote:
>> But the language requires ODR, so we can emit templates as weak_odr, telling the optimizer and linker that the symbols should be merged _and_ that ODR can be assumed to hold (i.e. inlining is OK).
>
> Thanks! This was also my impression. But the problem is that Iain Buclaw seems to disagree with us. He claims that template functions must be overridable by global functions and this is supposed to inhibit template functions inlining. Is there any independent source to back up your or Iain's claim?
>

For example, druntime depends on this behaviour.

Template: https://github.com/dlang/druntime/blob/a0ad8c42c15942faeeafb016e81a360113ae1b6b/src/rt/config.d#L46-L58

Regular symbol: https://github.com/dlang/druntime/blob/a17bb23b418405e1ce8e4a317651039758013f39/test/config/src/test19433.d#L1

If we can rely on instantiated symbols to not violate ODR, then you would be able to put symbols in the .link-once section.  However all duplicates must also be in the .link-once section, else you'll get duplicate definition errors.

On 1/29/22 10:04, Salih Dincer wrote:

> Could you also try the following code with the same configurations?

The program you posted with 2 million random values:

ldc 1.9 seconds
gdc 2.3 seconds
dmd 2.8 seconds

I understand such short tests are not definitive but to have a rough idea between two programs, the last version of my program that used sprintf with 2 million numbers takes less time:

ldc 0.4 seconds
gdc 0.5 seconds
dmd 0.5 seconds

(And now we know gdc can go about 7% faster with additional command line switches.)

Ali

On Saturday, 29 January 2022 at 18:28:06 UTC, Ali Çehreli wrote:
> On 1/29/22 10:04, Salih Dincer wrote:
>
> > Could you also try the following code with the same
> configurations?
>
> The program you posted with 2 million random values:
>
> ldc 1.9 seconds
> gdc 2.3 seconds
> dmd 2.8 seconds
>
> I understand such short tests are not definitive but to have a rough idea between two programs, the last version of my program that used sprintf with 2 million numbers takes less time:
>
> ldc 0.4 seconds
> gdc 0.5 seconds
> dmd 0.5 seconds
>
> (And now we know gdc can go about 7% faster with additional command line switches.)
>
> Ali

You need to be compiling with PGO to test the compilers optimizer to the maximum. Without PGO they have to assume a fairly conservative flow through the code which means things like inlining and register allocation are effectively flying blind.

On Saturday, 29 January 2022 at 18:28:06 UTC, Ali Çehreli wrote:
> On 1/29/22 10:04, Salih Dincer wrote:
>
> > Could you also try the following
> > code with the same configurations?
>
> The program you posted with 2 million random values:
>
> ldc 1.9 seconds
> gdc 2.3 seconds
> dmd 2.8 seconds
>
> I understand such short tests are not definitive but to have a rough idea between two programs, the last version of my program that used sprintf with 2 million numbers takes less time...
>

sprintf() might be really fast, but your algorithm is definitely 2.5x faster than mine! (with LDC) I couldn't compile with GDC. Theoretically, I might have lost the challenge :)

With love and respect...

On Tuesday, 25 January 2022 at 22:41:35 UTC, Elronnd wrote:
> On Tuesday, 25 January 2022 at 22:33:37 UTC, H. S. Teoh wrote:
>> interesting because idivl is known to be one of the slower instructions, but gdc nevertheless considered it not worthwhile to replace it, whereas ldc seems obsessed about avoid idivl at all costs.
>
> Interesting indeed.  Two remarks:
>
> 1. Actual performance cost of div depends a lot on hardware.  IIRC on my old intel laptop it's like 40-60 cycles; on my newer amd chip it's more like 20; on my mac it's ~10.  GCC may be assuming newer hardware than llvm.  Could be worth popping on a -march=native -mtune=native.  Also could depend on how many ports can do divs; i.e. how many of them you can have running at a time.
>
> 2. LLVM is more aggressive wrt certain optimizations than gcc, by default.  Though I don't know how relevant that is at -O3.

-O3 often chooses longer code and unrollsmore agressively inducing higher miss rates in the instruction caches.
-O2 can beat -O3 in some cases when code size is important.