<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 3, 2022, 11:36 AM Elaine Lefler <<a href="mailto:elaineclefler@gmail.com" target="_blank" rel="noreferrer">elaineclefler@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Apr 2, 2022 at 4:51 AM Jin-oh Kang <<a href="mailto:jinoh.kang.kr@gmail.com" rel="noreferrer noreferrer" target="_blank">jinoh.kang.kr@gmail.com</a>> wrote:<br>
><br>
> Wouldn't it make much more sense if we simply copied optimized copy routines from other libc implementations? They have specialised implementations for various architectures and microarchitectures (e.g. cache line size), not to mention the performance enhancements that have accumulated over time.<br>
<br>
I think this is a really good point.<br>
<br>
><br>
> Another option is to just call system libc routines directly, although in this case it might interfere with stack unwinding, clear PE/unix separation, and msvcrt hotpatching.<br>
><br>
<br>
Also a good idea, but the problem is that Windows dlls expect Windows<br>
calling conventions. There's no way (at least none I can immediately<br>
find) of wrapping a call to the system library without crashing.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It should of course move around argument registers and deal with caller/callee-saved registers; this is implied in "some ABI adaptations, such as calling convention adjustment and SEH."</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Sat, Apr 2, 2022 at 5:19 AM Rémi Bernon <<a href="mailto:rbernon@codeweavers.com" rel="noreferrer noreferrer" target="_blank">rbernon@codeweavers.com</a>> wrote:<br>
><br>
> Calling the system libc will need a "syscall", and will most likely<br>
> defeat any performance improvement it could bring.<br>
<br>
I don't think that works either, since these functions live in an .so<br>
and not in the kernel. Now, if it were possible, the system libraries<br>
are _significantly_ faster than anything Wine offers (even with SSE2<br>
optimizations), so I think their raw speed would make up for any<br>
overhead.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It's not a real syscall per se; rather, it's more like a gate between the PE side (corresponding to Windows userspace) and the Unix side (Wine's pseudo kernel space which interacts directly with the host OS). The PE/Unix separation is designed so that every interaction with the system goes to the syscall gate, just like on Windows (we're not there yet, but we'll eventually). This helps satisfy video game anti-cheat technologies and conceal the Unix (.so) code which would otherwise cause confusion for Win32 apps and debuggers tracing the execution path.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Sat, Apr 2, 2022 at 7:24 AM Jinoh Kang <<a href="mailto:jinoh.kang.kr@gmail.com" rel="noreferrer noreferrer" target="_blank">jinoh.kang.kr@gmail.com</a>> wrote:<br>
><br>
> As long as correctness and (any sort of) performance advantages are preserved, no further maintenance effort would be _strictly_ necessary.<br>
><br>
<br>
Agree with this. It's not terribly difficult to prove their<br>
correctness. Once that's done you should never need to update them. A<br>
new architecture might introduce instructions that are even more<br>
performant, but I don't think it's conceivable that vector<br>
instructions would ever become slower than non-vectors. Doing so would<br>
cripple ~15 years of software development, nobody would buy a CPU that<br>
does that.<br>
<br>
Here's how I see it: vector instructions were created specifically to<br>
solve this problem of operating on large regions of memory very<br>
quickly. Nearly every other program with similar requirements is<br>
either 1) Using these instructions, or 2) Relying on an external<br>
library that does so (note: that library is often msvcrt!). So I think<br>
Wine should do one of those two as well.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Also worth noting is that Wine already does it, with SSE2 memcpy and etc..</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Sat, Apr 2, 2022 at 8:59 AM Piotr Caban <<a href="mailto:piotr.caban@gmail.com" rel="noreferrer noreferrer" target="_blank">piotr.caban@gmail.com</a>> wrote:<br>
><br>
> On 4/2/22 13:19, Rémi Bernon wrote:<br>
> > (I personally, believe that the efficient C implementation should come<br>
> > first, so that any non-supported hardware will at least benefit from it)<br>
> I also think that it will be good to add more efficient C implementation<br>
> first (it will also show if SSE2 implementation is really needed).<br>
><br>
> Thanks,<br>
> Piotr<br>
><br>
<br>
I can't speak definitively, because it looks a little different for<br>
every function. But, overwhelmingly, my experience has been that<br>
nothing will run measurably faster than byte-by-byte functions without<br>
using vector instructions. Because the bottleneck isn't CPU power, the<br>
bottleneck is memory access.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">It should be.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Like I said, vectors were created<br>
specifically to solve this problem, and IME you won't find notable<br>
performance gains without using them.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I think Rémi is aware of that. However, optimization on C implementation is arguably much more universally applicable to a broader range of (micro-)architectures.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Now, we CAN use #ifdefs and preprocessor macros to define a fake<br>
__m128i on systems that don't natively support it. Then write<br>
emulation for each operation so that GCC can compile real vector<br>
instructions when possible (x86-64) and fallback to smaller types on<br>
systems without vector support. That way we'd avoid large<br>
vendor-specific code blocks. But you're not going to escape this idea<br>
of "we need to read large chunks and operate on them all at once".<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">What you're thinking of is a SIMD abstraction library. I don't see how it would be highly necessary, since we're okay with vendor-specific code blocks as long as they are justified. Note that we now only support 4 architectures (IA-32, x86-64, ARM AArch32, and ARM AArch64).</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Personally I think Jinoh's suggestion to find a compatible-licensed<br>
library and copy their code is best. Otherwise I sense this will<br>
become an endless circle of "do we really need it?" (yes, but this<br>
type of code is annoying to review) and Wine could benefit from using<br>
an implementation that's already widely-tested.<br>
<br>
- Elaine<br>
</blockquote></div></div></div>