5 ms·

Non-von Neumann architectures have a lot of catching up to do on the software side. Nearly every mainstream programming language has "get one thing from memory,

Non-von Neumann architectures have a lot of catching up to do on the software side. Nearly every mainstream programming language has "get one thing from memory, compute on it, put it back" semantics.

naasking 4y ago
Plenty don't though, like functional programming and relational databases. They're common enough these days.
- chowells 4y ago
  Eh. Most functional languages actually serialize operations pretty linearly in their default evaluation model, which is why they have explicit constructs for parallelism and concurrency. There are some languages that are intended to parallelize implicitly, though. They tend to use keywords like "data-parallel" and "array language" to describe themselves. Futhark is a good example: https://futhark-lang.org/ https://futhark-lang.org/
  - naasking 4y ago
    > Most functional languages actually serialize operations pretty linearly in their default evaluation model, which is why they have explicit constructs for parallelism and concurrency. Yes, but evaluation models can adapt easier when the language does not have explicit mutation, so there's less "catching up" to do for functional languages. Also concurrent programming will always require a separate class of constructs from parallelism. There's also: https://wiki.haskell.org/GHC/Data_Parallel_Haskell https://wiki.haskell.org/GHC/Data_Parallel_Haskell
    - chowells 4y ago
      Data Parallel Haskell has been deprecated since roughly when I started using Haskell. It's basically seen as a failed experiment.
  - hoosieree 4y ago
    And co-dfns: https://github.com/Co-dfns/Co-dfns https://github.com/Co-dfns/Co-dfns (subset of APL compiled for GPU).
bheadmaster 4y ago
> Nearly every mainstream programming language has "get one thing from memory, compute on it, put it back" As far as I remember, non-von Neumann architectures (Harvard architecture being the textbook example) are ones where program code is not stored in the same memory as data (please correct me if I'm wrong). Since most of the modern programs don't rely on modifying code in execution, why would software for non-von Neumann architectures be any different from the current software for von Neumann architectures?
- DSMan195276 4y ago
  The big difference in that situation is that you need to know whether a pointer is to your code memory or your data memory, most languages assume a single address space and don't make a distinction. Technically it's possible for the compiler/runtime to track that information and hide it from you but it would have overhead. If you look at writing C programs for AVR (Harvard architecture) there's a lot of extra stuff provided to allow reading from "program memory", with all regular pointers reading from RAM/data memory.
  - bheadmaster 4y ago
    I see - since most of the currently popular languages are object-oriented and implement inheritance through virtual table of function pointers, that would certainly at least slow things down significantly. Thanks for the clarification.
    - josephg 4y ago
      “Most” of the currently popular languages? That’s true for C++ and maybe Java and C#. Is that true for python or javascript? Swift? It’s definitely not true for newer languages like Scala, rust or zig.
      - xmcqdpt2 4y ago
        Scala is object oriented and anyway even if you write non OOP code it ends up (usually) on the JVM so you still get all the virtual tables stuff. If anything idiomatic Scala usually has significantly more pointer indirection than Java.
atoav 4y ago
I think what this is or could be (if I understood it correctly) is basically memory that can be configured to perform certain mutations "automatically" once you feed it data. Imagine something like an FPGA but with memory. So of course you have to find ways to make it do what you want, but that does not mean it could be combined with a traditional von Neumann architecture.

Non-von Neumann architectures have a lot of catching up to do on the software side. Nearly every mainstream programming language has "get one thing from memory, compute on it, put it back" semantics.

naasking 4y ago

Plenty don't though, like functional programming and relational databases. They're common enough these days.

chowells 4y ago
Eh. Most functional languages actually serialize operations pretty linearly in their default evaluation model, which is why they have explicit constructs for parallelism and concurrency. There are some languages that are intended to parallelize implicitly, though. They tend to use keywords like "data-parallel" and "array language" to describe themselves. Futhark is a good example: https://futhark-lang.org/ https://futhark-lang.org/
- naasking 4y ago
  > Most functional languages actually serialize operations pretty linearly in their default evaluation model, which is why they have explicit constructs for parallelism and concurrency. Yes, but evaluation models can adapt easier when the language does not have explicit mutation, so there's less "catching up" to do for functional languages. Also concurrent programming will always require a separate class of constructs from parallelism. There's also: https://wiki.haskell.org/GHC/Data_Parallel_Haskell https://wiki.haskell.org/GHC/Data_Parallel_Haskell
  - chowells 4y ago
    Data Parallel Haskell has been deprecated since roughly when I started using Haskell. It's basically seen as a failed experiment.
- hoosieree 4y ago
  And co-dfns: https://github.com/Co-dfns/Co-dfns https://github.com/Co-dfns/Co-dfns (subset of APL compiled for GPU).

bheadmaster 4y ago

> Nearly every mainstream programming language has "get one thing from memory, compute on it, put it back" As far as I remember, non-von Neumann architectures (Harvard architecture being the textbook example) are ones where program code is not stored in the same memory as data (please correct me if I'm wrong). Since most of the modern programs don't rely on modifying code in execution, why would software for non-von Neumann architectures be any different from the current software for von Neumann architectures?

DSMan195276 4y ago
The big difference in that situation is that you need to know whether a pointer is to your code memory or your data memory, most languages assume a single address space and don't make a distinction. Technically it's possible for the compiler/runtime to track that information and hide it from you but it would have overhead. If you look at writing C programs for AVR (Harvard architecture) there's a lot of extra stuff provided to allow reading from "program memory", with all regular pointers reading from RAM/data memory.
- bheadmaster 4y ago
  I see - since most of the currently popular languages are object-oriented and implement inheritance through virtual table of function pointers, that would certainly at least slow things down significantly. Thanks for the clarification.
  - josephg 4y ago
    “Most” of the currently popular languages? That’s true for C++ and maybe Java and C#. Is that true for python or javascript? Swift? It’s definitely not true for newer languages like Scala, rust or zig.
    - xmcqdpt2 4y ago
      Scala is object oriented and anyway even if you write non OOP code it ends up (usually) on the JVM so you still get all the virtual tables stuff. If anything idiomatic Scala usually has significantly more pointer indirection than Java.

atoav 4y ago

I think what this is or could be (if I understood it correctly) is basically memory that can be configured to perform certain mutations "automatically" once you feed it data. Imagine something like an FPGA but with memory. So of course you have to find ways to make it do what you want, but that does not mean it could be combined with a traditional von Neumann architecture.