From nobody Fri Sep 13 21:53:27 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X57Nk1KPmz5W2Kk for ; Fri, 13 Sep 2024 21:53:42 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X57Nh6dq3z4Nsl for ; Fri, 13 Sep 2024 21:53:40 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.221.174 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-vk1-f174.google.com with SMTP id 71dfb90a1353d-50108b373d2so373826e0c.2 for ; Fri, 13 Sep 2024 14:53:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726264420; x=1726869220; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yu/5peQY6IrcUj+q+suC6Kt+PmfiyiXW4TjJizG4NCo=; b=mWcrRDNmUq4QAcVcpBRITqZ6DTjKTouBpWxEzvCX2zpasxhGfdJinnRvxV9zLLDB/K 09oFqQ+14koPXReADb6ClHWimf0uWadWX+qReQoQ8b5NM9B6UIcHphdlfMhawm9D/sek TKsszL4WDheUZun7wBAgkguDTgTY3C9mvyGKlvstnPQYkzMBmaf1weHDsdZxe3NAY4Hh X+QMU2N3hDb0RjYcV2DX2ewLEaHmJ1N/GH6DQCcwSDM/6/ZR1Szy1G+q579SI+WYwvPH fdcoLftHDeLvjaCTN4Gn8/RLtUYiXUWibKq3mfHvafySoEWhKHGS0XnxFUl4dB554hXC sYgg== X-Forwarded-Encrypted: i=1; AJvYcCXbjhIYuOEFbwiRp7ZM7nMT400mNeOJvefTxMKCtuuel8BRTOLUdYNpyhJq3QwxwBYlqLO/LMwYNwxf9sULKPQ=@freebsd.org X-Gm-Message-State: AOJu0YwnfEea1drDeQxb6T3tQLVq5Mh5v26oI4wtGIkjoZcD6HDTPPLz m1m8l0JIpTa5hmfMsySzSZH4UZZXrWs/dAOuEA0b0q6tBdQF/+/ipRaMWEM2Y39UHC7HAGT3M1t ZxDaXWZPO1WttxAt44m6mfCTXE2UH1A== X-Google-Smtp-Source: AGHT+IFUQ7W6oeo5nKEeALJg4GuPhwEN8STTUSoebAJqzcFSezWbaDCbZqQd6x8ze2R4RV+kQRAbhUKiO6op1KgtWJs= X-Received: by 2002:a05:6122:a0b:b0:4f5:199b:2a61 with SMTP id 71dfb90a1353d-50344e3f297mr3349146e0c.9.1726264419921; Fri, 13 Sep 2024 14:53:39 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <2EE309BF-CE1D-48AD-9C53-D4C87998B4A0@freebsd.org> <2D0F93DC-36DA-4FB9-BFD2-D7678EC03CD7@FreeBSD.org> <9924d197-1b3f-4781-9fe0-20579c8e9066@gmail.com> <4cd2a84b-ec98-4270-a698-c7832402799f@gmail.com> In-Reply-To: From: Alan Somers Date: Fri, 13 Sep 2024 15:53:27 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: Aryeh Friedman Cc: Paul Floyd , FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000089b7420622074141" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.77 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.87)[-0.872]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; FREEFALL_USER(0.00)[asomers]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TAGGED_RCPT(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.221.174:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.221.174:from] X-Rspamd-Queue-Id: 4X57Nh6dq3z4Nsl --00000000000089b7420622074141 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 13, 2024, 2:14=E2=80=AFPM Aryeh Friedman wrote: > On Fri, Sep 13, 2024 at 3:01=E2=80=AFPM Paul Floyd = wrote: > > > > > > > > On 13-09-24 12:24, Aryeh Friedman wrote: > > > On Fri, Sep 13, 2024 at 7:59=E2=80=AFAM Paul Floyd > wrote: > > > > > > > > Incorrect a pointer by definition points to a memory region of > > > > It's really difficult to follow what you are banging on about. One > > moment it's allocators and the next it's pointers. > > Again wrong all a pointer is at the end of the day is a memory address > anything to do with that memory access's contents and/or addresses > near it not what a pointer is. We would all have an easier time understanding "what you are banging on about" if you would use correct English grammar. Could you please try to make an effort? In other words arr+i =3D=3D arr[i] iff > and only iff your type is one processor word big. In all other cases > you just have to trust your math is right if your don't it with ptr > math instead of array notation. But since neither is bounds checked > then you are completely free to address stuff beyond your allocation > unless. All this adds up to ptr!=3Darrays but array indexing=3D=3Dptrs. > In other words malloc, calloc, etc. make no guerntee that the memory > is actually reserved for your exclusive use only that it marked that > way at run time. > > > > > > *UNKNOWN* size and it is only the runtime environment that keeps trac= k > > > > I'm well aware of that. > > > > > Malloc is not the *ONLY* way to allocate memory at the system level a= n > > > > You could also implement your own custom allocator based on mmap. > > There are many other ways that are much cleaner than the above if > you're dealing with system level stuff... I am amazed you would point > to mmap as a solution and recommend kernel Rust use at the same time > He didn't recommend that anybody use mmap directly. I think we all know that only a masochist would use mmap directly for this purpose. A masochist, or somebody implementing a custom allocator. because if that is how Rust does it (which I assume it does) then you > are relying on kernel calls to do that (which might be accessible at > below the kernel interface). > > > > > > Go read CLRS it is a very clear and obvious algorthm the only thing > > > > You mean this bit > > > > "10.3 Implementing pointers and objects > > How do we implement pointers and objects in languages that do not > > provide them?" > > Your being purposely dense here if we are talking about > growing/shrinking arrays there is an entire section on how to analyze > that since it is a classic case of you have on O(1) function [index > lookup] and the other growing it (O(n)) then how to amortize the big-O > over time. How you got I was talking about anything is complete > beyond me. > > > > > > What is the point. We are discussing languages (C, C++ and Rust) that D= O > > have them. > > > > > you have to be careful of is it is not O(1) so you need to time it > > > carefully when I do the expanson/contraction instead of just letting > > > the runtime environment do it for you. An extreme case of this > > > going very wrong happened in July 1969 here is the transcript: > > > > > > 4 06 42 10 CC > > > Eagle, Houston. You're GO for landing. Over. > > > > Space cadet? > > Again you missed the point the point being that a simple memory > management function that you claim Rust does real well at (async > behind the scenes array size management) if called at the "right" time > (like when attempting the final descent to the moon [btw in the > real-life case the mission was saved by Armstrong taking manually > control]) it can to catastrophic results such as the very computer you > need to safely and softly land on the moon becoming non-responsive. > This is a *COMPLETELY* unacceptable result in any mission-critical (or > higher application... for example if it happened on one of the remote > cardiac monitors we use at just the right time we can miss you having > a heart attack... i.e. for us bugs [of any kind]=3D=3Ddead people). > -- > Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org I think you are confusing "systems programming" with "real time programming". I too have programmed real time systems. In my case, for audio electronics. Avoiding dynamic memory allocations is indeed important for real time programming, but Rust is neither uniquely good nor bad at that. And please understand that there is much more to systems programming than real time systems. -Alan --00000000000089b7420622074141 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Sep 13, 2024, 2:14=E2=80=AFPM Aryeh Friedman &= lt;aryeh.friedman@gmail.com= > wrote:
On F= ri, Sep 13, 2024 at 3:01=E2=80=AFPM Paul Floyd <paulf2718@gmail.com= > wrote:
>
>
>
> On 13-09-24 12:24, Aryeh Friedman wrote:
> > On Fri, Sep 13, 2024 at 7:59=E2=80=AFAM Paul Floyd <paulf2718= @gmail.com> wrote:
>
> >
> > Incorrect a pointer by definition points to a memory region of >
> It's really difficult to follow what you are banging on about. One=
> moment it's allocators and the next it's pointers.

Again wrong all a pointer is at the end of the day is a memory address
anything to do with that memory access's contents and/or addresses
near it not what a pointer is.
We would all have an easier time understanding &q= uot;what you are banging on about" if you would use correct English gr= ammar. Could you please try to make an effort?

<= /div>
In other words arr+i =3D=3D arr[i] iff
and only iff your type is one processor word big.=C2=A0 =C2=A0In all other = cases
you just have to trust your math is right if your don't it with ptr
math instead of array notation.=C2=A0 =C2=A0But since neither is bounds che= cked
then you are completely free to address stuff beyond your allocation
unless.=C2=A0 =C2=A0All this adds up to ptr!=3Darrays but array indexing=3D= =3Dptrs.
In other words malloc, calloc, etc. make no guerntee that the memory
is actually reserved for your exclusive use only that it marked that
way at run time.

>
> > *UNKNOWN* size and it is only the runtime environment that keeps = track
>
> I'm well aware of that.
>
> > Malloc is not the *ONLY* way to allocate memory at the system lev= el an
>
> You could also implement your own custom allocator based on mmap.

There are many other ways that are much cleaner than the above if
you're dealing with system level stuff...=C2=A0 I am amazed you would p= oint
to mmap as a solution and recommend kernel Rust use at the same time

He didn= 't recommend that anybody use mmap directly. I think we all know that o= nly a masochist would use mmap directly for this purpose. A masochist, or s= omebody implementing a custom allocator.

<= div dir=3D"auto">
because if that is how Rust does it (which I assume it does) then you
are relying on kernel calls to do that (which might be accessible at
below the kernel interface).

>
> > Go read CLRS it is a very clear and obvious algorthm the only thi= ng
>
> You mean this bit
>
> "10.3 Implementing pointers and objects
> How do we implement pointers and objects in languages that do not
> provide them?"

Your being purposely dense here if we are talking about
growing/shrinking arrays there is an entire section on how=C2=A0 to analyze=
that since it is a classic case of you have on O(1) function [index
lookup] and the other growing it (O(n)) then how to amortize the big-O
over time.=C2=A0 =C2=A0How you got I was talking about anything is complete=
beyond me.


>
> What is the point. We are discussing languages (C, C++ and Rust) that = DO
> have them.
>
> > you have to be careful of is it is not O(1) so you need to time i= t
> > carefully when I do the expanson/contraction instead of just lett= ing
> > the runtime environment do it for you.=C2=A0 =C2=A0 An extreme ca= se of this
> > going very wrong happened in July 1969 here is the transcript: > >
> > 4 06 42 10 CC
> > Eagle, Houston. You're GO for landing. Over.
>
> Space cadet?

Again you missed the point the point being that a simple memory
management function that you claim Rust does real well at (async
behind the scenes array size management) if called at the "right"= time
(like when attempting the final descent to the moon [btw in the
real-life case the mission was saved by Armstrong taking manually
control]) it can to catastrophic results such as the very computer you
need to safely and softly land on the moon becoming non-responsive.
This is a *COMPLETELY* unacceptable result in any mission-critical (or
higher application... for example if it happened on one of the remote
cardiac monitors we use at just the right time we can miss you having
a heart attack... i.e. for us bugs [of any kind]=3D=3Ddead people).
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org


--00000000000089b7420622074141--