That was an accidental push. I do think it would be best to remove this new feature completely, but of course I would have raised the issue before *intentionally* removing it. This is why I think thi
I wasn't clear sorry, is known to be broken in the native-comp branch. It tries to run the native compilation tests also when has no native compiler plus I think there are also few other failure I ha
Hi Adam, I took a look to the issue. I think issue reduces to: (defvar repro-xxx 123) (cl-eval-when (compile load eval) (defmacro repro-macro () "foo" repro-xxx) (repro-macro)) (provide 'repro) And t
The speedups are disappointing, but I'm not surprised: most byte-code operations end up calling non-trivial C functions. Maybe the results would be a bit more encouraging if you tried to compile lex
This would be quite similar to compiling to a primitive, where the arguments will have to be lexically scoped. It may show an improvement over the standard byte-code, but the lexbind byte-code may sh
Great news, thank you for working on this. Could you elaborate why this is an issue, and what exactly are the details that need to be adapted to a different setjmp implementation? Also, did you try
This could have issues with setjmp, I think. Yes, I know. But we need to support only the way we compile Emacs, right? Why do you need this? The following command will show you the full absolute fil
Yeah, I guess... The primary way Emacs is distributed is already-compiled, and these will presumably have .eln files pre-installed. I think it makes some sense in having the development version of Em
Hi all, this is just to mention that as part of the code review process was decided to change the configure flag used to configure the native compiler in the 'feature/native-comp' branch. As of 42fc7
So, there's 11s-12s of "interactive cost". I'm not sure what those 11s-12s come from, but I think it's safe to take the "1.9x" as the more relevant measure in terms of measuring the impact of native
Hi all, this is the usual update for the activity of the last 2/3 weeks on the native-comp branch. - I did some reorganization of the passes and reworked the allocation strategy for the relocable obj
For ELPA packages, this might make sense (even though, with your proposed scheme, one would have to reinstall all packages on an existing system to take advantage of native compilation, right?). But
I've got some time to repeat the measure trying to understand better what's going on. I've repeated the same test but running it 10 times. (benchmark 10 '(mapc #'byte-compile-file (directory-files "~
I still think we should adhere to the GNU Coding Standards (https://www.gnu.org/prep/standards/standards.html) in this case and use --enable- here (native compilation is a feature), not --with(there
libgccjit is an external package the same way libjansson is an external package (at least right now I don't know of a GNU/Linux distribution that ships libgccjit with their gcc package. I could be wr
The --with-SOMETHING options are not only for external packages. We have other similar configure-time options: --with-modules --with-threads --with-native-image-api --with-dumping --with-wide-int et
Hi Raman, I believe the last update here https://akrl.sdf.org should answer your questions on where the .eln are :) The compilation for packages is supposed to happen automatically, but if you really
I haven't tried to compile it with the 32-bit compiler. There are many ways to call setjmp() in Windows. It depends on the architecture, whether the Universal CRT is used, whether SEH is enabled, th
Wow these are very good results, it's interesting to collect feedback from real world scenarios, thanks. This is strange. The semantic of the native compiled code should be exactly the same of the by
The native compilation effort introduced earlier this year is archived at http://www.mundell.ukfsn.org/native. It can now compile all the byte codes. Here are three speed comparisons. The commas in t