[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shrinking the C core
|
From: |
Ihor Radchenko |
|
Subject: |
Re: Shrinking the C core |
|
Date: |
Sun, 20 Aug 2023 15:36:34 +0000 |
"Alfred M. Szmidt" <ams@gnu.org> writes:
> Please keep the CC intact, not everyone subscribed.
>
> > It should be quite obvious why SBCL is faster than the Emacs
> > Lisp VM (or even native). Just look at this call to (car
> > "foo"), and compare what happens in Emacs.
> >
> > * (disassemble 'foo)
> > ; disassembly for FOO
> > ; Size: 166 bytes. Origin: #x225D873F ; FOO
>> ...
> Okay?
>
> I guess that you do not understand the above? Or what? Do you know
> and understand what happens in Emacs when a similar call is done? It
> is far more than "166 bytes".
It would be helpful if you show us what happens in Elisp with a similar
call. Especially after native compilation.
I am asking genuinely because `car' (1) has dedicated opt code and thus
should be one of the best-optimized function calls on Elisp side; (2)
Fcar is nothing but
/* Take the car or cdr of something whose type is not known. */
INLINE Lisp_Object
CAR (Lisp_Object c)
{
if (CONSP (c))
return XCAR (c); // <- XCONS (c)->u.s.car
if (!NILP (c))
wrong_type_argument (Qlistp, c);
return Qnil;
}
So, it is a very simple example that can actually explain the basic
differences between Elisp and CL. It would be nice if you (considering
your low-level understanding) can provide us with an analysis of what is
different between Elisp and CL implementations of such a simple
function.
> This has literally nothing to do with the difference between static
> typing, and dynamic typing. The author, and you, have it completeley
> backwards ...
I am sorry, because it was my message that started the confusion.
I was mostly referring to separation between Elisp
interpreted/byte/native code and C subrs. AFAIU, static analysis info
cannot be passed between these two parts of Emacs runtime: subr cannot
know in advance what Lisp_Object type it is working on, even if static
analysis of the caller Elisp code has such information (e.g. from GCC
JIT compiler).
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
- Re: Shrinking the C core, (continued)
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/14
- Re: Shrinking the C core, Emanuel Berg, 2023/08/15
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/16
- Re: Shrinking the C core, Emanuel Berg, 2023/08/19
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/20
- Re: Shrinking the C core, Emanuel Berg, 2023/08/20
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/20
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/20
- Re: Shrinking the C core, Emanuel Berg, 2023/08/20
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/20
- Re: Shrinking the C core,
Ihor Radchenko <=
- Re: Shrinking the C core, Eli Zaretskii, 2023/08/20
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/20
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/20
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/20
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/20
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/20
- Re: Shrinking the C core, Alfred M. Szmidt, 2023/08/20
- Re: Shrinking the C core, Eli Zaretskii, 2023/08/20
- Re: Shrinking the C core, Emanuel Berg, 2023/08/27
- Re: Shrinking the C core, Ihor Radchenko, 2023/08/20