컴퓨터 시스템 시뮬레이터: 친숙한 전체 플랫폼 시뮬레이터와 알 수 없는 시계 방향 및 추적

컴퓨터 시스템 시뮬레이터에 관한 기사의 두 번째 부분에서는 컴퓨터 시뮬레이터에 대한 간단한 소개 형식, 즉 일반 사용자가 가장 자주 접하는 전체 플랫폼 시뮬레이션과 시계 기준에 대해 계속 이야기하겠습니다. -개발자 집단에서 더 흔히 볼 수 있는 시계 모델 및 추적.

В 첫 번째 부분 나는 일반적으로 시뮬레이터가 무엇인지와 시뮬레이션 수준에 대해 이야기했습니다. 이제 그 지식을 바탕으로 좀 더 깊이 들어가 전체 플랫폼 시뮬레이션, 트레이스를 수집하는 방법, 나중에 이를 사용하여 수행할 작업 및 시계별 마이크로아키텍처 에뮬레이션에 대해 이야기할 것을 제안합니다.

전체 플랫폼 시뮬레이터 또는 "현장에서 혼자는 전사가 아닙니다"

예를 들어 네트워크 카드와 같은 특정 장치의 작동을 연구하거나 이 장치의 펌웨어 또는 드라이버를 작성하려는 경우 해당 장치를 별도로 시뮬레이션할 수 있습니다. 그러나 나머지 인프라와 분리하여 사용하는 것은 그리 편리하지 않습니다. 해당 드라이버를 실행하려면 중앙 프로세서, 메모리, 데이터 버스에 대한 액세스 등이 필요합니다. 또한 드라이버가 작동하려면 운영 체제(OS)와 네트워크 스택이 필요합니다. 또한, 별도의 패킷 생성기와 응답 서버가 필요할 수 있습니다.

전체 플랫폼 시뮬레이터는 BIOS 및 부트로더부터 OS 자체 및 다양한 하위 시스템(예: 동일한 네트워크 스택, 드라이버 및 사용자 수준 애플리케이션)까지 모든 것을 포함하는 완전한 소프트웨어 스택을 실행하기 위한 환경을 만듭니다. 이를 위해 프로세서 및 메모리, 디스크, 입/출력 장치(키보드, 마우스, 디스플레이) 및 동일한 네트워크 카드 등 대부분의 컴퓨터 장치의 소프트웨어 모델을 구현합니다.

다음은 Intel의 x58 칩셋의 블록 다이어그램입니다. 이 칩셋의 전체 플랫폼 컴퓨터 시뮬레이터는 블록 다이어그램에 자세히 설명되지 않은 IOH(입력/출력 허브) 및 ICH(입력/출력 컨트롤러 허브) 내부 장치를 포함하여 나열된 장치 대부분의 구현이 필요합니다. . 실습에서 알 수 있듯이 우리가 실행할 소프트웨어에서 사용하지 않는 장치는 많지 않습니다. 이러한 장치의 모델을 만들 필요는 없습니다.

대부분의 경우 전체 플랫폼 시뮬레이터는 프로세서 명령 수준(ISA, 아래 참조)에서 구현됩니다. 이전 기사). 이를 통해 비교적 빠르고 저렴하게 시뮬레이터 자체를 만들 수 있습니다. ISA 레벨은 예를 들어 더 자주 변경되는 API/ABI 레벨과 달리 다소 일정하게 유지되기 때문에 좋습니다. 또한 명령어 수준에서의 구현을 통해 소위 수정되지 않은 바이너리 소프트웨어를 실행할 수 있습니다. 즉, 실제 하드웨어에서 사용되는 것과 똑같이 이미 컴파일된 코드를 변경 없이 실행할 수 있습니다. 즉, 하드 드라이브의 복사본("덤프")을 만들고 이를 전체 플랫폼 시뮬레이터에서 모델의 이미지로 지정하면 짜잔! – OS 및 기타 프로그램은 추가 작업 없이 시뮬레이터에 로드됩니다.

시뮬레이터 성능

위에서 언급했듯이 전체 시스템, 즉 모든 장치를 시뮬레이션하는 프로세스는 다소 느린 작업입니다. 이 모든 것을 마이크로아키텍처나 논리와 같은 매우 세부적인 수준에서 구현하면 실행 속도가 극도로 느려집니다. 그러나 명령 수준은 적절한 선택이며 사용자가 편안하게 상호 작용할 수 있을 만큼 충분한 속도로 OS와 프로그램을 실행할 수 있도록 해줍니다.

여기서는 시뮬레이터 성능에 관한 주제를 다루는 것이 적절할 것입니다. 일반적으로 IPS(초당 명령 수), 보다 정확하게는 MIPS(백만 IPS), 즉 XNUMX초에 시뮬레이터에서 실행되는 프로세서 명령 수로 측정됩니다. 동시에 시뮬레이션 속도는 시뮬레이션 자체가 실행되는 시스템의 성능에 따라 달라집니다. 따라서 원래 시스템과 비교하여 시뮬레이터의 "느림"에 대해 이야기하는 것이 더 정확할 수 있습니다.

QEMU, VirtualBox 또는 VmWare Workstation과 같이 시중에 나와 있는 가장 일반적인 전체 플랫폼 시뮬레이터는 우수한 성능을 제공합니다. 시뮬레이터에서 작업이 진행되고 있다는 사실이 사용자에게 눈에 띄지 않을 수도 있습니다. 이는 프로세서, 바이너리 변환 알고리즘 및 기타 흥미로운 기능에 구현된 특수 가상화 기능 덕분에 발생합니다. 이것은 모두 별도의 기사에 대한 주제이지만 간단히 말해서 가상화는 시뮬레이터가 명령을 시뮬레이션하지 않고 실행을 위해 실제 프로세서에 직접 보낼 수 있도록 하는 최신 프로세서의 하드웨어 기능입니다. 시뮬레이터와 프로세서는 유사합니다. 바이너리 변환은 게스트 기계 코드를 호스트 코드로 변환한 후 실제 프로세서에서 실행하는 것입니다. 결과적으로 시뮬레이션은 5~10배로 약간만 느려지고 실제 시스템과 동일한 속도로 실행되는 경우도 많습니다. 이는 많은 요인의 영향을 받지만. 예를 들어, 수십 개의 프로세서가 있는 시스템을 시뮬레이션하려는 경우 속도는 즉시 수십 배만큼 떨어집니다. 반면 최신 버전의 Simics와 같은 시뮬레이터는 다중 프로세서 호스트 하드웨어를 지원하고 시뮬레이션된 코어를 실제 프로세서의 코어에 효과적으로 병렬화합니다.

마이크로 아키텍처 시뮬레이션의 속도에 대해 이야기하면 일반적으로 시뮬레이션 없이 일반 컴퓨터에서 실행하는 것보다 약 1000-10000배 느린 수십 배 정도 느립니다. 그리고 논리적 요소 수준의 구현은 몇 배나 느려집니다. 따라서 이 수준에서는 FPGA를 에뮬레이터로 사용하여 성능을 크게 향상시킬 수 있습니다.

아래 그래프는 모델 세부 사항에 대한 시뮬레이션 속도의 대략적인 의존성을 보여줍니다.

비트별 시뮬레이션

낮은 실행 속도에도 불구하고 마이크로아키텍처 시뮬레이터는 매우 일반적입니다. 각 명령어의 실행 시간을 정확하게 시뮬레이션하려면 프로세서 내부 블록의 시뮬레이션이 필요합니다. 여기서 오해가 발생할 수 있습니다. 결국 각 명령의 실행 시간을 단순히 프로그래밍하면 안되는 것 같습니다. 그러나 이러한 시뮬레이터는 동일한 명령의 실행 시간이 호출마다 다를 수 있으므로 매우 부정확합니다.

가장 간단한 예는 메모리 액세스 명령입니다. 요청된 메모리 위치를 캐시에서 사용할 수 있으면 실행 시간이 최소화됩니다. 이 정보가 캐시에 없으면("캐시 누락") 명령어 실행 시간이 크게 늘어납니다. 따라서 정확한 시뮬레이션을 위해서는 캐시 모델이 필요합니다. 그러나 문제는 캐시 모델에만 국한되지 않습니다. 프로세서는 데이터가 캐시에 없을 때 메모리에서 데이터가 검색될 때까지 단순히 기다리지 않습니다. 대신, 메모리에서 읽은 결과에 의존하지 않는 명령을 선택하여 다음 명령 실행을 시작합니다. 이는 프로세서 유휴 시간을 최소화하는 데 필요한 소위 "순서가 다른" 실행(OOO, Out of Order Execution)입니다. 해당 프로세서 블록을 모델링하면 명령어 실행 시간을 계산할 때 이 모든 것을 고려하는 데 도움이 됩니다. 이들 명령어 중 메모리에서 읽은 결과를 기다리는 동안 실행되는 경우 조건부 점프 동작이 발생할 수 있다. 현재 조건의 결과를 알 수 없는 경우 프로세서는 다시 실행을 중지하지 않고 "추측"하고 적절한 분기를 수행하며 전환 시점부터 사전에 명령을 계속 실행합니다. 분기 예측기라고 불리는 이러한 블록은 마이크로아키텍처 시뮬레이터에서도 구현되어야 합니다.

아래 그림은 프로세서의 주요 블록을 보여줍니다. 알 필요는 없으며 마이크로 아키텍처 구현의 복잡성을 보여주기 위해서만 표시됩니다.

실제 프로세서에서 이러한 모든 블록의 작동은 특수 클록 신호에 의해 동기화되며 모델에서도 동일한 일이 발생합니다. 이러한 마이크로아키텍처 시뮬레이터를 사이클 정확도라고 합니다. 주요 목적은 개발 중인 프로세서의 성능을 정확하게 예측하거나 벤치마크와 같은 특정 프로그램의 실행 시간을 계산하는 것입니다. 값이 필요한 것보다 낮으면 알고리즘과 프로세서 블록을 수정하거나 프로그램을 최적화해야 합니다.

위에서 볼 수 있듯이 클록별 시뮬레이션은 매우 느리기 때문에 프로그램 작동의 특정 순간을 연구할 때만 사용됩니다. 여기서 프로그램 실행의 실제 속도를 알아내고 장치의 향후 성능을 평가해야 합니다. 프로토타입이 시뮬레이션되고 있습니다.

이 경우 기능 시뮬레이터를 사용하여 프로그램의 남은 실행 시간을 시뮬레이션합니다. 이러한 사용 조합은 실제로 어떻게 발생합니까? 먼저, OS와 연구 중인 프로그램을 실행하는 데 필요한 모든 것이 로드되는 기능 시뮬레이터가 시작됩니다. 결국 우리는 OS 자체나 프로그램 시작 초기 단계, 구성 등에 관심이 없습니다. 하지만 이 부분을 건너뛰고 바로 중간부터 프로그램 실행으로 넘어갈 수도 없습니다. 따라서 이러한 모든 예비 단계는 기능 시뮬레이터에서 실행됩니다. 우리가 관심을 갖는 순간까지 프로그램이 실행된 후에는 두 가지 옵션이 가능합니다. 모델을 시계별 모델로 교체하고 계속 실행할 수 있습니다. 실행 가능한 코드(즉, 일반 컴파일된 프로그램 파일)를 사용하는 시뮬레이션 모드를 실행 중심 시뮬레이션이라고 합니다. 이는 가장 일반적인 시뮬레이션 옵션입니다. 추적 기반 시뮬레이션이라는 또 다른 접근 방식도 가능합니다.

추적 기반 시뮬레이션

두 단계로 구성됩니다. 기능 시뮬레이터를 사용하거나 실제 시스템에서 프로그램 작업 로그가 수집되어 파일에 기록됩니다. 이 로그를 추적이라고 합니다. 검사 대상에 따라 추적에는 실행 가능한 명령, 메모리 주소, 포트 번호 및 인터럽트 정보가 포함될 수 있습니다.

다음 단계는 시계별 시뮬레이터가 트레이스를 읽고 거기에 기록된 모든 명령을 실행할 때 트레이스를 "재생"하는 것입니다. 마지막에는 프로그램의 이 부분의 실행 시간과 이 프로세스의 다양한 특성(예: 캐시 적중률)을 얻습니다.

트레이스 작업의 중요한 특징은 결정론입니다. 즉, 위에서 설명한 방식으로 시뮬레이션을 실행하여 동일한 일련의 작업을 반복해서 재현합니다. 이를 통해 모델 매개변수(캐시, 버퍼 및 대기열 크기)를 변경하고 다양한 내부 알고리즘을 사용하거나 조정하여 특정 매개변수가 시스템 성능에 어떤 영향을 미치는지, 어떤 옵션이 최상의 결과를 제공하는지 연구할 수 있습니다. 실제 하드웨어 프로토타입을 제작하기 전에 프로토타입 장치 모델을 사용하여 이 모든 작업을 수행할 수 있습니다.

이 접근 방식의 복잡성은 먼저 애플리케이션을 실행하고 추적을 수집해야 한다는 점과 추적 파일의 크기가 크다는 점에 있습니다. 장점으로는 관심 있는 장치나 플랫폼의 일부만 시뮬레이션하는 것으로 충분하지만, 실행을 통한 시뮬레이션에는 일반적으로 완전한 모델이 필요하다는 점입니다.

따라서 이 기사에서는 전체 플랫폼 시뮬레이션의 기능을 살펴보고 다양한 수준의 구현 속도, 클록별 시뮬레이션 및 추적에 대해 이야기했습니다. 다음 기사에서는 개인적인 목적과 대기업의 개발 관점에서 시뮬레이터를 사용하는 주요 시나리오를 설명하겠습니다.

출처 : habr.com