해석 된 코드와 컴파일 된 코드의 성능에 대한 일반적인 진술을 할 수 있습니까?

회사가 사용해야 할 권장 사항에 도달하기 위해 두 가지 기술을 비교하고 있습니다. 기술 A의 코드는 해석되는 반면 기술 B의 코드는 기계 코드로 컴파일됩니다. 필자의 비교에서 나는 기술 B가 해석 프로세스의 추가 오버 헤드가 없기 때문에 일반적으로 더 나은 성능을 가질 것이라고 언급했다. 또한 프로그램을 여러 가지 방법으로 작성할 수 있기 때문에 기술 A로 작성된 프로그램이 기술 B로 작성된 프로그램보다 성능이 우수 할 수 있습니다.

검토를 위해이 보고서를 제출했을 때, 검토자는 일반적으로 해석 프로세스의 오버 헤드가 기술 B의 성능이 더 좋다고 결론을 내릴만큼 충분히 큰 이유를 밝히지 않았다고 밝혔습니다.

그래서 제 질문은 컴파일 / 해석 된 기술의 성능에 대해 말할 수 있습니까? 컴파일이 일반적으로 더 빠르다고 해석 할 수 있다면 리뷰어에게 내 요점을 어떻게 확신시킬 수 있습니까?

아니.

일반적으로 언어 구현의 성능은 주로 돈, 자원, 인력, 연구, 엔지니어링 및 개발에 소비 된 금액에 달려 있습니다.

특히, 특정 프로그램의 성능은 주로 알고리즘에 대한 생각의 양에 달려 있습니다.

몇 가지가 있습니다 매우 거기에 빠른 통역, 및 생성 어떤 컴파일러 매우 느린 코드.

예를 들어, Forth가 여전히 인기있는 이유 중 하나는 많은 경우 해석 된 Forth 프로그램이 동등한 컴파일 된 C 프로그램보다 빠르며 동시에 Forth로 작성된 사용자 프로그램 과 Forth 인터프리터로 작성된 것입니다. C에서 C로 작성된 사용자 프로그램보다 작 습니다.

일반화와 특정 시나리오는 문자 적으로 반대입니다.

당신은 모순되는 것 같습니다. 한편으로, 당신은 해석 된 언어와 컴파일 된 언어에 대한 일반적인 진술을 원합니다. 그러나 다른 한편으로, 기술 A 및 기술 B와 관련된 구체적인 시나리오에이 일반 진술을 적용하려고합니다.

구체적인 시나리오에 무언가를 적용하면 더 이상 일반화되지 않습니다 . 따라서 통역 된 언어가 일반적으로 느리다고 주장 할 수는 있지만, 여전히 논점은 아닙니다. 검토자는 일반화에 신경 쓰지 않습니다. 매우 구체적인 두 가지 기술을 분석하고 있습니다. 그것은 말 그대로 일반화와 반대입니다.

일반적으로, 해석 된 프로그램은 프로그램을 통역사의 호스트 언어로 작성하는 것보다 약 2 ~ 10 배 느리고 동적 언어에 대한 통역이 느립니다. 해석 된 프로그램은 모든 실제 작업을 수행해야하지만 해석 오버 헤드가 추가로 발생하기 때문입니다.

통역사의 구조에 따라 매우 큰 차이가있을 수 있습니다. 통역사 디자인에는 모순되는 두 가지 학교가 있습니다. 하나는 opcode가 최대한 쉽게 작아야 최적화 할 수 있고 다른 하나는 opcode가 최대한 커야 통역사 내에서 더 많은 일을 할 수 있다고 말합니다. 프로그램 구조가 인터프리터의 철학과 일치하면 오버 헤드는 무시할 수 있습니다.

예를 들어 Perl은 텍스트 조작을 지향하는 해석 언어입니다. 텍스트 조작을 수행하는 관용적 Perl 프로그램은 C 프로그램보다 훨씬 느리지 않으며 경우에 따라 C 프로그램보다 성능이 우수 할 수도 있습니다 (Perl은 다른 문자열 표현을 사용하고 다양한 텍스트 및 IO 관련 최적화 기능이 내장되어 있기 때문에 가능). 그러나 Perl에서 숫자 크 런칭을하는 것은 참으로 느리게 진행될 것입니다. 증분 ++x은 단일 어셈블리 명령어이지만 Perl 인터프리터의 여러 포인터 순회 및 분기와 관련됩니다. 최근에 CPU 바인딩 된 Perl 스크립트를 C ++로 이식했으며 컴파일러 최적화 수준에 따라 7 배 ~ 20 배 속도가 빨라졌습니다.

최적화 된 인터프리터가 최적화되지 않은 순진한 컴파일러보다 성능이 뛰어 나기 때문에 최적화에 대해 말하는 것이 중요합니다. 최적화 컴파일러를 작성하는 것은 어렵고 많은 노력이 필요하기 때문에 "기술 B"에 이러한 수준의 성숙이있을 가능성은 낮습니다.

(참고 : 컴퓨터 언어 벤치 마크 게임 사이트는 혼동되는 구조를 가지고 있지만 한 가지 문제에 대한 타이밍 테이블에 도달하면 다양한 언어의 성능이 모든 곳에서 나타납니다. 종종 명확한 성능 경계가 없습니다. 사이트의 가장 중요한 부분은 벤치 마크 결과가 아니라 의미있는 벤치 마크가 얼마나 어려운지에 대한 토론입니다.)

기술을 선택할 때 언어 런타임 자체의 성능은 전혀 관련이 없습니다. 기술이 일부 기본 제약 조건 (예산이 $ x, yyyy-mm-dd 이전에 제공 할 수 있어야하며 다양한 비 기능 요구 사항을 충족해야 함)을 충족시키는 것이 중요하며, 총 소유 비용 (개발자 생산성, 하드웨어 비용, 비즈니스 기회 비용, 버그 위험 및 기술의 예상치 못한 제약 조건, 유지 관리 비용, 교육 및 고용 비용 등). 예를 들어, 출시 기간이 가장 중요한 산업 인 경우 최고의 개발자 생산성을 갖춘 기술이 가장 적합합니다. 대규모 조직의 경우 유지 관리 성과 장기 비용이 더 흥미로울 수 있습니다.

컴파일 / 해석 된 기술의 성능에 대해 말할 수 있습니다. 그러나 먼저 "성능"을 정의해야합니다. 계산적으로 간단한 임베디드 시스템을 구축하는 경우 "성능"은 메모리 사용 측면에 기대어있을 것입니다. 대용량 데이터 세트에서 작동하는 계산 상 복잡한 시스템은 JVM 또는 .NET의 메모리 오버 헤드가 무시할 수 있기 때문에 단위 시간당 계산 수에서 "성능"을 정의하는 것으로 판단됩니다.

"성능"이 무엇인지 결정한 후에는 "언제든지 메모리에 500 억 개의 객체가 있고 해석 된 techA는 내부 관리를 위해 각 객체에 추가로 8 바이트를 추가하여 400GB의 메모리 오버 헤드와 같습니다 이 데이터를 추가하지 않는 techB와 비교할 때 "

이것은 기술적 인 질문이며 이미 많은 좋은 기술적 답변을 얻었지만 상황의 약간 다른 측면을 지적하고 싶습니다. "기술 A 또는 기술 B"와 같은 결정을 순전히 결정할 수 없다는 사실 기술 및 / 또는 성능상의 이유로.

이와 같은 기술적 측면은 A와 B 사이의 결정에서 아주 작은 부분 일뿐입니다. 명심해야 할 다른 요소는 수십 가지가 있습니다.

• 라이센스 비용이 포함됩니까? 예를 들어 : PostgreSQL 머신 클러스터를 사용하는 것과 비교하여 SQL Server 머신 클러스터를 사용하려면 상당한 금액을 지불해야합니다.
• 해당 기술 (스택)과 생태계에 익숙한 직원이 있습니까? 그렇다면, 가능합니까? 그렇지 않다면 일부를 고용 할 수 있습니까? 비용이 얼마나 듭니까? 아니면 기존 교육을 훈련합니까? 비용이 얼마나 듭니까?
• 고객이 원하는 것은 무엇입니까? 이것은 많은 시간이 걸릴 수 있습니다.
• 내가 권장하는 기술이 프로덕션 용으로 준비되어 있습니까? 아니면 현재의 과대 광고일까요? (예 : Node.js가 처음 나왔을 때 생각하십시오)
• 내가 추천하는 기술이 기존 아키텍처 또는 내가 생각한 아키텍처와 잘 맞습니까? 아니면 서로 원활하게 연동하여 많은 돈을 써야합니까?
• 특정 상황에 따라 더 많은 측면이 있습니다.

보시다시피, 그러한 결정을 내릴 때 고려해야 할 많은 것들이 있습니다.

나는 이것이 당신의 질문에 구체적으로 대답하지는 않는다는 것을 알고 있지만, 그것이 당신의 상황과 그러한 결정의 세부 사항에 대해 더 큰 그림보기를 가져 온다고 생각합니다.

부분 평가 는 인터프리터 및 컴파일러와 관련된 개념적 프레임 워크입니다.

해석 된 코드와 컴파일 된 코드의 성능에 대한 일반적인 진술을 할 수 있습니까?

프로그래밍 언어는 사양입니다 ( R5RS 또는 n1570 과 같은 일부 보고서에 작성 ). 그것들은 소프트웨어 가 아니기 때문에 성능 을 말하는 것도 의미가 없습니다 . 그러나 일부 프로그래밍 언어에는 인터프리터 및 컴파일러를 포함하여 여러 가지 구현이있을 수 있습니다 .

C와 같이 전통적으로 컴파일 된 언어 (즉, 구현 이 종종 컴파일러 인 언어 )에서도 일부 부분은 종종 해석됩니다. 예를 들어, 형식 제어 스트링 의 printf (C 표준에서 정의 된)는 자주 (의해 "해석" C 표준 라이브러리 가지고 printf 기능 하지만, 일부 가변 인수 기술을 사용하여) 컴파일러 (포함 GCC를 ) -in 수 한정된 특정한 경우-최적화하고 하위 수준 호출로 "컴파일"합니다.

또한 "통역사"내에서도 일부 구현은 JIT 컴파일 기술을 사용 하므로 런타임시 기계 코드를 생성합니다 . 좋은 예는 luajit 입니다. 다른 구현 (예 : Python, Ocaml, Java, Parrot, Lua)은 소스 코드를 바이트 코드로 변환 한 다음 해석됩니다.

SBCL 은 모든 REPL 상호 작용 (및 기타 호출 eval)을 기계 코드로 동적으로 변환하는 Common Lisp "컴파일러" 입니다. 그래서 당신은 그것이 통역 인이라고 생각합니다. 브라우저 (예 : v8 ) 에서 대부분의 JavaScript 구현은 JIT 컴파일 기술을 사용합니다.

다시 말해, 인터프리터와 컴파일러의 차이는 매우 모호하며 (실제로 둘 다에 연속체가 있음) 실제로 대부분의 프로그래밍 언어 구현 에는 종종 인터프리터와 컴파일러 (최소 바이트 코드까지)가 있습니다.

구현은 대부분의 "컴파일러"또는 "인터프리터"와 유사한 기술을 사용하여 독립적으로 빠르거나 느릴 수 있습니다.

일부 언어 특성은 해석 방식을 선호합니다 ( 전체 프로그램 분석을 통해서만 효율적으로 컴파일 할 수 있음 ).

들어 일부 문제의 유형, 일부 소프트웨어를 설계 메타 프로그래밍 접근하는 것은 가치가 중요한 속도 업을 제공합니다. 특정 입력이 주어지면 프로그램 이 처리하기 위해 특수 코드를 동적으로 생성 한다고 상상할 수 있습니다. C 또는 C ++ 에서도 가능합니다 (일부 JIT 라이브러리를 사용하거나 C 코드를 생성하여 동적으로로드되는 플러그인으로 컴파일).

참조 이 관련 파이썬에 대한 질문을하고, 그

와 같은 코드의 경우 A = A + B하나 또는 두 개의 기계 명령어로 컴파일 할 수 있으며 각각 특정 횟수의 사이클을 수행합니다. 간단한 이유로 그 횟수만큼 같은 해석을 할 수있는 통역사는 없습니다.

인터프리터는 또한 자체 명령 세트를 실행합니다 (바이트 코드, p 코드, 중간 언어 등). ADD와 같은 바이트 코드를 볼 때마다 어떻게 든 그것을 찾아서 추가하는 코드로 분기해야합니다.

다음 그것을 볼 때, 그것은하는 반복 , 그 조회를 제외하고 는 사전 조회를 기억하는 방법이있다. 이전 검색을 기억하는 방법이 없다면 더 이상 "인터프리터"라고하는 것이 아니라 JITter (Just-In-Time) 컴파일러입니다.

반면에 ...

와 같은 코드의 경우 callSomeFunction( ... some args ...)해당 코드를 입력하고 떠나는 데 얼마나 많은 사이클이 소비됩니까? 그것은 모두 내부에서 일어나는 일에 달려 있습니다 callSomeFunction. callSomeFunction자체 컴파일 된 경우에도 몇 개가 될 수 있으며 수조가 될 수 있습니다 . 그것이 많으면 해당 코드 라인의 해석 비용에 대해 논쟁 할 필요가 없습니다. 돈은 다른 곳입니다.

해석 된 언어는 컴파일 할 필요가없는 것과 같이 고유 한 값을 갖습니다. (표면 구문의 바이트 코드로의 "컴파일"에는 사소한 시간이 걸립니다. 예를 들어 R 또는 MATLAB을 사용하십시오.)

또한 지능적인 수준의 프로그래밍에 유연성이 필요합니다. Minsky 's Society of Mind , Chapter 6.4 B- Brains에는 세계를 다루는 A 프로그램이 있으며 A 프로그램을 다루는 B 프로그램이 있으며 더 많은 레벨이있을 수 있습니다. 다른 프로그램을 작성하고 관리하는 프로그램은 해석 시스템에서보다 쉽게 ​​수행 할 수 있습니다.

Lisp에서는 (+ A B)A와 B를 추가하기 위해 작성할 수 있지만 일단 작성되면 실행할 수 있습니다. 당신은 또한 쓸 수있는 (eval (list '+ 'A 'B))프로그램을 구성하는 다음을 실행합니다. 다른 것을 만들 수 있습니다.

프로그램의 주제는 다른 프로그램 입니다. 이것은 해석 된 언어로 작성하기가 더 쉽습니다 (Jörg가 지적한 것처럼 최신 버전의 Lisp는 eval컴파일 중이므로 컴파일 속도가 빠르지 않습니다).

종류에 따라 다르지만 일반적으로 JIT를 통해 컴파일되거나 정적으로 컴파일 된 컴파일 환경은 많은 컴퓨팅 집약적 작업에서 더 빠를 것입니다. 단순한 동일한 언어를 가정합니다.

해석 된 언어에는 인터프리터 루프 루프가 있어야 명령을 읽고 적절한 조치를 선택하여 실행할 수 있습니다. Python 또는 Java 바이트 코드를 해석하는 것과 같은 가장 좋은 경우 ( 이전 JVM과 마찬가지로) 몇 가지 명령 오버 헤드가 있으며 분기 예측 변수로 혼란을 겪었습니다. 마지막 명령이 없으면 잘못된 예측으로 인해 큰 처벌을받을 수 있습니다. 매우 바보 같은 JIT조차도 이것을 크게 가속화해야합니다.

그것은 통역 된 언어가 바람을 피울 수 있다고 말했다. 예를 들어 Matlab은 행렬 곱셈에 최적화 된 루틴을 가지고 있으며 약간의 변경만으로도 GPU에서 코드를 실행할 수 있습니다 (면책 조항 : nVidia에서 근무합니다-여기에 표시된 의견은 모두 본인의 견해를 나타내지 않습니다). 그렇게하면 세부 사항에 대해 걱정할 필요없이 짧고 강력한 상위 코드를 작성할 수 있습니다. 누군가가 코드를 관리하고 저수준 언어로 코드를 최적화하는 데 시간과 리소스를 투입했습니다. 그것에 대해 상속 된 것은 없으며, 예를 들어 Matlab이 코드를 JIT하는 것을 막지 못하지만 종종 높은 수준의 루틴을 호출하는 오버 헤드가 낮은 수준의 시간과 비교하여 최소화되는 이유가 없습니다.

TL; DR-컴파일 된 프로그램은 해석 된 프로그램에 비해 큰 성능 이점이 있습니다 (애플-애플 비교의 경우 PyPy Speed 참조 ). 그러나 실행 속도는 문제의 일부일 뿐이며 전체 속도에 크게 기여하지 않을 수 있습니다 (시간이 대부분 라이브러리에서 소비되는 경우). 또한 구현이 중요합니다.

귀하의 가정은 가정이지만 잘 확립되어 있습니다.

컴파일 된 코드 가 해석 된 코드보다 빠른 이유를 다루지 않을 것입니다 . 컴퓨터가 어떻게 작동하는지 알고 있다면 분명합니다. 차이점은 특정 유형의 문제에 대해 수십 배가 될 수 있습니다. 검토자가 일반적인 경우에 대해 이의를 제기하는 경우 자신의 의견을 모릅니다.

그들이 포인트를 가질 수있는 곳은 개발중인 응용 프로그램의 유형에 차이가 있는지 여부입니다. 대부분 I / O이거나 대부분 컴파일 된 라이브러리를 호출하고 계산이 많지 않은 경우 해석 프로세스의 오버 헤드가 실제로 중요하지 않을 수 있습니다.

그러나 나의 포스트의 요점은 이것이다. IT 전문가로서 당신은 일이 어떻게 작동해야하는지에 대한 일반적인 지식에 기초하여 결정을 내릴 때가 종종있다. 특정 테스트를 수행하면보다 정확한 답변을 얻을 수 있지만 비용이 더 많이 들고 먼저 도착하지는 않습니다.

그러나 때때로 당신은 잡히게됩니다. 나 한테 일어난 일이야 당신은 좋은 가정을하고 세상의 어리 석음을 고려하지 않은 것을 알게됩니다.

그러나 나는 내가 가장 좋아하는 Dilbert 만화뿐만 아니라 설명 할 수 없다. 현명한 엉덩이가되는 것보다 더 좋은 것은 없습니다.

TL; DR : 당신은 옳 아야하지만, 만일의 경우를 위해 실제 세계를 확인하십시오.

다소 이국적인 것을 사용하지 않는 한, 문제는 해석 된 언어 A와 컴파일 된 언어 B에 대한 성능에 관한 것이 아닙니다.

귀하 / 귀하의 팀이 B가 아닌 A를 알고 B보다 A에서 더 나은 코드를 작성한다면 A보다 B에서 훨씬 더 나은 성능을 얻을 수 있습니다. 한 언어에 경험이있는 사람들이 있고 언어 / 라이브러리가 당신이 필요로하는 직업, 그것에 충실하십시오.

다음은 다양한 언어로 된 정규식에 대한 링크입니다. 컴파일 여부에 관계없이 정규 표현식이 일부 언어로 더 잘 구현되어 있음을 알 수 있습니다. http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=regexdna

하나는 컴파일되고 다른 하나는 해석된다는 사실에 근거하여 두 기술의 성능에 대해 이야기하는 것은 좋은 생각이 아닙니다. 다른 답변에서 언급했듯이 응용 프로그램 영역 (일부 언어는 일부 작업을 매우 빠르게 수행하고 다른 작업은 더 느리게 수행하도록 최적화 됨)과 해당 기술을 사용하려는 사람들의 경험에 따라 달라질 수 있습니다.

훌륭한 해석 언어 코더를 사용하고 익숙하지 않은 기술을 제공하면 성능이 향상 될 것이라고 기대하는 것이 합리적이라고 생각하지 않습니다. 이론적으로 후자가 더 나은 성능을 초래할 수도 있지만 실제로는 필요한 기술과 경험이 없으면 모든 최적화 기회를 사용하지는 않습니다.

유명한 실리콘 밸리 회사 직원 중 한 명으로부터 나는 숙련 된 개발자들에게 복잡하지만 고도로 최적화 된 코드를 유지하는 것보다 비용이 많이 들고 번거롭기 때문에 사용하기가 더 쉬운 언어를 선호한다고 들었습니다. 덜 효율적인 구현을 처리하기 위해 더 많은 장비를 구입하므로 기술을 선택할 때도 고려해야합니다.

일단 큰 결정을 정당화하기 위해 비슷한 진술을해야했습니다.

첫째, 그들은 겸손한 엔지니어를 믿기를 원하지 않을 수 있으므로 필자는 비슷한 벤치 마크 테스트를 찾아 인용했습니다. 마이크로 소프트 나 유명한 대학 같은 사람들로부터 많은 것들이 있습니다. 그리고 그들은 다음과 같이 말할 것입니다 : 방법 A는 변수 X와 Y에 따라 방법 B보다 3-10 배 빠릅니다.

둘째, 문제의 코드 덩어리 또는 이미 가지고있는 유사한 코드를 사용하여 자체 벤치 마크를 실행할 수 있습니다. 밤새 1000 번 실행하면 실제로 측정 가능한 차이가 있습니다.

이 시점에서 A와 B의 차이점 (또는 부족)은 명확해야합니다. 따라서 가능한 모든 다이어그램을 사용하여 모든 가정을 명시하고 사용 된 모든 데이터를 정의하여 결과를 명확하게 형식화하십시오.

동적 언어는 정적으로 컴파일 된 언어에 비해 장점이 있다고 주장합니다. "런타임 최적화"

이것이 Java가 C ++보다 빠를 수있는 이유 중 하나입니다.

예, 동적으로 유형이 지정된 언어를 로드 하면 항상 번역 비용이 발생하며 단점이 있습니다. 그러나 일단 실행되면, 인터프리터는 정적 언어가 절대로 가질 수없는 런타임 정보로 빈번한 코드 경로를 프로파일 링하고 향상시킬 수 있습니다.

참고 : Java는 동적 언어가 아닌 해석 된 언어입니다. 그러나 런타임 정보로 속도를 높일 수있는 좋은 예입니다

... 또한 프로그램을 여러 가지 방법으로 작성할 수 있기 때문에 기술 A로 작성된 프로그램이 기술 B로 작성된 프로그램보다 성능이 우수 할 수 있습니다.

검토를 위해이 보고서를 제출했을 때, 검토자는 일반적으로 해석 프로세스의 오버 헤드가 기술 B의 성능이 더 좋다고 결론을 내릴만큼 충분히 큰 이유를 밝히지 않았다고 밝혔습니다. ...

이것은 내 접근 방식입니다.

일반적으로 인터프리터는 컴파일되므로 모든 해석 된 기술은 낮은 수준에서 살펴보면 컴파일 된 기술에 지나지 않습니다. 따라서 컴파일 된 기술은 더 많으며 더 많은 가능성으로 더 똑똑 할 수 있습니다 (일반적으로 귀하는 그렇습니다). 컴파일 타임에 사용할 수있는 정보의 양과 런타임시에만 사용할 수있는 정보의 양과 컴파일러와 인터프리터의 성능에 따라 다르지만 이론적으로는 항상 적절한 컴파일러를 사용하여 모든 인터프리터의 성능을 동일하게 유지할 수 있어야합니다. 인터프리터가 컴파일러로 제작 되었기 때문입니다. 가능하다고해서 그것이 기술 A와 B에 해당되는 것은 아닙니다.

실제로, 컴파일 된 시스템과 해석 된 시스템을 비교할 수있는 모든 벤치 마크에 대해 검토 자에게 알려주십시오. 그런 다음 최적화 된 어셈블리 코드 별 알고리즘을 능가하는 통역사를 제안 해달라고 요청하십시오.

두 가지 특정 기술 A와 B를 비교할 때 그러한 일반적인 진술이 전혀 도움이되지 않는다고 덧붙여 야 할 것입니다 .A와 B의 선택은 해석되거나 컴파일되는 것보다 훨씬 중요합니다.