• 북마크
  • 추가메뉴
어디로 앱에서 쉽고 간편하게!
애플 중고 거래 전문 플랫폼
오늘 하루 보지 않기
KMUG 케이머그

소프트웨어

[App 개발] Cell 아키텍쳐 (2)

본문

셀 아키텍쳐 ­ 2장: 셀의 내부

스트림 프로세싱

셀이 일반 프로세서와 다른 점은 APU 를 하나로 연결하여 스트림 프로세서로 동작시키는 기능이 있다는 점입니다. 스트림 프로세서는 데이터를 수령하여 처리하는 것을 순차적으로 처리합니다. 이러한 순서는 한 개 혹은 여러 개의 APU 에 의해서 처리됩니다.

셀 프로세서는 각 순서별로 한 개 혹은 여러 개의 APU 로 스트리밍 명령을 수행하게 됩니다. 이를 구현하기 위해서 첫 번째 APU 가 입력 장치로부터 로컬 메모리로 데이터를 읽은 다음 데이터 처리를 수행하여 RAM 의 예약된 지점에 내용을 저장하고, 두 번째 APU 는 바로 그 데이터를 받아서 처리한 다음 두 번째 RAM 의 예약된 지점에 내용을 저장합니다. 프로그램에 따라서 첫 각 단계별로 여러 개의 APU 를 이용하여 여러 군데의 RAM 영역에 데이터를 입출력할 수도 있습니다. 만약 계산 능력이 부족할 경우 다른 셀의 APU 를 좀 더 긴 체인 형태로 동원할 수도 있습니다.

스트림 프로세싱은 메모리의 대역폭을 많이 필요로 하지는 않지만 셀에는 그런 능력이 있습니다. 특허 출원서에 따르면 각 셀은 64MB 데이터를 8 개의 뱅크 컨트롤러 (이것은 이상적인 경우이고 최대 갯수는 더 늘어납니다) 를 통해서 억세스할 수 있습니다. 만약 다른 뱅크에 있는 RAM 블럭을 사용하도록 스트림 프로세싱이 설정된다면, 스트림을 처리하는 다른 APU 에서는 다른 블럭의 메모리를 동시에 입출력할 수 있게 됩니다.

여러분의 피씨가 빠르다고 생각하십니까…
셀이 가장 열심히 일하는 경우는 APU 들이 복잡한 스트리밍 프로그램을 돌리면서 복수개의 메모리 뱅크를 사용하는 경우입니다. 이런 프로그램이 셀에서 동작할 때 셀의 이론상 최대 성능에 근접하게 되고 현재 사용되는 어떠한 데스크탑 프로세서보다도 몇 배나 만많은 초당 계산 능력을 나타낼 것입니다.

적절히 오버클럭이 되어 있고 (3.0GHz 이상) 아주 잘 최적화된 (SSE 어셈블리) 하이퍼트랜스포트로 연결된 다섯 개의 듀얼 코어 옵테론 컴퓨터 정도라면 셀 프로세서 한 개가 스트림 프로세싱으로 처리하는 정도의 계산량에 근접할 수 있을 것입니다. 이것은 순전히 이론상 데이터이며 셀의 성능과 “완벽한” 프로그램의 수행 여하에 따라 달라질 것이지만, 적어도 셀이 가지고 있는 잠재적인 프로세싱 능력의 한 가지를 보여주는 예입니다.


일반 데스크탑 CPU 들은 고성능 벡터 프로세싱에 적합하게 설계되지 않았습니다. 그 제품들도 SSE 나 AltiVec 의 형태로 벡터 유닛을 보유하고 있지만 보드 내에서 동일한 CPU 리소스를 공유하도록 되어 있습니다. 전용 로컬 메모리를 보유한 APU 는 고속 벡터 프로세싱에 특화되어 있고 메모리 외에 다른 것은 공유하지 않습니다. 게다가 이런 것이 여덟 개가 장착되어 있으니 셀의 계산 능력이 얼마나 대단한지 알 수 있습니다.

이런 엄청난 성능 차이는 어쩌면 허풍으로 들릴지 모르지만 이 정도 성능은 이미 선례가 있습니다. 여러분이 현재 컴퓨터에 장착한 최신 그래픽 카드에도 여러분의 생각보다 훨씬 더 풍부한 능력이 있습니다.

“예를 들어 최근 발표된 nVidia GeFrce 6800 Ultra 의 경우 조각 프로세싱 성능이 40 GFlops 에 근접합니다. SSE 를 이용한 3GHz 팬티엄4 의 성능을 비교하면 고작 6 GFlops 입니다.”

3D 그래픽 카드는 범용 CPU 보다 훨씬 고성능을 오래전부터 가지고 있었습니다. 이전에는 3D 그래픽 프로세싱에 국한되어 있었지만 최근 Shaders 가 부가되면서 이제는 일반적인 작업에 그 기능을 이용하고 있고, 지금까지도 별 어려움이 없었지만 앞으로 Shader 4.0 는 지금보다도 훨씬 범용으로 사용될 수 있을 것입니다.

현용 GPU 들은 잘만 프로그램되면 엄청난 계산 능력을 가질 수 있지만, 셀 프로세서는 더 저렴하면서 몇 배나 빠른 속도를 갖고 있습니다.

“하드” 리얼 타임 프로세싱

어떤 스트림 프로세싱은 정확한 타이밍으로 작동해야 하며 이것은 “하드” 리얼 타임 데이터 프로세싱이라는 형태로 이미 고려되어 있습니다. 어떤 처리 명령이 지정된 시간 한도 내에서 처리될 수 있도록 “절대 타이머” 가 이용됩니다. 타이머는 프로세싱 자체와 독립되어 있으므로 차세대 셀 칩과의 호환성 면에서도 유리합니다.

하드 리얼 타임 프로세싱은 특별하게 제작된 QNX 같은 특수 운영 체제에 의해 조정됩니다. 이러한 기능은 어떠한 OS 에서도 어느 정도 지원될 수 있는 것입니다. 이것은 APU 를 이용한 작업에만 사용되는 것이므로 QNX 가 조만간 없어질 것 같지는 않습니다.

DMA 컨트롤러

DMAC 는 셀에서 통신 허브의 역할을 수행하는 아주 중요한 부분입니다. PU 는 APU 에 직접 명령을 하달하지 않고 DMAC 를 통해서 하달하여 어떤 작업을 수행하도록 하며, 작업에는 언제나 데이터의 읽기/쓰기가 수반되므로 이것은 일리 있는 방법입니다. 이렇게 함으로써 PU 와 APU 간의 직접 통신이 필요없게 됩니다.

DMAC 가 셀의 모든 데이터의 입출력을 처리하게 되므로 초광대역 버스 시스템을 통한 통신이 필요하게 됩니다. 특허 출원서에서는 이것에 대해서 일반 버스 혹은 패킷 스위치 네트웍 같은 것이라고만 할 뿐 자세한 사항을 기술하고 있지 않습니다. 패킷 스위치 네트웍 구현에는 더 많은 회로가 요구되지만 더 넓은 대역폭을 가질 수 있습니다만, 제 생각에 셀은 초당 수십 기가바이트를 전송해야 하므로 그 이상의 방식을 연구하고 있을 것입니다. 특허 출원서를 통해서 알 수 있는것은 이 버스가 무척 광대역이며 적어도 1024 비트의 놀라운 대역폭을 기술하고 있습니다.

특허 출원서가 씌어질 당시까지만 해도 DMAC 의 아키텍쳐는 확립되지 않은 상태였고 따라서 두 개의 상이한 DMAC 버스 구조가 후보로 거론되었습니다. DMAC 의 분산형/중앙집중형 구조도 언급되어 있습니다.

DMAC 가 셀 설계의 가장 중요한 부분의 하나임은 분명합니다. DMAC 가 직접 계산을 수행하는 것은 아니지만 수십 기가바이트의 메모리를 여러 방향으로 흘려 주어야 합니다. 플스3가 약 100GB/s 의 메모리 인터페이스를 가지고 있다고 알려져있으며, 이것이 네 개의 셀 칩으로 분산된다고 하면 DMAC 는 각각 약 25GB/s 의 데이터를 처리해 주어야 합니다. 뿐만 아니라 메모리 보호와 PU 와 APU 의 명령 전달 통신도 처리해야 하므로, 단순히 빠른 버스속도 뿐만 아니라 대단히 복잡한 구조를 가져야 합니다.

메모리

셀 아키텍쳐를 넘어가서 메모리 시스템은 짧은 대기시간과 광대역폭의 빠른 속도를 위해 설계되어 있습니다. 앞에서도 기술했다시피 메모리는 1024비트 블럭으로 억세스됩니다. 그 이유는 특허 출원서에 나와있지 않지만 제 생각에 이렇습니다.

이것은 복잡성을 줄이는 효과 외에도 최신 컴퓨터의 성능을 저하시키는 큰 요인 중 하나인 메모리 억세스 응답 속도를 줄일 수 있습니다. 보다 세밀한 어드레싱을 위해서는 더 복잡한 로직이 더 많은 시간을 들여야 하기 때문입니다. 메모리 어드레스 참조 작업은 메모리 칩에서는 그리 두드러지지 않을지 모르나 각각의 참조 작업은 어드레스를 뱅크 컨트롤러에서 메모리 장비로 전송하는 느린 참조 작업이 수반됩니다. 이것을 메모리 한 번 억세스할 때마다 수행하는 것 자체도 그렇고 참조 작업에 필요한 어드레스 폭이 두 배로 늘어야 한다는 점입니다.

피씨에 램이 512메가가 있을 때 어드레스는 29비트*가 필요하지만, 시스템은 최소 64비트를 읽어들이므로 실제로는 26비트면 충분합니다. 피씨는 이보다 훨씬 더 많이 읽어들이므로 대략 23비트면 충분합니다.

* I/O 나 그래픽 어드레스는 가외로 1~2비트가 더 필요합니다

셀 구조에서는 8메가바이트의 뱅크가 8개 있으며 각각 1024비트씩 읽혀지므로 약 13비트가 필요하게 됩니다. 뱅크를 선택하는 데 필요한 3비트가 추가되지만 칩 내에서 처리되므로 크게 영향은 없습니다. 각 비트는 메모리 참조 영역을 두 배로 증가시키므로 피씨는 셀에 비해서 수천 배의 메모리 참조를 수행해야 합니다. 셀의 메모리 버스는 데이터 전송에 더 많은 시간을 할당할 수 있고 따라서 최대 이론상 전송 속도에 근접하게 됩니다. 제 생각이 틀릴 수도 있지만 실제 CPU 캐시에서도 비슷한 방법을 쓰고 있습니다.

셀은 실제로 초고속 메모리 전송을 수행합니다. 소니와 도시바는 2003년 램버스로부터 3.2GHz 메모리 기술을 라이센스했습니다. 만약 각 셀이 25.6 GB/s 를 가진다면 각각의 뱅크 전송율은 3.2 GB/s 가 됩니다. 버스의 비트 수는 그리 넓지 않게 하여서 (8개 모두에 64 데이터 핀) 칩 제조 가격을 하락시키는 효과를 갖게 합니다.

100GB/s 는 무척 넓직한 것 같지만 최근 사용되는 최신 그래픽 카드는 이미 50GB/s 대에 도달해 있으므로, 대략 수 년 사이에 두 배씩 증가했습니다. 그러나 이것은 이론적인 수치로서 아직 도달하지 못했으며, 위에서 설명한 셀의 대역폭은 경쟁 시스템보다 이론적인 수치에 훨씬 근접해 있으므로 셀이 훨씬 더 빠르게 동작할 것입니다.

특히 긴 스트림이 설정되었을 때 APU 는 다른 셀의 메모리를 억세스해야 할 필요가 있고, 따라서 셀들은 고속 인터커넥션으로 연결됩니다. 이것은 대략 선폭당 6.4 Gb/s 의 속도를 가진다는 것 외에 자세한 내용은 밝혀지지 않았습니다. 각각의 셀이 고속으로 데이터를 주고받을 수 있는 버스가 있을 것입니다. 이 기술은 하이퍼트랜스포트와 그리 달라 보이지는 않지만 구현 방식은 상당히 다를 것으로 보입니다.

그 외에도 스위칭 시스템이 고안되어 있어서 네 개 이상의 셀들이 모두 고속으로 메모리를 억세스할 수 있습니다. 이것은 셀 기반 웍스테이션에서 활용될 수 있을 것입니다. 8개 이상의 셀이 통신하는 것에 대해서는 확실하지는 않지만 시스템이 그 이상을 처리하는 것도 가능할 것으로 생각됩니다. IBM 은 이미 16테라플롭스의 성능을 가진 랙 모양의 웍스테이션을 발표했고, 여기에는 모두 64 개의 셀이 필요하므로 어떤 식으로든 그 방법을 확실히 고안했을 것입니다.

메모리 보호
메모리 시스템에는 DMAC 에 구현되어 있는 메모리 보호 기능이 있습니다. 메모리는 “놀이상자” 로 구별되어 어떤 APU 들이 억세스할 수 있는지를 구분하는 마스크가 사용됩니다. 이 마스크는 메모리 억세스가 실행되기 이전 DMAC 에서 수행되며, 어떤 특정 APU 가 잘못된 놀이상자를 억세스하려 할 때 메모리 억세스를 금지시킵니다.

일반 CPU 에도 하드웨어 메모리 보호 장치가 있지만 이것보다 훨씬 복잡한 구조입니다. RAM 블록의 사용 여부를 기록하는 페이지 테이블과 데이터가 메모리에 있는지 하드디스크에 있는지 여부를 기록합니다. 이 테이블은 계속 증가하게 되어 전체 내용을 CPU 가 한 번에 읽을 수 없게 되어, CPU 가 어떤 특정한 메모리 영역을 읽으려면 먼저 메모리의 페이지 테이블을 읽은 다음 디스크에서 데이터를 읽어들여야 하며 이 모든 작업이 실제 메모리 내용을 읽기 전에 수행되어야 합니다.

셀 프로세서는 APU 의 메모리 억세스의 수행 여부에 관계없이 테이블 내용은 DMAC 의 특수한 SRAM 에 기록되어 결코 정보를 잃지 않게 됩니다. 이러한 구조는 시스템의 유연성을 떨어뜨릴 수 있으나 구조가 단순하며 항상 빠른 데이터 억세스를 가능하게 합니다.

이러한 단순 구조는 APU 에만 해당되는 것이며 PU 에는 범용 메모리 보호 장치가 마련되어 있을 것입니다.

소프트웨어 셀

소프트웨어 셀은 apulet 이라고 불리우는 프로그램과 데이터의 조합의 저장, 그리고 apulet 을 수행하는데 필요한 명령과 다른 데이터들 (필요한 메모리, 동원되는 APU 갯수 등) 을 포함합니다. 셀에는 소스, 데스티네이션, 그리고 반송 어드레스 필드가 들어 있습니다. 내용은 전체 구조에 따라 변경될 수 있고 따라서 소프트웨어 셀은 다른 하드웨어 셀로 보내어질 수 있습니다. 그리고 특정한 셀을 정확히 지정할 수 있는 네트웍 독립 어드레스가 있습니다. 따라서 어떤 소프트웨어 셀을 어떤 네트웍의 특정한 컴퓨터에 있는 하드웨어 셀로 전송할 수도 있습니다.

APU 는 가상 메모리를 사용하지만 DMA 명령이 하달되는 즉시 실제 메모리에 매핑됩니다. 소프트웨어 셀에는 메모리에서 불러들이는 DMA 명령이 담겨 있어서, 만약 APU 가 스트림을 처리할 때 어디에서 데이터를 읽어서 결과를 어느 메모리에 저장해야 할지를 기억합니다. 그러한 준비가 모두 끝나면 APU 는 명령을 실행합니다.

이 시스템이 실제 어떻게 동작할지는 확실하지 않습니다만 아마도 약간의 적응성이 첨가되어 셀들이 네트웍에 보여지거나 사라지게 할 수도 있을 것입니다.

이러한 시스템은 기본 오퍼레이팅 시스템에 반영되어야 하지만 기존 OS 에 특정 계층으로 구현될 수도 있을 것입니다. 셀 프로세서가 어떤 특정한 OS 에서만 동작한다는 한계를 둘 필요는 없습니다.

멀티 셀 조합

셀 아키텍쳐의 특징 중 한 가지가 병렬 프로세싱입니다. 소프트웨어 셀은 어디든지 전송될 수 있고 어떤 특정한 전송 수단에 국한되지 않습니다. 소프트웨어 셀이 실시간으로 지정된 하드웨어 셀에서 동작하게 하는 것이 셀 아키텍쳐의 핵심입니다. 따라서 좀 더 계산능력이 필요하다면 셀 칩을 더 꽂으면 해결되도록 말입니다.

만약 여러 개의 셀들이 각각 WiFi 로 연결되어 있는 시스템이라면 시스템은 분산 소프트웨어 셀로 활용할 수 있습니다. 이 시스템은 어떤 커다란 몸체에 모두 담겨야 할 필요가 없습니다. 시스템은 단일 공유 메모리나 클로스 커플드 메모리로 묶여있지 않습니다. 전체 메모리 영역을 참조할 수 있지만 각 셀은 독립된 메모리 영역이 있고 자신의 메모리 내, 혹은 메모리를 고속 인터링크로 공유한 셀 칩들에서 가장 효율적으로 동작하게 됩니다.

셀 갯수를 넘어서는 프로세스의 처리에 대해서 자세히 기술되어 있지는 않지만 어떠한 네트워킹 기술에서도 동작하는 소프트웨어 셀 환경이란 이종의 네트웍 방식에서도 프로그램을 재작성할 필요 없는 첨단 셀 배열 방식이 활용될 것입니다.

병렬 처리 시스템은 기본적으로 하드웨어에서 처리해야 할 것들을 소프트웨어서 해 주어야 하므로 복잡도가 증가합니다. 시스템 속도는 줄어들지만 유연성은 증가하게 됩니다. 시스템은 처리해야 할 소프트웨어 셀을 어떻게 분산할 것인지를 결정하게 됩니다. 시스템이 변경되는 경우 (셀의 추가, 감소) 프로그래머가 따로 구현할 필요가 없도록 이 문제를 처리해야 합니다.

병렬 처리 소프트웨어를 짜는 것은 매우 어려운 일이며 따라서 이러한 구조가 문제를 해결하는 데 도움이 됩니다. 프로그래머는 소프트웨어를 셀이 처리할 수 있도록 병렬화해야 하지만 일단 프로그램이 작성되면 셀이 한 개 짜리이건 열 개 짜리이건 걱정할 필요가 없습니다.

나중에는 여러 개의 독립된 컴퓨터 대신 여러 컴퓨터가 하나의 시스템으로 동작하게 될 것입니다. 업그레이드는 옛날 시스템을 갈아치우는 것이 아니라 힘을 증가시키는 것이 됩니다. 더 나아가서 실제 컴퓨터라는 것은 PDA, TV, 캠코더 등이 하나의 시스템으로 활용되는 것입니다.

구체적 프로세싱

셀 아키텍쳐는 여러 가지 분야에 파급되지만 한 가지는 다른 기술 산업과는 전혀 반대 방향으로 발전했습니다. 운영체제는 개발자가 매번 필요한 드라이버를 작성할 필요 없이 하드웨어를 사용할 수 있는 기초적인 방법을 제시하는 것으로 시작했습니다. 시간이 지나면서 운영체제는 진화하여 여러 가지 복잡 다양한 작업을 수행하게 되었고 점점 더 하드웨어로부터 멀어지는 추상적인 방식으로 발전되었습니다.

객체 지향 프로그래밍은 개별 프로그램 코드를 추상화하는 데까지 이르렀습니다. 이런 방식은 개별 운영 체제로부터 응용프로그램을 추상화하여 독립적인 환경을 제공하는 자바와 같은 기술까지 진화했습니다. 웹 기술도 같은 방식으로, 출력되는 페이지는 그 내용을 보여주는 플랫폼과는 전혀 관련이 없이 동작합니다. 웹을 작성할 때 윈도우나 맥 전용 HTML 은 없으며, 특정 하드웨어, OS, 웹 브라우저는 완전히 추상화됩니다.

이제 하드웨어 제조업체들도 추상화를 시도합니다. 트랜스메타의 CPU 는 x86 계열로 판매되지만 실제 내부는 그렇지 않습니다. 소프트웨어 측면에서 CPU 내부의 자세한 내용에 대한 추상화가 적용되어 x86 뿐만 아니라 전혀 다른 아키텍쳐로도 동작할 수 있습니다. 이것은 트랜스메타 혹은 x86 에만 국한된 것이 아니라, 대부분의 최신 CPU 들의 내부 구조는 프로그래밍 모델과 전혀 다릅니다.

추상화는 컴퓨팅의 불문율로서 오늘날 컴퓨팅 기술의 핵심 요소입니다. 이것이 없으면 우리가 하는 대부분의 작업을 이룰 수 없습니다. 그러나 셀은 이것에 반대됩니다. 셀의 프로그래밍 모델은 구체적입니다. 여러분이 작성하는 APU 프로그램은 어떤 추상화가 아니라 APU 자체가 움직이는 방식 그대로의 프로그래밍입니다. 다시 말하면 “하드웨어를 직접 건드리는” 것입니다.

일반적으로 좋지 않은 방법으로서 불경스럽게까지 들리는 이 방식을 사용하려는 이유는 단 한가지, 효율 때문입니다. 추상화 계층이 늘어나면 그만큼 계산량이 현저히 늘어나며, 이러한 추상화는 실제 효율을 10배 정도 감소시킵니다. 요즘 출시되는 여러 추상화 계층이 깔려있는 시스템을 보시면 어째서 옛날 50 MHz 486 에서는 잘 돌았는데 지금은 속도가 개같이 되었는지 보시게 될 것입니다. 최신 프로세서는 현저히 늘어난 추상화 방식을 지원해야 할 필요성이 증가하게 됩니다.

추상화를 없앴을 때의 단점은 소프트웨어 개발자들의 복잡도를 현저히 증가시키며 하드웨어 제작자들의 시스템 변경 기회를 제한한다는 점입니다. 그 중에서 후자가 가장 중요한 핵심 이유입니다. 하지만 최신 프로세서들이 최근 몇 년간 구조가 많이 변경되지 않았음을 알 수 있습니다. 셀 디자이너들은 아키텍쳐의 급격한 변동이 없을 것으로 확신하고 처음부터 내용을 돌에 새겨넣듯 하였습니다. 그러나 특허 출원서에는 시스템에 약간의 유연성이 있다고 하였으니 부분적인 변화는 가능할 것으로 보입니다.

하지만 셀 구조에서도 추상화의 잇점을 살리고 있습니다. 자바는 OS 와 하드웨어를 추상화함으로써 플랫폼 독립을 이루었습니다. 자바는 모든 플랫폼에서 통용되는 “가상 머신” 기법을 사용하여, 어떤 하드웨어와 OS 가 변화하더라도 가상 머신은 변동이 없도록 하였습니다.

셀에서도 자바와 비슷한 방식을 지원하지만 전혀 다른 방향으로 구현됩니다. 자바는 모든 플랫폼에 동일한 “가상 머신”이라는 소프트웨어를 제공하지만, 셀에서는 셀 물리 하드웨어라는 자바 가상 머신과 동격의 개념을 하드웨어에서 제공합니다. 만약 OS X 에서 셀 코드를 작성하면 동일한 셀 코드는 윈도우, 리눅스 등에서 동작하게 되는데 왜냐하면 명령을 수행하는 것은 모두 셀 하드웨어이기 때문입니다.

이것은 반드시 셀 어셈블리로만 프로그램을 짜야 한다는 뜻이 아닙니다. 셀에서도 다른 것들과 마찬가지로 컴파일러를 제공합니다. 자바가 가상 머신을 제공하지만 직접 프로그래밍을 하지 않는것과 마찬가지입니다.

하드웨어 DRM

셀 하드웨어에 DRM 이 구현되어 있다는 점만으로도 등을 돌리는 사람이 있을 것입니다. 소니는 미디어 회사이며 그 범주에 들어가는 모든 회사들은 DRM 솔루션을 밀고 있습니다. 셀은 HDTV, 블루레이, HD-DVD 시스템을 목표로 하고 있으며, 어떠한 고화질 컨텐트건 DRM 에 의해 구동되므로 소니가 이 기능을 내장하지 않으면 자신의 주요 시장에서의 입지를 좁히는 결과가 됩니다. 하드웨어 DRM 은 마술 탄환은 아닙니다. 하드웨어 시스템은 셋톱 박스나 IBM 의 메인프레임을 위한 크립토 하드웨어 등에서 이미 구현되었습니다.

그 외의 기능과 미래

셀 아키텍쳐의 미래 기술 계획에는 광통신 기능이 예정되어 있습니다. 이것이 플스 3에 적용될지는 미지수이지만 개발자들은 현재 사용되는 구리선이 한계(대략 10GHz 로 봄)에 부딪힐 경우를 대비하고 있습니다. 실리콘 이외의 다른 신물질을 이용한 제조 공정도 계획되고 있지만 이것은 아주 요원한 미래의 일이 될 것입니다.

셀 디자인은 완전히 고정된 것이 아닙니다. APU 갯수는 유동적이며 각 APU 내에도 부동소숫점 계산기나 정수 계산기를 추가할 수 있습니다. 어떤 경우 APU 를 제거하고 I/O 유닛이나 그래픽 프로세서를 그 자리에 넣을 수도 있습니다. nVidia 는 플스 3 용 그래픽 하드웨어를 제공하게 되며, 차후에 셀의 변형 제품으로 이것을 구현하게 될 수도 있습니다.

무어의 법칙이 계속되며 칩에 더 많은 트랜지스터를 집적할 수 있는 한 개발자들은 이 장점을 적극 활용할 것입니다. 칩당 네 개의 셀을 집적하는 방식을 특허 출원서에서 기록하고 있고 그 외에도 다른 셀 응용 제품에서 다른 방식을 적용할 수 있습니다.

복수 APU 가 스트리밍 데이터를 처리할 때 RAM 에 읽고쓰기를 계속 반복하게 되는데, APU 간 데이터 기록이 가능한 버퍼를 추가하는 것도 아주 적합한 방법입니다. 직접 전송 방식도 특허 서류에서 언급하고 있지만 자세한 내용은 기록하지 않고 있습니다.

결론

셀 아키텍쳐는 기본적으로 범용 PowerPC CPU 에 8 개의 초고속 벡터 프로세서와 고속 메모리 와 I/O 시스템을 부가한 것으로서, 첨단 클러스터링 기능을 갖춘 작업 분산 장치와 연동하여 사용할 수 있습니다.

한 가지 분명하지 않은 것은 공격적인 디자인입니다. 캐시 메모리와 실시간 가상 메모리 시스템의 부재는 지난 20년간 범용 CPU 에서 채택하지 않은 매우 이례적인 것입니다. 이것과 비교할 수 있는 제품이라면 세이모어 크레이의 제품 디자인 종류일 것입니다. 셀의 빠른 속도뿐만 아니라 무척 공격적인 디자인으로 다른 회사들이 이를 따라잡는 데 많은 시간이 걸릴 것입니다*.

* 이것에 대해서는 4장에서 자세히 설명하겠습니다.
0 0
로그인 후 추천 또는 비추천하실 수 있습니다.
포인트 228,692
가입일 :
2003-02-18 14:12:30
서명 :
미입력
자기소개 :
미입력

최신글이 없습니다.

최신글이 없습니다.

댓글목록 0

등록된 댓글이 없습니다.
전체 529 건 - 9 페이지
2006.05
13

[App 개발] [질문] xcode는 인스톨 아니면 안되나요?

os를 덮어씌우기 했습니다. 좀 찝찝하지만 넘 갑작스럽게 시스템이 맛이가서 어쩔 수 없이 그냥 깔았습니다. 맥에서 기존에 파일들을 다 백업해주고.. 응용프로그램도 다 해줘서 자잘한 설정파일만 복사해줬는데 xcode는 실행이 안되네요...뭐 다시 인…

2006.05
02

[App 개발] 네이트온같은 것을 리버스엔지니어링으로 맥용으로 만들 수 있나요?

전 프로그래머는 아닙니다만, 갑자기 궁금해져서요. 불법인점은 논외로 치고서라도 궁금해서 질문 올립니다.-_-;; 마소전용 플그램을 리버스 엔지니어링해서 맥용으로 만드는 것이 가능할까요 가능하다면 메신저로 메세지 주고받는 것만이라도 호…

2006.04
30

[App 개발] Apple pro apps의 GUI 스타일은 어떻게..

C++로 커맨드라인수준의 프로그래밍만 하다가 팔자에도 없는 Cocoa 및 GUI 프로그래밍을 해야하는 상황이 닥쳤습니다 ㅎㅎ; 일단 이래저래 공부를 시작하고는 있는 중인데, 한가지 궁금증이 생겼습니다. Apple의 pro apps(가령 Final …

2006.04
22

[App 개발] xcode에서 인텔리센스 기능..

인텔리센스 라는 용어가 맞는지 모르겠습니다. 자동완성;; 이라 해야되나 써본거라곤 vs6 밖에 없어서...;; 새로운 걸 하고 싶어서 과감히 전환을 시도하는 중입니다. 맥도 새로 구입하고 ㅎㅎ 하루하루를 맥에 푹 빠져살고 있습니다. x…

2006.04
15

[App 개발] [질문]Xcode 만 설치하면 맥용 개발툴은 다 설치한건가요?

우연히 OS Cd를 뒤지다가 Xcode Tools란 폴더를 찾았습니다. 폴더를 열어보니 Xcode Tools라는 파일이 있어서 설치를 했네요. 이것만 이스톨하면 개발툴은 다 인스톨 된건가요 제가 원하는 언어는 C,C++.JAVA 입니다.

2006.03
23

[App 개발] GNU Scientific Library 를 Xcode 에서 컴파일하다

과학, 공학 전공하시는 분들이시라면, 선호하는 계산 라이브러리가 있으실 줄 압니다. 가장 간편하고 인기있는 라이브러리는 역시 Numerical Recipes 라이브러리가 되겠지만, 요즘은 GNU Scientific Library (GSL) 이 대세죠 …

2006.03
11

[App 개발] 인텔맥에 대처하는 우리의 자세 ㅡㅡ;

이미 작년 6월 이후부터 꾸준하게 유니버설 바이너리 관련 개발자 정보들이 나왔기 때문에 지금은 그 충격이 거의 상쇄되어 버린 기분입니다. 그리고 새로 출시된 인텔 아이맥과 맥북 프로의 성능이 기존 제품을 훨씬 능가한다는 사실을 보면서 많은 개발자들이 …

2006.01
03

[App 개발] Xcode 2.2 에서 C++ 프로그래밍 하기

아직 초보라서 잘 모르는데 어떻게 하는지 알려주세요... Project를 어떤 것을 선택해야하는지...

2005.12
28

[App 개발] Xcode 2.2 에서 카본 프로그램 만들자 (7) 응용문제

지금까지 연습했던 기법들을 모두 동원하여 그럴듯한 게임 하나를 만들어 보겠습니다. 만들기 쉽고 이해하기 편하고 간단한 예제로 무엇이 좋을까 생각해보니, 퍼즐 게임이 있더군요. 비트맵 조작, 마우스 입력, 간단한 게임 데이터 관리 등을 모두 연습해볼 수…

2005.12
26

[App 개발] Xcode 2.2 에서 카본 프로그램 만들자 (6) Keyboard

이번 예제는 겉으로 보기엔 후즐근해 보이겠습니다만, 그 내용은 심히 유용한 것을 담고 있습니다. 1. 키보드 입력 이벤트를 처리하는 루틴에서 이번에는 입력된 키보드 값을 버추얼 키 값에서 우리에게 친숙한 ASCII 값으로 바꾸었습니다. 이 값을 …

2005.12
24

[App 개발] Xcode 2.2 에서 카본 프로그램 만들자 (5) Events

이제는 본격적으로 이벤트 부분을 파 들어가 보도록 하겠습니다. 이 세상 거의 모든 GUI 는 Event Driven 입니다. 이벤트에 의하여 전체 프로그램이 동작하게 됩니다. 이러한 점은 많은 초심자들이나 옛날 Procedual Programming …

2005.12
21

[App 개발] Xcode 2.2 에서 카본 프로그램 만들자 (4) ATSUI

비트맵 예제는 지난 글들을 살펴보시면 되겠습니다. 이제부터는 간단한 것 같으면서도 상당히 까다로운 주제인 텍스트를 다루어 보고자 합니다. 그래픽 환경으로 넘어오면서 오히려 텍스트 다루는 것이 점점 더 어려워지고 있습니다. 글꼴도 다양하고 예쁘게 만들어…

2005.12
19

[App 개발] Xcode 2.2 에서 카본 프로그램 만들자 (3)

이번에는 본격적으로 Quartz 의 Core Graphics 를 이용해서 그림을 그려 보겠습니다. 참고 자료로는 애플 홈페이지에서 다운로드 받으실 수 있는 Quartz 2D Programming Guide 입니다. 프로그램의 기본 구조는 이…

2005.12
17

[App 개발] Xcode 2.2 에서 카본 프로그램 만들자 (2)

윈도우 프로그래밍을 처음 공부한ㄴ 사람들이 한결같이 내놓는 불만은 "왜 이렇게 어렵냐" 라는 것입니다. 막말로, C 에서는 printf("Hello World\\n") ; 요거 하나만 하면 글을 볼 수 있는데, 윈도우에서는 글자 하나를 보…

2005.12
16

[App 개발] Xcode 2.2 에서 카본 프로그램 만들자 (1)

Xcode 새 버젼의 카본 어플리케이션 템플릿이 좀 더 친절해졌더군요. 한편, 지금까지 자기 고유의 이벤트 핸들러를 갖고 계시던 분들에게는 더 힘들어 졌더군요. ㅠㅠ 자 해 봅시다. 일단. Xcode 를 실행하고, File->N…

2005.12
08

[App 개발] PCWEB 이란 곳에 올라온 코코아 강좌(1)

제가 소개할 사이트는 http://pcweb.mycom.co.jp/column/objc/ 에 연재되고 있는 코코아 강좌입니다. 이번에 제 1회를 부족한 일본어 실력으로 해석해 보았는데, 해보니 번역기를 돌린것과 비슷하게 되어버렸습니다. 결국 그렇…

2005.12
07

[App 개발] Apple Development Document 중 일부가 업데이트 되었습니다.

12.6일자로 몇가지 문서가 새로 마이너 버젼으로 업데이트 되었습니다. - Apple Human Interface GuideLines - Dashboard programming Topics - Dashboard Tutorial - DVD P…

2005.12
06

[App 개발] C# VS Object C (1) - 터미날 프로그램을 사용할때 받는 인자를 활용해서 MS-DOS 의 Mdi…

우선 object C 를 활용한 프로그램부터... 제가 제가 잘 적었는지 모르겟습니다. 워낙 엉뚱한 말을 저도 몰래 쓰기 때문에..... 이 프로그래의 사용법은 다음과 같습니다. 우선 소스 파일을 받으면 Xcode 로 열수 있습니다. 그…

2005.12
06

[App 개발] OMIAI (아스키 코드 값를 이용해서 도형의 색갈을 바꾸어 주는 프로그램입니다.)

두번째로 케이머그에 올리는 글이네요. 약 한달전에 만든건데, 필요한 분에게 프로그램과 소스만 전해주고 그냥 하드 속에다가 묵혀두었는데, 이렇게 놔두는 것 보다 공개해서 수정이나, 부족한 부분도 남에게 자문도 받아보고, 이를 통해서 공부도 배울…

2005.10
22

[App 개발] 신형 듀얼 코어 2.3 GHz 의 속도 비교

제가 지금까지 쓰던 PowerMac G5 Single 1.8 GHz, 프론트사이드 버스 900 MHz 짜리 제품과 이번에 새로 나온 Dual Core PowerMac G5 2.3 GHz, 프론트사이드 버스 1.15 GHz 제품과의 성능 비교입니다…

2005.09
30

[App 개발] Apple에서 하드웨어 제어 ~_~

안녕하세요 ㅎ 컴퓨터로 하드웨어를 제어해서 프로토타입을 만들 일이 생겼는데 Mac에서 사용가능한 인터페이스가 있는지 궁금해요 >_< PC의 경우 K8055보드같은 USB인터페이스가 판매되고 있습니다만 제품 사양에 Mac은 언급되지 않았더군요…

2005.09
29

[App 개발] 요즘 이런 망상에 빠져.. ~_~;

개발실 게시판에는 정말로 오랫만의 포스팅입니다. 그동안 일도 바쁘고.. 개인적인 작업과 학업.. 모두 바쁜 관계로.... 이제 어느덧 9월도 마지막에 다가가고 있습니다. 최근에는 그냥 알바식으로 일하면서.. 인체 인식으로 PC를…

2005.08
25

[App 개발] IDE와 DB관련해서 질문있습니다.

제가 4학년 플젝으로 erp제품중에서 일부분을 자바로 해보려하는데요. 원래 회사에다닐때 사용하던건 비베랑 ms-sql이였습니다. (보고서는 크리스탈 레포트로했습니다.) 대부분 sp로 짜여져서 sp지원하는 어떤 db를 사용해야할지 난감합니다.…

2005.08
17

[App 개발] 코드 최적화 (6) 분기 예측

분기 예측 (Branch Prediction) 이라는 것은 프로세서의 파이프라인이 길어지면서 발생하게 되는 비효율적인 문제를 해결하기 위한 방법으로 도입된 것이지요. 이것이 우리 프로그래밍에 어떤 영향을 미치게 되는지를 살펴보기 위하여 간단한 예제를 …

2005.08
15

[App 개발] XCode 2.1로 Maya plug-in 개발하기..?

Maya 6.0에서 제공하는 Maya API를 이용하여 plug-in을 개발하려고 help문서를 뒤져보니.. xcode는 예제의 프로젝트 파일을 컴파일해보라고 나와있는데.. xcode의 버전때문인지 컴파일이 되질 않는군요..-.- MSVC로 프로…

2005.08
15

[App 개발] 코드 최적화 (5) Unrolling

언롤링이라는 기법은 언뜻 보기에는 거의 삽질과 다름이 없습니다. 지난 (4) 번 예제에서 사용된 코드를 언롤링한 코드의 예를 보시면 이야기가 더 쉽게 진행될 것 같습니다. for( j = 0 ; j < MAT_SIZE ; j++ )…

2005.08
14

[App 개발] 코드 최적화 (4) 행렬, AltiVec

이번에는 매우 고전적이면서 아직도 수없이 많은 곳에서 쓰이고 있는 행렬 곱셈 문제를 한 번 생각해 보겠습니다. for( i = 0 ; i < MAT_SIZE ; i++ ) { for( j = 0 ; j…

2005.08
13

[App 개발] 코드 최적화 (3) 인덱싱

매트릭스 연산은 여러 곳에서 널리 쓰이고 있습니다. 단순 반복적인 계산을 거듭하는 이 루틴의 효율을 어떻게 높이느냐에 따라서 컴퓨터의 최대 계산 능력을 끌어낼 수도, 혹은 전혀 이용하지 못할 수도 있습니다. 다음의 예제는 가우스 소거법 소스를 간…

2005.08
13

[App 개발] 코드 최적화 (2) 컴파일러

계산 밀도 (Computational Intensity)라는 것이 있답니다. 이것이 무엇이냐 하면 컴퓨터에서 어떤 계산을 수행할 때 계산 명령 (Operation) 대 계산 인수 (Operand) 의 비율을 말합니다. 비싼 값을 주고 사는 좋은 컴파일…

2005.08
12

[App 개발] 코드 최적화 (1) 캐시

이름은 거창하게 지어 봤습니다만, 별 것 아니고요... ㅡㅡ;;; 앞으로 몇 회동안 제가 직접 작성한 코드로 어떻게 하면 빠른 프로그램을 작성할 수 있을까를 같이 한 번 연구해 보았으면 합니다. 보유하고 계신 맥의 종류마다 약간씩 다르지만, 제가…

2005.07
28

[App 개발] openGL을 이용해서 만든 카툰렌더러 입니다.

가입하고 첫 글 올립니다. 제작중인 게임 엔진으로 카툰렌더링한 스크린샷입니다. 크로스 플렛폼을 목표로 제작중이라 엔진은 콘솔에서 라이브러리로 만들었고, 아직 코코아는 내공이 부족해서 opengl fullscreen 예제에 붙였습니다. 퍼포먼스 …

2005.07
23

[App 개발] Cocoa 책 구입했습니다.

출장온김에 한국에서 구하기 힘들었던 Mac 프로그래밍 관련 책을 Amazon.com 에서 구입했습니다. 싸게 샀네요. 이거 두권이면 기초부터 시작해서 한참 동안 볼 수 있을것 같죠

2005.06
15

[App 개발] Cell 아키텍쳐 글을 읽기위한 간단한 토막상식 (2)

뭘 이런 걸 2편씩이나... ㅡㅡ;;; * DSP DSP 라는 것이 각광을 받기 시작한 것은 80년대 말~90년대 초라고 여겨집니다. 그 당시까지는 DSP 라는 개념이 확립되어 있긴 했지만 이것을 실현할 수 있는 빠른 속도의 프로세서가 …

2005.06
15

[App 개발] Cell 아키텍쳐 (5)

솔직히 이번 마지막 요약 결론글은 무지 조악합니다. 별로 권하고 싶지 않은 글이군요. ㅡㅡ; 장미빛 청사진이 이번에는 총천연 시네마스코포로 펼쳐지는데, 낯간지러워서 번역하다가 그만 윈도우 닫을 뻔 했습니다. ㅡㅡ;;; 한 편이 더 남았군요. 최근…

2005.06
14

[App 개발] Cell 아키텍쳐 (4)

4장의 글은 이번 애플-인텔 연합 발표가 있기 전의 내용이라 현재의 인식과 많은 차이가 있고, 실제 셀 탑재 웍스테이션도 선보인 지금의 생각과도 역시 괴리감이 느껴집니다. 셀 칩의 스펙이 보여주는 장미빛 청사진 (청사진이 장미빛이라... 쿨럭~ ㅡㅡ;…

2005.06
13

[App 개발] Cell 아키텍쳐 글을 읽기위한 간단한 토막상식 ㅡㅡ;;

전자공학이나 컴퓨터 공학을 전공하지 않으신 분들, 그리고 컴퓨터 구조의 기본에 대해서 잘 모르셔서 아래 글들을 접수하기 곤란하신 분들을 위해서 필요한 내용을 해설해 드리고자 합니다. 컴퓨터 잘 아시는 분들은 읽지 마시고... ㅎㅎ 저도 빠삭하게 다 아…

2005.06
13

[App 개발] Cell 아키텍쳐 (3)

3장: 셀 컴퓨팅 셀은 그래픽 전용 칩이 아닙니다. 셀은 범용으로 개발된 칩입니다. 만약 플스 3 의 그래픽 칩으로 활용된다면 nVidia 에서 제공될 것입니다. APU 는 일반 마이크로프로세서처럼 범용은 아니지만 셀 프로세서는 일반 파워피씨 마…

2005.06
13

열람중 [App 개발] Cell 아키텍쳐 (2)

셀 아키텍쳐 ­ 2장: 셀의 내부 스트림 프로세싱 셀이 일반 프로세서와 다른 점은 APU 를 하나로 연결하여 스트림 프로세서로 동작시키는 기능이 있다는 점입니다. 스트림 프로세서는 데이터를 수령하여 처리하는 것을 순차적으로 처리합니다. 이러…

2005.06
12

[App 개발] Cell 아키텍쳐 (1)

앞으로 몇 회에 걸쳐 Nicholas Blachford 사이트에 있는 Cell 아키텍쳐 설명 글을 번역해 올리도록 하겠습니다. 잡스가 Cell 을 보고 콧방귀를 뀌었다던데... 과연 왜 그랬는지 함 보죠. ^^ -------------------…

2005.05
30

[App 개발] 인공지능에 대해 공부해보려는데...

자연어 처리와 인공지능에 대해 관심을 갖고 공부해보고 싶은데요.... 이론적인 측면에서 어디서부터 어떻게 시작하면 돟을까요

2005.05
14

[App 개발] xcode2.0에서 파일 오픈?

사실 2.0뿐만 아니라 1.5에서도 잘 안되네요.. 파일 오픈하는 방법은 vc++이나 같은거 아닌가요 처음 작업은 vc++에서 c++로 짰습니다. (gcc라 오픈하는 방법도 다른건지요..) 오픈하려는 파일을 프로젝트 폴더안에 위치해두고 …

2005.05
11

[App 개발] 마스크 이미지를 이용한 애니메이션

이번에도 역시 제목만 요란할 뿐, 내용은 별로 대단할 것이 없습니다. ^^; 지난 예제에서 한 번 비트맵 데이터를 이용하여 CGContext 를 작성하는 방법을 사용해 보았습니다. 이번에는 이것을 응용하여 투명 레이어에 조그마한 애니메이션을 출력…

2005.05
10

[App 개발] 투명 윈도우를 만들자

오늘도 역시 콜롬부스의 달걀입니다. ㅡㅡ; 엉망으로 짠 프로그램이지만, 나름대로 설명을 달아두면 도움을 받으실 만한 분도 계시겠지요 ^^; 프로젝트명을 거창하게 FullScreenCoreImage 라고 달았지만, 아쉽게도 코어 이미지는 여기…

2005.05
08

[App 개발] Carbon 에서 Core Image 프로그램을 짜는 법 (2)

일단은 샘플로 프로그램을 짜 보았습니다. ^^ QuickDraw 와 Core Graphics 와 Core Image 가 마구 뒤섞인 무시무시한 프로그램이 탄생하고 말았습니다. ㅡㅡ; 예외 처리라든지 그런 것이 하나도 안 되어 있는 완전 개발…

2005.05
05

[App 개발] Carbon 에서 Core Image 프로그램을 짜는 법

타이거의 등장과 함께 꽤나 주목을 받고 있는 Core Image, 그럴싸한 비됴 카드와 128 메가 메모리 없이는 구경도 못한다는 신비의 기술을 한 번 구경하기 위해 이곳저곳 자료를 뒤적여 보았습니다. 카본에서 Core Image 를 호출하기 위해서였…

2005.05
03

[App 개발] Xcode 2.0 + gcc 4.0

오늘 배달온 타이거를 설치하고 나서 맨 먼저 해본 것이 그간 가지고 놀았던 매트릭스 연산 프로그램의 속도 측정이었습니다. Xcode 1.5 에 gcc 3.5 를 가지고 대략 17~20초 사이에 완료하던 작업을 8~9 초만에 끊습니다. 이는 gcc 4.…

2005.04
06

[App 개발] 코코아 개발 서적좀 추천해 주세요.

자바도 관심이 있긴 하지만 퍼포먼스 측면에서 코코아가 더 끌리네요 mfc로 약간 개발 경험이 있는데 역시나 맥쪽은 관련 자료가 드무네요.. 코코아 추천 서적좀 부탁드립니다 ^^

2005.03
26

[App 개발] 프로그래밍 공부하시는 분들이나 개발자 분들은 어떤 컴파일러를 이용하시나요?

오랫만에 개발실에 글을 남기네요.. 영환군입니다~ 최근에 ibm PC를 XP pro SP2로 세팅하면서 다시금 간단히 EditPlus와 Java SDK로 자바 코딩을 세팅하고.. 간단한 C++ 부터 windows APP까지의 컴파일을 위해 여…

2005.03
16

[App 개발] MSN 메신저 프로토콜 해부 1/3

원본은 여기에 있습니다: http://www.devarticles.com/c/a/HTML/The-MSN-Messenger-Protocol-Torn-Apart-Part-1/ ----------------------------------------…

2005.03
14

[App 개발] MSN 메신저 프로토콜

다음 글은 Venky's World (http://www.venkydude.com/articles/msn.htm) 의 글을 번역한 것입니다. MSN 메신저의 기본적인 동작 원리를 이해하는 데 도움이 될 수 있는 쉬운 글입니다. ----------…