벤치리뷰·뉴스·정보/고전 스페셜 정보

[고전 2005.03.10] 모든 문제는 Longhorn으로 이어진다

tware 2005. 12. 15. 04:30

 

Windows에서 개발되어 온 다양한 API를 정리하고 완전히 새로운 기능으로 재 통합. 지금까지 지원할 수 없었던 하드웨어나 기능도 구현 가능하게 된다. Longhorn (롱혼 = 비스타)이 담당하는 역할은 크지만, 그에 따라서 Longhorn을 전제로 하는 제품, 기술이 많이 존재하기 때문에 Longhorn의 일정 변경에 따른 업계의 피해는 매우 큰 것이다.


 그것은 예를 들어, Windows 이외의 자사 제품의 방향에도 영향을 주고 있는 정도다. 가장 큰 영향을 받은 것은 아마도 Office 것이다. 차기 Office는 본래 보안을 가장 중시하고 관리 코드 (.NET 프레임 워크에서 사용되는 중간 바이너리)을 써서 Longhorn에서 지원되는 WinFS를 최대한 활용하여 대폭 기능을 강화한 것이 된다, 라고 선전했다. 그러나 Longhorn에서 WinFS의 지원이 없어지고, 스케쥴도 뒤쪽으로 미끌어진 지금, 차기 Office는 완전히 다른 방향에서의 부가가치 향상을 지향하는 것 같다 (참고로 Microsoft는 지금까지 Office 개발 스케쥴을 미룬 것은 아니다).

 하지만 Longhorn 일정은 Intel의 전략에 까지 큰 영향을 주고있다. 얼마 전 샌프란시스코에서 개최된 IDF Spring 2005에서는 팻 겔싱어 씨의 기조 강연에 Microsoft 수석 부사장 짐 오르틴 씨가 게스트로 초대되어 양사가 협력하면서 업계를 고조시키는 자세를 보였다 .

 그러나 Intel은 적어도 2006년 이라는 Longhorn의 출하 예정을 믿지 않는 것이다.

 


32bit 프로세서의 VT는 기능 한정판?

 Intel은 지금까지 "T 's"라고 칭하고 프로세서에 관련된 다양한 주변 기술을 발표해 왔다. 그러나 가장 발표가 빨랐던 LaGrande Technology (LT = TXT = 인텔 한국어 사이트이름 = 신뢰 실행 기술 )는 아직까지 실현되지 않고있다. 기능은 구현되어 있지만, 그 기능을 잘 다루는 소프트웨어가 없기 때문이다.

 지난해 가을 IDF 단계에서 Intel 사장 겸 COO 인 폴 오텔리니는 LT는 Vanderpool Technology(코드네임) (VT 현재는 Intel Virtualization Technology로 이름을 바꿨다)와 함께, Longhorn에서 이용 가능하게 된다고 말했다.

 그런데 이번 IDF에서는 "VT의 일부분"을 선행해 Longhorn 전에 투입한다고 한다. 물론 그 배경에는 VT와 같은 가상 머신 기술이 올해 대대적으로 추진하는 듀얼 코어 프로세서의 매력을 어필하는 중요한 측면은 있다. 하지만 그것에는 다소 긴급처방의 인상이 강하다.

 LT의 경우 전체 시스템의 시큐리티 아키텍처에 관한 부분 때문에 선행 대응하는 것은 어렵지만 VT의 경우라면 해결할 수 없는 것은 아니다. Microsoft의 예정에 동조하는 것이 아닌, 가능한 것은 스스로 움직이자. 아마 Intel은 그렇게 생각한 것은 아닐까. Intel은 LT 관해서는 기조 강연 중에도 "2006년 Longhorn과 함께 나온다"라고 한마디 말했을뿐 슬라이드도 약간만 표시했을 뿐이었다. 2006년 중에 새로운 기술을 세우는 것은 불가능 하다. 그리 판단하고 "VT의 일부분"을 잘라 꺼내기로 한 것이다.

 그렇면 무엇이 본래의 VT와 다른가?

 그 차이는 버추얼 머신 매니저 (VMM)가 작동하는 장소다. 원래 VT에서는 VMM이 OS보다 높은 특권 모드에서 동작하고, 모든 OS가 가상 머신 안에서 움직인다. 따라서 보통의 VMM 애플리케이션 (VMware나 Virtual PC)과 같이 호스트 OS 게스트 OS 등의 구별도 없다. 그러나 이번에 발표 된 "VT​​ 일부분"은 VMM을 호스트 OS에서 기동하는 구조로 되어 있다.

 


기능 한정판 VT의 성능

 왜 Longhorn이 아니면 VT를 완전히 실현할 수 없는가? 그 이유는 부팅 순서에 있다. VMM을 OS가 동작하는 특권 모드 보다 높은 특권 모드로 동작시키기 위해는 OS가 아직 로드되지 않은 부팅 순서에서 직접 VMM를 시작하는 구조가 필요하다.

 그러기 위해서는 32bit 모드에서 동작하고, 모든 하드웨어에 대한 액세스를 가능하게 하는 EFI가 필수적이다. 실제로 처음부터 EFI 의한 부트 업으로 설계된 Itanium 2 플랫폼에서는 VT의 도입에 아무런 장애가 없다. 실제로 IDF의 전시회에서도 Montecito 용으로는 VT의 데모가 순조롭게 작동하고, 거의 제품에 가까운 수준의 완성에 있는 것을 느끼게 했다. 그러나 32bit 환경에서 EFI를 지원하려면 먼저 OS 측이 EFI에 대응해야 한다. Windows의 경우 그것이 Longhorn의 타이밍이다.

 그래서 Intel은 방침을 전환하고, 호스트 OS상에서 동작하는 VMM에서 VT용의 확장 명령어 세트 "VMX"를 VMM 벤더에 쓰게하는 것으로 현행 Windows 사용자도 VMX를 활용 가능하게 하는 것이 이번의 발표다. VMX에 대응 예정인 32bit의 VMM 소프트웨어는 VMware, Virtual PC, Xen의 이름이 올라있다.

 IDF 전시장에서 이들 벤더에게 이야기를 들어보니 VMX 의해 다음과 같이 개선 가능하다 말한다.

 "기존에는 완전히 가상화 하지 못하고, OS에 대한 동적 패치로 처리하고 있던 부분을 가상화 가능하게 되어 패치가 불필요. 그 결과 PC 용의 모든 OS를 동작시키는 것이 가능

"소프트웨어 에뮬레이션으로 하던 하드웨어 이벤트 처리의 대부분을 하드웨어로 처리 (단 I / O 처리 제외)"

 이것만으로도 상당한 성능 향상을 도모하는 것이 가능하다. Intel은 VT 사용때와 미사용 때의 하드웨어 이벤트 에뮬레이션 횟수를 공표하고 있는데, I / O 이벤트를 제외, 특히 인터럽트 처리가 극적으로 감소하고 있는 것을 알 수있다.

 I / O 처리가 감소하지 않는 것은 디스크나 그래픽 등의 하드웨어가 가상화 되는 것을 전제로 설계되어 있지 않기 때문이다. IDF는 하드웨어 개발자 "그래픽도 디스크도 모든 하드웨어를 가상화로 가자"라고 호소했다.

 I / O 이벤트 이외의 가상 하드웨어에서 대응 하는 것으로, 어디까지 성능 향상을 도모하나? 실은 호스트 OS상에서 동작하는 VMM 소프트웨어 벤더도 아직 데모도 완성하지 못한 단계로 예상은 어렵다. 그러나 VMM 소프트웨어에서 OS를 움직일 때 특유의 반응의 둔함은 없어지고, 듀얼 코어에 의한 성능 이득도 포함해, 게임 등을 행하지 않는 한 가상 머신임에 있는 것을 의식하지 않는 수준에는 된다고 VMware 담당자는 말한다.

 

VT 사용시 성능

 


VT의 미래상

 이에 대해 EFI 기동이 전제인 Montecito는 호스트 OS를 필요로 하지 않는 진정한 VT로 이미 작동하고 있다. Itanium 2 판의 VMM을 개발한 히타치 제작소에 따르면, 머신상에서 처리 가능한 동시 스레드를 가상 머신에 대해 각각 임의의 수를 할당하는 것도 가능하다 라고 말한다.

 즉, CPU를 가상화한 컴퓨터의 리소스를 가상 머신에 완전히 재 할당하는 것이다. 실력면에서도 대량의 I / O 처리가 각 VM에서 동시에 집중하는 일이 없는 한, 가상 머신인 것조차 의식하지 못할 것이라고 말한다. 릴리스 시기도 Montecito와 동시 발표가 될 전망.


 Intel에 따르면, 미래에는 하드웨어 벤더가 각각의 하드웨어를 가상화해서 I / O 처리 이벤트의 소프트웨어 에뮬레이션이 불필요해져 성능이 오르는 것은 물론, VT가 제공하는 가상화 기능의 범위도 크게 변해간다고 말했다.

 예를 들어 3D 그래픽 처리의 경우 그래픽 처리 파이프 라인을 가상 머신마다 임의의 수를 할당하거나, 처리 내용에 따라 VMM이 동적으로 할당하는 자원을 변화 시키거나 하는 일이 가능하 게된다. 같은 처리를 네트워크 대역폭과 파일 I / O에 대해서도 하는 것도 가능한 것이다.

 그러나 그러기 위해서는 조기에 VT가 "본래의 모습"이 되어야 한다. Itanium 2의 세계는 이미 시작하고 있지만, 우리 엔드유저가 사용하는 PC의 경우, 우선 Longhorn의 출하를 기다리고 EFI 기동 PC (또는 마더보드)로 교체하는 단계에 겨우 입구에 서있다. 또한 프로세서 이외의 하드웨어 가상화할 때 까지를 생각하면 아직도 앞으로 멀다

 이전 이 연재에서 Intel의 윌리엄 슈 씨에게 이야기를 들었던 때, 그는 "당초 제공되는 것은 VT1, 본래의 I / O 부분까지 성능을 끌어낼 2세대 VT2는 그 몇년 후에 된다" 라고 말했다. 그러나 아직 우리는 VT 0.5 의 세계로 겨우 들어가고 있는 단계인 것이다.

 

"Longhorn 대기"가 낳은 폐해

 Longhorn 대기 인한 폐해는 VT와 LT 이외에도 많이있다.

 예를 들어, 픽셀이 눈에 보이지 않을 정도의 고해상도가 가능해지고 있는 액정 패널에 대해서, 적당한 내부 처리 해상도로 스케일링의 표시를 행하면서, 기존 응용 프로그램과의 호환성을 취할 수 있도록 표시를 하려면 그래픽 표시 API가 변화해야 한다.

 예를 들어 여러 다른 컬러 포맷의 화상을 사용자가 의식하지 않고 볼 수 있게 되기 위해서는 역시 API의 변화가 필요. 현재 GDI +는 다중 디스플레이나 다른 프린터 용지마다 색상의 차이에 대해 다른 특성을 할당 할수 조차 없다. 멀티 디스플레이에서 다른 기종을 나란히 사용하면 위화감를 느낄 것이다. 이들은 주변 하드웨어와도 밀접하게 관련된 부분이며, Intel뿐만 아니라 많은 하드웨어 벤더가 "Longhorn 대기"에서 제품 계획의 변경을 강요 당하고 있다.

 물론 Microsoft에서도 할말은 있다. Longhorn는 Win16로 만들어진 API의 기본 아키텍처를 재검토할 최대의 기회이다. 여기에서 타협을 하면, 훗날의 발전이 저해 될 가능성도있다. 그래서 출시 시기 보다 기능의 구현이 중요한 것이라고 설명해 왔다.

 그러나 Longhorn의 최초 버전부터 스토리지 시스템의 WinFS가 잘리는 등, 더 이상의 스케쥴 지연이 업계 전체에 미치는 영향에 대해서 생각하기 시작하는 것 같다. 출시의 압박이 높아지면서 현실적인 접근으로 다가 왔다고 말할 수 있다. 그들이 어디까지 "타협"하는가는 올해 4월에 있는 WinHEC에서 어느 정도 분명해질 것이다. Microsoft는 WinHEC에서 WinFS 등 기능 축소를 행한 개발자용 빌드 (일부에는 β 판의 배포 이야기도 있지만, 현실적으로는 WinHEC 전용 스냅 샷 빌드로 예상하는 것이 타당할 것이다 )를 배포한다.

 다만 Longhorn이 기능 축소를 동반한 조기 개발로 움직이면, 그것으로 이야기가 해결되는 문제도 아니다. WinFS를 베이스로 하는 소프트웨어를 계획하고 있던 벤더는 계획을 재검토 해야 한다. 또 앞으로를 생각할 때 과연 지금까지의 Windows처럼 무엇이든 가져와 통합화 하는 개발의 방향성이 올바른 것인가? 라는 논의도 제약으로 떠 올름도 당연할 것이다.

 Windows의 진화가 멈춰 있던 기간, PC 시스템 성능이 크게 향상됐다. Microsoft는 Windows NT 3.1 / 3.5 / 3.51 시대의 마이크로 커널 사상으로 돌아와, 서브 시스템에서 개별적으로 기능 모듈을 제공하는 등 최근의 Windows 개발과는 다른 접근 방식에 대한 가능성을 생각해야 하는 것이 아닐까?

 Windows의 가치가 그 서브 시스템이 제공하는 기능 (과 거기에 접근하기 위한 API)에있는 것이라면, 커널을 완전히 분리해, 조금 이음새가 안맞는 OS의 핵에 대폭적인 손을 더해도 좋을텐데

 

2005년 3월 10일 기사 입니다.

 

 

[고전 2003.09.19] EFI 프레임 워크의 도입으로 변하는 BIOS

 

 

[분석정보] 32bit 시스템의 EFI 화는 2006년

 

 

[분석정보] iAMT, Montecito등 신기술이 공개된 IDF

 

 

[분석정보] intel의 듀얼 코어 CPU 1번타자 Montecito

 

 

[분석정보] 멀티 코어 + 멀티 스레드 + 동적 스케줄링으로 향하는 IA-64

 

 

MSI 에릭 장, Gigabyte와 ASUS에 정면으로 대응

 

 

[고전 1997.10.31] Intel과 DEC 전격 제휴 MPU의 판도가 바뀐다

 

 

[분석정보] 가상화 시대의 네트워크? IDF 2009에서 해독

 

 

[분석정보] IDF 2008에서 본 Intel의 가상화 대응 방안