Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 31 Dec 2018 13:19:07 -0500
From:      Eric McCorkle <eric@metricspace.net>
To:        freebsd-hackers@freebsd.org
Subject:   Re: Speculative: Rust for base system components
Message-ID:  <3372a962-407a-2e59-cede-8238d3072bae@metricspace.net>
In-Reply-To: <713BA6E4-1C4E-4890-831F-6379D3AB4425@gmail.com>
References:  <ca76e5f7-6e59-bd67-144a-90ad66f0252e@metricspace.net> <CANCZdfrMY73-7vK6F6q-iPdW7EOUP8CPThkyxwOoOWedyMu5Ag@mail.gmail.com> <713BA6E4-1C4E-4890-831F-6379D3AB4425@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--PYaIlGWxe8Q3h8PySRV2ty4OrfGKLpEYe
Content-Type: multipart/mixed; boundary="WmqEDypb7wVkTWEXcEMWt6CuxkY0Luvvm";
 protected-headers="v1"
From: Eric McCorkle <eric@metricspace.net>
To: freebsd-hackers@freebsd.org
Message-ID: <3372a962-407a-2e59-cede-8238d3072bae@metricspace.net>
Subject: Re: Speculative: Rust for base system components
References: <ca76e5f7-6e59-bd67-144a-90ad66f0252e@metricspace.net>
 <CANCZdfrMY73-7vK6F6q-iPdW7EOUP8CPThkyxwOoOWedyMu5Ag@mail.gmail.com>
 <713BA6E4-1C4E-4890-831F-6379D3AB4425@gmail.com>
In-Reply-To: <713BA6E4-1C4E-4890-831F-6379D3AB4425@gmail.com>

--WmqEDypb7wVkTWEXcEMWt6CuxkY0Luvvm
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 12/31/18 12:36 PM, Enji Cooper wrote:

> Rust is still a young language, but it has a number of benefits in term=
s of:
> i. Being able to scale past JIT python. This fact doesn=E2=80=99t matte=
r on workstations/servers, but it definitely matters on the low end with =
embedded systems and the upper end with distributed systems at scale (the=
re=E2=80=99s a reason why a number of critical services at my previous lo=
ngterm employment were written in C++, not python. Some argue Rust can ou=
tperform C/C++ [2]. C++ I can see (managed pointers were about an order o=
f magnitude less performant in a microbenchmark I wrote for grabbing the =
time in the Linux kernel vs malloc in C using llvm36). However, outperfor=
ming C is up for debate.

In terms of outperforming C++, you can outrun it on anything that
involves virtual calls or runtime type information.  C++ compilers have
gotten pretty good at optimizing this stuff, but that's all an
approximation of just not doing it in the first place.

In terms of C, I think the more accurate notion is that you converge to
C-like performance over time.  There's not a lot of opportunity to pull
out ahead of C in terms of performance, afterall, at least in purely
sequential code.


--WmqEDypb7wVkTWEXcEMWt6CuxkY0Luvvm--

--PYaIlGWxe8Q3h8PySRV2ty4OrfGKLpEYe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQQPGL/SuSPN3pRzpwUI38IpFsHCbAUCXCpdmwAKCRAI38IpFsHC
bLxbAP46053CGLv1CljF380xiwa1nqKJ2+M2m6HIGEboIBa/dAEApT4Fzgf+b99g
kWascfpOfsns82LxoPs/CF15OyAJqQs=
=iSLm
-----END PGP SIGNATURE-----

--PYaIlGWxe8Q3h8PySRV2ty4OrfGKLpEYe--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3372a962-407a-2e59-cede-8238d3072bae>