Don't define HAS_CUSTOM_BLOCKS on mono

[EgorBo]

Fixes dotnet/perf-autofiling-issues#33182 regressions

[EgorBo]

@EgorBot -mono --filter System.Memory.ReadOnlyMemory.ToArray

[EgorBot]

Benchmark results on Intel

BenchmarkDotNet v0.13.13-nightly.20240311.145, Ubuntu 22.04.4 LTS (Jammy Jellyfish)
Intel Xeon Platinum 8370C CPU 2.80GHz, 1 CPU, 16 logical and 8 physical cores
  Job-HTXVRI : .NET 9.0.0 (42.42.42.42424) using MonoVM, X64 X86Base
  Job-WOJFSK : .NET 9.0.0 (42.42.42.42424) using MonoVM, X64 X86Base
PowerPlanMode=00000000-0000-0000-0000-000000000000  IterationTime=250ms  MaxIterationCount=20
MinIterationCount=15  WarmupCount=1

Method	Toolchain	Size	Mean	Error	Ratio	Gen0	Allocated	Alloc Ratio
ToArray	Main	512	948.9 ns	3.19 ns	1.00	0.2504	1.03 KB	1.00
ToArray	PR	512	196.8 ns	1.75 ns	0.21	0.2521	1.03 KB	1.00

BDN_Artifacts.zip

[EgorBo]

@matouskozak PTAL, it fixes the issue according to the benchmark in #106764 (comment)

[matouskozak]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[matouskozak]

Thank you for the fix and help with investigating the issue.

I don't think that MonoJIT (or other Mono codegens) have this guarantee to unroll blocks (<= 64 bytes) so I think this is a good fix. @BrzVlad do you know otherwise?

[BrzVlad]

We do unroll copies, in mini_emit_memcpy, but we might not be hitting that path for whatever reason, or we might emit some redundant instructions. I think this fix is ok, but it is a sign that our copy function is not optimal.

[matouskozak]

mini_emit_memcpy

We do unroll copies, in mini_emit_memcpy, but we might not be hitting that path for whatever reason, or we might emit some redundant instructions. I think this fix is ok, but it is a sign that our copy function is not optimal.

Looking at the codepaths for [Write/Read]Unaligned we are going thru mini_emit_memory_[store/load] that doesn't pass thru mini_emit_memcpy but goes straight to EMIT_NEW_[STORE/LOAD]_MEMBASE_TYPE. So we are not even trying to take advantage of the mini_emit_memcpy copy unroll.

[BrzVlad]

That should still emit a OP_STOREV_MEMBASE that would later be decomposed to some optimal copy sequence in mono_decompose_vtype_opts.

[matouskozak]

We might want to backport this fix to .NET 9 due to the severity of the perf regressions dotnet/perf-autofiling-issues#33182 @jkurdek @vitek-karas.

That should still emit a OP_STOREV_MEMBASE that would later be decomposed to some optimal copy sequence in mono_decompose_vtype_opts.

Thank you, you're right. However, we are taking this path

runtime/src/mono/mono/mini/memory-access.c

Line 221 in 169e22c

mono_emit_method_call (cfg, mini_get_memcpy_method (), iargs, NULL);

instead of going thru mini_emit_memcpy because we pass size / align > MAX_INLINE_COPIES (klass min_align is 1). As a future work, we could try tweaking the MAX_INLINE_COPIES heuristics.

[EgorBo]

/backport to release/9.0

[github-actions]

Started backporting to release/9.0: https://github.com/dotnet/runtime/actions/runs/10505141188

[xtqqczze]

Looking at the codepaths for [Write/Read]Unaligned we are going thru mini_emit_memory_[store/load] that doesn't pass thru mini_emit_memcpy but goes straight to EMIT_NEW_[STORE/LOAD]_MEMBASE_TYPE. So we are not even trying to take advantage of the mini_emit_memcpy copy unroll.

Is there an issue tracking this missed optimization?

[matouskozak]

Looking at the codepaths for [Write/Read]Unaligned we are going thru mini_emit_memory_[store/load] that doesn't pass thru mini_emit_memcpy but goes straight to EMIT_NEW_[STORE/LOAD]_MEMBASE_TYPE. So we are not even trying to take advantage of the mini_emit_memcpy copy unroll.

Is there an issue tracking this missed optimization?

I'm not aware of it so I created it #106822.