Top researchers leave Intel to build startup with 'the biggest, baddest CPU' • Hacker News Board

Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

#131

Post by scroot » Sun, Jun 08, 2025, 2:10 AM UTC

inkyoto wrote: post #110

guywithahat wrote: post #26

As someone who knows almost nothing about CPU architecture, I've always wondered if there could be a new instruction set, better suited to today's needs. I realize it would require a monumental software effort but most of these instruction sets are decades old. RISC-V is newer but my understanding is it's still based around ARM, just without royalties (and thus isn't bringing many new ideas to the table per say)

There are not really any newer instruction sets as we are locked into the von Neumann architecture and, until we move away from it, we will continue to move data between memory and CPU registers, or registers ↭ registers etc, which means that we will continue to add, shift, test conditions of arithmetic operations – same instructions across pretty much any CPU architecture relevant today. So we have: CISC – which is…

Have you heard about ufork? I find it very promising

https://github.com/organix/uFork

Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

#132

Post by AlotOfReading » Sun, Jun 08, 2025, 4:11 AM UTC

mdaniel wrote: post #129

AlotOfReading wrote: post #127

Earlier quoted context omitted.

What would you want from on-gpu slots that you don't get from existing mechanisms to give your GPU access to system memory?

prelude: I realized that I typed out a ton of words but in the end engineering is all about tradeoffs, so, fine if there's a way I can teach some existing GPU, or some existing PCIe TPU, to access system RAM over an existing PCIe slot, that sounds like a fine step forward. I just don't have a lot of experience in that setup to know if only certain video cards allow that or what Bearing in mind the aforementioned "I'm…

Oh, it's not a good idea at all from a performance perspective to use system memory because it's slow as heck. The important thing is that you can do it. Some way of allowing the GPU to page in data from system RAM (or even storage) on an as-needed basis has been supported by Nvidia since at least Tesla generation.

There's actually a multitude of different ways now that each have their own performance tradeoffs like direct DMA from the Nvidia card, data copied via CPU, GPU direct storage, and so on. You seem to understand the gist though, so these are mainly implementation details. Sometimes there's weird limitations with one method like limited to Quadro, or only up to a fixed percentage of system memory.

The short answer is that all of them suck to different degrees and you don't want to use them if possible. They're enabled by default for virtually all systems because they significantly simplify CUDA programming. DDR is much less suitable than GDDR for feeding a bandwidth hungry monster like a GPU, PCI introduces high latency and further constructions, and any CPU involvement is a further slowdown. This would also apply to socketed memory on a GPU though: Significantly slower and less bandwidth.

There's also some additional downsides to accessing system RAM that we don't need to get into, like sometimes losing the benefits of caching and getting full cost memory accesses every time.

Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

#133

Post by Sohcahtoa82 » Sun, Jun 08, 2025, 5:33 AM UTC

ahartmetz wrote: post #115

Sohcahtoa82 wrote: post #64

Earlier quoted context omitted.

> If a Ryzen takes 1,250 times the transistor for one core, does one core run 1,250 times (even taking hyperthreading in to account) faster than an i80486 at the same clock? 500 times? 100 times? Would be interesting to see a benchmark on this. If we restricted it to 486 instructions only, I'd expect the Ryzen to be 10-15x faster. The modern CPU will perform out-of-order execution with some instructions even run in p…

A Ryzen is muuuuch more than 10-15x faster than a 486, and AVX et al do diddly squat for a lot of general-purpose code. Clock speed is about 50x and IPC, let's say, 5-20x. So it's roughly 500x faster.

I meant a comparison on a clock-for-clock level. In other words, imagine either the 486 running at the clock speed of a Ryzen, or the Ryzen running at the clock speed of the 486. In other other words, compare ONLY IPC.

The line I was commenting on said:

> If a Ryzen takes 1,250 times the transistor for one core, does one core run 1,250 times (even taking hyperthreading in to account) faster than an i80486 at the same clock?

Emphasis added by me.

Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

#134

Post by inkyoto » Sun, Jun 08, 2025, 10:19 AM UTC

GregarianChild wrote: post #114

inkyoto wrote: post #110

Earlier quoted context omitted.

There are not really any newer instruction sets as we are locked into the von Neumann architecture and, until we move away from it, we will continue to move data between memory and CPU registers, or registers ↭ registers etc, which means that we will continue to add, shift, test conditions of arithmetic operations – same instructions across pretty much any CPU architecture relevant today. So we have: CISC – which is…

Modern GPU instructions are often VLIW and the compiler has to do a lot to schedule them. For example, Nvidia's Volta (from 2017) uses 128-bit to encode each instruction. According to [1], the 128 bits in a word are used as follows: • at least 91 bits are used to encode the instruction • at least 23 bits are used to encode control information associated to multiple instructions • the remaining 14 bits appeared to be…

Personally, I have a soft spot for VLIW/EPIC architectures, and I really wish they were more successful in the mainstream computing.

I didn't consider GPU's precisely for the reason you mentioned – because of their unsuitability to run sequential workloads, which is most applications that end users run, even though nearly every modern computing contraption in existence has them today.

One, most assuredly, radical departure from the von Neumann architecture that I completely forgot about is the dataflow CPU architecture, which is vastly different from what we have been using in the last 60+ years. Even though there have been no productionised general purpose dataflow CPU's, it has been successfully implemented for niche applications, mostly in the networking. So, circling back to the original point raised, dataflow CPU instructions would certainly qualify for a new design.

Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

#135

Post by inkyoto » Sun, Jun 08, 2025, 11:02 AM UTC

scroot wrote: post #131

inkyoto wrote: post #110

Earlier quoted context omitted.

There are not really any newer instruction sets as we are locked into the von Neumann architecture and, until we move away from it, we will continue to move data between memory and CPU registers, or registers ↭ registers etc, which means that we will continue to add, shift, test conditions of arithmetic operations – same instructions across pretty much any CPU architecture relevant today. So we have: CISC – which is…

Have you heard about ufork? I find it very promising https://github.com/organix/uFork

Nope, not until now. It seems to be a much more modern take on the idea of an object oriented CPU architecture.

Yet, there is something about object oriented ISA's that has made CPU designers eschew them consistently. Ranging from the Intel iAPX-432, to the Japanese Smalltalk Katana CPU, to jHISC, to another, unrelated, Katana CPU by the University of Texas and the University of Illinois, none of them have ever yielded a mainstream OO CPU. Perhaps, modern computing is not very object oriented after all.

[0] https://github.com/organix/uFork/blob/main/docs/asm.md

Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

#136

Post by 627467 » Sun, Jun 08, 2025, 11:58 AM UTC

joshstrange wrote: post #117

I tire of “Employees from Y company leave to start their own” and even “Ex-Y employees launch new W”. How many times do we have to see these stories play out to realize it doesn’t matter where they came from. These big companies employee a lot of people of varying skill, having it on your resume means almost nothing IMHO. Just look at the Humane pin full of “ex-Apple employees”, how’d that work out? And that’s only o…

Yeah... "Combined 100 years of experience" and in previous article [0] it was "combined 80+ years" for the same people... What happened there? Accelerated aging?

[0] https://news.ycombinator.com/item?id=41353155

Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

#137

Post by GregarianChild » Sun, Jun 08, 2025, 2:51 PM UTC

inkyoto wrote: post #134

GregarianChild wrote: post #114

Earlier quoted context omitted.

Modern GPU instructions are often VLIW and the compiler has to do a lot to schedule them. For example, Nvidia's Volta (from 2017) uses 128-bit to encode each instruction. According to [1], the 128 bits in a word are used as follows: • at least 91 bits are used to encode the instruction • at least 23 bits are used to encode control information associated to multiple instructions • the remaining 14 bits appeared to be…

Personally, I have a soft spot for VLIW/EPIC architectures, and I really wish they were more successful in the mainstream computing. I didn't consider GPU's precisely for the reason you mentioned – because of their unsuitability to run sequential workloads, which is most applications that end users run, even though nearly every modern computing contraption in existence has them today. One, most assuredly, radical dep…

The reason that VLIW/EPIC architectures have not been successful that for mainstream workloads is the combination of

• the "memory wall",

• the static unpredictability of memory access, and

• the lack of sufficient parallelism for masking latency.

Those make dynamically scheduling instructions is just much more efficient.

Dataflow has been tried many many many times for general-purposed workloads. And every time it failed for general-purposed workloads. In the early 2020s I was part of an expensive team doing a blank-slate dataflow architecture for a large semi company: the project got cancelled b/c the performance figures were weak relative to the complexity of micro-architecture, which was high (hence expensive verification and high area). As one of my colleagues on that team says: "Everybody wants to work on dataflow until he works on dataflow." Regarding history of dataflow architectures, [1] is from 1975, so half a century old this year.

[1] J. Dennis, A Preliminary Architecture for a Basic Data-Flow Processor https://courses.cs.washington.edu/courses/cse548/11au/Dennis...

Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

#138

Post by mdaniel » Sun, Jun 08, 2025, 5:08 PM UTC

AlotOfReading wrote: post #132

mdaniel wrote: post #129

Earlier quoted context omitted.

prelude: I realized that I typed out a ton of words but in the end engineering is all about tradeoffs, so, fine if there's a way I can teach some existing GPU, or some existing PCIe TPU, to access system RAM over an existing PCIe slot, that sounds like a fine step forward. I just don't have a lot of experience in that setup to know if only certain video cards allow that or what Bearing in mind the aforementioned "I'm…

Oh, it's not a good idea at all from a performance perspective to use system memory because it's slow as heck. The important thing is that you can do it. Some way of allowing the GPU to page in data from system RAM (or even storage) on an as-needed basis has been supported by Nvidia since at least Tesla generation. There's actually a multitude of different ways now that each have their own performance tradeoffs like…

That's interesting, thanks for making me aware. I'll try to dig up some reading material, but in some sense this is going the opposite of how I want the world to work because nvidia is already a supply chain bottleneck and so therefore saying "the solution to this supply and demand is more CUDA" doesn't get me where I want to go

> any CPU involvement is a further slowdown. This would also apply to socketed memory on a GPU though: Significantly slower and less bandwidth

I am afraid what I'm about to say doubles down on my inexperience, but: I could have sworn that series of problems is what DMA was designed to solve: peripherals do their own handshaking without requiring the CPU's involvement (aside from the "accounting" bits of marking regions as in-use). And thus if a GPGPU comes already owning its own RAM, it most certainly does not need to ask the CPU to do jack squat to talk to its own RAM because there's no one else who could possibly be using it

I was looking for an example of things that carried their own RAM and found this, which strictly speaking is what I searched for but is mostly just funny so I hope others get a chuckle too: a SCSI ram disk https://micha.freeshell.org/ramdisk/RAM_disk.jpg>

Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

#139

Post by AlotOfReading » Sun, Jun 08, 2025, 5:23 PM UTC

mdaniel wrote: post #138

AlotOfReading wrote: post #132

Earlier quoted context omitted.

Oh, it's not a good idea at all from a performance perspective to use system memory because it's slow as heck. The important thing is that you can do it. Some way of allowing the GPU to page in data from system RAM (or even storage) on an as-needed basis has been supported by Nvidia since at least Tesla generation. There's actually a multitude of different ways now that each have their own performance tradeoffs like…

That's interesting, thanks for making me aware. I'll try to dig up some reading material, but in some sense this is going the opposite of how I want the world to work because nvidia is already a supply chain bottleneck and so therefore saying "the solution to this supply and demand is more CUDA" doesn't get me where I want to go > any CPU involvement is a further slowdown. This would also apply to socketed memory on…

Sorry if that was confusing. I was trying to communicate a generality about multiple very different means of accessing the memory: the way we currently build GPUs is a local maximum for performance. Changing anything, even putting dedicated memory on sockets, has a dramatic and negative impact on performance. The latest board I've worked on saw the layout team working overtime to place the memory practically on top of the chip and they were upset it couldn't be closer.

Also, other systems have similar technologies, I'm just mentioning Nvidia as an example.

Re: Top researchers leave Intel to build startup with 'the biggest, baddest CPU'

#140

Post by pabs3 » Mon, Jun 09, 2025, 7:06 AM UTC

ahartmetz wrote: post #89

leetrout wrote: post #42

Earlier quoted context omitted.

For those that don't know about the Mill see https://millcomputing.com/ I came to this thread looking for a comment about this. I've been patiently following along for over a decade now and I'm not optimistic anything will come from the project :(

Yeah, I guess not at this point, but the presentations were very interesting to watch. According to the yearly(!) updates on their website, they are still going but not really close to finishing a product. Hm.

Last thing I read said they need investment to be able to get much further.