흥미롭다:뭔가 정말 흥미롭다면, 그게 흥미롭다는 이야기를 굳이쓸필요가 없다

짧은단어:쓰기도 쉽고 이해하기도 쉽다. 뜻이 같은 두 단어가 있다면 짧은 쪽을 쓰자

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함수로 자료를 병렬 디바이스로 보내기
• 개별 스레드에서 병렬로 처리될 커널 만들기
• 커널 돌리기
• 계산이 끝나면 디바이스의 자료를 호스트 프로세서로 옮기기

병렬 프로그램을 만드는 3단계

1. 병렬처리가 가능한 작은 단위로 문제를 쪼개고

2. 각 단위 문제를 프로세서에 나눠주고

3. 병렬 프로세서간의 통신과 동기화를 시키자

병렬프로그래밍의 대부분은 데이터 간의 의존을 명확하게 하는 것이다.

• Three models of communication
  • Shared address space
  • Message passing
  • Data parallel
• Shared address space model: Abstraction
  • 공유 변수는 게시판 같은거 아무나 와서 쓰고 읽고한니깐
  • Threads communicate by
    • reading/writing to shared variables
      • interprocessor communication is implicit in memory operations
      • Thread 1 stores to X. Later, thread 2 read X
    • Manipulating synchronization primitives

• Natural extension of sequential programming model
• Shared address space model: implementation @ OS
  • Option1: threads share an address space ( all data is sharable)
  • Option2: each thread has its own virtual address space, shared portion of address spaces maps to same physical location

• Non-uniform memory access NUMA
  • in reality, All processors can access any memory location, but … cost of memory access (latency or bandwidth) is different for different processor
  • problem with preserving uniform access time: scalability
    • good: costs are uniform, bad: but memory is uniform far away
  • NUMA design are more scalable
    • high bandwidth to local memory; low latency access to local memory
  • Increased programmer effort: performance tuning

• Shared address space summary
  • Communication
    • 공유 변수를 스레드가 읽고 쓴다
    • 동기화 primitives를 써서 조절한다 (lock, semaphors)
    • 단일 프로세서 프로그램의 확장판이다- NUMA는 조금 다른 이야기
  • Hardware support to make implementations efficient
    • 어떤 프로세서건 어떤 주소를 읽고 쓸수 있어
    • NUMA design은 확장성이 uniform memory access 보다 조아
• Message passing model : abstraction
  • threads operate within independent address spaces
  • threads communicate by sending/receiving messages
    • explicit – point to point
    • send: specifies buffer to be transmitted, recipient, optional message tag
    • receive: specifies buffer to store data, sender and optional message tag
    • messages may be synchronous or asynchronous
  • 
• Message passing model: implementation
  • 인기 라이브러리 – MPI
  • 난점: 메시지 버퍼링 ( 어플리케이션이 받을때까지), 메모리 복사 비용을 최소화 하는 것
  • 하드웨어가 시스템 전체의 load와 store를 할 필요 없어
    • 독립적인 시스템을 연결해서 만들어, 클러스터
• 프로그래밍 모델과 실제 머신 타입을 연결시키는 일은 어려워
  • 메시지 패싱 추상화가 주소 공유 모델의 하드웨어를 사용하는 경우가 흔해
  • Can implement shared address space abstraction on machines that do not support in HW
    • mark all pages with shared variables as invalid
    • page-fault handler issues appropriate network requests
  • Keep in mind what is the programming model ( abstractions used to specific program) and what is the HW implementation; 추상화 모델과 실제 적용에 차이를 기억할것
• Data parallel model
• 변치 않는 계산 구조체
• 역사: 같은 작업을 array안의 각 element에 적용하기
  • SIMD 스타일
    • connection machine: thousands of processors, one instruction
    • Cray supercomputer vector processors
      • Add (A,B,n) : add array A and B with length n
• Matlab이 좋은 예
• SPMD programming (single program, multi data)
  • map (function, collection)
  • where function may be  a complicated sequence of logic
  • application of function to each element of collection is independent
    • in pure form : no communication between iteration of map
  • synchronization is implicit at the end of the map
• Stream programming
• 한가지의 함수를 데이터덩어리에 맵핑하는 것; functional = no side effect; no communication among invocation
• 하지만 실제로 인기 있는 opencl, cuda의 경우 imperative style에도 유연하게 작동해
• side effect 없는 순수 함수 (cannot write a non-deterministic program)
• 예측가능 데이터 접근으로 자료를 가져오고, 입력과 출력의 순간이 미리 정해져 있어
• 생산자-소비자 지역성;  컴파일러가 알아서 하는 일이 많아
• 단점:
• 복잡한 자료 흐름의 경우에는 별도의 연산자가 필요해
• 컴파일러가 충분히 똑똑하길 빌며 프로그램하자
• 실제 사용하다 보면, 원하는 연산자를 찾지 못하는 경우가 있다

스티브잡스 이후의 tech트랜드는 확실히 하드웨어다. 특히 킥스타터를 보면 덕후덕후하고 기발한 하드웨어들이 줄줄이 올라오고, 상당수의 제품들이 단순히 스타업의 프로토타잎이 아니라 메인스트림의 상품 수준이다. 원인으로 생각해 볼만 한것들은 클라우드 펀딩등으로 자금이 쉽게 제공되고, 잡스횽 덕에 높은 하드웨어적 아름다움에 대한 대중적 심미안이 뜨이고, 마지막으로 제조를 가능하게 하는 신기술(3d printing, cloud computing, etc)이 받혀주는 덕에 이런 트랜드가 이어져 가고 있다. 일하고 있는 A사에서도 CAD, CAE, PLM 을 democratize에 목숨거는 분위기인걸 보면 앞으로 몇 년은 갈 트랜드인것 같다.

원문 http://www.paulgraham.com/hw.html

Y Combinator의 장점 중 하나는 조기에 광범위하게 주목는 것이다. 즉 우리는 다른 사람들에 앞서 트렌드를 본다.  최근 가장 눈에 띈 트렌드 중 하나가 하드웨어 스탓업 많아진것이다. 84 기업 중 7 개가 하드웨어를 만들고 있었다. 대체로 그들은  기존 기업보다 잘하고 있었다.

물론 그들 투자자로부터 저항을 받는다. 투자자들은 하드웨어에 뿌리 깊은 편견을 가지고있다. 그러나 투자자의 아이디어는 후행 지표다. 최고인 창업자는 최고의 투자자보다 미래에 선견지명이있는 것이다. 왜냐하면 최고의 창업자들이 그 미래를 만들어 있기 때문이다.

이 트렌드를 견인하고있는 것은 하나뿐이 아니다. 클라우드 펀딩 사이트들에서는 하드웨어가 무척 잘하고있다. 태블릿의 보급도 태블릿에서 컨트롤 할 수있는 새로운 제품을 만드는 것을 가능하게하고 제품끼리 결합 것조차 가능하게하고있다. 전기 모터도 진화했고, 다양한 종류의 무선 연결도 당연 해지고있다. 이러한 트렌드가 제품을 제조하는 것을 밀고있다.

Arduino (아루두이노은 AVR 마이크로 컨트롤러, 입출력 포트를 갖춘 보드, C 언어 바람 Arduino 언어와의 통합 개발 환경으로 구성된 시스템), 3D 프린팅, 레이저 절단기와 CNC 밀링 머신이보다 쉽게​​ 이용할 수 있도록 이제보다 쉽게​​ 프로토 타입을 생산 가능하게하고있다. 또한, 온라인으로 구입하는 사람들이 늘고있는 것으로 유통 업체도 병목현상을 덜 격는다

내가 할 수있는 질문은, 왜 갑자기 하드웨어 쿨해졌는지이다.  그것은 지금까지도 멋졌어. 실제 물건은 훌륭하다. 물건은 소프트웨어와 같이 급격한 성장을 할 수있는 좋은 방법이 아니었다 뿐이다. 그러나 그 규칙해도 영구적으로 따르지 않는 것 같다. 오래된 일도 아니다. 그것은 1990년대 부터 그렇게 된것이다. 소프트웨어의 장점 것도 일시적인 것이 될지도 모른다. 해커 무리는 하드웨어를 만드는일 사랑하고, 고객 그걸  기꺼이 산다. 그래서 쉽게 하드웨어파는 일이 소프트웨어를 쉽게 파는 일에 가까와지고, 더욱 더 많은 하드웨어 스타트업을 볼수있게 될지도 모른다.

틀린 생각이 실제로 틀려질 때까지 틀린게 아닌것은 처음 보는 일이 아니다. 기업에서 투자자가 창업자로 부터 배움를 얻는 것도 처음이 아니다.

그래서 만약 당신이 하드웨어에 착수하고 생각하고 있다면, 무서워할 필요는 없다.  왜냐하면 당신은 투자자 무리가 당신을 공격하는 것을 걱정하는 것이기 때문이다. 특히 하드웨어의 아이디어를 가지고  Y Combinator (폴그레엄이 참여하는 펀드)에 응모할 때 두려워할 필요는 없다. 왜냐하면 우리는 하드웨어 스타트업에 강한 관심을 가지고 있기 때문이다.

우리는 다음 세대의 Steve Jobs 위한 기회의 방이 있다는 것을 알고있다. 그러나 또한 확실히  그 기회의 방에 <당신 이름> 을 써 넣을 수 있다는 것이다!

function 이 인자로 사용되면 느려지니깐 STL의 binary_function을 상속받아서 STL용 function 객체를 만들어쓴다.