3 ms·

I hope they design, build and sell a true 256-1024+ multicore CPU with local memories that appears as an ordinary desktop computer with a unified memory space f

I hope they design, build and sell a true 256-1024+ multicore CPU with local memories that appears as an ordinary desktop computer with a unified memory space for under $1000. I've written about it at length and I'm sure that anyone who's seen my comments is sick of me sounding like a broken record. But there's truly a vast realm of uncharted territory there. I believe that transputers and reprogrammable logic chips like FPGAs failed because we didn't have languages like Erlang/Go and GNU Octave/MATLAB to orchestrate a large number of processes or handle SIMD/MIMD simultaneously. Modern techniques like passing by value via copy-on-write (used by UNIX forking, PHP arrays and Clojure state) were suppressed when mainstream imperative languages using pointers and references captured the market. And it's really hard to beat Amdahl's law when we're worried about side effects. I think that anxiety is what inspired Rust, but there are so many easier ways of avoiding those problems in the first place.

zozbot234 1y ago
If you have 256-1024+ multicore CPUs they will probably have a fake unified memory space that's really a lot more like NUMA underneath. Not too different from how GPU compute works under the hood. And it would let you write seamless parallel code by just using Rust.
- deleted 1y ago
  [deleted]
jiggawatts 1y ago
Check out the Azure HBv5 servers. High bandwidth memory on-package with 352 AMD Zen 4 cores! With 7 TB/s memory bandwidth, it’s basically an x86 GPU. This is the future of high performance computing. It used to be available only for supercomputers but it’s trickling down to cloud VMs you can rent for reasonable money. Eventually it’ll be standard for workstations under your desk.
- nullc 1y ago
  it's kind of concerning that it's only available as a hosted product. Not good news for anyone that needs to run on-prem for confidentiality or availability reasons.
  - jiggawatts 1y ago
    I’m guessing the unit price is about $100K or higher, and it’s a niche product typically only used for HPC. If you’re a big enough customer, I’m sure you could buy these but I suspect the minimum order size is measured in the thousands of hosts.
- zackmorris 1y ago
  Thanks to you and the other commenters! - I just want to leave this breadcrumb showing possible markets and applications for high-performance computing (HPC), specifically regarding SpiNNaker which is simulating neural nets (NNs) as processes communicating via spike trains rather than matrices performing gradient descent: https://news.ycombinator.com/item?id=44201812 https://news.ycombinator.com/item?id=44201812 (Sandia turns on brain-like storage-free supercomputer) https://blocksandfiles.com/2025/06/06/sandia-turns-on-brain-like-storage-free-supercomputer/ https://blocksandfiles.com/2025/06/06/sandia-turns-on-brain-... (working implementation of 175,000 cores) https://www.theregister.com/2017/10/19/steve_furber_arm_brain_interview/ https://www.theregister.com/2017/10/19/steve_furber_arm_brai... (towards 1 million+ cores) https://www.youtube.com/watch?v=z1_gE_ugEgE https://www.youtube.com/watch?v=z1_gE_ugEgE (518,400 cores as of 2016) https://arxiv.org/pdf/1911.02385 https://arxiv.org/pdf/1911.02385 (towards 10 million+ cores) https://docs.hpc.gwdg.de/services/neuromorphic-computing/spinnaker/index.html https://docs.hpc.gwdg.de/services/neuromorphic-computing/spi... (HPC programming model) I'd use a similar approach but probably add custom memory controllers that calculate hashes for a unified content-addressable memory, so that arbitrary network topologies can be used. That way the computer could be expanded as necessary and run over the internet without modification. I'd also write something like a microkernel to expose the cores and memory as a unified desktop computing environment, then write the Python HPC programming model over that and make it optional. Then users could orchestrate the bare metal however they wish with containers, forked processes, etc. - A possible threat to the HPC market would be to emulate MIMD under SIMD by breaking ordinary imperative machine code up into parallelizable immutable (functional) sections bordered by IO handled by some kind of monadic or one-shot logic that prepares inputs and obtains outputs between the functional portions. That way individual neurons, agents for genetic algorithms, etc could be written in C-style or Lisp-style code that's transpiled to run on SIMD GPUs. This is an open problem that I'm having trouble finding published papers for: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4611137 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4611137 (has PDF preview and download) Without code examples, I'd estimate MIMD->SIMD performance to be between 1-2 orders of magnitude faster than a single-threaded CPU and 1-2 orders of magnitude slower than a GPU. Similar to scripting languages vs native code. My spidey sense is picking up so many code smells around this approach though that I suspect it may never be viable. - I'd compare the current complexities around LLMs running on SIMD GPUs to trying to implement business logic as a spaghetti of state machines instead of coroutines running conditional logic and higher-order methods via message passing. Loosely that means that LLMs will have trouble evolving and programming their own learning models. Whereas HPC doesn't have those limitations, because potentially every neuron can learn and evolve on its own like in the real world. So a possible bridge between MIMD and SIMD would be to transpile CPU machine code coroutines to GPU shader state machines: https://news.ycombinator.com/item?id=18704547 https://news.ycombinator.com/item?id=18704547 https://eli.thegreenplace.net/2009/08/29/co-routines-as-an-alternative-to-state-machines https://eli.thegreenplace.net/2009/08/29/co-routines-as-an-a... In the end, they're equivalent. But a multi-page LLM specification could be reduced down to a bunch of one-liners because we can reason about coroutines at a higher level of abstraction than state machines.
anthk 1y ago
Forth can.
david-gpu 1y ago
The challenges that arise when you have a massively parallel system are well understood by now. It is hard to keep all processing units doing something useful rather than waiting for memory or other processing units. Once you follow the logical steps to increase utilization/efficiency you end up with something like a GPU, and that comes with the programming challenges that we have today. In other words, it's not like CPU architects didn't think of that. Instead, there are good reasons for the status quo.

zozbot234 1y ago

If you have 256-1024+ multicore CPUs they will probably have a fake unified memory space that's really a lot more like NUMA underneath. Not too different from how GPU compute works under the hood. And it would let you write seamless parallel code by just using Rust.

deleted 1y ago
[deleted]

jiggawatts 1y ago

Check out the Azure HBv5 servers. High bandwidth memory on-package with 352 AMD Zen 4 cores! With 7 TB/s memory bandwidth, it’s basically an x86 GPU. This is the future of high performance computing. It used to be available only for supercomputers but it’s trickling down to cloud VMs you can rent for reasonable money. Eventually it’ll be standard for workstations under your desk.

nullc 1y ago
it's kind of concerning that it's only available as a hosted product. Not good news for anyone that needs to run on-prem for confidentiality or availability reasons.
- jiggawatts 1y ago
  I’m guessing the unit price is about $100K or higher, and it’s a niche product typically only used for HPC. If you’re a big enough customer, I’m sure you could buy these but I suspect the minimum order size is measured in the thousands of hosts.
zackmorris 1y ago
Thanks to you and the other commenters! - I just want to leave this breadcrumb showing possible markets and applications for high-performance computing (HPC), specifically regarding SpiNNaker which is simulating neural nets (NNs) as processes communicating via spike trains rather than matrices performing gradient descent: https://news.ycombinator.com/item?id=44201812 https://news.ycombinator.com/item?id=44201812 (Sandia turns on brain-like storage-free supercomputer) https://blocksandfiles.com/2025/06/06/sandia-turns-on-brain-like-storage-free-supercomputer/ https://blocksandfiles.com/2025/06/06/sandia-turns-on-brain-... (working implementation of 175,000 cores) https://www.theregister.com/2017/10/19/steve_furber_arm_brain_interview/ https://www.theregister.com/2017/10/19/steve_furber_arm_brai... (towards 1 million+ cores) https://www.youtube.com/watch?v=z1_gE_ugEgE https://www.youtube.com/watch?v=z1_gE_ugEgE (518,400 cores as of 2016) https://arxiv.org/pdf/1911.02385 https://arxiv.org/pdf/1911.02385 (towards 10 million+ cores) https://docs.hpc.gwdg.de/services/neuromorphic-computing/spinnaker/index.html https://docs.hpc.gwdg.de/services/neuromorphic-computing/spi... (HPC programming model) I'd use a similar approach but probably add custom memory controllers that calculate hashes for a unified content-addressable memory, so that arbitrary network topologies can be used. That way the computer could be expanded as necessary and run over the internet without modification. I'd also write something like a microkernel to expose the cores and memory as a unified desktop computing environment, then write the Python HPC programming model over that and make it optional. Then users could orchestrate the bare metal however they wish with containers, forked processes, etc. - A possible threat to the HPC market would be to emulate MIMD under SIMD by breaking ordinary imperative machine code up into parallelizable immutable (functional) sections bordered by IO handled by some kind of monadic or one-shot logic that prepares inputs and obtains outputs between the functional portions. That way individual neurons, agents for genetic algorithms, etc could be written in C-style or Lisp-style code that's transpiled to run on SIMD GPUs. This is an open problem that I'm having trouble finding published papers for: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4611137 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4611137 (has PDF preview and download) Without code examples, I'd estimate MIMD->SIMD performance to be between 1-2 orders of magnitude faster than a single-threaded CPU and 1-2 orders of magnitude slower than a GPU. Similar to scripting languages vs native code. My spidey sense is picking up so many code smells around this approach though that I suspect it may never be viable. - I'd compare the current complexities around LLMs running on SIMD GPUs to trying to implement business logic as a spaghetti of state machines instead of coroutines running conditional logic and higher-order methods via message passing. Loosely that means that LLMs will have trouble evolving and programming their own learning models. Whereas HPC doesn't have those limitations, because potentially every neuron can learn and evolve on its own like in the real world. So a possible bridge between MIMD and SIMD would be to transpile CPU machine code coroutines to GPU shader state machines: https://news.ycombinator.com/item?id=18704547 https://news.ycombinator.com/item?id=18704547 https://eli.thegreenplace.net/2009/08/29/co-routines-as-an-alternative-to-state-machines https://eli.thegreenplace.net/2009/08/29/co-routines-as-an-a... In the end, they're equivalent. But a multi-page LLM specification could be reduced down to a bunch of one-liners because we can reason about coroutines at a higher level of abstraction than state machines.

anthk 1y ago

Forth can.

david-gpu 1y ago

The challenges that arise when you have a massively parallel system are well understood by now. It is hard to keep all processing units doing something useful rather than waiting for memory or other processing units. Once you follow the logical steps to increase utilization/efficiency you end up with something like a GPU, and that comes with the programming challenges that we have today. In other words, it's not like CPU architects didn't think of that. Instead, there are good reasons for the status quo.