Combine --gc:arc with --threads:on slow down the performance heavily.

[khchen]

I wrote a reversi game with Monte Carlo AI engine as an example for wNim. I found that combining --gc:arc with --threads:on would impact the performance.

Here is my test. Test file is https://github.com/khchen/wNim/blob/master/examples/mcts/mcts.nim. I only paste the result of first round, adding a break to the loop will get the same result.

Compiling Command	Result
nim r -d:danger --opt:speed mcts	rounds: 1724
nim r -d:danger --opt:speed --gc:arc mcts	rounds: 1782
nim r -d:danger --opt:speed --threads:on mcts	rounds: 1715
nim r -d:danger --opt:speed --threads:on --gc:arc mcts	rounds: 1239

In conclusion, adding --gc:arc will speed up a little. However, combine --gc:arc with --threads:on will slow down the performance heavily. The most strange thing is that mcts.nim is just a single thread program! Is there a bug of compiler? or the bug is in my code?

[Araq]

Our default allocator is slow for --gc:arc --threads:on. We're moving to mimalloc, it's a known issue.

[Araq]

As a workaround, try -d:useMalloc.

[khchen]

Our default allocator is slow for --gc:arc --threads:on. We're moving to mimalloc, it's a known issue.

Ok, so maybe tis issue can be closed?

As a workaround, try -d:useMalloc.

Sorry, but no improvement.

Compiling Command	Result
nim r -d:danger --opt:speed mcts	rounds: 1724
nim r -d:danger --opt:speed --gc:arc mcts	rounds: 1782
nim r -d:danger --opt:speed --threads:on mcts	rounds: 1715
nim r -d:danger --opt:speed --threads:on --gc:arc mcts	rounds: 1239
nim r -d:danger --opt:speed --threads:on --gc:arc mcts -d:useMalloc	rounds: 1197

[timotheecour]

The most strange thing is that mcts.nim is just a single thread program! Is there a bug of compiler? or the bug is in my code?

random guess: you have a few {.threadvar.} variables in your code, and with --threads:on these use TLS which is slower;

which OS did you test on? #16750 made TLS faster on OSX, but it's unclear whether --gc:arc has impact on whether TLS uses native TLS or emulation?

[khchen]

random guess: you have a few {.threadvar.} variables in your code, and with --threads:on these use TLS which is slower;
which OS did you test on? #16750 made TLS faster on OSX, but it's unclear whether --gc:arc has impact on whether TLS uses native TLS or emulation?

There is no {.threadvar.} in the code, and I tested it under windows amd64.

[guzba]

I am also seeing significant performance cost to --threads:on. These figures are from Pixie.

gc:arc:

nim c --gc:arc -r -d:release  --debugger:native .\tests\benchmark_svg.nim
name ............................... min time      avg time    std dv   runs
svg decode ........................ 19.174 ms     19.921 ms    ±0.374   x251

gc:arc + threads:on

nim c --gc:arc --threads:on -r -d:release  --debugger:native .\tests\benchmark_svg.nim
name ............................... min time      avg time    std dv   runs
svg decode ........................ 52.026 ms     53.080 ms    ±0.545    x95

gc:arc + threads:on + -d:useMalloc:

nim c --gc:arc --threads:on -r -d:useMalloc -d:release  --debugger:native .\tests\benchmark_svg.nim
name ............................... min time      avg time    std dv   runs
svg decode ........................ 54.226 ms     55.403 ms    ±0.573    x91

Hottie (profiler) reports threadVarGetValue is a hot proc.

I grepped and confirmed that there are no {.threadvar.} pragmas in any of the code in Pixie or its dependencies.

[Araq]

Please also try --tlsEmulation:off

[guzba]

@Araq Sure can do, here are the results:

gc:arc + threads:on + tlsEmulation:off:

nim c --gc:arc --threads:on -r --tlsEmulation:off -d:release  --debugger:native .\tests\benchmark_svg.nim
name ............................... min time      avg time    std dv   runs
svg decode ........................ 20.609 ms     20.795 ms    ±0.100   x241

gc:arc + threads:on + tlsEmulation:off + -d:useMalloc:

nim c --gc:arc --threads:on -r --tlsEmulation:off -d:release -d:useMalloc  --debugger:native .\tests\benchmark_svg.nim
name ............................... min time      avg time    std dv   runs
svg decode ........................ 22.123 ms     22.857 ms    ±0.429   x218

It looks like --tlsEmulation:off eliminates the performance difference (at least 99% of it). Hopefully this is helpful to have confirmed.

[Araq]

Very interesting that it's still turned on for some platforms, only BoehmGC needs it these days...

[Varriount]

Very interesting that it's still turned on for some platforms, only BoehmGC needs it these days...

If so, then nim.cfg needs to be updated to reflect this. tlsEmulation is still enabled for Windows+GCC configurations.

[Araq]

Correct.

[ghost]

Sorry, closed by accident :(

[ghost]

The issue is still there even with tlsEmulation by the way (at least on Linux). -d:useMalloc improves it, but it's still behind non-threaded ARC performance. From my very limited testing a lot of the slowdown comes from the global heapLock that's acquired for each shared allocation/deallocation (in allocation-heavy programs).

Is the plan for switching to mimalloc still there?

[ghost]

I tried mimalloc myself, and for that silly benchmark (https://github.com/hanabi1224/Programming-Language-Benchmarks/blob/main/bench/algorithm/binarytrees/1.nim) --threads:on -d:useMalloc --mm:orc with mimalloc LD_PRELOAD is actually faster --mm:orc (single-threaded).

[ghost]

For some results on using mimalloc see https://github.com/Yardanico/mimalloc_nim

[Araq]

Is the plan for switching to mimalloc still there?

Yes, PRs are welcome.

[guzba]

I have been monitoring this after #19119 was reverted due to #19713

Nim 2.0 RC1 has just released been released today, which is of course extremely exciting! As a status update for this issue though, I do need to report that without passing --tlsEmulation:off the Pixie and Zippy benchmarks I monitor for performance remain 2 - 3.5x slower on Windows.

Pre-Nim 2.0, this wasn't a big deal since it only happened with --threads:on, which was not a common compilation configuration. With Nim 2.0,--threads:on is now the default so this TLS emulation issue is now a default performance penalty for everything on Windows.

Nim Compiler Version 1.9.1 [Windows: amd64]
Compiled at 2022-12-21
Copyright (c) 2006-2022 by Andreas Rumpf

active boot switches: -d:release

[Araq]

For the final release we should really disable thread local storage emulation. Ping @ringabout

[ringabout]

@guzba Hello, since Nim recommends using MinGW distribution on Window, which means if tls is disabled, it depends on winpthread.dll. Every project which uses mingw (since threads:on is a default option) needs to ship winpthread.dll (Users need to have winpthread.dll in their paths). It is also an implicit breaking change because if developers compile their program again with Nim 2.0, they may give their users broken binaries without shipping libwinthread because they probably work locally with mingw/bin added to path. Is there a better solution?

[guzba]

@ringabout First, thanks for all the work you've been doing for Nim 2.0! I've seen you everywhere I look re: Nim 2.0 work.

Second, I think you are correct it is a sticky problem. Adding an implicit dll dependency would not be something I'd want either. I am not an expert on this situation or problem however.

I do think it is fair to shoot for the dream -- both not paying a performance penalty and not having that dll dependency. I saw in the discussion that there perhaps could be static linking, or possibly whatever is triggering the requirement for that dll when tlsEmulation:off could be addressed / accomplished a different way?

I am not an expert on the mingw stuff nor the internals at play to really judge the difficulties or tradeoffs. I put a note on this because it is a bummer to see a performance penalty become the default and realized it may not be something everyone has realized.

I realize this is a bunch of unhelpful words I just don't have the knowledge at this moment to be more helpful.

[khchen]

Thanks to @guzba and @ringabout, I have also seen you both everwhere during I am playing with nim.

The dependence on libwinpthread-1.dll can be resolved by adding -l:-static option, but the output binary size will increase about 54k in size.

Here is my test today.

Nim Compiler Version 1.9.1 [Windows: amd64]
Compiled at 2022-12-24
Copyright (c) 2006-2022 by Andreas Rumpf

-d:release --opt:speed -d:strip -d:lto --cpu:amd64 -l:-static
gcc version 11.1.0 (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders)

Result (Rounds / Binary Size)	--tlsEmulation	--threads	--mm
614 (122,880)	on	on	orc
1418 (117,760)	on	on	refc
1318 (113,152)	on	off	orc
1438 (112,640)	on	off	refc
1038 (172,544)	off	on	orc
1368 (174,080)	off	on	refc
1320 (113,152)	off	off	orc
1437 (112,640)	off	off	refc

As a comparison, without -l:-static (output binary depends on libwinpthread-1.dll):

Result Binary Size	--tlsEmulation	--threads	--mm
117,760	off	on	orc
119,296	off	on	refc

[ringabout]

When --tleEmulation:off by default, there is still performance differences between refc and arc, that's duplicate of #15392 anyway.