Checking the build instructions once again for MPS it really strongly suggests that `mps.c` is _included_ into your object format source file for best performance/optimisation, this likely has issues for the cool/debug configuration

at the very least, importing source into the emacs repo (similar to gnulib ) would allow some forms of LTO to take place.

FWIW I have been using a pgtk+nativecomp build occasionally synced to master without issue for the last week or 2.

It feels faster, but my comparison is a main build on a different OS with different computers, so it's not a reasonable comparison.

"start-up/init.el drag racing" does show mps to be reliably quicker for my own config, but again not really a test.

On Wed, Nov 27, 2024 at 9:45 PM Andrea Corallo <acorallo@gnu.org> wrote:

Vincenzo Pupillo <v.pupillo@gmail.com> writes:

> In data mercoledì 27 novembre 2024 10:26:40 Ora standard dell’Europa centrale, Andrea Corallo ha scritto:
>> Gregor Zattler <telegraph@gmx.net> writes:
>>
>> > Dear Andrea, Gerd, ...
>> > * Andrea Corallo <acorallo@gnu.org> [2024-11-27; 03:52 -05]:
>> >> Sure if it's of interest: my idea of few things that helped a lot native
>> >> comp in gaining traction at time:
>> >>
>> >> - publishing simple blog posts summarizing and explaining the progresses
>> >> of the branch [1]
>> >
>> > Data Point: That got me interested.
>> > There were progress updates, so I
>> > visited the age rather often.
>> >
>> >> - native-comp being a feature branch, this clarified that the goal was
>> >> merging to master (IOW something which was probably likely to happen)
>> >> and that the branch was trackable by users. That's why I suggested
>> >> more than once this solution in the past.
>> >
>> > That and the instructions on how to use
>> > it motivated me to try out.
>> >
>> > In case of igc detailed build
>> > instructions would be needed (for me at least).
>>
>> Yeah that's a great point! For me building igc was not trivial. MPS
>> doesn't come with distros and the experience of compiling it from source
>> wasn't great, the instructions in the codebase were conflicting plus I
>> had to manually patch the codebase as OOB was not compiling. Finally
>> Emacs has to find it during compilation, otherwise I think it will
>> silently revert to the standard GC even if configured for it.
>>
>> Maybe some of this is fixed now I'm not sure, but these are all hard
>> barriers for users, clear and detailed instructions would be much needed
>> for a more spread use of it.
>
> Wouldn't it perhaps be better to clone mps to savannah (with our patches) and add it as a sub-module to emacs?
> Then initialize it if 'configure' is invoked with the --with-mps switch.
> If it were to become such a fundamental piece of emacs perhaps it would be better to be more independent.

If we decide MPS needs to be forked I think would be more convenient to
have it directly inside the Emacs tree.

BTW, I think if the user explicitly uses --with-mps the configuration
should fail if MPS is not available.

Andrea