msvcrt - memmove/memcpy optimizations

[Zebediah Figura]

On 8/14/20 9:18 AM, Zebediah Figura wrote:
> On 8/14/20 3:27 AM, piotr at codeweavers.com wrote:
>> Hi Fabian,
>>
>> I'll be back from vacation on Monday (currently I have very limited
>> internet access). I'll look on it then.
>>
>> I'm not sure how complicated the assembly implementation is but I'm
>> expecting that a separated assembly file will not be needed. Also,
>> AFAIK, we can't take the implementation from glibc. It would be also
>> useful to know how efficient Microsoft implementation is.
> 
> I believe you are correct. I misread their licensing files and thought
> they used LGPL 2, not GPL 2.

As Henri points out, I am even more confused than that. The project uses
several licenses, so one must truly read the header of the file in question.

All of the x86_64 implementations of memmove(), at least, seem to be
under LGPL 2.1. Unless there's another, unrelated reason why we can't
use them?

> 
>>
>> Musl also have platform specific implementation of memove (for i386 and
>> x64) written is assembly. I bet it should be good enough for Wine.
>>
>> Thanks,
>> Piotr
>>
>> On Aug 12, 2020 23:33, Fabian Maurer <dark.shadow4 at web.de> wrote:
>>
>>     Hello,
>>
>>     since msvcrt isn't relying on the standard library memmove/memcpy
>>     anymore,
>>     there's been a pretty bad performance regression. See
>>     https://bugs.winehq.org/
>>     show_bug.cgi?id=49663.
>>
>>     For the best performance, and since those memory operations are
>>     pretty common,
>>     we'd presumably like to optimize them as much as possible. You might
>>     have seen
>>     my patch for an implementation from musl, although Zebediah
>>     rightfully pointed
>>     out we might want to opt for the best performance we can get...
>>     glibc currently offers the best performance, thanks to SSE/AVX
>>     implementations
>>     and runtime selection of the best supported path.
>>
>>     First, would you have any objections adding specialized paths
>>     written in
>>     assembly for x86?
>>     And if we were to add them, would we link against assembly files, or
>>     someway
>>     transform them into inline assembly? AFAIK, Wine didn't come with pure
>>     assembly files yet...
>>
>>     If you want, I could set up a few crude benchmarks to see how different
>>     versions compare.
>>
>>     Regards,
>>     Fabian Maurer
>>
>>
>>
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20200814/968f46b0/attachment-0001.sig>