4 ms·

well just today i sped up a simple algorithm by a factor of two or three on larger data sets by simply turning on parallelism in a for loop, which distributes i

well just today i sped up a simple algorithm by a factor of two or three on larger data sets by simply turning on parallelism in a for loop, which distributes iterations across cores and then merges them afterwards. so multicore performance came for free. in other instances, when programming concurrent programs, i have no worry of performance losses because, again, multicore support comes for free. that is more qualitative, but it is important. and it means my concurrent programs are actually concurrent.

yawaramin 8y ago
Regarding your simple algorithm, that's great but map/reduce is a well-known 'embarrassingly parallelizable' algorithm. If the majority of your code is map/reduce that's great for you but a lot of code is not trivially parallelizable like that. The problem with 'no worry of performance losses' with multicore is that using multiple cores itself has a cost. You need to split up your workload, schedule the work across the cores, pass the actual data as messages to whatever 'task' abstraction you're using, and unless the garbage collector has fancy tricks, this will mean having to deep-copy the data to preserve thread safety. So again, there's no such thing as a free lunch in multicore.
- nikofeyn 8y ago
  > If the majority of your code is map/reduce that's great for you who said it was? (it isn’t.) you asked for examples, and i gave the most recent one. > You need to split up your workload, schedule the work across the cores, pass the actual data as messages to whatever 'task' abstraction you're using, and unless the garbage collector has fancy tricks, this will mean having to deep-copy the data to preserve thread safety. you’re making a huge amount of assumptions and supposed “costs” here based upon the rather limiting nature of most programming languages when it comes to concurrency. most of the multicore programming i do is with actors with a data flow language. multicore programming is so trivial you don’t even think about it.
  - yawaramin 8y ago
    > who said it was? (it isn’t.) you asked for examples, and i gave the most recent one. OK, but then, outside of that kind of use case, most applications are not trivially parallelizable like that. > most of the multicore programming i do is with actors with a data flow language. multicore programming is so trivial you don’t even think about it. Maybe I miscommunicated, but I don't mean that you literally are doing all these things, but that something is–some combination of the language, the runtime, and the developer. My point is that no matter who is doing it, these things have costs–runtime performance, memory use, limits on the usable data structures and programming techniques.

yawaramin 8y ago

Regarding your simple algorithm, that's great but map/reduce is a well-known 'embarrassingly parallelizable' algorithm. If the majority of your code is map/reduce that's great for you but a lot of code is not trivially parallelizable like that. The problem with 'no worry of performance losses' with multicore is that using multiple cores itself has a cost. You need to split up your workload, schedule the work across the cores, pass the actual data as messages to whatever 'task' abstraction you're using, and unless the garbage collector has fancy tricks, this will mean having to deep-copy the data to preserve thread safety. So again, there's no such thing as a free lunch in multicore.

nikofeyn 8y ago
> If the majority of your code is map/reduce that's great for you who said it was? (it isn’t.) you asked for examples, and i gave the most recent one. > You need to split up your workload, schedule the work across the cores, pass the actual data as messages to whatever 'task' abstraction you're using, and unless the garbage collector has fancy tricks, this will mean having to deep-copy the data to preserve thread safety. you’re making a huge amount of assumptions and supposed “costs” here based upon the rather limiting nature of most programming languages when it comes to concurrency. most of the multicore programming i do is with actors with a data flow language. multicore programming is so trivial you don’t even think about it.
- yawaramin 8y ago
  > who said it was? (it isn’t.) you asked for examples, and i gave the most recent one. OK, but then, outside of that kind of use case, most applications are not trivially parallelizable like that. > most of the multicore programming i do is with actors with a data flow language. multicore programming is so trivial you don’t even think about it. Maybe I miscommunicated, but I don't mean that you literally are doing all these things, but that something is–some combination of the language, the runtime, and the developer. My point is that no matter who is doing it, these things have costs–runtime performance, memory use, limits on the usable data structures and programming techniques.