inserting -stdlib=libstdc++ into cxxflags

[René J.V. Bertin]

On Sunday March 17 2024 03:44:00 Sergey Fedorov wrote:

>> but if libc++ 5 was maybe still a bit faster overall than libstc++ the
>situation is now rather reversed though differences remain small

I take that back, the differences aren't always small!

I realised that the so-called "native" benchmark from the libcxx source tree could be used with the libstdc++ from (currently) port:libgcc13. It took some time to figure out how to inject the `-stdlib=macports-libstdc++` argument properly but once I got that working on Linux it transferred without further ado to Mac.

These results just in. Libc++ and all benchmarking code built with `clang++-mp-12 -O3 -march=native -flto`.

libstdc++ is indeed consistently faster. Usually by not much (though the differences in kernel time spent can be relatively important):

```
> build/libcxx/benchmarks/algorithms.partition_point.libcxx.out
Run on (4 X 2700 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x2)
  L1 Instruction 32 KiB (x2)
  L2 Unified 256 KiB (x2)
  L3 Unified 4096 KiB (x1)
Load Average: 1.13, 1.27, 1.34
<snip>
89.198 user_cpu 0.907 kernel_cpu 1:30.11 total_time 99.9%CPU {93360128M 0F 226542R 0I 0O 0k 0w 445c}
> /build/libcxx/benchmarks/algorithms.partition_point.native.out
Run on (4 X 2700 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x2)
  L1 Instruction 32 KiB (x2)
  L2 Unified 256 KiB (x2)
  L3 Unified 4096 KiB (x1)
Load Average: 1.42, 1.35, 1.34
<snip>
75.612 user_cpu 0.911 kernel_cpu 1:16.53 total_time 99.9%CPU {102424576M 0F 229228R 0I 0O 0k 0w 504c}
```

```
> build/libcxx/benchmarks/algorithms.libcxx.out --benchmark_repetitions=1 --benchmark_filter='_262144$'
Run on (4 X 2700 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x2)
  L1 Instruction 32 KiB (x2)
  L2 Unified 256 KiB (x2)
  L3 Unified 4096 KiB (x1)
Load Average: 1.63, 1.75, 1.70
<snip>
220.386 user_cpu 2.961 kernel_cpu 3:43.50 total_time 99.9%CPU {79626240M 0F 542726R 0I 9O 0k 154w 3502c}
> build/libcxx/benchmarks/algorithms.native.out --benchmark_repetitions=1 --benchmark_filter='_262144$'
Run on (4 X 2700 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x2)
  L1 Instruction 32 KiB (x2)
  L2 Unified 256 KiB (x2)
  L3 Unified 4096 KiB (x1)
Load Average: 1.66, 1.79, 1.67

<snip> 
190.844 user_cpu 2.615 kernel_cpu 3:13.50 total_time 99.9%CPU {89800704M 0F 504812R 0I 9O 0k 149w 1942c}
```

But observe this, as far as I understand a "small" version of the above benchmark that seems to highlight a huge overhead in libc++:

```
> build/libcxx/benchmarks/algorithms.libcxx.out --benchmark_repetitions=1 --benchmark_filter='_1$'
Run on (4 X 2700 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x2)
  L1 Instruction 32 KiB (x2)
  L2 Unified 256 KiB (x2)
  L3 Unified 4096 KiB (x1)
Load Average: 1.61, 1.37, 1.36
<snip>
1947.681 user_cpu 221.754 kernel_cpu 36:10.22 total_time 99.9%CPU {78262272M 0F 1503675R 0I 9O 0k 152w 22829c}
> build/libcxx/benchmarks/algorithms.native.out --benchmark_repetitions=1 --benchmark_filter='_1$'
Run on (4 X 2700 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x2)
  L1 Instruction 32 KiB (x2)
  L2 Unified 256 KiB (x2)
  L3 Unified 4096 KiB (x1)
Load Average: 1.63, 1.42, 1.36
<snip>
1056.593 user_cpu 8.435 kernel_cpu 17:45.51 total_time 99.9%CPU {78917632M 0F 1458187R 0I 9O 0k 154w 12805c}
```

Here the library from the "bloated" GCC is twice as fast overall, and uses almost 30x less kernel CPU time!

I see the same on Linux.

This makes me wonder if shouldn't try building llvm+clang against macports-libstdc++ . I have already managed to do so with lld-17 (only depends on libc++ via libxml2, and turns out to be "safe to mingle"). Newer clang versions build against their own libc++ even on Linux (when building with clang) so that suggests the code has been designed to separate the possibly 2 C++ runtime versions that get linked. It would probably be impossible to use the resulting libLLVM or libclang in dependent ports but maybe the performance increase might be worth it.

R