Scala가 C 또는 C ++ 대신 Java 및 .NET으로 구현 된 이유를 아는 사람이 있습니까? 대부분의 언어는 Cor C ++ [Erlang, Python, PHP, Ruby, Perl]로 구현됩니다. Java 및 .NET 라이브러리에 액세스하는 것 외에 Java 및 .NET에서 구현 된 Scala의 장점은 무엇입니까?

최신 정보

스칼라가 C로 구현되면 JVM에 의존하는 것보다 더 잘 조정할 수 있기 때문에 더 많은 이점을 얻지 못합니까?

C와 C ++는 언어 이고 JVM은 가상 머신 이고 .Net은 플랫폼 이기 때문에 문제는 혼동 됩니다 . 스칼라는 C 또는 C ++로 구현 될 수 있으며 가상 머신의 바이트 코드 대신 머신 코드를 생성 할 수 있습니다.

질문에 대한 답변 :

Scala는 실제로 구현 된 언어 인 Scala가 훨씬 더 나은 언어이기 때문에 C 또는 C ++로 구현되지 않았습니다.

왜 더 낫습니까? 스칼라 언어 에 대한 Odersky의 목표에 대해 읽어보십시오 .

의도 한 질문에 대한 답변 :

Scala는 주로 JVM 바이트 코드를 생성합니다. 그 이유는 안정적이고 효율적인 가비지 수집기, 런타임 최적화 및 JVM에 의한 JIT (Just-In-Time) 컴파일과 같은 기능뿐만 아니라 뛰어난 이식성을 제공하기 때문입니다 .

마지막으로 반복하겠습니다 : JVM 은 실행중인 코드에서 기계 코드 핫스팟을 컴파일 합니다. C 및 C ++ 컴파일러와 마찬가지로 컴파일됩니다.

사용 가능한 다른 가상 머신이 있지만 Scala의 작성자 인 Odersky는 이미 JVM에 매우 익숙했습니다. 그는 CLR을 대안으로 사용하려고했지만 그 목표를 달성하려는 노력은 아직 성공하지 못했습니다.

물어볼 수있는 질문에 대답하기 :

머신 코드로 컴파일해도 JVM 바이트 코드로 컴파일하는 것보다 충분한 이점이 없습니다.

JVM과 동등한 기능을 능가하는 C 또는 C ++에서 마이크로 벤치 마크를 생성 할 수 있습니다. C 또는 C ++에서 매우 최적화 된 코드가 Java 또는 Scala에서 매우 최적화 된 코드를 능가 할 것입니다. 그러나 장기 실행 프로그램의 차이점은 그다지 크지 않습니다.

Scala는 짧은 실행 프로그램의 오버 헤드가 너무 크기 때문에 특히 좋은 스크립팅 언어가 아닙니다.

그러나 대부분의 경우 개발 속도 와 유지 관리 용이성이 실행 속도보다 중요합니다 . 사람들이 쉽게 이해하고 변경할 수있는 매우 높은 수준의 코드 작성에 더 관심이있는 경우 JVM에서 제공하는 런타임 최적화가 C 또는 C ++ 컴파일러에서 수행 한 컴파일 타임 최적화를 쉽게 이길 수있어 JVM (및 CLR)을 만들 수 있습니다. ) 실제로 더 빠르게 실행되는 대상입니다.

따라서 스칼라 컴파일러 가 머신 코드 실행 파일인지 아니면 스칼라 프로그램 이 머신 코드 인지에 대한 질문이 있더라도 잠재적 속도 게인이 반드시 실제 속도 게인 으로 변환되는 것은 아닙니다 .

그리고 그건 그렇고

반례를 드리겠습니다 : Haskell. 하스켈은 기계 코드를 생성하지만 하스켈 프로그램은 스칼라보다 데비안의 총격전에서 더 나쁘다. 그렇다면 머신 코드로 직접 컴파일하면 스칼라 프로그램이 더 빠를 것이라고 확신 할 수 있습니까?

전세계에 소개 될 때 가장 큰 장애물 중 하나는 라이브러리 가용성입니다. 이에 대한 전통적인 응답은 C 기반 라이브러리에 액세스 할 수 있도록 C 기반 FFI (foreign function interface)를 제공하는 것입니다. 이것은 여러 가지 이유로 이상적이지 않습니다.

• 많은 고급 언어와 호환되지 않는 라이브러리의 상호 작용 방식은 여러 가지가 있습니다. 라이브러리가에 대한 포인터를 원하는 경우 예를 들어 struct, 어떻게 어떤 포인터 언어 않습니다 및 더 struct들에 대처?
• 서로 다른 라이브러리와 언어의 메모리 모델 간에는 종종 상호 작용이 불가능하며, 해결이 불가능하거나 오류가 발생하기 쉬운 경우가 많습니다.
• 많은 FFI의 글루 코드는 사소한 것이 아니며 실제로는 보편적이지 않을 수있는 지식을 가정합니다. (믿거 나 말거나, 모든 프로그래머가 C 전문가는 아니며, 그들이되기를 원하거나 요구하지도 않습니다!)

이것은 C ++에서 더욱 악화됩니다. C ++은 컴파일러 에서 동일한 플랫폼 (!) 의 컴파일러까지 C ++ (이진 수준에서)과 호환 되지 않으며 다른 언어는 말할 것도 없습니다.

JVM을 대상으로하면 이러한 많은 문제가 해결되는 동시에 엄청나게 많은 Java 기반 라이브러리 제품군에 액세스 할 수 있습니다 . (얼마나 큰가? 아파치 소프트웨어 파운데이션 의 스타터를위한 방대한 선택 범위를 살펴 보자 .)

• Java의 호출 및 소유권 규칙은 C보다 더 규칙적입니다.
• 또한 JVM은 언어 및 라이브러리 모두에 대한 단일 메모리 모델 (가비지 수집 포함)을 제공합니다. 누가 무엇을 소유하고 어디에서 정리해야하는지 추적 할 필요가 없습니다. 런타임은 당신을 위해 그것을 수행합니다.
• JVM에 빌드 된 대부분의 언어에 대해 FFI의 접착 코드는 존재하지 않습니다 (언어의 배후에 프레임 워크로 제공됨). 예를 들어 Scala, Clojure, JRuby 등의 Java 라이브러리에 액세스하기 위해 Java로 프로그래밍 할 필요가 없습니다. 기본 "객체"에 액세스하는 것과 같은 방식으로 Java 객체에 액세스합니다 (예 : Clojure는 OOP 의미의 실제 객체와 모국어로 작성하십시오.

이러한 장점의 위에 당신은 또한 자바가 실행 어디서나 실행의 추가 장점이 없이 재 컴파일 (그러나 에 한 번 테스트! : 쓰기, 사방 테스트)와 자바의 다소 인상적인 JIT 기술을 가진 액세스 할 수 있습니다.

CLR은 비슷한 강점을 제공하지만 IMO의 약점을 추가합니다. 이는 공급 업체 잠금 환경과 거의 같습니다. (예, 모노에 대해 알고 있습니다. 여전히 벤더 잠금 환경이라고 생각합니다.)

이 인터뷰 에 따르면 기존 Java 인프라 및 라이브러리에 대한 액세스가 주된 이유였습니다.

... Java는 매우 어려운 제약 조건이있는 기존 언어입니다. 결과적으로, 나는 내가하고 싶었던 방식으로 많은 일을 할 수 없었습니다. 제가 확신했던 방식이 올바른 방식 일 것입니다. 그 이후로 본질적으로 내 작업의 초점이 Java를 개선하는 것이었을 때, 나는 물러나야 할 때라고 결정했습니다. 깨끗한 시트로 시작하고 Java보다 나은 것을 디자인 할 수 있는지 확인하고 싶었습니다. 그러나 동시에 처음부터 시작할 수 없다는 것을 알았습니다. 기존 인프라에 연결해야했습니다. 그렇지 않으면 라이브러리, 도구 등이없는 상태에서 자신을 부트 스트랩하는 것이 실용적이지 않기 때문입니다.

따라서 Java와 다른 언어를 설계하고 싶더라도 Java 인프라 (JVM 및 해당 라이브러리)에 항상 연결하기로 결정했습니다 . 그 아이디어는 ...

Erlang, Python, PHP, Ruby, Perl과 같은 다른 모든 언어는 Java 및 .NET 이전에 작성되었습니다 . 해당 언어의 작성자가 해당 시점에 Java 또는 .NET 런타임 환경을 사용할 수있는 경우 언어를 빌드 할 때 활용했을 수 있습니다.

물론, 나는 그 언어의 개발자를 위해 말할 수 없으므로, 그들이 사용할 수 있었을 때 .NET 및 / 또는 Java를 사용할 것이라고 확신 할 수는 없지만 좋은 생각. 결국 Java / .NET 바이트 코드로 컴파일 할 언어를 설계하면 JIT 컴파일러 / 최적화 기의 모든 이점을 얻을 수 있으며, 언어는 Java / .NET이 실행되는 모든 플랫폼에서 자동으로 실행되며 모든 Java / .NET 라이브러리 등.

C 코드 는 기본 코드 (기계 코드) 로 정적으로 컴파일됩니다 .

스칼라는 자바 바이트 코드로 정적으로 컴파일 된 다음 필요에 따라 최적화 된 네이티브 코드로 동적으로 컴파일됩니다. 과정:

스칼라 코드 --- 정적으로 컴파일 된 ---> JVM 바이트 코드 --- JVM-Hotspot-to ---> 네이티브 코드에 의해 동적으로 컴파일 된

언어 구축 / 실행을위한 일반 옵션 :

• a) 런타임 인터프리터 엔진을 통해 직접 소스 코드 해석
• b) 코드를 원시 코드로 정적으로 컴파일 (아마도 중간 단계 (예 : 소스-> C-> 네이티브)를 통해)
• c) 소스 코드를 하위 수준의 중간 코드로 정적으로 컴파일하고 런타임에 해석
• d) 소스 코드를 하위 수준의 중간 코드로 정적으로 컴파일 한 다음 초기 해석을 사용하고 동적 컴파일 및 최적화 기술을 사용하여 기본 코드로 변환합니다. 일반적인 실행 경로와 병목 현상이 발견 될 때까지 코드가 해석 된 다음 일반적인 조건에서 가장 빠른 실행을 위해 코드가 컴파일됩니다. 실행 조건이 이것을 보증하기에 충분히 변할 때 재 컴파일 / 재조정됩니다.

귀하의 질문 : "왜 Java가 (b)가 아닌 JVM과 함께 (d) C 중간 코드를 사용합니까?"

대답:

첫째, 스칼라가의 관찰 많은C보다 높은 수준의 언어로 프로그래밍 능력, 프로그래밍 용이성 및 간결성을 제공합니다. 첫 번째 클래스 및 고차 함수, 암시 적 함수, 객체, 클로저 및 카레 링 기능, 빠른 스택 보존 루프에 대한 테일 재귀 컴파일 지원, 객체로 모든 것, 메소드로 모든 연산자로 인해 Java보다 약 1 수준 높음 라이브러리, 케이스 클래스 및 축소 (패턴 일치), 암시 적 유형 파생, 확장 된 다중 상속 가능 특성 및 확장 된 제네릭을 통한 강력한 다형성, 쌍 및 튜플 및 단점 (리스트 및 트리)에 대한 내장 구문에서 (재 정의) 가능 ) 및 맵, 불변 데이터 구조 지원, 메시지 복사 및 액터 간 전달을 통한 강력한 '반응적인'병렬 및 동시 컴퓨팅 지원 임의의 도메인 별 DSL, 스크립트 기능 및 REPL에 대한 고급 지원. 객체 지향, 포인터 관리 및 가비지 수집, 문자열 지원, 멀티 스레딩 지원 및 동시성 제어, 표준 API 라이브러리로 인해 Java가 C보다 '1 수준 높았습니다.

1. 성능 : 고급 언어의 경우 (d)는 (a)-(c)보다 빠른 성능을 제공합니다.
   직접 작성하여 직접 최적화 한 C 코드는 빠릅니다. 그러나 C로 정적으로 컴파일 된 고급 언어는 상대적으로 느립니다. 자바 디자이너들은 이것을 잘 알고있었습니다. 현재 "Hotspot"디자인은 성능을 최대로 향상시킵니다. 단일 코어에서 Java HotSpot 코드는 사람이 최적화 한 C보다 평균 '50 % 빠릅니다 '(최상의 경우'120 % 빠름 ', 최악의 경우 '30 % 빠름') 그러나 물론 그것은 사과를 오렌지와 비교합니다-저수준 코드 v 고수준 코드. 그리고 그것은 많이 될 것입니다핫스팟 최적화를 사용하지 않으면 악화됩니다. 확인하려면 JVM 인수를 통한 핫스팟 컴파일을 비활성화하십시오! 또는 핫스팟이 존재하지 않거나 미숙 한 Java 1 & 2 성능을 고려하십시오. 또는 perlcc와 같은 C를 통해 다른 언어를 컴파일 해보십시오. 위의 내용은 강력하고 생산적인 언어에 대한 훌륭한 결과입니다. 추가 개발을 통해 JVM이 곧 수동으로 코딩 된 C보다 평균 속도를 능가 할 수 있습니다. 스칼라는 평균적으로 자바만큼 70-80 % 느립니다. 그러나 scala는 여러 코어에 걸쳐 강력하게 확장되며 (추가 개선이 진행 중임) Java는 부분적으로 C는 그렇지 않습니다. 이러한 고급 언어에 대한 단일 코어 성능은 다음과 같이 평가됩니다.

   해석 <정적으로 컴파일 <동적으로 컴파일

   멀티 코어 성능 / 확장 성 등급 :

   해석 된 동적 코드 <정적으로 컴파일 된 명령형 코드 <정적으로 컴파일 된 기능 / 선언적 코드 <동적으로 컴파일 된 기능적 / 선언적 코드

   프로세서 속도가 한계에 도달하고 이제 무어의 법칙에 따라 코어 수가 증가하고 있기 때문에 스칼라가 우승 자리에 올라 있습니다. 스칼라는 멀티 코어에서 매우 빠르며 앞으로 C 또는 java보다 몇 배 더 빠를 수 있습니다. C로 정적으로 컴파일하는 것이 가장 빠른 옵션은 아닙니다.

2. 상호 운용성 : 광범위하게 지원되는 VM의 언어는 '분리 된'언어보다 더 나은 언어 상호 운용성을 갖습니다.. 스칼라는 단순히 자바 클래스, 인터페이스 및 객체를 가져 와서 스칼라 클래스, 특성 및 객체 인 것처럼 사용함으로써 "자동으로 재생"합니다. Groovy, Clojure, JRuby 및 JPython과 같은 다른 JVM 언어에서도 비슷합니다. 각 언어가 이해하기 쉽고 사용 가능한 Java 런타임 클래스 / 인터페이스 / 객체로 얼마나 정확하게 컴파일되는지에 따라 상호 운용성이 용이합니다. 그것은 '무료'( '가까운'에서와 같이)를 위해 온다. 스칼라는 JNI의 후속 버전 인 JNA를 통해 C와 상호 운용되며 약간의 노력이 필요하지만 시간이 지남에 따라 도구가 상당히 간소화되었습니다. JNA는 실제로 임의의 언어로 컴파일 된 네이티브 코드와 상호 운용 될 수 있지만 컴파일 된 데이터 유형 및 함수의 정확한 구조를 알아야합니다. 그렇지 않은 경우

3. 이식성 : JVM은 수십 개의 운영 체제 플랫폼 / 버전에서 즉시 사용할 수 있습니다. 스칼라는 자동으로 포팅됩니다. 주목할만한 예외는 iOS (iPad / iPhone / iPod)입니다. Apple에서 '기술적으로'가 아니라 '상업적으로'차단되었습니다. JVM의 초기 설계 중에는 12 년 전에는 예상 할 수 없었습니다. JVM은 Google을 지원하는 Dalvik VM이 포함 된 Android (판매 된 새 전화의 50 % 이상)를 포함하여 C를 지원하지 않는 장치를 포함하여 수십 개의 다른 서버, 데스크톱, 모바일 및 임베디드 장치에서 제대로 실행됩니다. 물론 C 코드는 다양한 플랫폼에서 작동하므로 Java와 함께 또는 그 이상으로 평가 될 수 있습니다 (특히 C는 Objective-C의 하위 집합입니다). 그러나 C는 (1), (2) & (3)의 비용이 듭니다. 물론 iOS의 HTML5 / javascript / webkit (또는 objective-C) 프리젠 테이션 레이어는 원격 스칼라 앱과 상호 운용 될 수 있으므로 개발자는 그렇게해야합니다. 물론 생산성이 떨어집니다.

4. 툴과 라이브러리 : 분명히 C보다 더 많은 스칼라가 활용할 수있는 수천 개의 상용 및 오픈 소스 Java 라이브러리와 툴이 있습니다.

5. 보안 : -제어 된 앱 서버 또는 JVM 환경에서 실행하면 회사 환경에서 매우 유용한 보안 정책 및 제한 사항에 대한 강력한 지원이 제공됩니다.

JVM / CLR

JVM (및 CLR)은 최적화 및 코드 이식성 측면에서 고유 한 이점을 제공합니다.

내가 아는 한, Scala의 JVM 버전 만 최신 상태로 유지되고 있지만 .NET 버전은 그렇지 않습니다.

관련이없는 두 가지를 혼합 한 것 같습니다.

첫 번째는 스칼라 제작자가 스칼라를 구현하기 위해 어떤 프로그래밍 언어 를 사용하는 것입니까?

답은 스칼라 자체입니다. 그리고이 새로운 언어를 발명했지만 그것을 구현하기 위해 직접 사용하지 않는다면, 이것이 유일하게 받아 들일 수있는 대답입니다.

두 번째 는 스칼라로 작성된 프로그램을 실행하기위한 대상 플랫폼 은 무엇 입니까?

여기서 선택이 더 흥미로워 지지만 현재 100 % 작동하는 유일한 대상은 JVM입니다. .NET 지원은 아직 진행 중입니다. 또한 일부 사람들은 Scala가 javacsript로 컴파일되도록 노력하고 있습니다. 이론적으로, 누군가가 C, C ++, LLVM, 원시 코드 또는 기타로 컴파일하기 위해 더 많은 '백엔드'를 추가하는 것을 막을 수있는 것은 없습니다.

JVM이 기본 플랫폼으로 선택된 이유는 무엇입니까? 내 생각 엔

• 모두 가비지 수집을 원합니다
• 사용할 수있는 많은 훌륭한 라이브러리
• Java로 지루한 많은 수의 프로그래머가 새로운 무언가로 뛰어들 준비가되어 있지만 JVM의 한계를 유지하십시오 (기존 코드를 다른 플랫폼으로 마이그레이션하고 싶지는 않습니다)

우선, 당신이 정말로 묻고 싶었던 것은 스칼라가 엄격한 언어로 컴파일되지 않은 이유입니다. 내가 모른다고 말할 것입니다. 그러나 기본 코드보다 JVM을 선호 할 이유가 없다고 말할 것입니다.

왜? 그 이유는 간단합니다. 모든 가상화 기술은 메모리 부족, 불필요한 오버 헤드 및 또 다른 간접 계층을 생성합니다. 이는 구현의 문제가 아니라 가상화의 핵심 개념 뒤에 놓인 논리의 문제입니다. 당신이 무엇을 하든지 항상 열등한 특성으로 끝날 것입니다. 특히 JVM은 메모리가 부족합니다. 그것은 뒤에서 돌아가는 자체 런타임 컴파일러를 가지고 있기 때문에 더 이상 그렇게 느리지는 않지만 여전히 가장 혼잡 한 코드 부분을 찾아 바이너리 코드로 변환 할 수 있도록 컴파일러 프로세스를 실행해야합니다.

스칼라 JVM을 기반으로 한 이유는 아마도 언어의 인기 때문일 것이라고 말했다. 또한 크로스 플랫폼에서 작동하도록 어셈블리가 어떻게 보이는지 알아내는 것보다 JVM을 통해 언어를 구현하는 것이 더 쉽기 때문에 약간의 게으름이이 결정의 배후에 있다고 생각합니다. 기존 C 백엔드를 사용하더라도 사실로 인해 더 많은 작업이 필요합니다. JVM만큼 잘 표준화되어 있지 않습니다.

이것이 제가 생각할 수있는 이유이지만 라이센스 문제 및 관련 정치와 같은 다른 이유도있을 수 있습니다 (내가 원하지 않는 더러운 것들).

더 나은 튜닝을위한 능력이 좋은 트레이드 오프라는 것은 확실하지 않습니다. JVM은 런타임에 최적화를 수행 할 수 있으며 일반적으로 정적 컴파일에서 발생하는 것보다 우수하지는 않지만 일반적으로 충분합니다. (물론 특정 애플리케이션 및 워크로드의 경우 원칙적으로 정적 최적화로 JIT를 이길 수 있어야하지만 실제로는 정확한 워크로드 또는 전체 애플리케이션이없는 경우가 많습니다.)