5 ms·

So, functional programming then?

by nemoniac 9y ago

oppositelock 9y ago
Yup, basically.
- cm2187 9y ago
  It's not exactly functional programming. It can be a traditional OOP, just structured in independent blocks, and you execute each block on different threads. But the block internally can have as much shared state as it wants. You get the simplicity and familiarity of OOP and most of the benefits of multi-threading.
  - ece 9y ago
    I think the key words are "reentrant function" which in the context means atomic, pure functions. He didn't say something about OO, like DI or multiple inheritance in a some clean way, or something about classes or structs. This is more FP than not. By far.
agumonkey 9y ago
I'm tired of thinking this in my head but - skimming through doug lea concurrency articles: FP - thread safe C: pure functions, shared nothing: FP - comment above: FP at what point will people start to call it what it is ?
- deleted 9y ago
  [deleted]
- CyberDildonics 9y ago
  Because thinking that functional programming is going to solve all your problems is simple, easy, and wrong. Anyone who has written high performance software knows this. First, garbage collection without locks is extremely exotic, so likely all your memory allocations and deallocations will lock and with typical functional programming you will be doing a lot of them. Then you can get into what you mean by FP - if you share nothing then your communication is done by copying. This is not a magic bullet and isn't an option for many scenarios. If you do shared state for join parallelism you can cover other scenarios, but now you are sharing data. Atomics are very fast and work very well when they line up with the problem at hand. Then again, you are creating some sort of data structure that is made to have its state shared. If the problem was so easy to solve, it wouldn't be nearly as much a problem. Handwaving with 'just use FP' is naive and is more of a way for people to feel that they have the answer should anyone ask the question, but reality will quickly catch up.
  - agumonkey 9y ago
    What about immutability and shared structure. You can stream your computation in a way to avoid copying, avoid locking (unless you have to synchronize on a change). Persistent DS are rarely mentioned, I only know Demaine's course.
    - mbessey 9y ago
      Yeah, immutability was something that got kind of glossed over in that article (I'm the author). And Functional Programming was a lot less mainstream then. Maybe I should do an update.
      - agumonkey 9y ago
        Well you're excused, 2006 was a really different world. FP was still alien and multithreading probably a lot less mainstream. That said if you have new thoughts on the subject, please write them :)
    - CyberDildonics 9y ago
      > What about immutability and shared structure > You can stream your computation in a way to avoid copying Where is the synchronization in this scenario? You either have to decide how to split up the read only memory to different threads (fork join) or you have one thread make copies of pieces and 'send' them to other threads somehow. Arguably these are the same thing. This is one technique, but again, it doesn't cover every scenario. I don't know if calling it 'immutability' changes anything. > avoid locking (unless you have to synchronize on a change) Synchronizing on changes is the whole problem, you can't just hand wave it away as if it is a niche scenario. Anyone can create a program that has threads read memory and do computations. If you can modify the memory in place with no overlap between threads, even better. These however are the real niche scenarios, because the threads eventually need to do something with their results whether it's sending to video memory, writing to disk, or preparing data for another iteration or state in the pipeline. Then you have synchronization and that's the whole issue.
      - 9y ago
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]

So, functional programming then?

oppositelock 9y ago

Yup, basically.

cm2187 9y ago
It's not exactly functional programming. It can be a traditional OOP, just structured in independent blocks, and you execute each block on different threads. But the block internally can have as much shared state as it wants. You get the simplicity and familiarity of OOP and most of the benefits of multi-threading.
- ece 9y ago
  I think the key words are "reentrant function" which in the context means atomic, pure functions. He didn't say something about OO, like DI or multiple inheritance in a some clean way, or something about classes or structs. This is more FP than not. By far.

agumonkey 9y ago

I'm tired of thinking this in my head but - skimming through doug lea concurrency articles: FP - thread safe C: pure functions, shared nothing: FP - comment above: FP at what point will people start to call it what it is ?

deleted 9y ago
[deleted]
CyberDildonics 9y ago
Because thinking that functional programming is going to solve all your problems is simple, easy, and wrong. Anyone who has written high performance software knows this. First, garbage collection without locks is extremely exotic, so likely all your memory allocations and deallocations will lock and with typical functional programming you will be doing a lot of them. Then you can get into what you mean by FP - if you share nothing then your communication is done by copying. This is not a magic bullet and isn't an option for many scenarios. If you do shared state for join parallelism you can cover other scenarios, but now you are sharing data. Atomics are very fast and work very well when they line up with the problem at hand. Then again, you are creating some sort of data structure that is made to have its state shared. If the problem was so easy to solve, it wouldn't be nearly as much a problem. Handwaving with 'just use FP' is naive and is more of a way for people to feel that they have the answer should anyone ask the question, but reality will quickly catch up.
- agumonkey 9y ago
  What about immutability and shared structure. You can stream your computation in a way to avoid copying, avoid locking (unless you have to synchronize on a change). Persistent DS are rarely mentioned, I only know Demaine's course.
  - mbessey 9y ago
    Yeah, immutability was something that got kind of glossed over in that article (I'm the author). And Functional Programming was a lot less mainstream then. Maybe I should do an update.
    - agumonkey 9y ago
      Well you're excused, 2006 was a really different world. FP was still alien and multithreading probably a lot less mainstream. That said if you have new thoughts on the subject, please write them :)
  - CyberDildonics 9y ago
    > What about immutability and shared structure > You can stream your computation in a way to avoid copying Where is the synchronization in this scenario? You either have to decide how to split up the read only memory to different threads (fork join) or you have one thread make copies of pieces and 'send' them to other threads somehow. Arguably these are the same thing. This is one technique, but again, it doesn't cover every scenario. I don't know if calling it 'immutability' changes anything. > avoid locking (unless you have to synchronize on a change) Synchronizing on changes is the whole problem, you can't just hand wave it away as if it is a niche scenario. Anyone can create a program that has threads read memory and do computations. If you can modify the memory in place with no overlap between threads, even better. These however are the real niche scenarios, because the threads eventually need to do something with their results whether it's sending to video memory, writing to disk, or preparing data for another iteration or state in the pipeline. Then you have synchronization and that's the whole issue.
    - 9y ago

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]