Re: freeze for sbcl-2.6.8

arthur miller <[email protected]>
Newsgroups gmane.lisp.steel-bank.devel
Message-ID <VI1PR09MB24962426E1EA41052821DB2C96A22@VI1PR09MB2496.eurprd09.prod.outlook.com>
Of course it is not, and that wasn't what I said either. I just asked a simple question,
so I know if I should spend time on something or not. Xsavec has been out for 10
years, so I am sure you and other people here are aware of it.

Just asking if it is not in SBCL because nobody had time or interest
to add it or if there is some technical reason why it is not in use, that is all. Sorry, if I
bother with a regression, was just a curious question that popped on my mind.
________________________________
Från: Stas Boukarev <[email protected]>
Skickat: den 22 augusti 2026 22:41
Till: arthur miller <[email protected]>
Kopia: [email protected] <[email protected]>
Ämne: Re: [Sbcl-devel] freeze for sbcl-2.6.8

xsavec is not synonymous to avx2.



On Sat, Aug 22, 2026 at 11:35 PM arthur miller <[email protected]> wrote:
>
> Yeah of course, I understand; the question was out of context and not framed well.
>
> If I frame it like this: is there a technical reason to not use xsavec/xsaves/xrestors
> in SBCL instead of xstore/xrstor? Or is it not in there just because it is not done yet.
>
> Not for this particular case, it is a regression, but wonder if it is something for a future
> patch or not? Should have ask back whan I was working on zmm support, but than it
> was a bit too much other stuff.
> ________________________________
> Från: Stas Boukarev <[email protected]>
> Skickat: den 22 augusti 2026 22:19
> Till: arthur miller <[email protected]>
> Kopia: Douglas Katzman <[email protected]>; Christophe Rhodes <[email protected]>; [email protected] <[email protected]>
> Ämne: Re: [Sbcl-devel] freeze for sbcl-2.6.8
>
> xsave (for avx512) isn't invoked unless avx512 registers are used
> within a function. So, xsavec isn't going to improve anything.
>
> On Sat, Aug 22, 2026 at 11:02 PM arthur miller <[email protected]> wrote:
> >
> > Forgive me for chimming in, but a question, since you are already
> > talking about xstore/xrstor and want more performance. Can we switch to
> > "compact" versions of those (xsavec & co)? These, potentially
> > write/restore less data, in cases where saving/restoring xmm/ymm/zmm is
> > enabled.
> >
> > I learned about it when I was patching for zmm. I didn't dare to try
> > to change that, but instead patched in support to what was already in.
> >
> > As I understand it, when full store is needed (zmm registers in use),
> > than the performance is roughly the same, but if zmm/ymm/xmm regs do not
> > need to be saved becuase they weren't written since the last clear, they
> > won't be saved either.
> >
> > Compacted stores/restores are supported on Linux since kernel 4.4, year
> > 2016, and on Windows since version 10 some release number in 2015.
> > ________________________________
> > Från: Douglas Katzman via Sbcl-devel <[email protected]>
> > Skickat: den 22 augusti 2026 18:07
> > Till: Stas Boukarev <[email protected]>
> > Kopia: Christophe Rhodes <[email protected]>; [email protected] <[email protected]>
> > Ämne: Re: [Sbcl-devel] freeze for sbcl-2.6.8
> >
> > 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.