Bridge pattern은 객체지향 설계방법이고, PIMPL은 파일 물리적으로 설계하는 방법이다.

PIMPL은 실제 구현을 감추는 한 방법으로, 우선적으로 컴파일 의존성을 쪼개는 것이다

Bridge pattern은 기본 추상화 객체에 여러가지 구현을 허락하는 방법이다.

swap()은 두 가지 객체의 값을 교환하는 표준 함수이다. 만약 각 구현에서 포인터를 swap한다면, 런타임에 클래스의 구조를 바꿔줘야 한다. 기본적으로 PIMPL을 사용하는 클래스는 한 가지 구현만을 갖는데, 다른 하위클래스를 가지는 추상 클래스는 없고, forward declared, 다른 곳에서 컴파일되는 한 클래스만을 가질 뿐이다.  구현 클래스를 바꾸는 일이 메인 헤더파일을 include하는 소스 파일을 다시 컴파일하게 만들지 않는다.

예로 많은 수의 private 멤버함수, enums, 데이터를 갖고 있다면, 클래스를 개발하는 도중에는 이러한 private 구성원들을 자주 바꾸게 된다. 만약에 여러파일에 이러한 클래스를 include 한다면, 그래서 private 멤버의 변화때문에 많은 파일을 재컴파일해야 한다면 PIMPL을 사용하는게 좋다.

PIMPL is a way of hiding the implementation, primarily to break compilation dependencies.

The Bridge pattern, on the other hand, is a way of supporting multiple implementations.

swap is a standard C++ function for exchanging the values of two objects. If you swap the pointer to the implementation for a different implementation, you are essentially changing the mechanism of the class at runtime.

But in its basic and common form, a class using PIMPL points to a single implementation, so there is no abstract class with distinct subclasses — just one class, forward declared, and compiled elsewhere. Changing the implementation class does not require any recompilation of sources that include the main header.

For example, say you have a lot of private member functions, private enums, and private data. And these private "bits" change fairly frequently as the class is developed and maintained. If the #include dependencies are such that touching this header file causes a large number of sources to be recompiled, you have a good candidate for PIMPL.

So the Bridge pattern is about object-oriented design, while the PIMPL idiom is about physical design of files.

http://stackoverflow.com/questions/2346163/pimpl-idiom-vs-bridge-design-pattern

http://books.google.com/books?id=qW1mncii_6EC&printsec=frontcover&hl=ko#v=onepage&q&f=false

• No more free lunch; 발열과 에너지 소모가 클럭 주파수 늘여서 성능을 높이기에 한계를 가져왔다
• Many core application은 execution throughput이 중요
• 2010년 기준으로 제대로 작성된 many core application은 10k~40k의 스레드를 생성
• CPU와 GPU는 상호 보완적인 관계
• HPC programming requires some knowledge of how the hardware works
• Typical CUDA program flow
• 병렬 디바이스에서 작동할 자료를 API 함수로 allocate,
• API함수로 자료를 병렬 디바이스로 보내기
• 개별 스레드에서 병렬로 처리될 커널 만들기
• 커널 돌리기
• 계산이 끝나면 디바이스의 자료를 호스트 프로세서로 옮기기