굳이 병렬처리를 함슬람식으로 할필요 있냐

[익명(211.246)]

씨샵이나 go처럼 언어 차원에서 스레딩 하면 되지

[커헠(msca8h)]

그게 아니야. 함수형처럼 함수들이 완전 병렬적으로 설계가 가능한걸 Embarassingly Parallel 이라고 하는데, 함수형은 거의 모든 설계들이 그러한 반면 C#, C++ 등의 명령형 언어들은 대부분의 경우에는 공유메모리를 이용한 병렬 설계가 나오잖아. 공유메모리 병렬 설계는 락킹 등의 문제로 인해서 부끄러울 정도로 병렬인 설계들 보다 성능이 떨어질 수 밖에 없고, 개발자는 머리가 터져

[커헠(msca8h)]

그래서 함수형 설계 방식들을 도입하는거야. 병렬에서 생산성도 성능도 더 높으니까

[Ja2(turningeye)]

네 꼭 그렇게 해야 합니다. 쓰레드가 자원을 같이 공유 할 경우 일반적인 접근은 잠금장치를 사용하는 건데요. 이 경우 잠금 장치를 남용하면, 병렬 처리의 효율이 올라가지 않는 점. 두번째로 도저히 코드상에서 버그를 고칠 수 없는 하이젠버그의 문제가 있습니다. CPU 자체도 알아서 최적화를 수행 하기 때문에, 쓰레드를 던지는 순간 이제 방법은 최악의 상황이 발생하지 않도록 기도하는 방법 밖에 없습니다.

[Ja2(turningeye)]

이를 해결하기 위해서 함수의 사이드 이펙트를 억제하고 변수의 mutability를 제거 하는 것이죠. Java in concurrency 를 읽어 보시면, 이책은 자바에서 동시성 프로그래밍을 어떻게 하기 위한 방법 보단 mutable 변수로 동시성 프로그래밍을 하는 것이 얼마나 고된 일인 지를 설명하고 있습니다. 참고로 저자는 자바의 동시성 라이브러리의 저자 이기도 합니다.

[익명(1.236)]

병렬처리로 인한 스케쥴링 문제로는 Richard anomalies가 있습니다. 관심이 있다면 꽤나 흥미로운 내용일 것입니다.

[Ja2(turningeye)]

만약 자원이 분리된 경우라면 병렬 처리 시 한다면 이문제에서는 조금 자유로워 집니다. 대표적으로는 matrix 계산이 있겠네요. 즉 문제는 코드가 외부 환경과 적극적으로 커뮤니케이션 하지 않는 아주 제한된 상항을 제외 하면 단순히 코드에 쓰레드를 뿌려 놓으면 안좋은 일은 언젠가 터집니다. 그것도 최악의 상황에요.

[츄럴(119.198)]

크 함슬람들... 열변...

[Ja2(turningeye)]

그런데 go는 이런쪽으로 지원이 잘 돼있다고 알고 있습니다. 함수형인지는 살펴보지 않아서 모르겠네요.

[익명(14.45)]

C로 OOP하는 경우도 있듯이 함수형 잘 이해하면 다른 언어로도 구현가능함

[츄럴(119.198)]

어쨌든 뭔가 새로운 멋진 무언가가 나와서 병렬처리에 고통 받는 후로그래머들을 구원해야할 것인데.. 그것이 함슬람일지 lust니 go 같은 애들일지는 10년 쯤 지나면 알 수 있을 거 같다

[츄럴(119.198)]

난 함슬람을 응원합니다.. 람다 후 함크바르!