implements display based subtype checking (6.4x faster without threads; 2.8x faster with threads)

[ringabout]

ref #20777

todo

• cpp
• downcast
• benchmarks

Here is the benchmark #18612 (comment)

[Araq]

I declare this to be crucial for version 2.

[Araq]

CI failure unrelated, merging.

[github-actions]

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from 7d15fdd

Hint: mm: orc; opt: speed; options: -d:release
165062 lines; 8.223s; 614.25MiB peakmem

[rockcavera]

This PR broke compiler compilation here.

e:\Nim>koch boot -d:release --skipUserCfg --skipParentCfg
iteration: 1
bin\nim.exe c  --skipUserCfg --skipParentCfg -d:nimKochBootstrap --nimcache:nimcache/r_windows_amd64 -d:release --skipUserCfg --skipParentCfg --noNimblePath --compileOnly compiler\nim.nim
Hint: used config file 'e:\Nim\config\nim.cfg' [Conf]
Hint: used config file 'e:\Nim\config\config.nims' [Conf]
Hint: used config file 'e:\Nim\compiler\nim.cfg' [Conf]
...............................................................................................................................................................................................................................
e:\Nim\compiler\ccgutils.nim(56, 14) Warning: target type is larger than source type
  target type: 'Hash' (8 bytes)
  source type: 'uint32' (4 bytes) [CastSizes]
................
e:\Nim\compiler\vmops.nim(149, 8) Warning: gc is deprecated [Deprecated]
..................................................................
Error: system module needs: isObjWithCache
FAILURE

nim -v
Nim Compiler Version 1.7.3 [Windows: amd64]
Compiled at 2022-11-08
Copyright (c) 2006-2022 by Andreas Rumpf

git hash: ca3b6cba5dca1b0f73d8dec7476d440af9780567
active boot switches: -d:release

[ringabout]

Hi @rockcavera
How about clearing the nimcache and removing the old bin/nim executable?

[rockcavera]

@ringabout , It worked! Thanks.

[ringabout]

No problem.

[rockcavera]

Looks like this PR caused a regression in performance using --mm:refc and --threads:on

REFC

before this PR -d:release --mm:refc --threads:off
 Proc with ref object 0.107
 Closures 2.246
 Methods 0.3599999999999999

after this PR -d:release --mm:refc --threads:off
 Proc with ref object 0.108
 Closures 2.092
 Methods 0.3260000000000001

before this PR -d:release --mm:refc --threads:on
 Proc with ref object 0.107
 Closures 4.382000000000001
 Methods 0.4370000000000003

after this PR -d:release --mm:refc --threads:on
 Proc with ref object 0.107
 Closures 11.914
 Methods 1.298999999999999


ARC

before this PR -d:release --mm:arc --threads:off
 Proc with ref object 0.107
 Closures 1.78
 Methods 2.605

after this PR -d:release --mm:arc --threads:off
 Proc with ref object 0.108
 Closures 1.645
 Methods 0.3240000000000003

before this PR -d:release --mm:arc --threads:on
 Proc with ref object 0.108
 Closures 7.931
 Methods 4.205

after this PR -d:release --mm:arc --threads:on
 Proc with ref object 0.108
 Closures 7.888
 Methods 1.329999999999999

before this PR -d:release --mm:arc --threads:on -d:useMalloc
 Proc with ref object 0.107
 Closures 13.06
 Methods 3.424999999999999

after this PR -d:release --mm:arc --threads:on -d:useMalloc
 Proc with ref object 0.108
 Closures 14.402
 Methods 1.850999999999999

before this PR -d:release --mm:arc --threads:off -d:useMalloc
 Proc with ref object 0.108
 Closures 9.478
 Methods 2.664999999999999

after this PR -d:release --mm:arc --threads:off -d:useMalloc
 Proc with ref object 0.106
 Closures 9.887
 Methods 0.3569999999999993

[ringabout]

I cannot reproduce on Win11

bin/nim r -d:release --mm:refc --threads:off

 Proc with ref object 0.045
 Closures 1.111
 Methods 0.1920000000000002

bin/nim r -d:release --mm:refc --threads:on

 Proc with ref object 0.046
 Closures 2.146
 Methods 0.2000000000000002

[rockcavera]

I talk about a comparison between performance before PR and after PR:

before this PR -d:release --mm:refc --threads:on
 Proc with ref object 0.107
 Closures 4.382000000000001
 Methods 0.4370000000000003

after this PR -d:release --mm:refc --threads:on
 Proc with ref object 0.107
 Closures 11.914
 Methods 1.298999999999999

[ringabout]

True, but in my case, there are no significant differences with threads on/off in refc after my PR, which indicates there shall be no regressions. My result is Methods 0.1920000000000002 vs Methods 0.2000000000000002.

In your case, it is Methods 0.3260000000000001 vs Methods 1.298999999999999.

That's the contradiction.

[Araq]

The refc code path is not changed at all. No idea what you measure. :P

[rockcavera]

In fact, I must have done something wrong in the last test. I recompiled and re-tested and indeed there is no regression for refc.

before this PR -d:release --mm:refc --threads:off
 Proc with ref object 0.108
 Closures 2.265
 Methods 0.359

after this PR -d:release --mm:refc --threads:off
 Proc with ref object 0.108
 Closures 2.353
 Methods 0.3599999999999999

before this PR -d:release --mm:refc --threads:on
 Proc with ref object 0.107
 Closures 4.292999999999999
 Methods 0.4500000000000002

after this PR -d:release --mm:refc --threads:on
 Proc with ref object 0.107
 Closures 4.306
 Methods 0.4340000000000002