Erlang과 Haskell의 혼합




functional-programming garbage-collection (4)

함수 프로그래밍 패러다임을 구입했다면 Erlang과 Haskell을 좋아할 가능성이 있습니다. 둘 다 순전히 기능적인 코어와 멀티 코어 환경에 적합한 경량 스레드와 같은 다른 장점을 가지고 있습니다. 하지만 약간의 차이점이 있습니다.

Erlang은 상업적으로 입증 된 결함 허용 언어로서 성숙한 배포 모델입니다. 핫 코드 로딩을 ​​통해 런타임에 버전을 업그레이드 할 수있는 독특한 기능이 있습니다. (멋지다!)

한편, Haskell은 주류 언어 중 가장 정교한 형식 시스템을 가지고 있습니다. (내가 '주류'를 O'Reilly 책이 출판 된 어떤 언어로 정의 하스켈은 그렇게 생각한다.) 그것의 직선 단일 스레드 성능은 Erlang의 우월하고 가벼운 스레드는 훨씬 가볍게 보인다.

나는 나머지 코딩 인생을 위한 개발 플랫폼을 구성하려고 노력하고 있으며 최선의 플랫폼을 얻기 위해 Erlang과 Haskell을 섞을 수 있는지 궁금해하고 있었다. 이 질문에는 두 부분이 있습니다.

  1. Erlang을 GHC 런타임 인스턴스를 함께 묶는 일종의 내결함성 MPI로 사용하고 싶습니다. GHC 런타임마다 Erlang 프로세스가 하나씩 있습니다. "불가능한 일이 생겼다"와 GHC 런타임이 죽으면 Erlang 프로세스가 어떻게 든 그것을 감지하고 죽을 것입니다. Erlang의 핫 코드로드 및 배포 기능은 계속 작동합니다. GHC 런타임은 하나의 코어 만 사용하거나 로컬 시스템의 모든 코어를 사용하거나 중간에 모든 조합을 사용하도록 구성 할 수 있습니다. Erlang 라이브러리가 작성되면 Erlang 레벨 코드의 나머지 부분은 순전히 상용구가되어야하며 애플리케이션별로 자동 생성됩니다. (예를 들어, Haskell DSL에 의한 것일 수도 있습니다.) 이러한 것들 중 적어도 일부를 달성하는 방법은 무엇입니까?
  2. Erlang과 Haskell이 같은 Garabage Collector를 공유 할 수 있기를 바랍니다. JVM과 CLR에서 실행되는 언어는 런타임을 공유하여 더 많은 양을 차지합니다. JVM 또는 CLR에서 Erlang (핫 코드로드) 및 Haskell (높은 종류의 다형성)을 실행하는 데 기술적 제한이 있다는 것을 알고 있습니다. 하지만 가비지 컬렉터 만 분리하면 어떨까요? (일종의 함수형 언어 런타임 시작). 할당은 분명히 여전히 빨라야 할 것입니다. 그래서 그 비트는 정적으로 링크되어야합니다. 그리고 가변 힙과 불변 힙을 구별하기위한 몇 가지 메커니즘이 있어야합니다. GHC가 이것을 필요로하기 때문에 메모리를 한 번 쓰는 게으름). 가비지 컬렉터가 힙을 공유 할 수 있도록 HIPE와 GHC를 모두 수정하는 것이 가능합니까?

경험 (긍정적 또는 부정적), 아이디어 또는 제안으로 답하십시오. 사실, 어떤 의견 (곧바로 학대의 짧은!) 환영합니다.

최신 정보

지금까지 4 개의 모든 답장을 보내 주셔서 감사합니다. 각자 제가 모르는 유용한 것을 적어도 하나씩 가르쳐주었습니다.

코딩 인생의 나머지 부분과 관련 해서 - 나는 토론을 촉발하기 위해 약간의 혀를 뺨에 포함 시켰지만 실제로는 사실입니다. 내가 죽을 때까지 일하려고하는 프로젝트가 있으며, 안정적인 플랫폼이 필요합니다.

위에서 제안한 플랫폼에서는 하스켈 만 작성하고, 상용구 Erlang은 자동으로 생성됩니다. 하스켈은 얼마나 오래 지속될 것입니까? Lisp은 여전히 ​​우리와 함께하고 있으며 곧 사라질 것 같지 않습니다. Haskell은 BSD3 오픈 소스이며 임계 질량을 달성했습니다. 프로그래밍 자체가 50 년 후에도 계속된다면 하스켈이나 하스켈의 지속적인 진화가 여전히 여기에있을 것으로 기대합니다.

rvirding의 게시물에 대한 응답으로 2 업데이트

동의 함 - 완벽한 "Erskell / Haslang"범용 가상 머신을 구현하는 것이 절대 불가능하지는 않을지 모르나 실제로는 매우 어려울 것입니다. 가비지 콜렉터 레벨 만 VM과 같은 것으로 공유하는 것은 여전히 어렵지만 , 내게는 덜 어려운 일입니다. 가비지 수집 모델에서 함수형 언어는 불변의 데이터 (썽크 포함)의 불균형과 매우 빠른 할당을 요구하는 공통점이 많이 있어야합니다. 공통성이 모 놀리 식 VM으로 단단히 묶여 있다는 사실은 이상하게 보입니다.

VM은 임계 질량을 달성하는 데 도움이됩니다. F #과 Scala와 같은 'lite'기능 언어가 어떻게 사라 졌는지 살펴보십시오. 스칼라는 Erlang의 절대적인 내결함성을 가지고 있지는 않지만, JVM에 묶여있는 많은 사람들에게 탈출 경로를 제공한다.

단일 힙을 사용하면 메시지 전달 속도가 매우 빨라지지만 여러 가지 다른 문제가 발생합니다. GC를 수행하는 것이 인터랙티브하고 전역 적으로 중단되지 않아야하므로 GC를 수행하는 것이 더 어려워집니다. 따라서 인터프리터가 아닌 인터럽트없이 동일한 간단한 알고리즘을 사용할 수 없습니다. 프로세스 힙 모델.

물론, 그것은 나에게 완벽한 의미입니다. GHC 개발팀의 현명한 사람들은 문제의 일부를 "세계를 멈추게하는"GC와 함께 해결하려고 노력하고있는 것 같습니다.

http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf

(분명히 "세계를 멈추게한다"는 Erlang의 주요 유스 케이스에 대해서는 비행하지 않을 것이다.) 그러나 "세계를 멈추게한다"는 유스 케이스에서도 속도가 보편적이지는 않다. 그래서 나는 당신과 동의합니다. 보편적으로 가장 좋은 GC가있을 것 같지 않습니다. 이것이 제가 제 질문의 제 1 부에서 지정한 이유입니다.

GHC 런타임은 하나의 코어 만 사용하거나 로컬 시스템의 모든 코어를 사용하거나 중간에 모든 조합을 사용하도록 구성 할 수 있습니다.

이런 방식으로 주어진 유스 케이스에 대해 벤치마킹 한 후에 얼랭 (Erlang) 방식을 선택하고 코어 당 하나의 얼랑 (Erlang) 프로세스를 더한 하나의 GHC 런타임 (단일 스레드 GC로)을 실행하고 얼랑 (Erlang)이 좋은 지역 .

또는 프로세서 당 4 개의 코어와 프로세서의 메모리 대역폭이 좋은 듀얼 프로세서 시스템에서 벤치마킹은 프로세서 당 하나의 Erlang 프로세스와 하나의 GHC 런타임 (병렬 GC 사용)을 실행하는 것이 좋습니다.

두 경우 모두 Erlang과 GHC가 힙을 공유 할 수 있다면 공유는 아마도 단일 코어에서 실행되는 단일 OS 스레드에 묶여있을 것입니다. (나는 여기서 깊이 빠져 나가고 있는데, 나는 그 질문을했다.)

또한 GC와는 독립적으로 기능 언어를 벤치마킹하는 또 다른 의제가 있습니다. 종종 OCaml v GHC v Erlang v의 벤치마킹 결과를 읽었으며 결과가 다른 GC에 의해 얼마나 혼란스럽게되는지 궁금합니다. GC의 선택이 기능적 언어의 선택과 직각이 될 수 있다면 어떨까요? GC는 어쨌든 비쌉니까? 이 악마 옹호자 블로그 게시물보기

http://john.freml.in/garbage-collection-harmful

내 Lisp 친구 John Fremlin이 글을 올렸습니다. 자신의 게시물 제목 인 "Automated Garbage Collection is rubbish"가 주어졌습니다. 존 (John)이 GC가 느리다고 말했고 실제로 그렇게 많이 향상되지는 않았지만 몇 가지 숫자에 맞설 수 있기를 바랍니다.


  1. OTP gen_supervisor 프로세스를 사용하여 open_port ()로 생성 한 하스켈 인스턴스를 모니터링 할 수 있습니다. "포트"가 어떻게 종료했는지에 따라, 다시 시작하거나 의도적으로 멈추고 해당 얼랑 프로세스도 죽게 할 수 있습니다.

  2. Fugheddaboudit. 당신이 말하는 이러한 언어 독립적 인 VM조차도 가끔 언어간에 전달되는 데이터에 문제가 있습니다. 어떻게 든 두 가지 사이의 데이터를 직렬화해야합니다 : 데이터베이스, XML-RPC, 그런 것.

그건 그렇고, 남은 평생 동안 단일 플랫폼에 대한 아이디어는 아마도 비실용적 일 것입니다. 컴퓨팅 기술과 패션은 너무 자주 변경되어 한 언어 만 계속 사용할 수 있습니다. 여러분의 바로 그 질문은 이것을 지적합니다. 오늘날까지도 우리가 원하는 모든 것을하는 언어는 없습니다.


Haskell과 Erlang 사람들은 Erlang이 배포를 감독하는 모델에 관심이 있고, Haskell은 공유 메모리 노드를 병렬로 실행하여 모든 번호 계산 / 논리를 수행합니다.

이것에 대한 시작은 haskell-erlang 라이브러리입니다 : http://hackage.haskell.org/package/erlang

그리고 우리는 Hubris를 통해 Ruby에서 유사한 노력을했습니다 : http://github.com/mwotton/Hubris/tree/master

문제는 실제로 Erlang / Haskell interop을 통해 까다로운 문제를 찾아내는 사람을 찾는 것입니다.


그의 의견에 언급 된 dizzyd는 메시지의 모든 데이터가 복사되는 것은 아니기 때문에 큰 바이너리는 프로세스 힙 외부에 존재하며 복사되지 않습니다.

다른 메모리 구조를 사용하여 프로세스 별 힙 (heap)을 분리하는 것을 피할 수 있으며 이전 구현에서 여러 번 수행되었습니다. 단일 힙을 사용하면 메시지 전달 속도가 매우 빨라지지만 여러 가지 다른 문제가 발생합니다. GC를 수행하는 것이 인터랙티브하고 전역 적으로 중단되지 않아야하므로 GC를 수행하는 것이 더 어려워집니다. 따라서 인터프리터가 아닌 인터럽트없이 동일한 간단한 알고리즘을 사용할 수 없습니다. 프로세스 힙 모델.

우리가 사용하는 한 불변의 데이터 구조를 가지고있는 한 견고성과 안전성에는 문제가 없다. 사용할 메모리 및 GC 모델을 결정하는 것은 큰 트레이드 오프이며 불행히도 보편적으로 가장 좋은 모델입니다.

Haskell과 Erlang은 둘 다 기능적 언어이지만 많은면에서 매우 다른 언어이며 매우 다른 구현을 가지고 있습니다. 두 언어를 효율적으로 처리 할 수있는 "Erskell"(또는 Haslang) 기계를 개발하는 것은 어려울 것입니다. 나는 개인적으로 그것들을 분리하여 유지하는 것과 당신이 그들 사이에 좋은 인터페이스를 가지고 있는지 확인하는 것이 훨씬 더 낫다고 생각합니다.


이것은 꽤 오래된 스레드이지만 독자가 여전히 관심이 있다면 Cloud Haskell을 살펴 보는 것이 좋습니다. Cloud Haskell 은 Erlang 스타일의 동시성과 GHC 안정적 배포를 제공합니다.

다가오는 distributed-process-platform 라이브러리는 gen_servers, 감독 트리 및 Erlang / OTP에서 차용 한 다양한 "haskell flavored"추상화와 같은 OTP-esque 구문에 대한 지원을 추가합니다.







ghc