Re: More on Lisp structures performance
"Yuri Davidovsky (as work at disclosure dot ie)" <[email protected]>
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
> On 23 Jan 2026, at 17:24, David McClain <[email protected]> wrote: > > Wow!! Bravo !!! > > You did a magnificent job! Much appreciated, sir. Your praise does mean a lot to me. > But the conclusions leave me a bit unsettled. We actually haven’t gotten to proper conclusions yet, there is actually more to detangle, and I hope you will find it interesting too. > In effect we have to diddle a var at the beginning in hopes of keeping it assigned to a register. This is true, it does seem that in certain high performance requirements one needs to be mindful of what is actually present in the registers even while remaining in a high level language. > But we don’t have any real control over register spilling, do we? Not really, and I think no high level language does, including C. > What limits must we observe to ensure that the var remains in a register? Basically any situation where you repeatedly compare against a variable that does not change (or a constant) can end up like that. I think on ARM you can use 16 bit literals without having to fiddle with partial summations, but even then, if it gets inlined during the assembly macroexpand, it seems like you will likely end up with two operations instead of one: 1. First you will be writing a literal into a register. 2. Then you will do the actual compare. It will be done every time you revisit this comparison, by the look of it. I will do some more research on it when I get a chance, it looks like a subtle thing that one should be more aware of. > Or perhaps it all comes down to disassembly and double checking that we haven’t damaged our intent... That is really the only way to be sure. Is this a compiler bug? Not in a sense that it is going to bring down your app. Can it make life more difficult? It does seem so. I got lucky spotting it rather quickly, I can totally imagine one going around in circles for hours trying to tally the cycle counts and wondering why the algorithm is not running as fast as it should according to the estimates. _______________________________________________ Lisp Hug - the mailing list for LispWorks users [email protected] http://www.lispworks.com/support/lisp-hug.html