From: "Brennan Vincent" <brennan@umanwizard.com>
To: Eli Zaretskii <eliz@gnu.org>, tomas@tuxteam.de
Cc: acorallo@gnu.org, stefankangas@gmail.com, emacs-devel@gnu.org
Subject: Re: [PATCH] Add a mechanism for passing unibyte strings from lisp to modules.
Date: Wed, 26 Jun 2024 23:36:16 -0400 [thread overview]
Message-ID: <87wmmbgiq7.fsf@taipei.mail-host-address-is-not-set> (raw)
In-Reply-To: <867ceb90qj.fsf@gnu.org>
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Wed, 26 Jun 2024 15:33:09 +0200
>> From: tomas@tuxteam.de
>> Cc: brennan@umanwizard.com, acorallo@gnu.org, stefankangas@gmail.com,
>> emacs-devel@gnu.org
>>
>> > > > How will it be different from the Lisp vectors we already have?
>> > >
>> > > The box around every byte.
>> >
>> > What box? Please tell more, as I don't think I follow.
>>
>> Maybe I'm all wrong, but AFAIU, a vector can contain arbitrary Lisp
>> values. That makes 64bits/8bits plus boxing/unboxing (which is, I
>> assume, quick, but nonzero).
>>
>> Having a specialized "array of bytes" (as there is one for bools)
>> might be beneficial for big arrays, and perhaps avoid big data moving
>> operations over the C/LISP fence.
>
> If you are saying that using 64-bit values there incurs a run-time
> performance penalty, then accessing bytes does that as well. Someone
> should profile this and present evidence wrt the relative performance
> of these, then we can discuss whether the penalty is real and whether
> it is worth adding yet another data type to Emacs.
Sure, I wrote a quick benchmark that passes a 10MB buffer to a module
which just sums the bytes and returns and integer. It is about 200x
faster using a unibyte string (with my original patch) than a vector.
C code:
// Compile with gcc -O3 -fPIC -shared -o test-module.so test.c
#include <emacs-module.h>
#include <stdlib.h>
int plugin_is_GPL_compatible;
static emacs_value
Fcall_test(emacs_env *env, ptrdiff_t nargs, emacs_value args[], void *) EMACS_NOEXCEPT
{
unsigned char sum = 0;
emacs_value vec = args[0];
size_t sz = env->vec_size(env, vec);
for (int i = 0; i < sz; ++i)
sum += env->extract_integer(env, env->vec_get(env, vec, i));
return env->make_integer(env, sum);
}
static emacs_value
Fcall_test2(emacs_env *env, ptrdiff_t nargs, emacs_value args[], void *) EMACS_NOEXCEPT
{
unsigned char sum = 0;
emacs_value arr = args[0];
char *buf;
ptrdiff_t sz = 0;
env->copy_unibyte_string_contents(env, arr, NULL, &sz);
buf = malloc(sz);
env->copy_unibyte_string_contents(env, arr, buf, &sz);
for (int i = 0; i < sz - 1; ++i)
sum += buf[i];
return env->make_integer(env, sum);
}
/* bind c_func (native) to e_func (elisp) */
static void
bind(emacs_env *env, emacs_value (*c_func) (emacs_env *env,
ptrdiff_t nargs,
emacs_value args[],
void *) EMACS_NOEXCEPT,
const char *e_func,
ptrdiff_t min_arity,
ptrdiff_t max_arity,
const char *doc,
void *data)
{
emacs_value fset_args[2];
fset_args[0] = env->intern(env, e_func);
fset_args[1] = env->make_function(env, min_arity, max_arity, c_func, doc, data);
env->funcall(env, env->intern(env, "fset"), 2, fset_args);
}
int
emacs_module_init(struct emacs_runtime *ert)
{
emacs_env *env = ert->get_environment(ert);
bind(env,
Fcall_test, "btv--test", 1, 1,
"test using vector",
NULL);
bind(env,
Fcall_test2, "btv--test2", 1, 1,
"test using byte array",
NULL);
emacs_value provide_arg = env->intern(env, "test-module");
env->funcall(env, env->intern(env, "provide"), 1, &provide_arg);
return 0;
}
Elisp code:
(require 'test-module)
(require 'benchmark)
(setq v (make-vector 10000001 37))
(setq v2 (make-string 10000001 37))
`(,(benchmark-elapse (btv--test v))
,(benchmark-elapse (btv--test2 v2)))
Result of evaluating elisp code:
(0.17861138 0.000805208)
next prev parent reply other threads:[~2024-06-27 3:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-21 18:13 [PATCH] Add a mechanism for passing unibyte strings from lisp to modules Brennan Vincent
2024-06-21 18:13 ` Brennan Vincent
2024-06-21 19:08 ` Eli Zaretskii
2024-06-21 20:14 ` Brennan Vincent
2024-06-22 6:50 ` Eli Zaretskii
[not found] ` <87o77t6lyn.fsf@taipei.mail-host-address-is-not-set>
2024-06-22 16:12 ` Eli Zaretskii
2024-06-23 21:15 ` Andrea Corallo
2024-06-24 11:45 ` Eli Zaretskii
2024-06-25 17:36 ` Brennan Vincent
2024-06-26 12:26 ` Eli Zaretskii
2024-06-26 12:39 ` tomas
2024-06-26 13:23 ` Eli Zaretskii
2024-06-26 13:33 ` tomas
2024-06-26 14:32 ` Brennan Vincent
2024-06-26 15:53 ` Eli Zaretskii
2024-06-26 15:34 ` Eli Zaretskii
2024-06-27 3:36 ` Brennan Vincent [this message]
2024-06-27 6:05 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wmmbgiq7.fsf@taipei.mail-host-address-is-not-set \
--to=brennan@umanwizard.com \
--cc=acorallo@gnu.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=stefankangas@gmail.com \
--cc=tomas@tuxteam.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.