6 ms·

I'm an ex game engine developer and I bristle anytime anyone thinks any existing functional language is better for multicore. Specifically garbage collection al

I'm an ex game engine developer and I bristle anytime anyone thinks any existing functional language is better for multicore. Specifically garbage collection alone will make any language an order of magnitude slower generally per a single core. Also the C/C++ game development community at least has great approaches to multicore which makes C/C++ linearly scale with scores to boot, see for example: http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine http://www.gdcvault.com/play/1022186/Parallelizing-the-Naugh.... I love functional languages, more for thinking in them, prototyping ideas, especially compilers/visualizers, and etc. But for any language that adds garbage collection, immutable data structures (way more operations per write and crazy memory thrashing/alignment issues), unless used sparsely or in a mixed paradigm (ugh, except maybe scala/clojure) are going to pay a magnitude of performance loss. Mind you there are tricks around using more system languages (C/C++/Rust/D etc) for a lot of the heavy lifting with the application core being functional that gets you closer to the best of both worlds.

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
raphaelj 10y ago
Garbage collection is not slow. Actually it's probably the fastest dynamic allocation method. Allocating data with a copying garbage collector is O(1), which is as fast as allocating something on the stack, while malloc() is usually O(log(n)) with n being the number of live objects in the heap. Running a collection on a such GC is usually O(n), with n begin the number of live objects. This is way faster than calling free() on each allocated object, but slower than using the stack. They idea that languages that rely on a garbage collector are slower is not really due to the garbage collector, but to the fact that they allocate way too much on the heap (I'm looking at you, Java). C/C++/Rust are awesome because they allow you to control way more where data is allocated. Also, it's theoretically possible for a compiler in a functional programming language to decide to allocate on the stack instead of the heap. Another issue is that the time is will take to execute the collection can be unpredictable. It can happen that the GC will stop the entire program for a few milliseconds every few seconds. This is highly undesirable for realtime applications such as video-games.
- imtringued 10y ago
  The only problem with GCs is the stop the world pause. I'm seriously wondering why not more languages have a gc per "process" like erlang.
  - nickpsecurity 10y ago
    The only problem with "stop-the-world" GC's on hardware not built for them. There's "pauseless" collectors out there where that either doesn't happen or happens so fast you don't experience it. Some do microseconds. One was in a Scheme machine where they put it into the memory subsystem. So, the program just allocated, deleted, whatever with a parallel, hardware GC managing pages in the background. Many things one can do in GC's. The only one I know with mainstream success is Azul's: http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf http://www.azulsystems.com/sites/default/files/images/c4_pap... https://www.azul.com/products/zing/ https://www.azul.com/products/zing/ Note: No affiliation with them. Their Azul systems and pauseless GC were simply the best stuff I found researching Java & GC hardware. Assuming they match marketing claims. ;)
zbobet2012 10y ago
Garbage collection is an idea. It can be slower, or faster, than other memory management techniques depending on implementation and specific usage. Functional programming languages do not _require_ a GC. They just largely have it. "Fibers" like you linked in the presentation (m:n green thread scheduling) have been in use for decades. Many, many languages other than C++ have had them for over a decade. Go is built on them. Functional languages _can be_ better for multicore because of referential transparency. As a game dev you are used to working on 4-8 cores. Some of us work on 40-80 cores * 10k machines and have been for years. Much of your complaints such as immutable data overhead make sense if it let's you work on 10x more cores at the same time. I will also point out that immutable data _really_ is not 10x slower, unless you think those Haskell micro bench marks are all lies.
- valarauca1 10y ago
  >Functional programming languages do not _require_ a GC. They just largely have it. No they just require Infinite Memory [1] XOR GC. Pure Functional programming has no concept of Alloc/Delloc. Let alone the concept of binding/assignment can fail. These are real. To quote James Michens [2] >Pointers are real. They’re what the hardware understands. Somebody has to deal with them. You can’t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis. Denying the existence of pointers is like living in ancient Greece and denying the existence of Krackens and then being confused about why none of your ships ever make it to Morocco, or Ur-Morocco, or whatever Morocco was called back then. Pointers are like Krackens—real, living things that must be dealt with so that polite society can exist. [1] Infinite memory simply means more memory then the program can ever consume... But the halting problem exists so you can't actually know how much memory your program will consume :P [2] http://scholar.harvard.edu/files/mickens/files/thenightwatch.pdf http://scholar.harvard.edu/files/mickens/files/thenightwatch...
  - kazinator 10y ago
    Pure functional programming doesn't require any special memory management beyond the stack, if it avoids any data representations that use reference semantics and have indefinite lifetimes. Lazy evaluation and higher order functions with environment are pretty much out. But even C can be functional: int (*pg)(int) = f(); int x = h() + 2*z; int w = pg(y); /* ... etc */ Here, we just introduce new variables instead of assigning new ones, don't malloc anything and indirect only by means of dumb function pointers carrying no environments. There could be some higher level (though nonetheless quite primitive) assignment-free language for specifying tasks for the 1000 cores of this chip, instead of programming them in assembler.
kazinator 10y ago
> I bristle anytime anyone thinks any existing functional language is better for multicore. .. and have they read the paper for this multicore? Though it has a large number of processors, there are severe resource constraints per node, with respect to how large a local program can be and how much memory is available.
- JoeAltmaier 10y ago
  But virtualizing such things is what OSs are all about.

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

raphaelj 10y ago

Garbage collection is not slow. Actually it's probably the fastest dynamic allocation method. Allocating data with a copying garbage collector is O(1), which is as fast as allocating something on the stack, while malloc() is usually O(log(n)) with n being the number of live objects in the heap. Running a collection on a such GC is usually O(n), with n begin the number of live objects. This is way faster than calling free() on each allocated object, but slower than using the stack. They idea that languages that rely on a garbage collector are slower is not really due to the garbage collector, but to the fact that they allocate way too much on the heap (I'm looking at you, Java). C/C++/Rust are awesome because they allow you to control way more where data is allocated. Also, it's theoretically possible for a compiler in a functional programming language to decide to allocate on the stack instead of the heap. Another issue is that the time is will take to execute the collection can be unpredictable. It can happen that the GC will stop the entire program for a few milliseconds every few seconds. This is highly undesirable for realtime applications such as video-games.

imtringued 10y ago
The only problem with GCs is the stop the world pause. I'm seriously wondering why not more languages have a gc per "process" like erlang.
- nickpsecurity 10y ago
  The only problem with "stop-the-world" GC's on hardware not built for them. There's "pauseless" collectors out there where that either doesn't happen or happens so fast you don't experience it. Some do microseconds. One was in a Scheme machine where they put it into the memory subsystem. So, the program just allocated, deleted, whatever with a parallel, hardware GC managing pages in the background. Many things one can do in GC's. The only one I know with mainstream success is Azul's: http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf http://www.azulsystems.com/sites/default/files/images/c4_pap... https://www.azul.com/products/zing/ https://www.azul.com/products/zing/ Note: No affiliation with them. Their Azul systems and pauseless GC were simply the best stuff I found researching Java & GC hardware. Assuming they match marketing claims. ;)

zbobet2012 10y ago

Garbage collection is an idea. It can be slower, or faster, than other memory management techniques depending on implementation and specific usage. Functional programming languages do not _require_ a GC. They just largely have it. "Fibers" like you linked in the presentation (m:n green thread scheduling) have been in use for decades. Many, many languages other than C++ have had them for over a decade. Go is built on them. Functional languages _can be_ better for multicore because of referential transparency. As a game dev you are used to working on 4-8 cores. Some of us work on 40-80 cores * 10k machines and have been for years. Much of your complaints such as immutable data overhead make sense if it let's you work on 10x more cores at the same time. I will also point out that immutable data _really_ is not 10x slower, unless you think those Haskell micro bench marks are all lies.

valarauca1 10y ago
>Functional programming languages do not _require_ a GC. They just largely have it. No they just require Infinite Memory [1] XOR GC. Pure Functional programming has no concept of Alloc/Delloc. Let alone the concept of binding/assignment can fail. These are real. To quote James Michens [2] >Pointers are real. They’re what the hardware understands. Somebody has to deal with them. You can’t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis. Denying the existence of pointers is like living in ancient Greece and denying the existence of Krackens and then being confused about why none of your ships ever make it to Morocco, or Ur-Morocco, or whatever Morocco was called back then. Pointers are like Krackens—real, living things that must be dealt with so that polite society can exist. [1] Infinite memory simply means more memory then the program can ever consume... But the halting problem exists so you can't actually know how much memory your program will consume :P [2] http://scholar.harvard.edu/files/mickens/files/thenightwatch.pdf http://scholar.harvard.edu/files/mickens/files/thenightwatch...
- kazinator 10y ago
  Pure functional programming doesn't require any special memory management beyond the stack, if it avoids any data representations that use reference semantics and have indefinite lifetimes. Lazy evaluation and higher order functions with environment are pretty much out. But even C can be functional: int (*pg)(int) = f(); int x = h() + 2*z; int w = pg(y); /* ... etc */ Here, we just introduce new variables instead of assigning new ones, don't malloc anything and indirect only by means of dumb function pointers carrying no environments. There could be some higher level (though nonetheless quite primitive) assignment-free language for specifying tasks for the 1000 cores of this chip, instead of programming them in assembler.

kazinator 10y ago

> I bristle anytime anyone thinks any existing functional language is better for multicore. .. and have they read the paper for this multicore? Though it has a large number of processors, there are severe resource constraints per node, with respect to how large a local program can be and how much memory is available.

JoeAltmaier 10y ago
But virtualizing such things is what OSs are all about.