Q: What is default architecture for code produced by native compiler?

Q: What is default architecture for code produced by native compiler?

[Arthur Miller]

Just wonder, is it generic x86 or something later or does it uses
native for architecture and cpu flags (-march=native and -mcpu=native)?

If it is generic, do we have option to pass in arch and cpu flags?

Thanks in advance for answer!

Re: Q: What is default architecture for code produced by native compiler?

[Andrea Corallo via Emacs development discussions.]

Arthur Miller <arthur.miller@live.com> writes:

> Just wonder, is it generic x86 or something later or does it uses
> native for architecture and cpu flags (-march=native and -mcpu=native)?

I'd say is GCC's default.

> If it is generic, do we have option to pass in arch and cpu flags?

No we don't, even if we could expose it using
'gcc_jit_context_add_command_line_option' for non obsolete versions of
GCC.

Regards

  Andrea

Re: Q: What is default architecture for code produced by native compiler?

[Arthur Miller]

Andrea Corallo <akrl@sdf.org> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Just wonder, is it generic x86 or something later or does it uses
>> native for architecture and cpu flags (-march=native and -mcpu=native)?
>
> I'd say is GCC's default.

Yes, I see. The default is generic.

$ echo | gcc -v -E - 2>&1 | grep cc1
 /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/cc1 -E -quiet -v - -mtune=generic -march=x86-64 -dumpbase -

I am not sure what "generic" cpu boils down to on intel, but I would of course
prefer to generate code for my cpu (skylake) if possible.

>> If it is generic, do we have option to pass in arch and cpu flags?
>
> No we don't, even if we could expose it using
> 'gcc_jit_context_add_command_line_option' for non obsolete versions of
> GCC.

Allright, is there any interest to expose this? :-)

We could have a defcustom in comp.el, either some boolean like:
"native-comp-prefer-host-cpu"

or maybe a string like: "native-comp-compiler-options" but that is maybe too
wide? I don't know how resilient is native comp to various opt flags, is it very
picky which are used, or anything gcc can take works?

I have never looked at native branch code, so I am not sure how it works, but
grep tells me that this function were fun happens is comp--compile-ctxt-to-file,
would that be the only one I need to hack?

To be honest, I have no idea if there is much if anything to win in speed in elisp context,
between generic and skylake, but I have to try :).

> Regards
>
>   Andrea
Thanks for very fast answer!

best regards
/a

Re: Q: What is default architecture for code produced by native compiler?

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Wed, 25 Aug 2021 03:13:49 +0200
> Cc: emacs-devel@gnu.org
> 
> >> If it is generic, do we have option to pass in arch and cpu flags?
> >
> > No we don't, even if we could expose it using
> > 'gcc_jit_context_add_command_line_option' for non obsolete versions of
> > GCC.
> 
> Allright, is there any interest to expose this? :-)
> 
> We could have a defcustom in comp.el, either some boolean like:
> "native-comp-prefer-host-cpu"

What's wrong with using native-comp-driver-options?

I'm also curious why you want to mess with that.  Do you use the
equivalent GCC switches when compiling Emacs?  If so, why?

> To be honest, I have no idea if there is much if anything to win in speed in elisp context,
> between generic and skylake

My guess would be nothing.  And if you want to try that, I'd first
suggest trying that when building some program with GCC.

Re: Q: What is default architecture for code produced by native compiler?

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Wed, 25 Aug 2021 03:13:49 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> >> If it is generic, do we have option to pass in arch and cpu flags?
>> >
>> > No we don't, even if we could expose it using
>> > 'gcc_jit_context_add_command_line_option' for non obsolete versions of
>> > GCC.
>> 
>> Allright, is there any interest to expose this? :-)
>> 
>> We could have a defcustom in comp.el, either some boolean like:
>> "native-comp-prefer-host-cpu"
>
> What's wrong with using native-comp-driver-options?
>
> I'm also curious why you want to mess with that.  Do you use the
> equivalent GCC switches when compiling Emacs?  If so, why?
Yes, I do, I compile Emacs with -O3 -march=native and -mcpu=native

Hopefully gcc will emit some AVX instructions where possible. I haven't
dissasembled Emacs binary so I don't know how big is difference between generic
and native.

>> To be honest, I have no idea if there is much if anything to win in speed in elisp context,
>> between generic and skylake
>
> My guess would be nothing.

Probably. Depends on the problem and data I guess.

Re: Q: What is default architecture for code produced by native compiler?

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: akrl@sdf.org,  emacs-devel@gnu.org
> Date: Thu, 26 Aug 2021 01:26:30 +0200
> 
> > I'm also curious why you want to mess with that.  Do you use the
> > equivalent GCC switches when compiling Emacs?  If so, why?
> Yes, I do, I compile Emacs with -O3 -march=native and -mcpu=native
> 
> Hopefully gcc will emit some AVX instructions where possible. I haven't
> dissasembled Emacs binary so I don't know how big is difference between generic
> and native.

Well, I suggest that you do look into the differences between the
produced code, and try to measure the effect on the speed of Emacs.

Btw, -O3 is not recommended, as it frequently produces a slower Emacs.

Re: Q: What is default architecture for code produced by native compiler?

[martin rudalics]

 > Btw, -O3 is not recommended, as it frequently produces a slower Emacs.

Where do we say that?  INSTALL has

Here's an example of a 'configure' invocation, assuming a Bourne-like
shell such as Bash, which uses these variables:

   ./configure \
     CPPFLAGS='-I/foo/myinclude' LDFLAGS='-L/bar/mylib' \
     CFLAGS='-O3' LIBS='-lfoo -lbar'

(this is all one shell command).  This tells 'configure' to instruct the
preprocessor to look in the '/foo/myinclude' directory for header
files (in addition to the standard directories), instruct the linker
to look in '/bar/mylib' for libraries, pass the -O3 optimization
switch to the compiler, and link against libfoo and libbar
libraries in addition to the standard ones.

martin

Re: Q: What is default architecture for code produced by native compiler?

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, akrl@sdf.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 26 Aug 2021 10:02:16 +0200
> 
>  > Btw, -O3 is not recommended, as it frequently produces a slower Emacs.
> 
> Where do we say that?

I don't think we do.  It's my personal recommendation, disregard it at
will.

> INSTALL has
> 
> Here's an example of a 'configure' invocation, assuming a Bourne-like
> shell such as Bash, which uses these variables:
> 
>    ./configure \
>      CPPFLAGS='-I/foo/myinclude' LDFLAGS='-L/bar/mylib' \
>      CFLAGS='-O3' LIBS='-lfoo -lbar'

It's just an example, buried deep in a file that I doubt many people
read.  But feel free to use -Og or -Os there, if you think people
could draw some unwanted conclusions from that example.

Re: Q: What is default architecture for code produced by native compiler?

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org, akrl@sdf.org
>> From: martin rudalics <rudalics@gmx.at>
>> Date: Thu, 26 Aug 2021 10:02:16 +0200
>> 
>>  > Btw, -O3 is not recommended, as it frequently produces a slower Emacs.
>> 
>> Where do we say that?
>
> I don't think we do.  It's my personal recommendation, disregard it at
> will.
I have learned that most of your personal suggestions are very sane, so I would
be interested to learn more. If you can recommend some good benchmark I would be
interested to do comparisons. I am not sure how to test it myself.

I used to compile with -Ofast and some simd parallel flags; I had to turn off
some precies math and so, and I have seen it used to link with simd inabled libs
for strcopy and some other, but I don't know how  much impact it has.

>> INSTALL has
>> 
>> Here's an example of a 'configure' invocation, assuming a Bourne-like
>> shell such as Bash, which uses these variables:
>> 
>>    ./configure \
>>      CPPFLAGS='-I/foo/myinclude' LDFLAGS='-L/bar/mylib' \
>>      CFLAGS='-O3' LIBS='-lfoo -lbar'
>
> It's just an example, buried deep in a file that I doubt many people
> read.  But feel free to use -Og or -Os there, if you think people
> could draw some unwanted conclusions from that example.

I never saw that either, I just am aware that I can pass compiler flags to
configure script. 

Re: Q: What is default architecture for code produced by native compiler?

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: martin rudalics <rudalics@gmx.at>,  emacs-devel@gnu.org,  akrl@sdf.org
> Date: Thu, 26 Aug 2021 18:02:55 +0200
> 
> I have learned that most of your personal suggestions are very sane, so I would
> be interested to learn more. If you can recommend some good benchmark I would be
> interested to do comparisons. I am not sure how to test it myself.

Well, there is the scroll-through-xdisp.c benchmark we frequently see
on this list, so maybe try that.  Assuming that scrolling speed
matters to you, that is.

Another possibility is to time byte-compilation of a large enough
file.

Re: Q: What is default architecture for code produced by native compiler?

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: martin rudalics <rudalics@gmx.at>,  emacs-devel@gnu.org,  akrl@sdf.org
>> Date: Thu, 26 Aug 2021 18:02:55 +0200
>> 
>> I have learned that most of your personal suggestions are very sane, so I would
>> be interested to learn more. If you can recommend some good benchmark I would be
>> interested to do comparisons. I am not sure how to test it myself.
>
> Well, there is the scroll-through-xdisp.c benchmark we frequently see
> on this list, so maybe try that.  Assuming that scrolling speed
> matters to you, that is.
>
> Another possibility is to time byte-compilation of a large enough
> file.

I could test that with byte compilation. Thanks for the hints.

Re: Q: What is default architecture for code produced by native compiler?

[Arthur Miller]

martin rudalics <rudalics@gmx.at> writes:

>> Btw, -O3 is not recommended, as it frequently produces a slower Emacs.
>
> Where do we say that?  INSTALL has
>
> Here's an example of a 'configure' invocation, assuming a Bourne-like
> shell such as Bash, which uses these variables:
>
>   ./configure \
>     CPPFLAGS='-I/foo/myinclude' LDFLAGS='-L/bar/mylib' \
>     CFLAGS='-O3' LIBS='-lfoo -lbar'
>
> (this is all one shell command).  This tells 'configure' to instruct the
> preprocessor to look in the '/foo/myinclude' directory for header
> files (in addition to the standard directories), instruct the linker
> to look in '/bar/mylib' for libraries, pass the -O3 optimization
> switch to the compiler, and link against libfoo and libbar
> libraries in addition to the standard ones.
>
> martin

Yes I pass my compiler flags to configure script that way.

Re: Q: What is default architecture for code produced by native compiler?

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: akrl@sdf.org,  emacs-devel@gnu.org
>> Date: Thu, 26 Aug 2021 01:26:30 +0200
>> 
>> > I'm also curious why you want to mess with that.  Do you use the
>> > equivalent GCC switches when compiling Emacs?  If so, why?
>> Yes, I do, I compile Emacs with -O3 -march=native and -mcpu=native
>> 
>> Hopefully gcc will emit some AVX instructions where possible. I haven't
>> dissasembled Emacs binary so I don't know how big is difference between generic
>> and native.
>
> Well, I suggest that you do look into the differences between the
> produced code, and try to measure the effect on the speed of Emacs.
>
> Btw, -O3 is not recommended, as it frequently produces a slower Emacs.

Do you sugest some benchmarks I could try?

Re: Q: What is default architecture for code produced by native compiler?

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: akrl@sdf.org,  emacs-devel@gnu.org
> Date: Thu, 26 Aug 2021 17:58:54 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Btw, -O3 is not recommended, as it frequently produces a slower Emacs.
> 
> Do you sugest some benchmarks I could try?

Any operation that takes long enough for you to be able to see the
differences would do.  It is best to use something that you personally
do a lot.

Re: Q: What is default architecture for code produced by native compiler?

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: akrl@sdf.org,  emacs-devel@gnu.org
>> Date: Thu, 26 Aug 2021 17:58:54 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Btw, -O3 is not recommended, as it frequently produces a slower Emacs.
>> 
>> Do you sugest some benchmarks I could try?
>
> Any operation that takes long enough for you to be able to see the
> differences would do.  It is best to use something that you personally
> do a lot.
Hmm, in an interactive application like Emacs, that can be a bit difficult to
measure reliably. I don't know, I was interested in comparison before, but I was
lazy to come up with somethign :).

Re: Q: What is default architecture for code produced by native compiler?

[Arthur Miller]

Andrea Corallo <akrl@sdf.org> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Just wonder, is it generic x86 or something later or does it uses
>> native for architecture and cpu flags (-march=native and -mcpu=native)?
>
> I'd say is GCC's default.
>
>> If it is generic, do we have option to pass in arch and cpu flags?
>
> No we don't, even if we could expose it using
> 'gcc_jit_context_add_command_line_option' for non obsolete versions of
> GCC.
>
> Regards
>
>   Andrea
I am sorry to bother, but I have just seen:

(defcustom native-comp-driver-options nil
  "Options passed verbatim to the native compiler's back-end driver.
Note that not all options are meaningful; typically only the options
affecting the assembler and linker are likely to be useful.

Passing these options is only available in libgccjit version 9
and above."
  :type '(repeat string)                ; FIXME is this right?
  :version "28.1")

I have tested with:

(setq native-comp-driver-options '("-march=native" "-mcpu=native"))

but I see no difference in emitted code when I dissaemble produced binaries.

Re: Q: What is default architecture for code produced by native compiler?

[Andrea Corallo via Emacs development discussions.]

Arthur Miller <arthur.miller@live.com> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Arthur Miller <arthur.miller@live.com> writes:
>>
>>> Just wonder, is it generic x86 or something later or does it uses
>>> native for architecture and cpu flags (-march=native and -mcpu=native)?
>>
>> I'd say is GCC's default.
>>
>>> If it is generic, do we have option to pass in arch and cpu flags?
>>
>> No we don't, even if we could expose it using
>> 'gcc_jit_context_add_command_line_option' for non obsolete versions of
>> GCC.
>>
>> Regards
>>
>>   Andrea
> I am sorry to bother, but I have just seen:
>
> (defcustom native-comp-driver-options nil
>   "Options passed verbatim to the native compiler's back-end driver.
> Note that not all options are meaningful; typically only the options
> affecting the assembler and linker are likely to be useful.
>
> Passing these options is only available in libgccjit version 9
> and above."
>   :type '(repeat string)                ; FIXME is this right?
>   :version "28.1")
>
> I have tested with:
>
> (setq native-comp-driver-options '("-march=native" "-mcpu=native"))
>
> but I see no difference in emitted code when I dissaemble produced binaries.

Driver options are not for the compiler but rather linker and assembler,
infact `native-comp-driver-options' relies on
'gcc_jit_context_add_driver_option' [1].

That said for most of the code we generate ATM I doubt would make much
difference to specify a different -march and/or -mcpu.

Regards

  Andrea

[1] <https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html>

Re: Q: What is default architecture for code produced by native compiler?

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> Date: Wed, 25 Aug 2021 07:36:59 +0000
> From:  Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> > (setq native-comp-driver-options '("-march=native" "-mcpu=native"))
> >
> > but I see no difference in emitted code when I dissaemble produced binaries.
> 
> Driver options are not for the compiler but rather linker and assembler,
> infact `native-comp-driver-options' relies on
> 'gcc_jit_context_add_driver_option' [1].

Then the name of the defcustom is misleading, IMO.  These can only be
the options that cc1 (or assembler/linker) understands, is that right?

And I guess this means we cannot support GCC options, because there's
no front-end driver like GCC in libgccjit?

> That said for most of the code we generate ATM I doubt would make much
> difference to specify a different -march and/or -mcpu.

That's also my opinion.

Re: Q: What is default architecture for code produced by native compiler?

[Andrea Corallo via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: emacs-devel@gnu.org
>> Date: Wed, 25 Aug 2021 07:36:59 +0000
>> From:  Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org>
>> 
>> > (setq native-comp-driver-options '("-march=native" "-mcpu=native"))
>> >
>> > but I see no difference in emitted code when I dissaemble produced binaries.
>> 
>> Driver options are not for the compiler but rather linker and assembler,
>> infact `native-comp-driver-options' relies on
>> 'gcc_jit_context_add_driver_option' [1].
>
> Then the name of the defcustom is misleading, IMO.

You are probably right, the defcustom name is inherited from the
libgccjit entry point name but it is probably not optimal.  Any
suggestion for a better one?

> These can only be
> the options that cc1 (or assembler/linker) understands, is that right?
>
> And I guess this means we cannot support GCC options, because there's
> no front-end driver like GCC in libgccjit?

To make it more clear I think we can summarize the situation as:

| libgccjit entry-point                   | affects what | emacs customize            |
|-----------------------------------------+--------------+----------------------------|
| gcc_jit_context_add_driver_option       | gas + ld     | native-comp-driver-options |
| gcc_jit_context_add_command_line_option | cc1          | ??                         |

So yes, exposing 'gcc_jit_context_add_command_line_option' we could.

Regards

  Andrea

Re: Q: What is default architecture for code produced by native compiler?

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: arthur.miller@live.com, emacs-devel@gnu.org
> Date: Wed, 25 Aug 2021 13:04:25 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Driver options are not for the compiler but rather linker and assembler,
> >> infact `native-comp-driver-options' relies on
> >> 'gcc_jit_context_add_driver_option' [1].
> >
> > Then the name of the defcustom is misleading, IMO.
> 
> You are probably right, the defcustom name is inherited from the
> libgccjit entry point name but it is probably not optimal.  Any
> suggestion for a better one?

Something like native-comp-backend-driver-options, together with
explaining in the doc string that typically only assembler and linker
options are meaningful.

> So yes, exposing 'gcc_jit_context_add_command_line_option' we could.

We probably should, yes.

Thanks.

Re: Q: What is default architecture for code produced by native compiler?

[Andrea Corallo via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: arthur.miller@live.com, emacs-devel@gnu.org
>> Date: Wed, 25 Aug 2021 13:04:25 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Driver options are not for the compiler but rather linker and assembler,
>> >> infact `native-comp-driver-options' relies on
>> >> 'gcc_jit_context_add_driver_option' [1].
>> >
>> > Then the name of the defcustom is misleading, IMO.
>> 
>> You are probably right, the defcustom name is inherited from the
>> libgccjit entry point name but it is probably not optimal.  Any
>> suggestion for a better one?
>
> Something like native-comp-backend-driver-options, together with
> explaining in the doc string that typically only assembler and linker
> options are meaningful.

Ack

>> So yes, exposing 'gcc_jit_context_add_command_line_option' we could.
>
> We probably should, yes.

Deal, will do.

Thanks

  Andrea