가장 빠른 기능적 언어


18

나는 최근에 기능 프로그래밍, 특히 Haskell과 F #에 대해 더 깊이 연구 해 왔습니다. 인터넷 검색 후 더 유명한 기능 언어 (Scala, F # 등)의 벤치 마크 비교를 찾을 수 없었습니다.

하이브리드라는 점을 감안할 때 일부 언어 (Scala가 염두에 두는 것)에 반드시 공평하지는 않지만 어떤 운영 및 전체에서 어떤 성능을 능가하는지 알고 싶습니다.


18
언어는 빠르지 않거나 느리지 않습니다.
starblue

6
언어 구현은 빠르지 않거나 느리지 않습니다. 언어 구현을 사용하여 실행되는 프로그램은 (다른 프로그램과 비교할 때)입니다. 자 선심-누군가가 한 프로그래밍 언어가 다른 프로그래밍 언어보다 빠르다는 것에 대해 말할 때, 분명한 방법은 특정 언어 구현을 사용하여 특정 프로그램이 실행되고 있음을 이해하는 것입니다.
igouy

3
@ starblue : 그것은 매우 도움이되는 답변이 아닙니다. 동일한 언어의 두 가지 구현을 만들 수는 있지만, 그중 하나는 다른 것보다 느립니다. 언어를 넣는 방식은 다른 언어보다 구현시 특정 비 효율성을 요구하는 언어 설계 세부 사항이 존재하지 않음을 의미합니다. 디자인, 필요하지 않습니다. 그리고 그것은 사실이 아닙니다. (특히이 주제에서; 기능적인 언어는 그것들로 유명합니다!)
Mason Wheeler

3
@igouy "언어 구현이 빠르거나 느리지 않다"이것은 사실이 아니다. CPythonvs PyPy빨리 떠오른다.
NlightNFotis

@NlightNFotis-CPython은 몇 초가 걸립니까? PyPy는 몇 초가 걸립니까? 언어 구현은 빠르거나 느리지 않습니다. 이 프로그램은 CPython에서 몇 초가 걸립니까?
igouy

답변:


25

따르면 위대한 벤치 마크 게임 , ATS는 빠른 하스켈, 스칼라와 나머지보다, 그리고 중 하나는 뒤에 속도 가까운에 대한 대략적인 넥타이 CL의 변종. 그 후 Ocaml과 F #은 Racket과 Clojure가 뒤쳐지는 것과 거의 같은 속도 범주에 있습니다 ...

그러나이 중 어느 것도 실제로는 전혀 의미가 없습니다. 문제, 기계, 컴파일러, 코딩 기술, 때로는 운이 문제입니다. 일반적으로 Haskell과 같은 직접 기계 코딩 언어는 F #과 같은 VM 컴파일 언어보다 성능이 뛰어나고 순수하게 해석되는 언어보다 성능이 뛰어납니다. 또한 일반적으로 정적 형식 언어는 정적 형식으로 인해 동적 형식보다 빠르기 때문에 런타임보다는 컴파일시 모든 형식 작업을 계산할 수 있습니다. 다시 말하지만, 이것은 일반적인 규칙이며 항상 예외가 있습니다. "패러다임"은 그것과 거의 관련이 없습니다.


고려해야 할 많은 요소가 있다는 것을 알고 있으며 모든 것이 완벽하더라도 다른 데이터에서 다르게 수행 될 수 있다고해도 제 질문은 매우 모호합니다. 링크 덕분에 정말 도움이되었습니다-나는 ATS가 그렇게 빠르다는 것을 결코 알지 못했습니다.
Farouk

자세한 비교 정보가있는 멋진 링크. Clojure가 훨씬 많은 메모리를 사용하고 Java보다 훨씬 오래 걸리는 것을 보니 실망했습니다. Clojure가 비슷한 성능을 가지고 있다는 주장을 기억합니다.
DPM

ATS 웹 사이트는 ATS가 다양한 프로그래밍 패러다임을 지원한다고 말합니다. 따라서 ATS가 나머지보다 빠르다고 주장하기 전에 해당 프로그램이 실제로 기능적 스타일로 작성되었음을 보여 주어야합니다. 기능적인 ATS가 나머지 것보다 빠르지 않을 수도 있습니다.
igouy

2
Scala 웹 사이트에는 Scala가 객체 지향 기능과 기능을 통합한다고 명시되어 있습니다. 스칼라 프로그램이 객체 지향 프로그램이 아닌 기능적 프로그램으로 작성되었는지 확인 했습니까?
igouy

12

또한 프로그래밍 언어 의 성능을 측정 / 정량화 할 수 없다는 점도 지적해야 합니다 . 가장 좋은 방법은 특정 프로그램을 실행하여 특정 플랫폼에서 특정 언어 구현 의 성능을 측정하는 입니다.

따라서 "가장 빠른 기능적 언어"에 대해 질문 할 때 현재 구현 된 언어 중 최상의 것을 실제로 묻는 것입니다.


@igouy의 의견에 따르면 언어 구현을위한 다른 성능 측정 방법이 있습니다. 예를 들어 컴파일 시간. 그러나 응용 프로그램의 런타임이 언어 자체의 척도가 아니라 언어 구현의 (간접적) 척도라는 사실을 바꾸지는 않습니다.

예를 들어 Java를 고려하십시오. 클래식 (Java 1.0) Java의 언어 기능 만 사용하여 단일 스레드 벤치 마크를 작성한다고 가정하십시오. JDK 1.0을 사용하여 컴파일하고 실행하면 성능이 저하됩니다 ( 'cos JDK 1.0에는 기본 코드 컴파일러가 없었습니다). JDK 1.1에서 ... JDK 1.7로 가면 점진적으로 더 나은 결과를 얻을 수 있습니다. 그러나 이것은 벤치 마크가 동일한 언어 하위 세트를 사용하기 때문에 Java 언어 로 인한 것이 아닙니다 . 오히려 속도 향상은 컴파일러, 런타임 시스템 및 / 또는 클래스 라이브러리 구현의 개선으로 인한 것입니다. 이들은 모두 구현 문제입니다.

다른 요점은 이러한 구현 차이가 동일한 언어에서 실제로 중요 할 수 있다는 것입니다 (예 : 수십 배). 따라서 언어 X에 대한 최상의 구현이 언어 Y의 최상의 (또는 유일한) 구현보다 빠르다는 사실이 반드시 언어 자체에 대해 많은 것을 말해 주지는 않습니다 .


가장 좋은 방법은 특정 프로그램의 성능을 측정하는 것입니다. 언어 구현의 성능을 측정 할 때 프로그램을 실행하는 데 걸리는 시간이 아니라 일부 프로그램을 컴파일하는 데 걸리는 시간을 확인하려고합니다.
igouy

프로그램의 실행 시간은 특정 하드웨어 등에서 특정 언어 구현을 사용하여 실행될 때 해당 특정 프로그램의 속성입니다. 프로그램의 실행 시간이 언어의 속성이 아니라는 점을 감안할 때이 컨텍스트에서 언어 이름을 허용하는 것은 자선입니다 는 잘 알려진 일반적인 언어 구현의 약어로 사용되고 있습니다.
igouy

@igouy-사실입니다. 그러나 많은 사람들이 "자바는 느리다. 불행히도이 넌센스는 문자 그대로 전 세대의 프로그래머들에 의해 읽히고 자바의 명성을 크게 손상시켰다"고 주장하는 많은 오래된 웹 사이트에서 알 수 있듯이 구별을하지 않는다.
Stephen C

당신이 말할 수있는 자유를 원하는대로 - "언어의 구현의 (간접) 측정은"- 다른 사람이 말할 자유 안 이유를 설명하십시오 - 언어의 (간접) 측정 .
igouy

@igouy-1) 당신은 당신이 좋아하는 것을 자유롭게 말할 수 있습니다. 그러나 그것이 당신을 옳게 만드는 것은 아닙니다. 2) 언어의 유일한 구현이 쓰레기 인 경우를 고려하십시오. 우리는 그것을 벤치마킹합니다. 그런 다음 구현을 업데이트하고 벤치마킹하면 성능이 크게 향상되었습니다. 언어 성능이 향상 되었습니까? 언어가 바뀌지 않았다면 어떻게 말이 되나요?
Stephen C

6

실행 속도만으로 언어를 살펴보면 몇 가지 주요 사항이 누락되었습니다. 속도는 좋은 것이지만 유일한 것은 아닙니다.

Haskell은 매우 강력한 유형 시스템을 사용하여 버그가없고 강력 할 수있는 프로그램을 만듭니다.

Erlang은 내장 된 모니터링 시스템을 사용하여 다양한 유형의 결함에 직면했을 때 엄청난 수준의 신뢰성을 제공 할 수있는 결함 시스템을 생성 할 수 있습니다. 또한 Erlang은 다른 언어와 비교하기 어려운 수준의 동시성을 제공 할 수 있습니다.

사실 현대의 실행 속도는 대부분의 경우에 고려할 사항의 목록보다 훨씬 아래에 있다고 생각합니다. (괜찮은 숫자 계산을하고 있다면 속도에 fortran을 사용하고 싶을 수도 있지만 그렇지 않으면 중요하지 않습니다)

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.