emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On elisp running native


From: yyoncho
Subject: Re: On elisp running native
Date: Tue, 25 Feb 2020 08:14:02 +0200

Hi,

I did benchmarks of json parsing here it is what I get:

  | test         | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) |
  |--------------+----------------+------------+---------+-------------+-----------------|
  | json-parsing |           2.57 |       3.32 |     318 |        5.89 |            0.10 |
  |--------------+----------------+------------+---------+-------------+-----------------|
  | total        |           2.57 |       3.32 |     318 |        5.89 |            0.10 |


Native:

  | test         | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) |
  |--------------+----------------+------------+---------+-------------+-----------------|
  | json-parsing |           1.71 |       4.31 |     343 |        6.02 |            0.01 |
  |--------------+----------------+------------+---------+-------------+-----------------|
  | total        |           1.71 |       4.31 |     343 |        6.02 |            0.01 |

It looks like this is bellow the average speedup you might wanna take a look:

Here it is the benchmark code:

(require 'cl-lib)
(require 'json)

(defvar json-parsing-input (with-temp-buffer
    (insert-file-contents-literally  "benchmarks/sample.json")
    (buffer-string)))


(defun elb-json-parsing-entry ()
  (cl-loop repeat 1000
  do (json-read-from-string json-parsing-input)))

Thanks,
Ivan

On Tue, Feb 25, 2020 at 1:21 AM Andrea Corallo <address@hidden> wrote:
Eli Zaretskii <address@hidden> writes:

>> From: Andrea Corallo <address@hidden>
>> Cc: address@hidden, address@hidden
>> Date: Sat, 28 Dec 2019 08:56:17 +0000
>>
>> Eli Zaretskii <address@hidden> writes:
>>
>> > I'm not sure I understood you, but dlopen, dlsym etc. (or their moral
>> > equivalents) are readily available on Windows; see src/dynlib.c.  So
>> > that cannot be the reason why libgccjit is not available on Windows.
>>
>> Sure, but libgccjit AFAIU just calls directly dlopen
>> (gcc/gcc/jit/jit-playback.c:2650).
>
> That's OK.  One of the MinGW flavors actually provides these functions
> directly; for the other it should be easy to write them so that
> libgccjit can call them.
>
>> I've just found this interesting old thread:
>>
>> https://gcc.gnu.org/ml/jit/2015-q3/msg00124.html
>
> Thanks.  Not sure what to make from that, especially since AFAIK the
> Windows code is PIC by default.  The problems they are talking about
> are very easy to solve, but somehow no one has yet solved them.  Which
> might mean there's more to it than meets the eye.  (However, I'm
> talking out of sheer ignorance, so perhaps you should ask on the GCC
> list whether there are any fundamental problems with providing
> libgccjit on Windows.)

I just bumped in this Chinese blog where the guy apparently is running
the native-comp branch on Windows 10 using mingw64:

http://www.albertzhou.net/blog/2020/01/emacs-native-comp.html

To a quick look in libgccjit he had to modify the dlopen&friends part
and added some handling for temporary files.  In Emacs comp.c code he
touched some setjmp code.

I know zero about Windows but this should help answering the question if
this port is possible and what's roughly the effort.

Andrea

--
address@hidden


reply via email to

[Prev in Thread] Current Thread [Next in Thread]