4 ms·

> I bristle anytime anyone thinks any existing functional language is better The parent comment doesn't say that, though. I imagine current functional languag

by geon 10y ago

> I bristle anytime anyone thinks any existing functional language is better The parent comment doesn't say that, though. I imagine current functional languages are about as ill suited as current imperative languages for running on a 1000 core machine. Something new might be needed.

tremon 10y ago
I think that the concept of purity, present mostly in functional languages, helps a lot for writing parallellizable (?) code. My naive assumption would be that pure code could be adapted for a 1000-core machine with only changes to the compiler and runtime environment. That said, few things in CS are written with this kind of parallellism in mind: even most algorithms' pseudocode is written in imperative style, and assumes the ratio of data to execution cores is on the same order as the data size itself. We definitely need something new. Both on the algorithmic front and on the architectural front. I suspect that on this scale, you could easily need more than 10% of the computing power simply to feed the right data to the correct cores. A programmable memory management unit might be helpful.
- geon 10y ago
  > My naive assumption would be that pure code could be adapted for a 1000-core machine with only changes to the compiler and runtime environment. Perhaps for use cases where current, garbage collected languages are suitable. For areas where (today) asm/c/c++/rust is a must, you would need a functional language that can give you guarantees about garbage generation, so you can be sure you won't need to collect garbage, at least in specific areas of the code. Perhaps a stream-oriented language would be suitable? The runtime could spin up more cores as needed depending on back-pressure.
  - marcosdumay 10y ago
    > For areas where (today) asm/c/c++/rust is a must, you would need a functional language that can give you guarantees about garbage generation That's the entire point of the "purity" idea. Pure FP languages give you very strict guarantees about garbage generation. The only question is if everyday code has enough pure code to fill a 1000 cores processor.
    - geon 10y ago
      > Pure FP languages give you very strict guarantees about garbage generation I thought the only guarantee is they don't have side effects.
      - marcosdumay 10y ago
        They are immutable, there's no implicit cross-dependency between data upper on the calling hierarchy, and any shared data can be recalculated as many times as needed. That's what I get from the top of my mind. There are probably more features that will help. Purity is a very strict guarantee.
- pjssjppjs 10y ago
  > We definitely need something new. Well, if only there would have been some ideas around… like TTA[0] or Dataflow architecture[1] These are just things that come to mind when thinking about an architecture like this. You'll probably still need something new, but this, instead of some bottle neck computing would be my starting point. Admittedly I'm still waiting for processors like thisat consumer prices, but those ideas seem to have been forgotten at a time when I was still figuring out how to tie shoelaces and such. [0]https://en.wikipedia.org/wiki/Transport_triggered_architecture https://en.wikipedia.org/wiki/Transport_triggered_architectu... [1]https://en.wikipedia.org/wiki/Dataflow_architecture https://en.wikipedia.org/wiki/Dataflow_architecture

by geon 10y ago

tremon 10y ago

I think that the concept of purity, present mostly in functional languages, helps a lot for writing parallellizable (?) code. My naive assumption would be that pure code could be adapted for a 1000-core machine with only changes to the compiler and runtime environment. That said, few things in CS are written with this kind of parallellism in mind: even most algorithms' pseudocode is written in imperative style, and assumes the ratio of data to execution cores is on the same order as the data size itself. We definitely need something new. Both on the algorithmic front and on the architectural front. I suspect that on this scale, you could easily need more than 10% of the computing power simply to feed the right data to the correct cores. A programmable memory management unit might be helpful.

geon 10y ago
> My naive assumption would be that pure code could be adapted for a 1000-core machine with only changes to the compiler and runtime environment. Perhaps for use cases where current, garbage collected languages are suitable. For areas where (today) asm/c/c++/rust is a must, you would need a functional language that can give you guarantees about garbage generation, so you can be sure you won't need to collect garbage, at least in specific areas of the code. Perhaps a stream-oriented language would be suitable? The runtime could spin up more cores as needed depending on back-pressure.
- marcosdumay 10y ago
  > For areas where (today) asm/c/c++/rust is a must, you would need a functional language that can give you guarantees about garbage generation That's the entire point of the "purity" idea. Pure FP languages give you very strict guarantees about garbage generation. The only question is if everyday code has enough pure code to fill a 1000 cores processor.
  - geon 10y ago
    > Pure FP languages give you very strict guarantees about garbage generation I thought the only guarantee is they don't have side effects.
    - marcosdumay 10y ago
      They are immutable, there's no implicit cross-dependency between data upper on the calling hierarchy, and any shared data can be recalculated as many times as needed. That's what I get from the top of my mind. There are probably more features that will help. Purity is a very strict guarantee.
pjssjppjs 10y ago
> We definitely need something new. Well, if only there would have been some ideas around… like TTA[0] or Dataflow architecture[1] These are just things that come to mind when thinking about an architecture like this. You'll probably still need something new, but this, instead of some bottle neck computing would be my starting point. Admittedly I'm still waiting for processors like thisat consumer prices, but those ideas seem to have been forgotten at a time when I was still figuring out how to tie shoelaces and such. [0]https://en.wikipedia.org/wiki/Transport_triggered_architecture https://en.wikipedia.org/wiki/Transport_triggered_architectu... [1]https://en.wikipedia.org/wiki/Dataflow_architecture https://en.wikipedia.org/wiki/Dataflow_architecture