linux-kernel - Re: C aggregate passing (Rust kernel policy)

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: <p3rj67s5hiqcfgneko5ktzxowmrbihdn5tsegjvfbeoc5e7bvs@yanurk7vardt>
Date: Sat, 22 Feb 2025 19:06:40 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 
	Ventura Jack <venturajack85@...il.com>, Gary Guo <gary@...yguo.net>, airlied@...il.com, 
	boqun.feng@...il.com, david.laight.linux@...il.com, ej@...i.de, 
	gregkh@...uxfoundation.org, hch@...radead.org, ksummit@...ts.linux.dev, 
	linux-kernel@...r.kernel.org, miguel.ojeda.sandonis@...il.com, rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)

On Sat, Feb 22, 2025 at 03:50:59PM -0800, H. Peter Anvin wrote:
> On February 22, 2025 1:22:08 PM PST, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
> >On Sat, Feb 22, 2025 at 12:54:31PM -0800, H. Peter Anvin wrote:
> >> VLIW and OoO might seem orthogonal, but they aren't – because they are
> >> trying to solve the same problem, combining them either means the OoO
> >> engine can't do a very good job because of false dependencies (if you
> >> are scheduling molecules) or you have to break them instructions down
> >> into atoms, at which point it is just a (often quite inefficient) RISC
> >> encoding. In short, VLIW *might* make sense when you are statically
> >> scheduling a known pipeline, but it is basically a dead end for
> >> evolution – so unless you can JIT your code for each new chip
> >> generation...
> >
> >JITing for each chip generation would be a part of any serious new VLIW
> >effort. It's plenty doable in the open source world and the gains are
> >too big to ignore.
> >
> >> But OoO still is more powerful, because it can do *dynamic*
> >> scheduling. A cache miss doesn't necessarily mean that you have to
> >> stop the entire machine, for example.
> >
> >Power hungry and prone to information leaks, though.
> >
> 
> I think I know a thing or two about JITting for VLIW..  and so does someone else in this thread ;)

Yeah, you guys going to share? :)

The Transmeta experience does seem entirely relevant, but it's hard to
tell if you and Linus are down on it because of any particular insights
into VLIW, or because that was a bad time to be going up against Intel.
And the "unrestricted pointer aliasing" issues would've directly
affected you, recompiling x86 machine code, so if anyone's seen numbers
on that it's you guys.

But it was always known (at least by the Itanium guys) that for VLIW to
work it'd need help from the compiler guys, and when you're recompiling
machine code that's right out. But then you might've had some fun jit
tricks to make up for that...