왜 안드로이드 폰에 컴퓨터보다 더 많은 코어가 있습니까?

랩톱에는 일반적으로 최대 4 개의 코어가 있으며 이중 코어가 더 일반적 일 수 있습니다. 최근에 쿼드 코어에서 듀얼 코어로 전환했으며 CPU를 많이 사용하는 작업에서도 쿼드 코어의 사용 사례 수가 제한되어 있음을 확인할 수 있습니다.

반면에 휴대 전화에서는 쿼드 코어, 헥사 코어 및 8 코어가 일반적인 것으로 보입니다. 왜? 어떤 작업을 활용할 수 있습니까?

big.LITTLE 이 답의 일부가 될 수 있음을 이해합니다 . 즉, 너무 많은 코어의 주요 이점은 모든 코어를 동시에 사용할 수있는 기능이 아니라 현재 워크로드에 적합한 전력 소비를 가진 코어를 사용한다는 것입니다. 그러나 예를 들어 Snapdragon 625에는 8 개의 Cortex-A53 코어가 있으며 big.LITTLE에는 해당되지 않습니다.

ARM 아키텍처는 와트 당 최적의 성능이 낮을 수 있습니다. 즉, 와트 당 최적의 성능을 발휘하도록 단일 코어를 조정하면 Intel보다 ARM의 성능이 저하됩니다. 따라서 성능을 제공하기 위해 더 많은 코어가 사용됩니다. 이것은 단지 가설 일뿐입니다.

그러나이 경우에도 휴대 전화에서 8 개의 코어와 같은 워크로드가 효율적으로 사용할 수있는 것을 알 수 없습니다. 랩톱에서는 프로젝트의 전체 (비 증분) 컴파일과 같은 것을 상상할 수 있습니다. 그러나 전화?

• 게임은 성능이 고갈 될 수 있지만 일반적으로 CPU보다는 GPU 성능이 필요합니까?
• 이론적으로 다중 코어는 설치 또는 업그레이드시 (즉,“앱 최적화 3/121”단계) Android Lollipop / Marshmallow AOT 컴파일 속도를 높일 수 있습니다. 그러나 이것이 여러 코어를 활용할 수 있는지 확실하지 않습니다. 내가 코드를 기억하는 한, 한 번에 하나의 앱 만 컴파일되고 있지만 컴파일 프로세스 자체에는 약간의 병렬성이있을 수 있습니다.
• 또한 Android 7 이상은 컴파일 할 때 여러 코어를 활용할 수 있습니다. 그러나 유휴 및 충전시 컴파일이 이루어 지므로 이점이 다소 최소화 된 것으로 보입니다. 적어도 하루 밤 전화를 충전 할 때 – 그런 시나리오에서 30 분이나 2 시간이 걸리더라도 상관 없습니다.

이미 언급했듯이, big.LITTLE의 조합 전략 (기술적, HMP는 , 이기종 멀티 프로세싱 클러스터는) 많은 (그리고 때로는 압도적으로 많은) 코어의 주요 이유입니다. 모바일 장치는 종종 여러 가지 시나리오 (고부하 및 경부 하 포함)로 실행됩니다.

소비자 수준의 극단적 인 예로는 MediaTek의 Helio X20이 있는데, 여기에는 2 개의 성능 지향 A72 코어, 4 개의 균형 잡힌 A53 코어 및 4 개의 에너지 효율적인 A35 코어가 있습니다. 다양한 사용 사례에서 매우 유연합니다. 그러나 8 코어 2 클러스터로 충분 하다고 생각 합니다.

또 다른 데스크탑과 같은 예인 Qualcomm의 Snapdragon 800 시리즈 (S 800, S 801 및 S 805)도 있습니다. 각 SoC에는 동일한 마이크로 아키텍처의 코어가 4 개만 있으며 2 개 더 높고 2 개 더 낮습니다. Qualcomm은 이러한 자체 SoC를 자체 마이크로 아키텍처 (Krait 400 및 Krait 450)에 매우 확신했기 때문에 작성했습니다.

게임의 경우 CPU가 아닌 GPU 성능이 필요한 것처럼 보이더라도 여전히 CPU에 많은 부하를가합니다. GPU는 처리 할 데이터를 제공하지 않으면 단독으로 작동 할 수 없으며 이는 게임을하는 동안 CPU가 수행하는 주요 작업 중 하나입니다. 대부분의 게임의 경우 GPU는 그래픽 만 렌더링하는 반면 데이터, 리소스 및 자산로드, 시스템, 환경 및 물리와 같은 게임 내 메커니즘 계산과 같은 다른 모든 작업은 CPU에서 수행합니다. 로우 엔드 CPU를 고수하면서 GPU를 업그레이드하면 더 높은 프레임 속도를 볼 수 없습니다.

두 번째 이유는 안드로이드가 CPU 리소스를 활용하는 방법 입니다. 안드로이드는 자신 만의 애플리케이션 환경을 만듭니다. Java의 코드 (및 API) 만 사용하지만 Dalvik이라는 자체 가상 머신이 있으며 나중에 ART (API 레벨 21)로 대체되었습니다. APK는 실행 파일이 "중립"형식으로 .class되어 있으며 Java 파일 과 매우 유사 합니다. 코드가 실행되기 전에 기계의 기본 명령어로 코드가 한 번 더 컴파일됩니다 ^[1] . 컴파일 프로세스는 멀티 스레드이며 성능 향상을 위해 멀티 코어를 활용할 수 있습니다.
그리고 앱이 실행될 때 앱과 함께 또는 앱과 병렬로 실행되는 여러 다른 프로세스와 메커니즘 (가비지 콜렉터와 같은)이 있습니다. 코어가 많을수록 지원 프로세스와 메인 앱을보다 효율적으로 실행할 수 있습니다.
_{1. 파일 형식 식별자를 사용하는 경우 "최적화 된"덱스 파일은 ELF 형식이고 "중립"덱스 파일은 고유 한 형식입니다.}

또 다른 적은 이유는 ARM 코어가 Intel x86 칩만큼 빠르게 작동 할 수 없기 때문입니다 . 인텔 x86 마이크로 아키텍처는 인텔 8086 칩이 설계되기 시작한 1976 년으로 거슬러 올라갈 수 있습니다 . 이는 x86이 오랜 기간 동안 개발되었음을 의미합니다. 현대적인 단일 고급 ARM Cortex-A73 코어는 Intel Clarkdale 코어만큼 강력하며 Core i5-660 을 예로 들어 설명합니다 (GeekBench, 단일 코어). x86은 CISC 마이크로 아키텍처이고 ARM은 RISC 이기 때문 입니다.마이크로 아키텍처. 두 개 정도의 활성 앱만으로 게으른 전화기는 원하지 않습니다. 더 많은 코어가 압력을 완화하는 데 도움이됩니다. 그렇기 때문에 듀얼 코어 SoC는 스마트 시계에서만 비교적 인기가 있습니다. 스마트 워치에서 성능이 필요한 사람은 누구입니까?

흥미롭게도, 더 많은 코어는 동일한 부하에서 단일 코어보다 전력이 적습니다 . CPU 주파수와 전력 소비 사이의 관계는 선형 이상이므로 주파수의 두 배는 항상 두 배 이상 또는 심지어 3 배 또는 4 배 많은 전력을 요구하는 반면 캐시와 같은 다른 리소스 제한으로 인해 두 배 미만의 성능을 제공합니다. ). 따라서 4 개의 코어가 동일한 부하에서 단일 코어를 쉽게 이길 수있어 더 나은 성능을 제공하고 동시에 더 적은 전력을 요구합니다.

추가 자료 :

• 스마트 폰의 CPU 코어 8 개와 10 개가 좋은 아이디어 인 이유 – 부엌에서 얻은 교훈
• 왜 일부 전화에는 2 개의 쿼드 코어 프로세서가 있고 다른 전화에는 비슷한 클럭 옥타 코어가 있습니다. 성능면에서 어느 것이 더 낫습니까?

그 이유는 복잡 할만큼 간단합니다.

짧은 대답은 "휴대 전화 시장은 인텔이 주도한 적이없고 주도하지 않기 때문"입니다.

긴 대답은 여기에서 다시 시작하기에는 너무 길지만, 기본 개념은 Intel이 수년간 CPU 시장을 지배하기 위해 지불하고 부패 (그리고 벌금을 부과)하는 시점까지 PC 시장을 지배했다는 것입니다. PC 제조업체를위한 최초이자 유일한 선택입니다.

시장을 완전히 통제함으로써 인텔은 CPU 가격을 인플레이션하면서 사용자가 원하는 기능과 처리 능력을 인위적으로 결정할 수 있었으며 약간의 인텔 이력을 분석하면 기본 강점은 기본적으로 CPU 주파수의 증가로 인해 실제로는 똑똑하거나 혁신적인 일을 시도하지 않았습니다. "더 많은 코어가 필요하지 않지만 100MHz 더 빠르게 실행되는이 육즙이 많은 새로운 CPU가 있습니다"라고 말할 수 있기 때문에 필요하지 않았습니다. 동시에 _{서버가 항상 필요 했기 때문에 서버} 시장에서 멀티 코어 CPU를 엄청나게 높은 가격으로 판매 할 수 _{있습니다사용하는 서버를 실현하려는 현재 추세가 있다는 점까지 많은 병렬 전력을 ... 무엇을 추측합니까? 저렴한 전화 CPU 수백 개가 병렬로 작동합니다)}

이것은 병렬 프로그래밍의 중요성을 따라 잡지 못한 개발자 커뮤니티에 반영되어 대부분의 사람들이 시간에 두 개 이상의 스레드를 사용하여 귀찮게하지 않았습니다. 기술적 인 방식으로 소프트웨어가 한 번에 둘 이상의 작업을 수행하도록합니다. 그건 그렇고, 고객 기반의 99 %가 최대 2 개의 코어를 가질 때 의미가 있습니다. 슬프게도, 이것은 병렬 알고리즘이 실제로 구현하기가 어렵고 작은 문제 부분에만 적용된다는 전설로 이어졌습니다.

그 대신 모바일 시장은 인텔의 성공을 본 적이 없다. 실제로 인텔이 일반적인 X86 아키텍처와 다른 것을 시도하는 대부분의 시간에 발생하므로 실제로는 반대입니다. 따라서 시장의 영향과 통제력이 부족한 반면, 다른 CPU 생산자들은 PC 시장 이외의 시대에 평범한 방향 인 병렬 컴퓨팅으로 나아갔습니다.

하나는 매우 실용적이고 다른 하나는 역사적입니다.

실제적인 이유는 전화기에서 혼합 아키텍처를 사용하기 때문입니다. 전력 소비는 전화에 중요하며 전화는 성능이 거의 필요없는 모드에서 많은 시간을 소비합니다. 성능이 거의 필요하지 않을 때는 최소한의 전력 소비를 위해 일부 코어를 최적화하고, 필요할 때 최대 성능을 제공하도록 일부 코어를 최적화하는 것이 좋습니다.

다른 이유는 대체로 역사적입니다. 2005 년까지 데스크톱 CPU는 모두 단일 코어였습니다. 데스크톱 CPU 성능을 향상시키는 것은 거의 초당 가능한 많은 명령을 실행할 수있는 코어를 만드는 데 거의 독점적으로 이루어졌습니다. 오늘날에도 많은 데스크톱 소프트웨어는 여러 코어를 최대한 활용할 수 없으므로 코어가 20 % 더 느린 8 코어 CPU보다 4 코어 CPU를 선호합니다.

단일 코어에서 최대한 많은 성능을 얻으려면 엄청난 양의 CPU 공간이 필요합니다. 그렇지 않으면 더 많은 코어를 제공하는 데 사용할 수있는 부동산입니다. 그렇기 때문에 인텔의 최신 Kaby Lake CPU는 최대 4 코어에서 구매하고 각 코어는 이전 코어보다 빠르기 때문에 사람들이이를 구매합니다. 대부분의 경우 코어 수가 더 많은 CPU에서도 업그레이드됩니다.

시간이 지남에 따라 더 많은 코어를 지원하도록 훨씬 더 많은 데스크탑 소프트웨어가 완전히 최적화 될 것으로 예상됩니다. 그런 상황에서 엔지니어링 트레이드 오프는 데스크탑의 더 빠른 코어보다 더 많은 코어를 선호하기 시작합니다. 코어는 거의 확실히 빨라지지만 각 코어의 속도가 20 % 느리더라도 4 코어 CPU보다 8 코어 CPU를 선호하는 사람들을 보게 될 것입니다. 칩 디자이너들은 시장을 따를 것이다.

휴대 전화가 짧은 버스트로 계산 능력을 제공 할 수 있어야하고 (특정 앱은 빠를 필요가 있음) 과열을 피하는 것이 중요합니다 (노트북은 랩탑이나 PC보다 열 분산이 훨씬 더 어렵습니다). 이를 위해 건축가는 작업량이 적을 때 단일 코어를 사용하도록 전화를 설계하고 필요할 때 성능을 향상시키기 위해 추가 코어를 제공합니다. 휴대 전화가 더 큰 코어를 사용하지 않으면 작업량이 상당히 적은 경우에도 과열이 문제가됩니다.

출처 : 대학원 수준의 컴퓨터 아키텍처 과정.

첫째, Java 가상 머신은 역사적으로 일반적인 데스크탑 소프트웨어보다 멀티 코어 이상의 이점을 얻을 수 있습니다. Java로 단일 스레드 앱을 작성하더라도 대부분의 가비지 수집기 코드가 앱과 함께 실행되므로 멀티 코어에서 더 빨리 실행됩니다.

둘째, 휴대폰의 백그라운드에서 자동 업데이트, 광고 다운로드, 바이러스 백신 소프트웨어, GSM 모듈 관리 등 많은 일이 일어나고 있습니다. 랩톱에서 이러한 모든 작업은 하나의 코어를 거의 사용하지 않지만 ARM 코어는 반응이 약한 시스템을 원할 경우 백그라운드 작업에 전념하는 사람들을 두 명 이상 가질 수 있습니다.

마지막으로 마케팅이 있습니다. 8 코어의 혜택을 누릴 수 있는지 평가할 수있는 사용자는 많지 않지만 8 코어 스마트 폰은 2 코어 또는 4 코어 스마트 폰보다 비싸게 들립니다.

지금까지의 답변은 안드로이드 폰의 엄청나게 많은 수의 CPU 코어로 이어지는 문제의 일부 측면을 설명합니다. 다시 읽어보십시오. 안드로이드 폰. 아이폰은 오랫동안 몇 코어에 머물러 있었고 여전히 안드로이드 플래그쉽보다 훨씬 매끄 럽습니다.

안드로이드 설계자들은 자바 프로그래밍을 선택하고 결과적으로 JVM을 애플리케이션의 런타임으로 선택하기로 결정할 때 큰 도박을했습니다. Java는 설계 원칙으로 인해 성능을 희생하여 실행하기 전에 각 CPU 아키텍처에 대한 코드를 컴파일하고 빌드해야하는 문제를 해결합니다. Java는 일반적으로 JVM이라고하는 무겁고 부피가 큰 가상 머신을 도입합니다. JVM은 실제로 소프트웨어 레벨에서 CPU를 에뮬레이션하여 각 장치에 대해 개별적으로 코드를 컴파일 할 필요가 없습니다. JVM을 실행하는 장치에 관계없이 동일한 속성을 갖는 가상 CPU라고 생각하면 JVM에 대해 코드를 한 번만 컴파일하면 모든 장치에서 실행될 수 있습니다. 이를 통해 제조업체는 응용 프로그램 호환성에 대해 걱정할 필요없이 원하는 하드웨어를 던질 수 있습니다.

JVM 자체는 단지 사양 일 뿐이며이 사양을 준수하는 한 사람들은 자신의 JVM을 자유롭게 개발할 수 있습니다. 원래 안드로이드 JVM은 Dalvik이라고 불렀습니다. 오늘날 Google은이를 ART로 대체했습니다.

이제 JVM의 문제점은 무엇입니까? 그것은 많은 컴퓨팅 리소스를 소비하는 무거운 소프트웨어입니다. 또한 가비지 콜렉션과 같은 Java 언어의 다른 특성과 JVM의 자원 소비는 하드웨어 성능이 적당한 장치에 비해 너무 많아집니다. 장치에서 열려있는 각 응용 프로그램 및 시스템 서비스는 그 자체가 ART JVM의 인스턴스이며 이제는이를 관리하는 데 실제로는 유능한 하드웨어가 필요하다고 결론을 내릴 수 있습니다. 사용자 인터페이스를 그려야 할 때 상황이 더욱 악화됩니다.

각 응용 프로그램은 여러 스레드에서 실행됩니다. 각 CPU 코어는 한 번에 하나의 스레드 만 실행할 수 있습니다. 각 앱에는 사용자 인터페이스와 관련된 작업을 수행하는 하나의 기본 스레드가 있습니다. 파일 액세스, 네트워크 등을 수행하기 위해 응용 프로그램 당 더 많은 스레드가있을 수 있습니다. 일반적으로 CPU 코어보다 많은 응용 프로그램 (및 시스템 서비스)이 열려 있으며 결과적으로 CPU 코어보다 훨씬 많은 스레드가 있습니다. 따라서 각 코어는 서로 다른 스레드를 지속적으로 처리하고 각 스레드를 조금씩 수행하고 다음 단계로 전환해야합니다. 이 전환은 CPU에 많은 시간이 걸리고 응용 프로그램이 본질적으로 JVM 인 경우이 작업이 훨씬 더 철저 해집니다.

이 설명을 바탕으로 안드로이드가 원활하게 실행하기 위해 강력한 하드웨어가 필요하다고 추론 할 수 있습니다. 초기 세대의 Android 기기는 지연, 충돌 및 기타 불행한 것들로 유명했습니다. 그러나 수년에 걸쳐 이러한 문제는 대부분 강력한 하드웨어에 의존하여 해결되었습니다.

반면, iOS 애플리케이션은 기본 머신 코드로 컴파일되므로 가상화가 필요하지 않습니다. 사용 된 언어와 운영 체제도 더 효율적이므로 일부 장치는 과잉 칩셋 없이도 이러한 장치를 원활하게 유지할 수 있습니다.

위의 모든 것을 다시 시작하면 PC와 전화의 사용 사례가 상당히 다르다고 말할 수 있습니다. 단일 또는 두 개의 앱에서 사용되는 대부분의 PC (물론 많은 탭이있는 브라우저는 많은 CPU 코어가 필요하며 i-3에서도 지연 될 수 있음), 멀티 태스킹에 사용되는 전화. 최소한 네트워크 연결, UI 그리기, 시스템 트리거, 알림. PC에서 작업 관리자를 열면 많은 프로세스가 있지만 오래된 Core 2 duo에서도 CPU 성능의 몇 % 미만을 사용합니다. 4 코어는 꽤 저렴합니다 (MTK 65x2는 OEM 시작시 1 달러였습니다). 코어 당 성능이 마지막으로 부족한 경우에도 위험 대비 CISC입니다. 우리가 볼 수 있듯이 에너지 효율적! = 강력 합니다 . 멀티 코어는 심각한 단일 트레드로드와 멀티 태스킹 경험이 없기 때문에 모바일에 적합합니다 (그러나 우리는 iPhone이 소프트웨어로 인해 코어와 RAM이 더 적게 필요하다는 것을 알 수 있습니다)이 비디오 또는 다른 사람처럼 )

나는 큰 구성을 위해 4 또는 8 이상의 주요 추진 요인 중 하나는 현재 마케팅 일뿐이라고 생각합니다.

높은 코어 수의 큰 문제 중 하나는 메모리 크기를 고려할 때입니다. 일반적으로 데스크톱 응용 프로그램에서 여러 코어의 활용도를 향상 시키려면 단일 스레드 응용 프로그램에서 구조를 복제하고 훨씬 더 많은 메모리를 사용해야합니다.

RAM이 매우 비싸기 때문에 (특히 2017/2018 RAM 위기 상황에서) 발생하지 않습니다. 마케팅은 높은 숫자를 원하지만 제어는 구성 요소 가격을 낮추려고합니다. 코어 당 1 기가 바이트 미만의 RAM 미만의 균형을 보면 손상이 실패한 것입니다.