Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Jan 2019 11:06:16 +0000
From:      Johannes Lundberg <johalun0@gmail.com>
To:        freebsd-hackers@freebsd.org
Subject:   Re: Speculative: Rust for base system components
Message-ID:  <804bd7ee-d9c3-08ba-031f-df0348860d35@gmail.com>
In-Reply-To: <CAG6CVpWJ=AOVt7zXZKCXqJnbtJ8U_EyYTpTHOVzpoRk5JDWjyA@mail.gmail.com>
References:  <20190101045638.D280E1F56@spqr.komquats.com> <a2d04773-c7cc-457d-4db6-913cb84e885b@metricspace.net> <CADWvR2izXwGRwkWn52x6s3U73ki5Qdg98Y-00use=G9febhrGA@mail.gmail.com> <4ea0612bbad08e61a15d495459b2bede@rpi.edu> <CAG6CVpWJ=AOVt7zXZKCXqJnbtJ8U_EyYTpTHOVzpoRk5JDWjyA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On 1/2/19 12:35 AM, Conrad Meyer wrote:
> Hi Garance,
>
> On Tue, Jan 1, 2019 at 3:18 PM drosih <drosih@rpi.edu> wrote:
>> Brian's simple experiment is a simple experiment.  It's interesting,
>> but hardly the definitive word in evaluating a language.
> Sure, that's fair enough.  On the other hand, it matches every other
> report of the compiler and language I've heard, even from advocates of
> the language.  Compiler performance was on the Rust roadmap for 2017
> (incremental rebuilds added during 2017) and 2018:
>
> https://blog.rust-lang.org/2017/02/06/roadmap.html
> https://blog.rust-lang.org/2018/03/12/roadmap.html
>
> In particular I think the Rust 2018 community survey (URL below) is
> informative.  Scroll to the figure just above "Many non-users
> responded that they did want to learn Rust, but there were factors
> that slowed them down."  Leading reasons for people who had used Rust
> but no longer did were: (1) Rust is too intimidating, too hard to
> learn, or too complicated; (3) Rust doesn't solve a problem for me;
> and (6) Switching to Rust would slow me down too much.  One of the top
> 10 free-form comments for November 2018 is "improve compile times."
> It's still a problem.
>
> https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html
>
>> I thought the 'ripgrep' program seemed like an interesting one
>> to look at.  Compare how fast it works to how fast our grep works.
> It's not a great comparison; our grep (either GNU grep 2.5.1 or
> BSDgrep) is just not very good and must conform to POSIX.
>
> 'ag' (pkg install the_silver_searcher) is a more interesting
> comparison, with similar ability to exclude files automatically.  Both
> are source-code focused; by default, both .gitignore and similar files
> to exclude files and directories.  Both share similar goals, probably
> inspired by 'ack' (which is slower than both): high real-world
> performance, threaded search, and fast, non-PCRE regular expressions
> by default.
>
> On the other hand, grep(1) must maintain POSIX compatibility, which
> makes for significantly slower defaults in many searches.  This limits
> the impact of improving the performance of the internals on
> real-world, default-behavior search — because excluding files is a
> huge boon for ag/rg.
>
> In my experience, ripgrep is much faster than our grep, but pretty
> similar to 'ag'.  Both have a comparable feature set; if anything, ag
> has more features IME.
>
> The binary sizes are interesting:
>
> -r-xr-xr-x 3 root wheel  113640 Nov  4 15:47 /usr/bin/grep*
> -r-xr-xr-x 1 root wheel   89104 Oct 28 14:24 /usr/local/bin/ag*
> -rwxr-xr-x 1 root wheel 4284416 Oct 29 05:12 /usr/local/bin/rg*
>
> All are dynamically linked and stripped amd64 binaries.  Ripgrep
> (Rust) is 48x the binary size of ag and 37x that of grep(1).  Like
> grep(1), 'ag' is written in C.


Hi


Rust by default statically link everything in executable binaries. This 
is comparable to statically link in libc and all other dependencies in 
your C program. You can have Rust programs link against shared rust 
libraries (std, etc) and get the size down to basically same as C.


If Rust is used in base and everything is built at the same time, with 
same version compiler, it would make sense to link dynamically I think.


Switching topic a bit. Just wanted to also add my contribution, a simple 
sysctl Rust library https://github.com/johalun/sysctl-rs .


Cheers

>
> Of that 4 MB binary, 2805414 bytes of ripgrep are ".text".  Other
> major contributors are .rodata, .eh_frame and .rela.dyn at 540kB,
> 300kB, and 240kB respectively.
>
> Of the 89 kB ag binary, 37 kB is ".text", 14kB is ".rodata," and 13kB
> is ".data".  I think this difference is illustrative and reasonably
> representative.
>
> Best,
> Conrad
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?804bd7ee-d9c3-08ba-031f-df0348860d35>