1. Lazy
계산이 지연된 thunk들이 메모리를 차지한다.
2. IO Monad
하스켈 프로그램은 먼저 main메소드로 IO모나드를 만들고, 해당 IO모나드를 실행시키는 두 과정으로 진행된다.
이것도 1번과 마찬가지 이야기인데,
일종의 고차함수가 거대한 함수를 반환하고, 그것을 한꺼번에 실행시키는 셈.
거대한 IO모나드가 메모리를 차지한다.
3. 재귀
아무리 최적화가 들어간다해도 재귀를 많이쓰면 메모리를 많이 먹지 않을까?
이 세가지가 제가 의심중인 하스켈의 메모리 사용량입니다.
3번은 최적화기법들이 문제를 해결했을것 같고,
1번 2번의 경우에는 다음 질문의 답에 따라 해석이 달라질것같습니다.
(물론, 이론상의 추정이 아닌 실제 메모리사용량이 중요하고, 그것이 궁금합니다)
다음 질문:
고차함수가 함수를 일급객체로 다룰때,
함수는 코드영역에 있는가 힙 영역에 있는가?
만약 함수나 표현식이 코드영역에 있는 데이터를 참조하는것이라면,
thunk는 표현식 전체에 대한 데이터를 생성할 필요가 없습니다만,
그래도 어떤 값이 무엇에 바인딩되었는지를(현재의 계산상태를) 알기 위해 thunk마다 힙영역의 데이터가 필요하긴 할것같습니다.
만약 함수나 표현식이 코드영역에 있는 데이터를 참조하는 것이라면,
IO모나드가 거대해 지더라도 데이터는 코드영역에 있는 데이터를 재사용할 뿐이기 때문에 메모리사용량이 그렇게까지 많지는 않을수도 있습니다.
한줄요약:
하스켈이 strict언어보다 메모리를 많이먹는지 궁금하고, 고차함수가 함수데이터를 다룰때 함수 데이터들의 코드쪼가리들이 어떻게 재사용되는지가 궁금합니다.(재사용되지 않고 표현식마다 코드들을 복제해서 들고있을거라고 생각되지는 않음)
계산이 지연된 thunk들이 메모리를 차지한다.
2. IO Monad
하스켈 프로그램은 먼저 main메소드로 IO모나드를 만들고, 해당 IO모나드를 실행시키는 두 과정으로 진행된다.
이것도 1번과 마찬가지 이야기인데,
일종의 고차함수가 거대한 함수를 반환하고, 그것을 한꺼번에 실행시키는 셈.
거대한 IO모나드가 메모리를 차지한다.
3. 재귀
아무리 최적화가 들어간다해도 재귀를 많이쓰면 메모리를 많이 먹지 않을까?
이 세가지가 제가 의심중인 하스켈의 메모리 사용량입니다.
3번은 최적화기법들이 문제를 해결했을것 같고,
1번 2번의 경우에는 다음 질문의 답에 따라 해석이 달라질것같습니다.
(물론, 이론상의 추정이 아닌 실제 메모리사용량이 중요하고, 그것이 궁금합니다)
다음 질문:
고차함수가 함수를 일급객체로 다룰때,
함수는 코드영역에 있는가 힙 영역에 있는가?
만약 함수나 표현식이 코드영역에 있는 데이터를 참조하는것이라면,
thunk는 표현식 전체에 대한 데이터를 생성할 필요가 없습니다만,
그래도 어떤 값이 무엇에 바인딩되었는지를(현재의 계산상태를) 알기 위해 thunk마다 힙영역의 데이터가 필요하긴 할것같습니다.
만약 함수나 표현식이 코드영역에 있는 데이터를 참조하는 것이라면,
IO모나드가 거대해 지더라도 데이터는 코드영역에 있는 데이터를 재사용할 뿐이기 때문에 메모리사용량이 그렇게까지 많지는 않을수도 있습니다.
한줄요약:
하스켈이 strict언어보다 메모리를 많이먹는지 궁금하고, 고차함수가 함수데이터를 다룰때 함수 데이터들의 코드쪼가리들이 어떻게 재사용되는지가 궁금합니다.(재사용되지 않고 표현식마다 코드들을 복제해서 들고있을거라고 생각되지는 않음)
딱국추
IO도 컴파일하면 걍 기계어임. 그런거 없음
laziness는 메모리 사용량이 많다기 보다는 잘못 사용하면 space leak이 발생하기 쉽긴 함
고차함수도 그냥 다른언어 closure랑 비슷하게 구현됨. 함수 포인터, capture된 변수, partial application된 인자들을 연속된 메모리 공간에다가 모아두는 방식
와 고차함수의 구현부분 명쾌하네요. 하스켈이 람다대수의 구현이라는게 와닿음. 이렇게 고급개념을 마구사용하면서도 메모리얘기가 없다니... 놀라운데요? 뭔가 하이테크 언어 보는 기분이에요
GC가 있음
https://wiki.haskell.org/GHC/Memory_Management
딱국추