지난주 micro-software에서 주최한 "ISTEP 2013"세미나에 다녀왔습니다.

본 세미나의 주제는 멀티코어 개발자들을 위한 병렬프로그래밍입니다.

유익한 정보인 것 같아 공유하고자 합니다.

세미나는 다음과 같은 순으로 진행되었습니다.

1. Think Parallel

2. 강력한 멀티코어 프로세스 전략

3. 인텔 컴포저 XE 2013을 활용한 최적화, 벡터화 그리고 병렬화

4. 인텔 제온 파이에서의 애플리케이션 포팅

5. 제온 파이와 TBB를 결합한 반도체 제조 연구 분야 실무 사례 소개

<1. Think Parallel>

  "Think Parallel" 주제에서는 멀티코어/매니코어의 물리적한계 및 그에 따른 병렬처리의 필요성과 효율에 대해 이야기했습니다.

<2. 강력한 멀티코어 프로세스 전략>

  멀티코어 프로세스를 위한 인텔의 제품으로, 분석도구를 포함하는 통합 수트인 "Parallel Studio XE 2013"과 "Cluster Studio XE 2013",

그리고 차세대 프로세서인 "Intel Xeon Phi coprocessors"를 소개하였습니다.

"Parallel Studio XE 2013"과 "Cluster Studio XE 2013"의 주요기능입니다.

- 향상된 컴파일러 및 라이브러리 성능

- 3세대 인텔® 코어™ 프로세서와 다음 세대인 해즈웰(Haswell) 마이크로 아키텍처 및 인텔 제온(Xeon) Phi 코프로세서 지원

- 충돌 및 보안 취약성을 가져올 수 있는 버퍼 오버플로우를 감지하고 찾아낼 수 있는 포인터 검사기(Pointer checker)

- 기존 메모리 분석으로는 불가능했던 비 할당된 메모리 공간을 찾아주는 메모리 성장 분석(Memory growth analysis)

- 클러스터 안정성 향상을 가져오는 개선된 무장애 무중단(fault tolerance) MPI 라이브러리

<3. 컴포저 XE 2013을 활용한 최적화, 벡터화 그리고 병렬화>

프로젝트의 최적화 및 벡터화의 중요성(특히 Intel CilkPlus)과 인텔 컴파일러 성능을 강조하였습니다.

실제 인텔 컴파일러 데모를 시연하여 테스트의 결과를 볼 수 있었습니다.

예제) 1024 행렬의 곱셈의 수행속도 테스트

※자동벡터화 : 컴파일러에 기본으로 포함되어있는 벡터화

적절한 최적화 옵션과 벡터화를 통하여 효율적인 속도를 얻을 수 있음을 확인하였습니다.

<4. 인텔 제온 파이에서의 애플리케이션 포팅>

HPC(High Performance Computing) 및 멀티프로세서 병렬화를 최대로 이끌어 낼 수 있는 제품이라는 소개로

인텔의 제품을 하드웨어적, 소프트웨어적으로 나누어 설명하였습니다.

- 하드웨어적 측면에서의 적용 : Intel Xeon Phi coprocessors

- 소프트웨어적 측면에서의 적용 : Intel XE 제품(Parallel Studio XE 2013, Cluster Studio XE 2013)

Xeon Phi는 Host컴퓨터의 PCIe 슬롯에 장착되어, 보조 프로세서의 역할을 수행하는 코프로세서입니다.

이러한 Xeon Phi는 61코어와 512비트의 SIMD 벡터처리 능력과 1테라플롭이라는 최대 성능을 가지고 있습니다.

제온파이(Linux OS)는 호스트컴퓨터(windows OS)와 PCIe 버스를 통해 통신합니다.

제온파이의 목적은 application에 따라 호스트와 코프로세스의 사용을 코드상으로 제어하여 성능을 최대한 전략적으로 할 수 있도록 튜닝하는 것에 있습니다.

이러한 목적을 위해서는 application의 병렬화 및 벡터화를 최적으로 하여야 성능을 극대로 끌어올릴 수 있습니다.

<5. 제온 파이와 TBB를 결합한 반도체 제조 연구 분야 실무 사례 소개>

마지막 파트에서는 윈도우OS상에서 제온파이를 제어하는 기술을 설명하였습니다.

윈도우 os가 설치된 호스트 컴퓨터에서 제온 파이를 사용하기 위해서는,

- windows 7이상의 64bit 버전 설치

- .Net Framework 4.0이상

- MPSS 설치 - 제온 파이 코프로세서 드라이버

- 제온 파이의 플래시 업데이트

- 개발도구 설치. Visual Studio 2008이상

- 인텔 컴파일러 설치(Intel Composer XE 2013 update1 SP1

위와 같은 순서로 개발환경을 구축합니다.

구축을 완료한 후 OpenMP, MPI, TBB, Cilk Plus, MKL등의 라이브러리를 사용하여 병렬화를 구현할 수 있습니다.

하지만 윈도우 기반에서의 사용에는 데이터타입이나 포인터사용불가 등 데이터 구조의 제한과 문법 및 컴파일의 제한 등 아직 미흡한 부분이 많아,

제온파이의 적용은 어려워 보입니다.

실제 프로젝트에 적용해볼 항목들은 아래와 같습니다.

- Intel Parallel Studio XE 2013를 통한 프로젝트 분석

- Intel C++ Compiler 적용

- Intel TBB 라이브러리 적용

- Intel Cilk Plus 적용

- Intel MPI library (for Windows) 적용

[첨부] Intel ISTEP 2013 세미나 발표자료

이상입니다. 

[화면설계] 항목

playlist

단일 YouTube 재생목록을 표시합니다. 재생목록은 순서대로 감상하거나 다른 사용자와 공유할 수 있는 동영상의 모음입니다.

<OAuth 2.0>

[개요]
- 모바일, 플랫폼의 시대가 도래하면서(Open API) 데이터는 REST&JSON 포맷을 기반으로하여 API를 제공
- 인증방식은 OAuth2.0을 사용

[OAuth 1.0a]
- OAuth 1.0 : 트위터를 비롯한 웹 개발자들이 API인증 및 로그인한 사용자에 대한 권한부여를 동시에 제공하도록 하는 인증 프로토콜
- 2007년 10월 OAuth1.0 출시(보안결함)
- 2009년 OAuth 1.0a 발표 (정식 "The OAuth 1.0 Protcol")

- 장점
  a. API 인증 시 써드파티 어플리케이션에게 사용자의 비밀번호를 노출하지 않고 인증가능
  b. 인증과 API권한부여를 동시에 할 수 있음

- 동작방식
 : user / consumer / service provider

                                   <OAuth 1.0a 트라이앵글>

  : 3-legged OAuth라고도 함
  a. user : 트위터사용자
  b. consumer : 트위터 단말 어플리캐이션
  c. service provider : 트위터 API 서비스

  #가설 ?
    새로운 어플을 다운받았으나, 신뢰할 수 없다. (어떤짓을 할지 몰라~)
    이때 인증토큰을 사용하여 인증을 하게됨

[인증토큰]
- 인증이 완료되면 컨슈머(예, PocketTube)는 인증 토큰을 받게된다.
- 특징
   a. 컨슈머가 사용자의 id/pw를 가지지않고 API를 사용할 수 있음
   b. 필요한 API에만 제한적으로 접근할 수 있도록 권한제어가 가능
   c. 사용자가 서비스 프로바이더(예, YouTube)의 관리페이지에서 권한 취소가 가능
   d. 패스워드 변경 시에도 인증 토큰은 계속 유효함

   (※ c번의 유용한 점? 사용자가 핸드폰을 잃어버렸을때, 서비스프로바이더의 관리페이지에서 어플리케이션 인증을 취소할수 있다.)


[OAuth 2.0]
* OAuth 1.0a와 호환이 않되고 사용되는 언어부터 시작해 많은 것들이 다름

- 거의 초기부터 IETF 표준 프로세스 안에서 만들어지고 있음.
- 2010년 4월부터 등록됨
- 모바일에서의 OAuth1.0a의 불편함, signature 생성의 복잡함, 과한 CPU 소비, 기능과 규모의 확장성을 지원하기 위해 만들어짐
- 정식명칭 "OAuth 인증 프레임워크" ("The OAuth 2.0 Authorization Framework")

- 개선사항
  a. 사용함에 있어서 간단해짐
  b. 더 많은 인증방법을 지원(웹브라우저, 모바일 등 다양한 시나리오에 대응이 가능)
  c. 대형 서비스로의 확장성 지원

- 용어
  a. Resource Owner : 사용자
  b. Resource Server : API 서버
  c. Authorization Server : 인증서버(API와 같을 수도 있음)
  d. Client : 써드파티 어플리케이션

[대표적 서비스 프로바이더]

[OAuth 2.0 인증방식]
- 3-legged를 비롯하여 2-legged등 다양한 인증 방식 지원
- but, 기본은 3-legged

  a. Authorization Code Grant
   - 웹 서버에서 API를 호출하는 등의 시나리오에서 Confidential Client가 사용하는 방식
   - 로그인시 페이지 url에 response_type=code라고 넘김

  b. Implicit Grant
   - 브라우저 기반의 어플리케이션이나 모바일 어플리케이션에서 사용하는 방식
   - Client 증명서를 사용할 필요가없고, 실제로 가장 많이 사용하는 방식
   - 로그인시 페이지 url에 response_type=token이라고 넘김

  c. Password Credentials Grant
   - 2-legged방식
   - Client에 id/pw를 저장해놓고 id/pw로 직접 access token을 받아오는 방식
   - client를 믿을 수 없을때에는 사용하기에 위험이 있음
   - 로그인시 API에 POST로 grant_type=password라고 넘김

  d. Client Credentials Grant
   - 어플리케이션이 Confidential client일때 id와 secret을 가지고 인증하는 방식
   - 로그인시 API에 POST로 grant_type=client_credentials라고 넘김

  e. Extension
   - 추가적인 인증방식을 적용할 수 있도록 함

[다양한 토큰 지원]
  - 기본적으로는 Bearer토큰, 즉 암호화하지 않은 그냥 토큰(HTTPS를 사용하여 HTTPS의 암호화에 의존)
  - 다른 토큰 방식도 지원하지만 거의 안씀

  - "Refresh Token"
   : 같은 access token을 오래 사용시, 노출 위험이 있으므로 refresh token개념을 도입
   : 만료기간을 짧게하고 refresh token으로 access token을 갱신