Speculative: Rust for base system components
Alan Somers
asomers at freebsd.org
Sun Jan 6 18:24:54 UTC 2019
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"
More information about the freebsd-hackers
mailing list