Date: Tue, 1 Jan 2019 16:35:49 -0800 From: Conrad Meyer <cem@freebsd.org> To: drosih <drosih@rpi.edu> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Speculative: Rust for base system components Message-ID: <CAG6CVpWJ=AOVt7zXZKCXqJnbtJ8U_EyYTpTHOVzpoRk5JDWjyA@mail.gmail.com> In-Reply-To: <4ea0612bbad08e61a15d495459b2bede@rpi.edu> References: <20190101045638.D280E1F56@spqr.komquats.com> <a2d04773-c7cc-457d-4db6-913cb84e885b@metricspace.net> <CADWvR2izXwGRwkWn52x6s3U73ki5Qdg98Y-00use=G9febhrGA@mail.gmail.com> <4ea0612bbad08e61a15d495459b2bede@rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 =E2=80=94 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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpWJ=AOVt7zXZKCXqJnbtJ8U_EyYTpTHOVzpoRk5JDWjyA>