https://bugs.winehq.org/show_bug.cgi?id=56867
Bug ID: 56867 Summary: dynamic_cast too slow on wine compared to windows Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcp Assignee: wine-bugs@winehq.org Reporter: euloanty@live.com Distribution: ---
Herb Sutter said dynamic cast was using string comparison and now it is not. So the performance of dynamic cast becomes MUCH faster.
Same program with static link with microsoft's own library.
$ wine ./cout.exe coutfd:0.1162809s u=10000000
wine DLL implementation:
$ wine ./cout.exe coutfd:0.4995548s u=10000000
The overhead is 5x at least
https://bugs.winehq.org/show_bug.cgi?id=56867
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com --- Becomes much faster after msvc compiler changes, or because of what?
Source code for this benchmark would be interesting, and pre-built binaries too. What should be compared is the difference between wine and windows under same conditions, so statically linked binary on wine vs statically linked binary on windows, and so on. That's assuming benchmarks are measuring what there are supposed to.
https://bugs.winehq.org/show_bug.cgi?id=56867
--- Comment #2 from cqwrteur euloanty@live.com --- (In reply to Nikolay Sivov from comment #1)
Becomes much faster after msvc compiler changes, or because of what?
Source code for this benchmark would be interesting, and pre-built binaries too. What should be compared is the difference between wine and windows under same conditions, so statically linked binary on wine vs statically linked binary on windows, and so on. That's assuming benchmarks are measuring what there are supposed to.
https://github.com/trcrsired/fast_io/blob/master/benchmark/0018.get_fd/coutf...
This is to extract FILE* from C++'s std::cout
https://github.com/trcrsired/windows-msvc-sysroot
/* I am working on adding --sysroot toggle to clang */ Compile with clang --target=x86_64-windows -Iwindows-msvc-sysroot/include/c++/stl -Iwindows-msvc-sysroot/include -Lwindows-msvc-sysroot/x86_64-windows-msvc -Ofast
https://bugs.winehq.org/show_bug.cgi?id=56867
--- Comment #3 from cqwrteur euloanty@live.com --- Compile with clang --target=x86_64-windows -Iwindows-msvc-sysroot/include/c++/stl -Iwindows-msvc-sysroot/include -Lwindows-msvc-sysroot/x86_64-unknown-windows-msvc -Ofas
https://bugs.winehq.org/show_bug.cgi?id=56867
--- Comment #4 from cqwrteur euloanty@live.com --- dynamic cast is here
https://github.com/trcrsired/fast_io/blob/742950421eedc149585122059cd8196545...
Wine source shows it does strcmp which is slow. Microsoft has changed the implementation to not be strcmp-ed. Though i do not know how they've done it.
https://github.com/wine-mirror/wine/blob/f9af971bd7d6799d54436ba9f7fa327b7ed...
https://bugs.winehq.org/show_bug.cgi?id=56867
--- Comment #5 from cqwrteur euloanty@live.com --- (In reply to cqwrteur from comment #4)
dynamic cast is here
https://github.com/trcrsired/fast_io/blob/ 742950421eedc149585122059cd8196545e28dac/include/fast_io_legacy_impl/filebuf/ fp_hack/msvc_stl.h#L84
Wine source shows it does strcmp which is slow. Microsoft has changed the implementation to not be strcmp-ed. Though i do not know how they've done it.
https://github.com/wine-mirror/wine/blob/ f9af971bd7d6799d54436ba9f7fa327b7edfbc77/dlls/msvcrt/cpp.c#L819
https://youtu.be/ARYP83yNAWk?si=D0GjCDbYwLeEXW_1&t=4473
Herb Sutter (Microsoft VC Team Lead) said, "We know Microsoft did string comparison; we are fixing that."
https://bugs.winehq.org/show_bug.cgi?id=56867
cqwrteur euloanty@live.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
--- Comment #6 from cqwrteur euloanty@live.com --- I got the same result on windows. so it is my fault.
https://bugs.winehq.org/show_bug.cgi?id=56867
--- Comment #7 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=56867
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Austin English austinenglish@gmail.com --- Actually closing.