굳이 C나 러스트로 컴파일러 안만들고
자기자신으로 컴파일러로 만드는 이유가 뭐지
예를들어
자바로 자바 컴파일러(2)를 만들면
자바 컴파일러(2)를 컴파일 해주는 자바 컴파일러(1) 의 최적화 여부가 결정 날텐데
자바 컴파일러(1)은 C나 Rust 로 만든 컴파일러로 컴파일이 됐을테니까
메모리 관리나 흑마법 빡세게 해서 최적화가 좋았을거 아님?
근데 다음 세대 자바 컴파일러는 C나 Rust 수준의 최적화는 못할테니 오히려 안좋아지는거 아닌가
처음에만 C 등으로 만들고, 그 다음부턴 자기가 자기 자신을 컴파일 하면 되는거지 - dc App
v1 컴파일러로 v2 를 만들고, v2로 v3를 만들고... - dc App
그 말 하는거 아닌데...
뭔말함 - dc App
C로 만든게 더 성능 좋은거 아니냐는 뜻
필수는 아니지만 적어도 자신의 언어로 만든 컴파일러정도는 있는게 기본이라고 생각함. - dc App
typescript 는 rust, go로 만든 컴파일러도 잘 쓰이고 있으니 개발자 맘인듯 - dc App
typescript는 엄연히 말해서 compile 하는게 아니지...
왜? - dc App
pypy처럼 부트스트래핑 한게 최적화가 더 좋은 경우도 있고 결정적으로 그 언어의 개발 속도가 빨라짐
성능보단 생산성 문제
어차피 컴파일 속도가 느려지는거지 출력물 퍼포먼스가 느려지는게 아니잖아
출력물 퍼포먼스가 느려지지 않는 이유를 잘 모르겠음
C 컴파일러가 두개 있다고 해보자. 이 두개 컴파일러로 똑같은 C프로그램을 컴파일 했는데 동작이 서로 다르면 컴파일러가 엉터리인거지
근데 실제로 UB 때문에 컴파일러마다 최적화가 다르고 동작이 다른 경우가 있잖음.
class Foo 라는 구문을 C 에서 구조체로 가지고 있을지, Java 로 클래스로 가지고 있을지의 차이로 오버헤드가 생길 수 있을거 같은데 아님?
실제 바이너리가 다르다고 동작이 다른게 아니라고
'컴파일러'의 속도가 느려지는 거고 '컴파일된 결과물' 의 속도는 컴파일 로직에만 상관있지
짠 언어랑 무슨 상관이야 어차피 어셈블리로 뱉는건데