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 <akrl@sdf.org> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Andrea Corallo <akrl@sdf.org>
> >> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> >> Date: Sat, 28 Dec 2019 08:56:17 +0000
> >>
> >> Eli Zaretskii <eliz@gnu.org> 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
>
> --
> akrl@sdf.org
>
>