From nobody Fri Sep 13 13:21:02 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 4X4w1S2pdnz5X0yL for ; Fri, 13 Sep 2024 13:21:16 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) (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 4X4w1S0vQ7z4PZy for ; Fri, 13 Sep 2024 13:21:16 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-f173.google.com with SMTP id 5614622812f47-3e03f8ecef8so1249797b6e.1 for ; Fri, 13 Sep 2024 06:21:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726233675; x=1726838475; h=content-transfer-encoding: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=6uJ7PF445sWRXxB/c9ZZirCQz0Kovwtm/WgoZP3GbBs=; b=SeNPvLrsRtPzyL91ljbUSkgOSq6tzQNYvZXepKC9i0vmV+U8ueLBLL1/w5es4F3RPl LrtCAvDbyTSyD9tYVED9nkVQ5CHsBqpxoN2BIntkdQXLOaah8ecxM9Jfvh9YRaJo6TyA ozp/BnrUvRbRMuo2IhLGQFhb1RbvWPiprLL0qw+KrqOd12XdNKXf/UfPpxb4KLC7t9w+ bXKH8N8s7LVNqu0FawJcMnLdFMCD2m5g/6eB/bDRq572M/ZNl3iHWsYgOIT/q7WOsU53 ozJ1/ks9qbxqvdCrskGNmocv/hHI7tpUd006Kv6CJIvGEPpq63DzsZ9oM+TkurwRqE+s 3kkw== X-Gm-Message-State: AOJu0YwFZN5YmwovYfyH1KCpeXdCt9zGAlShAgOw2u3wLbtg0SJSDP7h 57W5vGj/elIgbtqkyg7AIZPJ2ZB3jMvg5NyYJ7r/wBPaH0zvKcRj0WRbKdbWO9QeatqpfzBzbW6 zTMO8M1Cxtbuel4bG3Wanbwntb53EAA== X-Google-Smtp-Source: AGHT+IFU1fhTfLYAYyeCwSQ0DAcaazc/i129QZzWwvC1SkwpOslD7F9Al6XpuSHDzF/mNVfi+O9Nvyqwhh3vM78uJp8= X-Received: by 2002:a05:6808:1514:b0:3d9:2925:cd37 with SMTP id 5614622812f47-3e071a848ebmr6841270b6e.2.1726233674802; Fri, 13 Sep 2024 06:21:14 -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> In-Reply-To: From: Alan Somers Date: Fri, 13 Sep 2024 07:21:02 -0600 Message-ID: Subject: Re: The Case for Rust (in any system) To: Jason Bacon Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4X4w1S0vQ7z4PZy On Fri, Sep 13, 2024 at 7:15=E2=80=AFAM Jason Bacon w= rote: > > On 9/13/24 05:33, Paul Floyd wrote: > > > > > > On 13-09-24 06:17, David Chisnall wrote: > >> On 13 Sep 2024, at 02:34, Joe Schaefer wrote: > >>> > >>> I just completed a month long project to port a C++ codebase that > >>> used vectors for array allocations back to using C=E2=80=98s calloc. = For a > >>> 15% increase in memory footprint, batch jobs that took three days to > >>> complete now finish in 10-12 hours. > >> > >> This sounds highly dubious given that std::vector is a very thin > >> wrapper around malloc. From your description, I would expect the same > >> speedup with some judicial use of .reserve(). > > > > I was going to say exactly the same thing. > > > > Considering the reply to this, another one to be plonked so that I wast= e > > less time. > > > > A+ > > Paul > > > > > > > > Some years ago, I wrote a script to time a simple selection sort coded > in various languages. Here's an example of the results: > > https://github.com/outpaddling/Lang-speed/blob/master/Results/coral-amd64= -100000 > > Note: The clang array/pointer performance is currently regressed due to > changes in the optimization parameters since clang 8. That's why it's > noticeably slower than GCC in these results. > > https://github.com/llvm/llvm-project/issues/53205#issuecomment-2318697322 > > In general, I have not seen a significant difference between arrays and > vectors in all my years running this benchmark. > > This benchmark is anecdotal, as it only measures performance for one > algorithm. But in my experience, C++ shows marginally slower > performance and noticeably more memory use than C. > > Coming back to Rust: The results above, showing about double the runtime > of C and C++, is the best I've seen from it. It was taking 4x as long > as C/C++ a few years ago. That's one reason I don't use it. I do > mostly scientific computing, where runtime can be costly. This is not > *always* an issue in systems code, but it should be examined before > choosing a language for a particular implementation. The other reason > is the impact of a Rust dependency on FreeBSD ports and pkgsrc packages: > Frequent changes to the Rust port/package lead to long build times and > frequent breakage of dependents. Right away, I can see that while your C program mallocs the array to the list's full size, your Rust program doesn't. It grows the list one element at a time, with Vec::push . I bet that if you change the Rust program to use Vec::reserve or Vec::with_capacity, so that it only has to allocate once, you'll find the results are different. -Alan