lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4tyipncgbrl5yidulxcsobk6pq5jl3dvzkqtckrqjldqpsh6bm@q5xeyqz5j2to>
Date: Wed, 27 Mar 2024 19:35:38 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: comex <comexk@...il.com>, "Dr. David Alan Gilbert" <dave@...blig.org>, 
	Philipp Stanner <pstanner@...hat.com>, Boqun Feng <boqun.feng@...il.com>, 
	rust-for-linux <rust-for-linux@...r.kernel.org>, linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org, 
	llvm@...ts.linux.dev, Miguel Ojeda <ojeda@...nel.org>, 
	Alex Gaynor <alex.gaynor@...il.com>, Wedson Almeida Filho <wedsonaf@...il.com>, 
	Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...sung.com>, 
	Alice Ryhl <aliceryhl@...gle.com>, Alan Stern <stern@...land.harvard.edu>, 
	Andrea Parri <parri.andrea@...il.com>, Will Deacon <will@...nel.org>, 
	Peter Zijlstra <peterz@...radead.org>, Nicholas Piggin <npiggin@...il.com>, 
	David Howells <dhowells@...hat.com>, Jade Alglave <j.alglave@....ac.uk>, 
	Luc Maranget <luc.maranget@...ia.fr>, "Paul E. McKenney" <paulmck@...nel.org>, 
	Akira Yokosawa <akiyks@...il.com>, Daniel Lustig <dlustig@...dia.com>, 
	Joel Fernandes <joel@...lfernandes.org>, Nathan Chancellor <nathan@...nel.org>, 
	Nick Desaulniers <ndesaulniers@...gle.com>, kent.overstreet@...il.com, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Marco Elver <elver@...gle.com>, 
	Mark Rutland <mark.rutland@....com>, Thomas Gleixner <tglx@...utronix.de>, 
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>, 
	Catalin Marinas <catalin.marinas@....com>, linux-arm-kernel@...ts.infradead.org, 
	linux-fsdevel@...r.kernel.org
Subject: Re: [WIP 0/3] Memory model and atomic API in Rust

On Wed, Mar 27, 2024 at 03:57:12PM -0700, Linus Torvalds wrote:
> On Wed, 27 Mar 2024 at 14:41, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
> >
> >
> > On the hardware end, the Mill guys were pointing out years ago that
> > register renaming is a big power bottleneck in modern processors;
> 
> LOL.
> 
> The Mill guys took the arguments from the Itanium people, and turned
> the crazy up to 11, with "the belt" and seemingly trying to do a
> dataflow machine but not worrying over-much about memory accesses etc.
> 
> The whole "we'll deal with it in the compiler" is crazy talk.

And Itanium did way better on Fortran, but all those spills and reloads
due to aliasing that an OoO processor can hide are death when you're
statically scheduled.

Unrestricted pointers are fundamentally a real barrier to improved ILP.
It's not _all_ branches and cache effects, though I will grant you that
cache effects do dominate.

But I think there's hope for improvement on that one too. A _lot_ of
kernel code defaults to lists instead of vectors even though we know
that vectors are better for performance - beacuse people are afraid of
memory allocations and error paths. Rust makes it way harder to fuck up
your error paths, and also makes it safer to refactor to improve your
data structures.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ