Re: freeze for sbcl-2.6.8

Sure, vmovaps might be faster in that place, but then everything will
be tainted by touching the high bits of ymm, and any use of sse2 will
transition back-and-forth between states, killing performance. Hence
why it uses xsave in the first place.
Saving ymm might work if it does the same thing as is currently done
for avx512, i.e. not touching them until used. But there's a lot of
routine explosions because of that (might also avoid saving xmm),
maybe some parameters instead of dedicated entry points.

As for the patch, it's hard for me to review it, lots of matching
between things to perform, but I suppose if it runs, it's hard to go
far with this stuff being wrong.
I don't lean one way or another on when to commit it.

On Sat, Aug 22, 2026 at 7:07 PM Douglas Katzman <[email protected]> wrote:
>
> I have the fix for that crash.   I mistakenly thought that FPR-SAVE/FPR-RESTORE no longer need to preserve RDX when using XRSTOR but they still do - but only for #+win32, so I'll add that.
> However, Gemini claims the following theoretical performance gain by simply avoiding XSAVE/XRSTOR entirely in the YMM case (not the avx512 of course) which is a very interesting point -
>
> ~4x Faster: 16 * VMOVAPS runs in ~15–20 cycles vs 80+ cycles for XSAVE/XRSTOR.
>
> Do you think I can commit this register changing patch + its fix for now, and we'll leave the above suggestion for next release (despite also being a valid fix for my crash) ?


_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel