[performance][windows][stdio] `write_valid_utf8_to_console` should almost certainly call `MultiByteToWideChar`

[strega-nil-ms]

(and similarly, read_u16s() should call WideCharToMultiByte)

Windows provides these nice functions which performantly implement utf-8 <-> utf-16 conversions. We should probably call them in the standard library when possible.

[the8472]

Do we get measurable performance wins that make calling more unsafe C APIs worth it? Especially with the inlining barrier across languages.
And I would assume console printing is bottlenecked on the console rendering part anyway, not on string conversions.

[ChrisDenton]

Do we have any good benchmarks for console I/O perf?

[the8472]

A simple main writing 100MB worth of lines to stdout and measuring the time it takes should do?

[ChrisDenton]

For sure. I was just wondering if we had something already. I mean, we'd probably want to be testing a few different languages as well to make sure we're not just optimizing for ASCII only.

[the8472]

I don't think we do because most benchmarks suppress console output.

[strega-nil-ms]

I did do a benchmark, and interestingly, ASCII text was about twice as fast with MultiByteToWideChar as with rust-native code; however, Chinese text was slightly slower. Given that most of the actual cost of printing to the screen is in the actual printing, I no longer think it's a good idea to do this.

See benchmarks at strega-nil/rust-bench-cvt-utf8-utf16.

Run on M1 chip:

test tests::ascii_windows_rust_equal ... ignored
test tests::chinese_windows_rust_equal ... ignored
test tests::bench_ascii_rust      ... bench:      32,544 ns/iter (+/- 2,549)
test tests::bench_ascii_windows   ... bench:      17,571 ns/iter (+/- 835)
test tests::bench_chinese_rust    ... bench:       7,710 ns/iter (+/- 561)
test tests::bench_chinese_windows ... bench:       8,556 ns/iter (+/- 669)

someone may want to check on an x64 chip, since that might be faster.

[the8472]

Just to check my understanding: The utf16 conversion only happens when one writes to an actually rendered console. There isn't some stuff like virtual consoles that act more like NUL where speeding up the conversion could help because the data will be discarded by the OS. And output to files is binary anyway.

[ChrisDenton]

There are now (since Windows 10, 1809) pseudo consoles which are consoles without the rendering part. Though the intent would be for the rendering to be implemented by another program, it would also be possible to skip or delay (e.g. by writing a log) rendering.

[the8472]

In that case a speedup may be useful, but is the optimization potential of the built-in conversion already squeezed dry?

[strega-nil-ms]

@the8472 yeah, I think it's unlikely that the added complexity is worth it given what the benchmarks show; I would really appreciate if someone ran the benchmark on x64, since it may be that Windows implements faster algorithms on that platform.

[ChrisDenton]

I don't think anyone has worked on optimizing this so I'm sure there's plenty of optimization potential. The results from I got from an AMD Ryzen 5 3600 machine are:

running 6 tests
test tests::ascii_windows_rust_equal ... ignored
test tests::chinese_windows_rust_equal ... ignored
test tests::bench_ascii_rust      ... bench:      19,443 ns/iter (+/- 244)
test tests::bench_ascii_windows   ... bench:       5,689 ns/iter (+/- 63)
test tests::bench_chinese_rust    ... bench:       8,925 ns/iter (+/- 107)
test tests::bench_chinese_windows ... bench:       8,065 ns/iter (+/- 214)

[strega-nil-ms]

Mmh, thanks @ChrisDenton! I'll also push some benchmarks for testing other cases later, since there are plenty of other cases than just "bulk-converting a bunch of text". Thanks!

Nicole