하드웨어 벤치마크 (2017년 중반)

하드웨어 벤치마크 분석으로, 개발자의 프로젝트에 알맞는 이상적인 하드웨어 구성 선택에 도움을 드리기 위한 글입니다.

Windows
MacOS
Linux

여기서 (2017년 중반 기준) 추정 가격과 예상 가격 관련 의견은 단순히 참고를 위한 정보 제공용입니다.

이 하드웨어 벤치마크 테스트는 프라이빗 P4V 스트림에서 //UE4/Main 의 Changelist (CL) 3477826 에서 취한 고정 코드 스냅샷으로 진행한 것입니다. 자동화 및 결과 취합 효율을 위하여, 해당 잡은 (동기화, 대기 등을 제외한) 타이밍 데이터와 함께 빌드 시스템을 통해 돌린 것입니다. 이 연구 목적으로 테스트에 사용된 머신 구성은 다음과 같습니다:

머신 이름

유형

CPU

코어/스레드

RAM

Dell T7910

데스크톱

Xeon E5-2667 v3 @ 3.2 GHz (듀얼)

8C/16T x 2

96GB

Dell T7810

데스크톱

Xeon E5-2643 v3 @ 3.4 GHz (싱글)

6C/12T

64GB

Lenovo P710

데스크톱

Xeon E5-2637 v4 @ 3.5 GHz (듀얼)

4C/8T x 2

96GB

Lenovo P510

데스크톱

Xeon E5-1650 v3 @ 3.5 GHz (싱글)

6C/12T

64GB

Current Builder

서버

Xeon E5-2680 v2 @ 2.8 GHz (듀얼)

10C/20H x 2

64GB

Cisco C220-01 (S)*

서버

Xeon E5-2637 v4 @ 3.5 GHz (싱글)

4C/8H

64GB

Cisco C220-01 (D)

서버

Xeon E5-2637 v4 @ 3.5 GHz (듀얼)

4C/8H x 2

64GB

Cisco C220-02 (S)*

서버

Xeon E5-2698 v4 @ 2.2 GHz (싱글)

20C/40H

64GB

Cisco C220-02 (D)

서버

Xeon E5-2698 v4 @ 2.2 GHz (듀얼)

20C/40H x 2

64GB

Cisco C220-03 (S)*

서버

Xeon E5-2640 v4 @ 2.4 GHz (싱글)

10C/20H

64GB

Cisco C220-03 (D)

서버

Xeon E5-2640 v4 @ 2.4 GHz (듀얼)

10C/20H x 2

64GB

*(D) 와 동일한 머신에서 CPU 만 하나 제거한 모델입니다.

테스트 도중, 데스크톱 머신은 Windows 10 , 서버 머신은 Windows 서버 2012 R2 에서 돌렸습니다. 또한, 모든 머신에는 Samsung 850 PRO 데이터 드라이브와 기가비트 이더넷 카드로 연결했습니다.

XGE 로 컴파일

이 테스트에는 데스크톱 머신만 고려했습니다. 본사의 표준 Incredibuild-XGE (XGE) 코디네이터와 에이전트 풀이 사용되었습니다.

모든 머신이 비슷한 퍼포먼스를 내었지만, T7910 가 다른 것보다 약간 느린 경향이 있었습니다. T7910 은 클럭 속도가 가장 느리긴 해도, 이 머신의 느린 퍼포먼스가 단순히 그 이유일 것으로 한정짓지는 않았습니다.

T7910

T7810

P710

P510

Compile UE4Editor Win64

0:07:03

0:06:28

0:06:35

0:06:29

Compile ParagonEditor Win64

0:06:22

0:05:42

0:06:03

0:05:48

Compile FortniteEditor Win64

0:05:24

0:05:08

0:04:57

0:05:00

XGE 로 컴파일하는 시간이 꽤나 일정치 않지만, 약간의 차이는 무시해도 괜찮을 것입니다. 보통, 에디터 컴파일에는 5 - 8 분 걸렸습니다.

HB_1.png

하루 중 각기 다른 시간마다 (오전 12시와 6시, 오후 12시와 6시) 별도의 테스트를 통해 에이전트 팜의 부하가 심한 병목현상이었는지 알아봤습니다.

HB_2.png

아침 컴파일 시간이 일정치 않아 보이는데, 많은 개발자들이 켜둔 UnrealGameSync 의 오전 6시 동기화 시간에 연관성이 있어 보였습니다.

메모리

P710P9710 의 추가 램이 퍼포먼스를 향상시키는 것 같지는 않아 보였습니다.

I/O

이 테스트는 전부 Samsung 850 PRO 데이터 드라이브에서 있었습니다. P710 에는 듀얼 RAID-0 PCIe m.2 시스템 드라이브가 탑재되어 있어 읽기/쓰기 퍼포먼스가 많이 높았습니다:

HB_3.png

HB_4.png

RAID-0 PCIe m.2

Samsung 850 PRO

XGE 컴파일의 일정치 않아서, 이 드라이브에서 컴파일하는 것이 퍼포먼스가 크게 향상되지는 않았습니다.

P710 - Samsung 850 PRO

P710 - 2 x PCIe m.2

변화

Compile UE4Editor Win64

0:06:35

0:05:33

-15.74%

Compile FortniteEditor Win64

0:04:57

0:05:16

6.37%

XGE 없이 컴파일

(아래) 노랑 선에서 보듯, T7910 퍼포먼스에 약간의 저하가 있습니다. 그 이유를 찾을 수는 없었지만, 모든 머신에서 이 테스트를 돌릴 때 다른 CPU 구성에서 컴파일 시간이 안정적인 것을 발견했습니다.

HB_5.png

에디터 컴파일 시간을 보면, 빌드 시간이 물리적 코어 개수에 정비례 관계이고, 코어 수가 같다면 싱글 CPU 구성이 듀얼 CPU 구성보다 약간 빠릅니다.

HB_6.png

IWYU (Include-What-You-Use) 리팩터링 이후, 에디터 컴파일이 고도로 병렬화되어 PCH (Precompiled Header) 병목현상이 매우 적어, 위에서 보이는 상관관계는 예상된 것입니다.

메모리

빌드 프로세스는 논리적 코어마다 컴파일러 인스턴스를 하나 스폰하여 C220-02 (D) 의 제한 요소가 되는데, 테스트의 다른 머신보다 코어 수가 많습니다 (40C/80H). C220-02 (D) 의 이러한 제한 요소 처리를 위해 램을 128GB 두 배로 늘렸더니 아래처럼 큰 향상이 있었습니다.

C220-02 (D) - 64GB

C220-02 (D) - 128GB

변화

Compile UE4Editor Win64

0:10:06

0:06:43

-33.50%

Compile ParagonEditor Win64

0:08:12

0:05:29

-33.13%

Compile FortniteEditor Win64

0:06:08

0:04:12

-31.52%

C220-03 (D) 머신의 램을 두 배로 늘린 이후 (20C/40H), 퍼포먼스가 약 10% 향상되었습니다 (아래 참고).

C220-03 (D) - 64GB

C220-03 (D) - 128GB

변화

Compile UE4Editor Win64

0:12:33

0:10:40

-14.92%

Compile ParagonEditor Win64

0:10:03

0:09:03

-10.01%

Compile FortniteEditor Win64

0:07:08

0:06:37

-7.24%

코어 수가 적은 머신의 경우, 이러한 효과의 기대치가 급격히 떨어지는데, 컴파일러 프로세스가 적을 수록 메모리를 적게 사용하기 때문입니다.

I/O

(P710 의) 듀얼 RAID-0 PCIe m.2 머신에서 Editor 컴파일이 큰 퍼포먼스 향상을 보이지는 않았습니다. 이 머신은 코어 수가 꽤나 적어 (2 x 4C/8T), 아마도 제한 요소가 아니었을 것입니다.

P710 - Samsung 850 PRO

P710 - 2 x PCIe m.2

변화

Compile UE4Editor Win64 - NoXGE

0:21:11

0:20:59

-0.94%

가용 램을 늘린 이후, I/O 가 아마도 C220-02 (D) 머신의 나머지 병목일 확률이 있습니다 (이 머신에 더욱 빠른 하드 드라이브 옵션이 없었습니다). 이 글 작성 시점에서, 비싼 CPU 가격이 (CPU 당 대략 $3,500 USD = 총 $7,000 USD) 확산에 걸림돌이 되지 않나 싶습니다.

콘텐츠 쿠킹

쿠킹 도중, 태스크 매니저 에서 보통 하나 또는 두 개의 스레드가 활성인 것으로 보였습니다. 채워진 (또는 "핫" 한) DDC (**파생 데이터 캐시) 덕에 패키지 시리얼라이제이션이 가장 병목현상이 심한 것 같았습니다.

T7910

T7810

P710

P510

Paragon Win64

0:38:00

0:35:04

0:37:18

0:35:15

Fortnite Win64

0:59:59

0:55:49

1:01:41

0:55:47

Current

C220-01 (D)

C220-02 (D)

C220-03 (D)

Paragon Win64

0:32:05

0:29:38

0:32:19

0:34:13

Fortnite Win64

1:03:59

0:51:32

0:55:47

0:58:32

데스크톱

빌더

C220 머신을 싱글 코어 구성으로 테스트한 결과는 채택하지 않았는데, 기본 Windows 서버 파워 구성이 (콘텐츠 쿠킹과 같은) 시리얼 작업에 대해 CPU 퍼포먼스가 조악하게 나오는 것을 발견했기 때문입니다.

메모리

Fortnite 쿠킹은 최대 램 사용량이 약 55GB 에 달하는 경향이 있어 가용 램 용량을 늘리는 것이 쿠킹 시간에 실제로 별다른 차이를 내지 못했습니다. 추가로, 패키지 리로드를 하지 않기 위해 가비지 컬렉션 을 비활성화시켰는데, 이는 64GB 램으로 워킹 세트 전체를 커버하기에 충분해 보였다는 뜻입니다. 이 최고수위선은 게임 크기가 커짐에 따라 늘어날 것입니다.

C220-03 (D) - 64MB

C220-03 (D) - 128MB

변화

Cook Paragon Win64

0:34:13

0:32:10

-6.01%

Cook Fortnite Win64

0:58:32

0:57:09

-2.35%

C220-02 (D) - 64MB

C220-02 (D) - 128MB

변화

Cook Paragon Win64

0:32:19

0:33:33

3.83%

Cook Fortnite Win64

0:55:47

0:55:58

0.34%

I/O

I/O 퍼포먼스 영향을 확인하기 위해, P710 에 제공된 듀얼 RAID-0 PCIe m.2 시스템 드라이브에서 포트나이트를 쿠킹했습니다. 놀랍게도, 퍼포먼스에 차이가 거의 없었습니다.

P710 - Samsung 850 PRO

P710 - 2 x PCIe m.2

Change

Cook Fortnite Win64

1:01:41

1:01:02

-1.04%

로컬 DDC

빌드 머신은 하위 호환상의 이유로 로컬 DDC 를 유지하지 않습니다. 다수의 브랜치에서 쿠킹을 돌릴 때 디스크 공간을 관리하기가 약간 까다롭고, 기존에 이 공간을 주기적으로 정리하려 해 봤으나 로컬 캐시를 사용하는 것보다 다시 채우는(back-fill) 데 더욱 많은 시간이 소모되었습니다.

머신 이름

Current

공유 DDC 만

로컬 및 공유 DDC

변화

Cook Paragon

0:32:05

0:31:55

-0.52%

Cook Fortnite

1:03:59

1:02:19

-2.60%

C220-01 (D)

공유 DDC 만

로컬 및 공유 DDC

변화

Cook Paragon

0:29:38

0:20:43

-30.09%

Cook Fortnite

0:51:32

0:48:24

-6.08%

C220-02 (D)

공유 DDC 만

로컬 및 공유 DDC

변화

Cook Paragon

0:32:19

0:23:36

-26.97%

Cook Fortnite

0:55:47

0:52:37

-5.68%

C220-03 (D)

공유 DDC 만

로컬 및 공유 DDC

변화

Cook Paragon

0:34:13

0:24:35

-28.15%

Cook Fortnite

0:58:32

0:54:23

-7.09%

공유 DDC

쿠킹 시 네트워크 퍼포먼스( 및 네트워크 공유 퍼포먼스)의 효과를 측정하기 위해, 공유 DDC 를 끄고 로컬 DDC 를 가득 채워 테스트를 돌렸습니다. 공유 DDC 에 쓰기 작업은 비동기로 이루어져서, 로컬 DDC 의 코히렌트가 높으면 공유 DDC 를 꺼도 쿠킹 시간에 영향을 주지 않습니다.

머신 이름

Current

공유 DDC 만

로컬 및 공유 DDC

변화

Cook Paragon

0:31:55

0:30:36

-4.13%

Cook Fortnite

1:02:19

1:02:57

1.02%

C220-01 (D)

공유 DDC 만

로컬 및 공유 DDC

변화

Cook Paragon

0:20:43

0:20:40

-0.24%

Cook Fortnite

0:48:24

0:48:13

-0.38%

C220-02 (D)

공유 DDC 만

로컬 및 공유 DDC

변화

Cook Paragon

0:23:36

0:23:16

-1.41%

Cook Fortnite

0:52:37

0:52:08

-0.92%

C220-03 (D)

공유 DDC 만

로컬 및 공유 DDC

변화

Cook Paragon

0:24:35

0:24:08

-1.83%

Cook Fortnite

0:54:23

0:54:50

0.83%

DDC 무효화

쿠커의 시간을 주로 잡아먹는 것은 패키지에 시리얼라이즈 인( 그리고 아웃) 할 때인데, 이 때는 CPU 코어를 추가로 활용하지 못합니다. 하지만 애니메이션 데이터 압축용 파생 데이터 생성, 플랫폼 전용 텍스처나 셰이더 컴파일 등의 작업에 병렬 실행됩니다.

DDC 는 대부분 애셋 유형에 대한 쿠커 마스킹에 뛰어난 역할을 합니다. 텍스처 압축은 특히 느릴 수 있지만, 압축기는 (있다 하더라도) 거의 변하지 않기에, 비용은 별개의 텍스처 변화마다 한 번씩만 일어납니다.

DDC 데이터를 가장 자주 무효화시키는 경우는 엔진 셰이더 버전이 바뀔 때입니다. 이 변화의 효과는 외부(off-site) 작업중인 사용자에게 가장 중요하게 작용할 수 있으므로, 셰이더 버전이 새로운 쿠킹 시간을 측정했습니다.

한 머신에서 캐시된 데이터가 다른 머신에서 사용되는 것을 피하기 위해, 이 테스트는 공유 DDC 를 끈 상태로 진행했습니다.

머신 이름

이전 셰이더

새로운 셰이더

변화

Current

Cook Paragon

0:30:36

7:53:40

1,447.93%

C220-01 (D)

Cook Paragon

0:20:40

15:04:22

4,275.97%

C220-02 (D)

Cook Paragon

0:23:16

7:55:22

1,943.12%

C220-03 (D)

Cook Paragon

0:24:08

9:08:44

2,173.76%

(2 x 10C/20H) 현재 빌드 머신이 (역시 2 x 10C/20H 인) C220-03 (D) 보다 (2 x 20C/40H 인) C220-02 (D) 와 퍼포먼스가 비슷하다는 점이 놀랍습니다. 하지만 이 테스트는 한 번만 돌린 것입니다. 테스트를 몇 번 더 돌렸다면, 약간 다른 결과가 나왔을 수도 있습니다.

흥미로운 사실이라면, 다른 게임의 경우, 파라곤의 셰이더만 빌드하는 것이 쿠킹 시간을 조금 더 적당한 수준으로 끌어 내렸습니다 (그 셰이더 대다수가 이미 로컬 DDC 에 있는 상태).

머신 이름

Current

이전 셰이더

새로운 셰이더

변화

Cook Fortnite

1:02:57

1:49:16

73.58%

C220-01 (D)

이전 셰이더

새로운 셰이더

변화

Cook Fortnite

0:48:13

Didn't Finish

None Applicable

C220-02 (D)

이전 셰이더

새로운 셰이더

변화

Cook Fortnite

0:52:08

2:08:57

147.35%

C220-03 (D)

이전 셰이더

새로운 셰이더

변화

Cook Fortnite

0:54:50

2:20:54

156.05%

에디터 컴파일 및 파라곤 쿠킹 이후, C220-01 (D) 에 대한 임베디드 컨트롤러(EC)에 잡 타임아웃이 발생하여, 이 테스트 도중 완료되지 못했습니다.

현지 개발자를 위한 추천

현지(onsite) 작업중인 경우, XGE 를 사용하면 (퍼포먼스 편차가 있을 수는 있지만) 코어 수가 많은 CPU 를 사용하는 것의 대안이 될 수 있습니다. 그에 사응하는 결과를 낸 유일한 독립형 머신은 128GB 램을 탑재한 2 x 20C/40T 빌더였습니다. T7810 이 신형 T7910 보다 나은 퍼포먼스를 내고 있고, 차이점이 미묘하기는 했지만, 빠른 프로세서를 탑재한 머신이 나아 보이기는 합니다.

기준 구성으로는 64GB 램 정도면 적합해 보이나, 96-128GB 램 (또는 앞으로 확장을 계획하는) 정도로 하는 것이 좋아 보입니다.

Samsung 850 PRO SSD 로 괜찮은 것 같고, 공간이 부족해질 때는 시스템 안전성 확보를 위해 별도의 시스템/데이터 드라이브를 마련하는 것이 합리적인 정책이기는 하지만, 저희가 쓰는 툴을 사용하기에 표준 256GB 드라이브로는 충분치 않다는 푸념이 잦았습니다. SSD 쓰기 증폭 기능으로 인한 퍼포먼스 손실을 방지하기 위해, 시스템 페이지파일 확장을 위한 여유 공간을 예약해 둬야 합니다. 512GB 로 두 배 늘이는 것이 합리적인 선택인 것으로 보입니다.

외부 개발자를 위한 추천

공유 DDC 또는 XGE 팜을 접근할 수 없는 개발자는 반드시 다수의 코어를 활용해야 합니다. (개당 $1,000 USD 정도 하는) 2 x 10C/20H 구성이 좋아 보이는데, 2 x 20C/40H 구성은 개당 대략 $3,500 USD 정도 하는데 비해 가성비가 기대에 못미치는 듯 합니다.

마지막으로, 128GB 램을 설치하면 (컴파일할 때) 퍼포먼스가 약 10% 상승하니 가치가 있는 것 같습니다.

빌드 팜 구성

외부 개발자의 경우, 빌드 머신은 전형적으로 내부 빌드 팜 사양과 일관되도록 지정합니다. "일반" 개발자와 달리, 빌더에 걸리는 부하가 꽤나 고정적이고 XGE 를 사용하면 경합이나 변동성이 늘어나며, 정지 시간 도중 작업량을 분산하지 못한다는 점을 과거 경험을 통해 배웠습니다. XGE 가 없을 때 퍼포먼스 주요 선수는 CPU 코어 수입니다.

빌드 팜에서 실행중인 잡 분석을 통해 쿠킹과 컴파일에 소모되는 시간 비율을 파악, 이 정보를 활용하여 같은 작업량을 처리할 때 각기 다른 CPU 구성의 가성비를 측정할 수 있었습니다. 현재 팜 용도는 50/50 에 가깝게 나뉘며, 매일 컴파일에 소모되는 빌더 시간은 대략 418 시간, 쿠킹이나 기타 (주로) 직렬 작업에는 대략 423 시간 소모되고 있습니다.

기준 머신 가격을 $5,000 USD 로 잡고 CPU 개당 가격을 아마존 가격으로 친다면, 평균 작업 유닛 하나를 해내는 속도에 따라 정규화된 머신 가격을 산정할 수 있습니다. 이를 기준으로 삼으면 $100,000 USD 를 고사양 머신 하나에 쓰는게 나은지, 저사양 머신 두 대에 쓰는게 나은지 알 수 있습니다.

머신 이름

CPU

상대적 작업량

CPU 가격

정규화된 머신 가격

작업량 당 가격

C220-01 (S)

E5-2637 v4 - 4C/8H 3.5GHz

1.395

$996.00

$5,996.00

$8,367.12

C220-01 (D)

E5-2637 v4 - 4C/8H 3.5GHz (듀얼)

1.276

$1,992.00

$6,992.00

$8,922.15

C220-02 (S)

E5-2698 v4 - 20C/40H 2.2GHz

0.931

$3,226.00

$8,226.00

$7,662.22

C220-02 (D)

E5-2698 v4 - 20C/40H 2.2GHz (듀얼)

0.851

$6,452.00

$11,452.00

$9,744.96

C220-03 (S)

E5-2640 v4 - 10C/20H 2.4GHz

1.268

$939.00

$5,939.00

$7,531.10

C220-03 (D)

E5-2640 v4 - 10C/20H 2.4GHz (듀얼)

1.006

$1,878.00

$6,878.00

$6,921.82

듀얼 10C/20H 구성이 최고 자리를 차지했습니다. 현재 저희 팜에 있는 듀얼 E5-2680v2 10C/20H 구성과 비슷합니다.

Select Skin
Light
Dark

Welcome to the new Unreal Engine 4 Documentation site!

We're working on lots of new features including a feedback system so you can tell us how we are doing. It's not quite ready for use in the wild yet, so head over to the Documentation Feedback forum to tell us about this page or call out any issues you are encountering in the meantime.

We'll be sure to let you know when the new system is up and running.

Post Feedback