Speculative: Rust for base system components

[Alan Somers]

Actually, LTO isn't necessary.  I just compiled those examples on my
local machine, building them into a binary.  Even without LTO, dead
code like into_iter and Iterator::sum does not get included in the
binary.  I'm not sure why it does on godbolt.  Perhaps they
intentionally disable dead code elimination?
-Alan

On Sun, Jan 6, 2019 at 11:01 AM Alan Somers <asomers at freebsd.org> wrote:
>
> But it's not a like-for-like comparison.  Rust eliminates dead code at
> a later stage.  If you want to compare the efficiency of generated
> code, you need to exclude the dead code that will be eliminated by
> LTO.  And you shouldn't be counting the labels for either language,
> because they don't affect the machine code.  If you want to compare
> build times, then you should actually measure build times.
> -Alan
>
> On Sun, Jan 6, 2019 at 10:51 AM Brian Neal <brian at aceshardware.com> wrote:
> >
> > Of course.  But I'm counting like for like.  So labels are counted for
> > all languages.  And I definitely don't rely on LTO when comparing the
> > efficacy of compiler, especially since the linker can spend lots of time
> > eliminating dead-code (usually single-threaded), which means longer
> > build times.
> >
> > On 1/6/2019 9:17 AM, Alan Somers wrote:
> > > Those 21 lines aren't 21 instructions; you're counting labels.  Also,
> > > the first three instructions aren't actually part of the function.
> > > They're dead code, and should be eliminate by LTO.  However, Rust
> > > doesn't do LTO when compiling libraries; only when linking
> > > executables.  The unwrap logic, etc is also not part of the function.
> > > So in this example, Rust produces only a few more instructions than C.
> > > Also, FYI the Rust expression "0..num" is exclusive on the right.
> > > It's equivalent to C's "for (int i = 0; i < num; i++)", though that
> > > doesn't change the instruction count.
> > >
> > > -Alan
> > _______________________________________________
> > freebsd-hackers at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"