Minor simplification to FixedWidthInteger._random(using: &generator).

[stephentyrone]

We don't actually need a divide or two paths or any of the other complexity here; the optimizer knows how to do this for us.

[stephentyrone]

@swift-ci please benchmark

[swift-ci]

Performance: -O

Regression	OLD	NEW	DELTA	RATIO
RandomShuffleLCG2	336	384	+14.3%	0.88x
Improvement	OLD	NEW	DELTA	RATIO
FlattenListFlatMap	4839	3683	-23.9%	1.31x (?)
FlattenListLoop	2831	2268	-19.9%	1.25x (?)

Code size: -O

Performance: -Osize

Regression	OLD	NEW	DELTA	RATIO
RandomShuffleLCG2	368	432	+17.4%	0.85x (?)

Code size: -Osize

Regression	OLD	NEW	DELTA	RATIO
RandomShuffle.o	3677	3805	+3.5%	0.97x

Performance: -Onone

Improvement	OLD	NEW	DELTA	RATIO
StringToDataSmall	750	700	-6.7%	1.07x (?)

Code size: -swiftlibs

How to read the data

The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview

  Model Name: Mac mini
  Model Identifier: Macmini8,1
  Processor Name: Intel Core i7
  Processor Speed: 3.2 GHz
  Number of Processors: 1
  Total Number of Cores: 6
  L2 Cache (per Core): 256 KB
  L3 Cache: 12 MB
  Memory: 64 GB

[stephentyrone]

Interesting, that's a regression that I didn't see locally. Taking a look ...

[stephentyrone]

@swift-ci please test

[benrimmington]

Suggested change

	internal func swift_stdlib_random(_: inout UInt64, _: Int)
	internal func swift_stdlib_random(_: UnsafeMutableRawPointer, _: Int)

The validation-test uses swift_stdlib_random with buffers larger than a UInt64.

[Azoy]

Also arc4random_buf uses the C calling conv.

[jrose-apple]

And you can't use @_silgen_name to declare arbitrary C things regardless, because they'll collide with the real declarations at the SIL level when someone imports them.

[benrimmington]

If swift_stdlib_random (for __APPLE__ platforms) was moved from Random.cpp to Random.h, using static inline SWIFT_ALWAYS_INLINE, would it be imported into Swift as @inlinable?

[stephentyrone]

Yeah, we do this in a bunch of other places, and it's also (almost) what I'll do here. I'll update this sometime this week. (We can't quite just make the function static inline, because we need to still have an external symbol to support code compiled with an earlier version of Swift, but that's easy enough to address.)

Minor note: it's not semantically equivalent to @inlinable--it has the semantics of a C[++] always-inline function.

[stephentyrone]

Is your contention that we shouldn't have any such static inline wrappers in the shims? If so, what's the alternative--just eat the performance hit for all of these operations? For random there's enough work happening that it's not catastrophic, but it's still measurable, and for some of these other operations it's worse.

[jrose-apple]

The rule is that the static ones can't call anything declared elsewhere. We've been eating the perf hit where the indirection is used for several releases; we can take a little longer to come up with a proper solution (or figure out how to compile with LTO).

[jrose-apple]

This problem is also specific to the standard library, because that's the only library that's below the $Platform module.

[stephentyrone]

The rule is that the static ones can't call anything declared elsewhere.

Except for strlen and memcmp (both of which actually have clang builtins, IIRC, so I think we could fix those) and malloc_size and free and ...

[jrose-apple]

It looks like I was tagged into #19614 and didn't complain then. I do not trust any of this though—the types are only matching up because the importer special-cases a few of the shims types like it does the real libc types, and the more we do it the more likely we are to accidentally diverge from the real SDK.

[jrose-apple]

And you can't use @_silgen_name to declare arbitrary C things regardless, because they'll collide with the real declarations at the SIL level when someone imports them.