Modules: definition of emacs_value

Modules: definition of emacs_value

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 253 bytes --]

Is it a strict requirement that emacs_value be a pointer? If not, couldn't
we simply define it as int64 and assume that that will be large enough to
hold a Lisp_Object for the foreseeable future? Or do we expect Lisp_Object
to ever grow beyond 64 bits?

[-- Attachment #2: Type: text/html, Size: 279 bytes --]

Re: Modules: definition of emacs_value

[Daniel Colascione]

[-- Attachment #1.1: Type: text/plain, Size: 590 bytes --]

On 02/29/2016 03:03 PM, Philipp Stephani wrote:
> Is it a strict requirement that emacs_value be a pointer? If not,
> couldn't we simply define it as int64 and assume that that will be large
> enough to hold a Lisp_Object for the foreseeable future? Or do we expect
> Lisp_Object to ever grow beyond 64 bits?

I don't like giving users raw Lisp_Objects. I really don't like making
32-bit callers cope with 64-bit values. If emacs_value is a pointer, we
have complete freedom with respect to runtime behavior. Putting a
Lisp_Object directly in an emacs_value is a false economy.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Modules: definition of emacs_value

[Stefan Monnier]

> I don't like giving users raw Lisp_Objects.  I really don't like making
> 32-bit callers cope with 64-bit values.  If emacs_value is a pointer, we
> have complete freedom with respect to runtime behavior.  Putting a
> Lisp_Object directly in an emacs_value is a false economy.

This assumes that the performance cost of the API is negligible.
Currently, the performance already sucks rocks because of all the extra
condition-case going on (thanks to your lobbying), but I don't think we
should add insult to injury.


        Stefan

Re: Modules: definition of emacs_value

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> schrieb am Mi., 2. März 2016 um
15:37 Uhr:

> > I don't like giving users raw Lisp_Objects.  I really don't like making
> > 32-bit callers cope with 64-bit values.  If emacs_value is a pointer, we
> > have complete freedom with respect to runtime behavior.  Putting a
> > Lisp_Object directly in an emacs_value is a false economy.
>
> This assumes that the performance cost of the API is negligible.
> Currently, the performance already sucks rocks because of all the extra
> condition-case going on (thanks to your lobbying), but I don't think we
> should add insult to injury.
>
>
Is this just speculation, or do you have actual benchmarks?

[-- Attachment #2: Type: text/html, Size: 1023 bytes --]

Re: Modules: definition of emacs_value

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

Daniel Colascione <dancol@dancol.org> schrieb am Di., 1. März 2016 um
00:15 Uhr:

> On 02/29/2016 03:03 PM, Philipp Stephani wrote:
> > Is it a strict requirement that emacs_value be a pointer? If not,
> > couldn't we simply define it as int64 and assume that that will be large
> > enough to hold a Lisp_Object for the foreseeable future? Or do we expect
> > Lisp_Object to ever grow beyond 64 bits?
>
> I don't like giving users raw Lisp_Objects.


But we are already doing that in most cases (64-bit pointers and
Lisp_Objects): the pointer is not a real pointer, just a Lisp_Object cast
to a pointer type.


> I really don't like making
> 32-bit callers cope with 64-bit values.


It's been a while since I did 32-bit programming, but what issues could
arise? We're not doing any arithmetic or other processing on the values,
just passing them around.


> If emacs_value is a pointer, we
> have complete freedom with respect to runtime behavior. Putting a
> Lisp_Object directly in an emacs_value is a false economy.
>

As said above, we're already doing that.

[-- Attachment #2: Type: text/html, Size: 1694 bytes --]

Re: Modules: definition of emacs_value

[Daniel Colascione]

[-- Attachment #1.1: Type: text/plain, Size: 830 bytes --]

On 03/02/2016 10:30 AM, Philipp Stephani wrote:
> 
> 
> Daniel Colascione <dancol@dancol.org <mailto:dancol@dancol.org>> schrieb
> am Di., 1. März 2016 um 00:15 Uhr:
> 
>     On 02/29/2016 03:03 PM, Philipp Stephani wrote:
>     > Is it a strict requirement that emacs_value be a pointer? If not,
>     > couldn't we simply define it as int64 and assume that that will be
>     large
>     > enough to hold a Lisp_Object for the foreseeable future? Or do we
>     expect
>     > Lisp_Object to ever grow beyond 64 bits?
> 
>     I don't like giving users raw Lisp_Objects. 
> 
> 
> But we are already doing that in most cases (64-bit pointers and
> Lisp_Objects): the pointer is not a real pointer, just a Lisp_Object
> cast to a pointer type.

I know, and I don't like it. I wish it were a real pointer.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Modules: definition of emacs_value

[Stefan Monnier]

> Is this just speculation, or do you have actual benchmarks?

Neither.  Just like Elisp's slowness is rarely seen in practice, I don't
expect this API's slowness to be seen in practice.  Instead, it will
change the kind of module that can be realistically defined (i.e. only
those where the cost of the API itself is not a problem).

The main problem for me is that this cost comes with only
hypothetical benefits.


        Stefan

Re: Modules: definition of emacs_value

[John Wiegley]

>>>>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Just like Elisp's slowness is rarely seen in practice

I guess you've never asked Gnus to thread 8000 past news articles before.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Modules: definition of emacs_value

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

Daniel Colascione <dancol@dancol.org> schrieb am Mi., 2. März 2016 um
21:14 Uhr:

> On 03/02/2016 10:30 AM, Philipp Stephani wrote:
> >
> >
> > Daniel Colascione <dancol@dancol.org <mailto:dancol@dancol.org>> schrieb
> > am Di., 1. März 2016 um 00:15 Uhr:
> >
> >     On 02/29/2016 03:03 PM, Philipp Stephani wrote:
> >     > Is it a strict requirement that emacs_value be a pointer? If not,
> >     > couldn't we simply define it as int64 and assume that that will be
> >     large
> >     > enough to hold a Lisp_Object for the foreseeable future? Or do we
> >     expect
> >     > Lisp_Object to ever grow beyond 64 bits?
> >
> >     I don't like giving users raw Lisp_Objects.
> >
> >
> > But we are already doing that in most cases (64-bit pointers and
> > Lisp_Objects): the pointer is not a real pointer, just a Lisp_Object
> > cast to a pointer type.
>
> I know, and I don't like it. I wish it were a real pointer.
>
>
Me too, but the chance to get that changed seems rather minimal.
Given that, we currently have the worst of both worlds: emacs_value is not
a real pointer, but still bound by the size of a pointer. Since we won't be
able to change emacs_value any more once 25.1 is released, now is the last
chance to get its definition changed.

[-- Attachment #2: Type: text/html, Size: 1839 bytes --]