이러한 비교에서 Swift가 Objective-C보다 훨씬 빠를 수있는 방법은 무엇입니까?

Apple은 WWDC14 에서 새로운 프로그래밍 언어 인 Swift 를 출시했습니다 . 프레젠테이션에서는 Objective-C와 Python간에 성능을 비교했습니다. 다음은 슬라이드 중 하나의 그림이며, 복잡한 객체 정렬을 수행하는 세 가지 언어를 비교 한 것입니다.

RC4 암호화 알고리즘을 사용한 성능 비교에 대한 훨씬 더 놀라운 그래프가있었습니다 .

분명히 이것은 마케팅 강연이며, 이것이 각각 어떻게 구현되었는지에 대해서는 자세히 다루지 않았습니다. 그래도 궁금해합니다.

1. 새로운 프로그래밍 언어가 어떻게 훨씬 빨라질 수 있습니까?
2. 잘못된 컴파일러로 인해 Objective-C 결과가 발생합니까? 아니면 Swift보다 Objective-C에서 효율성이 떨어지는 것이 있습니까?
3. 40 % 성능 향상을 어떻게 설명 하시겠습니까? 가비지 수집 / 자동화 된 참조 제어가 약간의 추가 오버 헤드를 생성 할 수 있다는 것을 알고 있습니다.

첫째, (IMO) 파이썬과 비교하는 것은 거의 의미가 없습니다. Objective-C와의 비교 만 의미가 있습니다.

• 새로운 프로그래밍 언어가 어떻게 훨씬 빨라질 수 있습니까?

Objective-C는 느린 언어입니다. (C 부분 만 빠르지 만 그것이 C이기 때문입니다.) 그것은 결코 빠르지 않았습니다. 그것은 그들의 (Apple의) 목적을 위해 충분히 빠르며, 이전 버전보다 빠릅니다. 그리고 속도가 느려서 ...

• Objective-C가 나쁜 컴파일러의 결과입니까, Objective-C에서 Swift보다 효율이 떨어지는 것이 있습니까?

Objective-C는 모든 메소드가 동적으로 전달되도록 보장했습니다. 정적 디스패치가 전혀 없습니다. 따라서 Objective-C 프로그램을 더 최적화 할 수 없었습니다. JIT 기술이 도움이 될 수도 있지만 AFAIK 인 Apple은 실제로 예측할 수없는 성능 특성과 객체 수명을 싫어합니다. 나는 그들이 JIT를 채택하지 않았다고 생각합니다. Swift는 Objective-C 호환성에 특별한 특성을 부여하지 않는 한 이러한 동적 디스패치를 ​​보장하지 않습니다.

• 40 % 성능 향상을 어떻게 설명 하시겠습니까? 가비지 수집 / 자동화 된 참조 제어가 약간의 추가 오버 헤드를 생성 할 수 있다는 것을 알고 있습니다.

GC 또는 RC는 여기서 중요하지 않습니다. 스위프트는 또한 주로 RC를 사용하고 있습니다. GC가 없으며 GC 기술에 대한 아키텍처가 크게 향상되지 않는 한 그렇지 않습니다. (IMO, 영원합니다) Swift에는 정적 최적화를위한 더 많은 공간이 있다고 생각합니다. 특히 저수준 암호화 알고리즘은 일반적으로 막대한 숫자 계산에 의존하기 때문에 정적으로 디스패치 언어에 큰 승리입니다.

실제로 40 %가 너무 작아서 놀랐습니다. 나는 훨씬 더 기대했다. 어쨌든 이것은 초기 릴리스이며 최적화가 주요 관심사가 아니라고 생각합니다. 스위프트는 기능이 완전하지 않습니다! 그들은 더 나아질 것입니다.

최신 정보

일부는 GC 기술이 우수하다고 주장하기 위해 계속 나를 괴롭 힙니다. 아래의 내용은 논쟁의 여지가 있지만 매우 편견이 있지만이 불필요한 주장을 피하기 위해 말해야한다고 생각합니다.

나는 보수적 / 추적 / 세대 / 증분 / 병렬 / 실시간 GC가 무엇이며 어떻게 다른지 알고 있습니다. 나는 대부분의 독자들도 이미 그것을 알고 있다고 생각합니다. 또한 GC는 일부 분야에서 매우 훌륭하며 경우에 따라 높은 처리량을 보여줍니다.

어쨌든, 나는 GC 처리량에 대한 주장이 항상 RC보다 낫다고 생각합니다. RC의 오버 헤드는 대부분 참조 횟수를 보호하고 참조 횟수를 보호하기 위해 잠금에서 비롯됩니다. RC 구현은 일반적으로 계산 작업을 피하는 방법을 제공합니다. Objective-C에는 __unsafe_unretainedSwift에 있으며 여전히 명확하지는 않습니다 unowned. 참조 계산 작업 비용이 허용되지 않는 경우에는 역학을 사용하여 선택적으로 옵트 아웃을 시도 할 수 있습니다. 이론적으로 우리는 비 보유 참조를 매우 적극적으로 사용하여 RC 오버 헤드를 피함으로써 거의 고유 한 소유권 시나리오를 시뮬레이션 할 수 있습니다. 또한 컴파일러가 불필요한 RC 작업을 자동으로 제거 할 수 있다고 생각합니다.

RC 시스템 인 AFAIK와 달리 참조 유형 의 부분 옵트 아웃은 GC 시스템의 옵션이 아닙니다.

나는 GC 기반 시스템을 사용하는 많은 출시 된 그래픽과 게임이 있다는 것을 알고 있으며, 대부분 결정론이 부족하여 고통 받고 있음을 알고 있습니다. 성능 특성뿐만 아니라 객체 수명 관리를위한 것입니다. Unity는 주로 C ++로 작성되었지만 작은 C # 부분은 모든 이상한 성능 문제를 유발합니다. HTML 하이브리드 앱은 여전히 ​​모든 시스템에서 예측할 수없는 급증으로 어려움을 겪고 있습니다. 널리 사용된다고해서 그것이 우월하다는 것은 아닙니다. 그것은 많은 옵션이없는 사람들에게 쉽고 인기가 있음을 의미합니다.

업데이트 2

불필요한 논쟁이나 토론을 피하기 위해 다시 한 번 더 자세한 내용을 추가합니다.

@ 아 식은 GC 스파이크에 대한 흥미로운 의견을 제시했다. 그것은 우리가 GC 물건을 옵트 아웃하는 방법으로 모든 가치 유형 접근 방식을 고려할 수 있다는 것입니다. 이것은 매우 매력적이며 일부 시스템에서도 가능합니다 (예를 들어 기능적으로 접근). 나는 이것이 이론적으로 훌륭하다는 것에 동의합니다. 그러나 실제로 몇 가지 문제가 있습니다. 가장 큰 문제는이 트릭을 부분적으로 적용하여 진정한 스파이크가없는 특성을 제공하지 않는다는 것입니다.

대기 시간 문제는 항상 전부 또는 전혀 문제가 되지 않기 때문 입니다. 10 초 동안 한 프레임 스파이크가있는 경우 (= 600 프레임) 전체 시스템에 문제가있는 것입니다. 이것은 얼마나 나쁘거나 나쁜가에 관한 것이 아닙니다. 그냥 합격 또는 실패입니다. (또는 0.0001 % 이하) 그렇다면 GC 스파이크의 출처는 어디입니까? 그것은 GC 부하의 나쁜 분포입니다. 그리고 그것은 GC가 근본적으로 결정적이지 않기 때문입니다. 쓰레기를 만들면 GC가 활성화되고 결국 스파이크가 발생합니다. 물론, GC로드가 항상 이상적인 이상적인 세계에서는 이런 일이 발생하지 않지만 나는 상상의 이상적인 세계가 아닌 실제 세계에 살고 있습니다.

그런 다음 스파이크를 피 하려면 전체 시스템에서 모든 참조 유형 을 제거 해야합니다 . 그러나 .NET 코어 시스템 및 라이브러리와 같은 제거 할 수없는 부분으로 인해 어렵고 미친 듯이 심지어 불가능합니다. 비 GC 시스템을 사용하는 것이 훨씬 쉽습니다 .

GC와 달리 RC는 기본적으로 결정 론적이며 스파이크를 피하기 위해이 미친 최적화 (순전 한 값 유형 전용)를 사용할 필요가 없습니다. 당신이해야 할 일은 스파이크를 일으키는 부분을 추적하고 최적화하는 것입니다. RC 시스템에서 스파이크는 로컬 알고리즘 문제이지만 GC 시스템에서는 스파이크가 항상 전역 시스템 문제입니다.

내 대답은 너무 많은 주제를 벗어난 것으로 생각되며 대부분 기존 토론의 반복입니다. 우월 / 열등 / 대안 또는 GC / RC에 관한 다른 것들을 주장하고 싶다면이 사이트와 StackOverflow에 많은 기존 토론이 있으며 계속 거기에서 싸울 수 있습니다.

파이썬보다 3.9 배 빠르기 때문에 대부분의 벤치 마크를 상당한 마진 (일부는 Perl, Ruby 및 PHP와 동일하지만 정적으로 입력 한 내용은 잃어 버림)으로 인해 대부분의 벤치 마크를 잃는 언어는 자랑 할만한 것이 아닙니다.

벤치 마크 게임은 빠른 파이썬 프로그램보다 대부분의 경우 크기 순서보다 더 있습니다 C ++ 프로그램을 보여줍니다. 정적으로 유형이 지정되지 않은 Java, C # (Mono), OCaml, Haskell 및 Clojure와 비교할 때 그리 좋지 않습니다.

따라서 실제 질문은 Objective-C가 파이썬보다 2.8 배 더 빠릅니다. 분명히 그들은 ObjC의 느린 동적 동적 디스패치가 많은 상처를주는 벤치 마크를 신중하게 선택했습니다. 정적으로 유형이 지정된 언어는 더 잘 수행 할 수 있어야합니다. 복잡한 객체 정렬에는 객체를 비교하기위한 많은 메소드 호출이 있으며 실제 비교는 그다지 복잡하지 않았을 것입니다. 따라서 Swift가 최소한 유형 정보를 활용하면 메소드 호출에서 쉽게 더 잘 수행 할 수 있으며 ObjC가 더 나을 수있는 다른 작업이 충분하지 않습니다.

물론 벤치 마크 게임이 명확하게 보여 주듯이, 서로 다른 작업에 대한 상대적인 성능은 크게 다르므로 하나의 벤치 마크가 실제로 대표적이지는 않습니다. 그들이 더 큰 이점을 가지고있는 벤치 마크를 가지고 있다면, 우리에게 그 대신에 다른 것을 보여 주었을 것입니다.

Objective-C는 모든 메소드 호출을 동적으로 전달합니다.

가설 : 벤치 마크는 정적 타이핑을 사용하여 Swift 컴파일러 compare가 sort루프 에서 메소드 조회를 수행하도록 합니다. 이를 위해서는 Complex의 서브 클래스가 아닌 배열의 Complex 객체 만 허용하는 좁은 유형 제한이 필요합니다.

(Objective-C에서는 언어 런타임 지원을 호출하여 메소드 포인터를 조회하여 원하는 경우 메소드 조회를 수동으로 끌어 올릴 수 있습니다. 배열의 모든 인스턴스가 동일한 클래스인지 확인하는 것이 좋습니다. .)

가설 : Swift는 루프에서 참조 계산 호출을 최적화합니다.

가설 : Swift 벤치 마크는 Objective-C 객체 대신 Complex 구조체를 사용하므로 정렬 비교에는 동적 메서드 디스패치 (서브 클래스 할 수 없기 때문에) 또는 참조 계산 작업 (값 유형이므로)이 필요하지 않습니다.

Objective-C에서는 Objective-C 객체를 포함하지 않는 한 (예 : C 배열의 구조체 정렬) 성능을 위해 C / C ++로 대체 할 수 있습니다.

솔직히 그들이 그들이 사용하는 테스트에 소스를 공개하지 않으면 나는 애플이 그 주제에 대해 말한 것을 믿지 않을 것입니다. 6 개월 전 인텔이 광고를 통해 인텔 토끼를 빨아 들였다고 말했을 때 전력 문제에 따라 PPC에서 인텔로 전환 한 회사라는 사실을 기억하십시오. Swift가 단순한 정렬보다 더 많은 범주에서 ObjC보다 빠르다는 확실한 반박 할 수없는 증거를보고 싶습니다.

또한 WWDC에서 발표되는 모든 통계는 마케팅 냄새가 나기 때문에 질문해야합니다.

그 모든 것은 swift와 ObjC 사이에서 어떤 테스트도 실행하지 않았다고 말하지만, swift는 자체 LLVM IR 확장 기능을 가지고 있으며 ObjC보다 컴파일 타임에 더 많은 최적화가 수행 될 수 있습니다.

전체 공개 : https://ind.ie/phoenix/ 에있는 오픈 소스 Swift 컴파일러를 작성 중입니다.

Apple 하드웨어에서만 Swift를 사용할 수 있도록 도와 주려면 알려 주시면 기꺼이 도와 드리겠습니다.

나는 Swift 튜토리얼을 통해 어려움을 겪었으며 Swift는 Objective-C보다 '개체화'가 적어 지구에 더 가깝습니다 (Visual Basic을 생각하게 만듭니다). 그들이 C 또는 C ++를 고려했다면, 컴파일 시간이 더 길기 때문에 후자가 이겼을 것이라고 생각합니다.

이 경우 Objective-C가 객체 지향 순도 (및 오버 헤드)의 희생자라고 가정합니다.