Multicore를 어떻게 활용하고 있습니까?

Multicore를 어떻게 활용하고 있습니까?

---

엔터프라이즈 웹 개발 세계에서 온 HPC 세계의 누군가로서 저는 "실제 세계"로 돌아온 개발자들이 어떻게 병렬 컴퓨팅을 활용하는지 항상 궁금합니다. 이는 모든 칩이 멀티 코어 로 전환되고 있기 때문에 훨씬 더 관련성이 있으며, 칩에 몇 개가 아닌 수천 개의 코어가있을 때 훨씬 더 관련성이 있습니다.

내 질문은 다음과 같습니다.

1. 이것이 소프트웨어 로드맵에 어떤 영향을 미칩니 까?
2. 저는 특히 멀티 코어가 다른 소프트웨어 도메인에 어떤 영향을 미치는지에 대한 실제 이야기에 관심이 있으므로 답변에 어떤 종류의 개발을 수행하는지 지정하십시오 ( 예 : 서버 측, 클라이언트 측 앱, 과학 컴퓨팅 등).
3. 멀티 코어 머신을 활용하기 위해 기존 코드로 무엇을하고 있으며 어떤 문제에 직면 했습니까? 당신이 사용하고 OpenMP를 , 얼랑 , 하스켈 , CUDA , TBB , UPC 또는 뭔가?
4. 동시성 수준이 계속 증가함에 따라 무엇을 할 계획이며 수백 또는 수천 개의 코어를 어떻게 처리 할 계획입니까?
5. 도메인 이 병렬 계산의 이점을 쉽게 얻지 못한다면 왜 흥미로운 지 설명하십시오.

마지막으로, 저는 이것을 멀티 코어 질문으로 구성했지만 다른 유형의 병렬 컴퓨팅에 대해 자유롭게 이야기 할 수 있습니다. MapReduce 를 사용하기 위해 앱의 일부를 포팅 하거나 대규모 클러스터의 MPI 가 패러다임이라면 분명히 언급하십시오.

업데이트 : 5 번 답을한다면, 사용 가능한 메모리 대역폭으로 공급할 수있는 것보다 더 많은 코어 (100, 1000 등)가 생기면 상황이 바뀔 것이라고 생각하는지 언급하십시오 (대역폭이 코어 당 점점 더 작아지는 방식으로 확인) ). 애플리케이션에 나머지 코어를 계속 사용할 수 있습니까?

---

내 연구 작업에는 컴파일러 및 스팸 필터링 작업이 포함됩니다. 나는 또한 많은 '개인 생산성'유닉스 작업을합니다. 또한 채점, 학생 코드 테스트, 성적 추적 및 기타 수많은 퀴즈를 포함하여 내가 가르치는 수업을 관리하기 위해 소프트웨어를 작성하고 사용합니다.

1. Multicore는 컴파일러가 다른 응용 프로그램을 지원하는 연구 문제를 제외하고 는 전혀 영향을 미치지 않습니다 . 그러나 이러한 문제는 주로 컴파일러가 아닌 런타임 시스템에 있습니다.
2. 큰 문제와 비용으로 Dave Wortman은 1990 년경에 4 개의 프로세서를 계속 사용하도록 컴파일러를 병렬화 할 수 있음을 보여주었습니다 . 내가 아는 누구도 실험을 반복 한 적이 없습니다. 대부분의 컴파일러는 단일 스레드를 실행할 수있을만큼 빠릅니다 . 그리고 컴파일러 자체를 병렬로 만드는 것보다 여러 다른 소스 파일에서 순차 컴파일러를 병렬로 실행하는 것이 훨씬 쉽습니다. 스팸 필터링의 경우 학습은 본질적으로 순차적 인 프로세스 입니다. 그리고 오래된 기계조차도 초당 수백 개의 메시지를 학습 할 수 있으므로 큰 말뭉치도 1 분 이내에 학습 할 수 있습니다. 다시 말하지만, 훈련은 충분히 빠릅니다 .
3. 내가 병렬 머신을 이용하는 유일한 중요한 방법은 parallel make를 사용하는 것 입니다. 이는 큰 혜택이며 큰 빌드는 병렬화하기 쉽습니다 . Make는 거의 모든 작업을 자동으로 수행합니다. 내가 기억할 수있는 유일한 다른 점은 병렬 처리를 사용하여 장기간 실행되는 학생 코드를 여러 실험실 컴퓨터로 파밍하여 시간을 계산하는 것입니다.이 작업을 양심적으로 할 수있는 이유는 컴퓨터 당 하나의 코어 만 사용했기 때문에 1 개만 사용했습니다. / 4 CPU 리소스. 아, 그리고 절름발이로 MP3 파일을 추출 할 때 4 개의 코어를 모두 사용하는 Lua 스크립트를 작성했습니다. 그 대본은 제대로하기위한 많은 작업이었습니다.
4. 수십, 수백, 수천 개의 코어 를 무시 합니다. 내가 "병렬 기계가오고있다. 준비해야한다"는 말을 처음 들었던 것은 1984 년이었다. 당시 병렬 프로그래밍이 고도로 숙련 된 전문가를위한 영역 이라는 것은 사실이며 오늘날에도 사실이다 . 변경된 유일한 점은 오늘날 제조업체가 우리가 원하든 원하지 않든 병렬 하드웨어 비용을 지불하도록 강요 하고 있다는 것입니다. 하지만 하드웨어 비용이 지불되었다고해서 무료로 사용할 수있는 것은 아닙니다. 프로그래밍 모델은 끔찍하며 스레드 / 뮤텍스 모델이 작동하도록합니다., 잘 수행하는 것은 말할 것도없고 하드웨어가 무료 인 경우에도 비용이 많이 드는 작업입니다. 나는 대부분의 프로그래머가 병렬 처리를 무시하고 조용히 자신의 사업을 시작하기를 기대합니다. 숙련 된 전문가가 패러렐 메이크 나 훌륭한 컴퓨터 게임과 함께 오면 조용히 박수를 보내고 그들의 노력을 활용하겠습니다. 내 앱의 성능을 원하면 메모리 할당 을 줄이는 데 집중 하고 병렬 처리를 무시합니다.
5. 병렬 처리 는 정말 어렵습니다. 대부분의 도메인은 병렬화가 어렵습니다. 병렬 작성과 같이 널리 재사용 할 수있는 예외는 많은 기쁨을주는 원인입니다.

요약 (내가 선도적 인 CPU 제조업체에서 일하는 기조 연설자로부터 들었습니다) : 업계는 기계를 더 빠르고 더 뜨겁게 작동시킬 수 없었고 추가 트랜지스터로 무엇을해야할지 몰랐기 때문에 멀티 코어로 지원했습니다. 이제 그들은 수익이 없으면 차세대 팹 라인을 구축 할 수 없기 때문에 멀티 코어를 수익성있게 만드는 방법을 찾기 위해 필사적입니다. 육즙 열차는 끝났고 실제로 소프트웨어 비용에주의를 기울여야 할 수도 있습니다.

병렬 처리를 진지하게 생각하는 많은 사람들은 128 개 이상의 프로세서를 탑재 한 GPU를 선호하는이 장난감 4 코어 또는 32 코어 머신을 무시하고 있습니다. 제 생각에는 실제 행동이 거기에있을 것입니다.

---

웹 애플리케이션의 경우 매우 간단합니다. 무시하십시오. 병렬로 수행해야하는 코드가없는 한 구식 단일 스레드 코드를 작성하고 만족할 수 있습니다.

일반적으로 주어진 순간에 처리 할 요청이 코어보다 훨씬 많습니다. 그리고 각각은 자체 스레드 (또는 기술에 따라 프로세스)에서 처리되기 때문에 이미 병렬로 작동하고 있습니다.

주의해야 할 유일한 장소는 동기화가 필요한 일종의 전역 상태에 액세스 할 때입니다. 완벽하게 확장 가능한 다른 세계에 인공적인 병목 현상이 발생하지 않도록 최소로 유지하십시오.

그래서 나에게 멀티 코어는 기본적으로 다음 항목으로 요약됩니다.

• 내 서버는 "CPU"가 적고 각 서버는 더 많은 코어를 사용합니다 (나에게 큰 차이는 없습니다).
• 동일한 수의 CPU가 더 많은 동시 사용자를 대체 할 수 있습니다.
• CPU가 100 %로드 된 결과가 아닌 성능 병목 현상이 발생하는 것 같으면 어딘가에서 잘못된 동기화를 수행하고 있음을 나타냅니다.

---

1. 현재로서는-솔직히 그다지 영향을 미치지 않습니다. 저는이를 가능하게하는 기술과 언어 기능에 대해 배우면서 '준비 단계'에 더 있습니다.
2. 특정 도메인이 하나도 없지만 수학 (멀티 코어가 필수적인 경우), 데이터 정렬 / 검색 (멀티 코어에서 분할 및 정복이 도움이되는 경우) 및 다중 컴퓨터 요구 사항 (예 : 백업 스테이션의 처리 능력 이 무언가에 사용 된다는 요구 사항 ).
3. 이것은 내가 일하는 언어에 달려 있습니다. 분명히 C #에서 내 손은 OpenMP와 동일한 알고리즘을 비교하기 시작할 때까지 성능을 향상시키는 병렬 확장의 아직 준비되지 않은 구현과 연결되어 있습니다 (아마도 공정한 비교가 아님). 따라서 .NET에서는 일부 for→ Parallel.For리팩토링 등으로 쉽게 이동할 수 있습니다 .
   일을 얻을 경우에는 정말 흥미로운 OpenMP를이 .NET에 비해 압도적처럼 성능이 당신이 일의 짜내 수 있기 때문에, C ++와 함께입니다. 사실 OpenMP가 그렇게 효율적으로 작동 할 것이라고 기대하지 않았기 때문에 저를 많이 놀라게했습니다. 글쎄, 나는 그것의 개발자가 그것을 다듬을 시간이 많았다 고 생각합니다. 또한 비용을 지불해야하는 TBB와 달리 Visual Studio에서 바로 사용할 수 있다는 점도 마음에 듭니다.
   MPI에 관해서는 한 대의 컴퓨터가 처리 할 수없는 계산을 속이기 위해 작은 집 프로젝트 (저는 LAN이 있습니다)에 PureMPI.net을 사용합니다. 저는 MPI를 상업적으로 사용 해본 적이 없지만 MKL에는 MPI에 최적화 된 기능이 몇 가지 있다는 것을 알고 있습니다.이 기능을 필요로하는 모든 사람에게 흥미로울 수 있습니다.
4. 나는 '경박 한 컴퓨팅'을 할 계획이다. 즉, 필요하거나 필요하지 않은 결과를 미리 계산하기 위해 여분의 코어를 사용할 계획이다. 물론 RAM은 허용한다. 또한 현재 대부분의 최종 사용자의 컴퓨터에서 처리 할 수없는 값 비싼 알고리즘과 접근 방식을 조사하려고합니다.
5. 병렬화의 혜택을받지 못하는 도메인에 관해서는 ... 음, 항상 무언가를 찾을 수 있습니다. 나는 한 가지 하고 염려하지만 유감스럽게도 내가 달성 할 수 ++ C와 유사한 속도 희망을 포기, .NET에서 괜찮은 지원입니다.

---

저는 의료 영상 및 이미지 처리 분야에서 일합니다.

단일 코어를 처리하는 것과 거의 동일한 방식으로 다중 코어를 처리하고 있습니다. 반응 형 UI를 갖기 위해 작성하는 애플리케이션에 이미 여러 스레드가 있습니다.

그러나 이제 가능하기 때문에 CUDA 또는 OpenMP에서 대부분의 이미지 처리 작업을 구현하는 데 집중하고 있습니다. 인텔 컴파일러는 OpenMP에 대한 많은 좋은 샘플 코드를 제공하고 CUDA보다 훨씬 더 성숙한 제품이며 훨씬 더 큰 설치 기반을 제공하므로 아마도 그와 함께 갈 것입니다.

비용이 많이 드는 (즉, 1 초 이상) 작업을 위해 우리가하는 경향은 가능한 경우 해당 작업을 다른 프로세스로 포크하는 것입니다. 이렇게하면 기본 UI가 계속 반응합니다. 그렇게 할 수 없거나 그렇게 많은 메모리를 이동하는 것이 너무 불편하거나 느리면 작업은 여전히 ​​스레드에 있으며 그 작업은 자체적으로 여러 스레드를 생성 할 수 있습니다.

우리의 핵심은 동시성 병목 현상이 발생하지 않도록하는 것입니다. .NET에서 개발합니다. 즉, 주 스레드가 UI를 업데이트하도록하려면 UI에 대한 호출 호출에서 UI 업데이트를 수행해야합니다.

어쩌면 내가 게 으르 겠지만, 매트릭스 반전 등과 같은 것들을 병렬화 할 때이 많은 것들을 알아내는 데 너무 많은 시간을 할애하고 싶지는 않습니다. 정말 똑똑한 많은 사람들이 질소처럼 빠르게 그 물건을 만드는 데 많은 시간을 보냈고, 저는 그들이 한 일을 받아들이고 그것을 부르고 싶습니다. CUDA와 같은 것은 이미지 처리를위한 흥미로운 인터페이스를 가지고 있지만 (물론 그것이 정의 된 것입니다), 그런 종류의 플러그 앤 플레이 프로그래밍에는 여전히 너무 미숙합니다. 나 또는 다른 개발자가 여가 시간을 많이 확보하면 시도해 볼 수 있습니다. 대신 OpenMP를 사용하여 처리 속도를 높일 것입니다 (확실히 향후 몇 달 동안 개발 로드맵에 포함됨).

---

지금까지 make다음을 사용 하여 더 효율적인 컴파일이 가능합니다 .

gmake -j

이 -j옵션을 사용하면 서로 의존하지 않는 작업을 병렬로 실행할 수 있습니다.

---

ASP.NET 웹 응용 프로그램을 개발 중입니다. 내 코드에서 직접 멀티 코어를 사용할 가능성은 거의 없지만 IIS는로드시 여러 작업자 스레드 / 프로세스를 생성하여 이미 여러 코어 / CPU에 대해 잘 확장됩니다.

---

F #을 사용하는 .NET 4에서 작업 병렬 처리로 많은 성공을 거두고 있습니다. 고객들은 n-1 코어가 유휴 상태가되는 것을 원하지 않기 때문에 멀티 코어 지원을 요청하고 있습니다!

---

저는 이미지 처리 중입니다. 우리는 가능한 한 여러 스레드에 분할 된 이미지를 처리하여 멀티 코어를 활용하고 있습니다.

---

나는 다른 질문에 대한 대답으로 이것의 일부를 말했습니다. (괜찮기를 바랍니다!) : 흐름 기반 프로그래밍 이라는 개념 / 방법론이 있습니다.(FBP)는 30 년 이상 사용되어 왔으며 캐나다의 주요 은행에서 대부분의 일괄 처리를 처리하는 데 사용되고 있습니다. 이전 구현은 파이버 기반 (C ++ 및 메인 프레임 어셈블러) 이었지만 Java 및 C #으로 스레드 기반 구현이 있습니다. 멀티 코어를 활용하는 문제에 대한 대부분의 접근 방식은 기존의 단일 스레드 프로그램을 사용하여 병렬로 실행할 수있는 부분을 파악하는 것과 관련이 있습니다. FBP는 다른 접근 방식을 취합니다. 응용 프로그램은 처음부터 비동기 적으로 실행되는 여러 "블랙 박스"구성 요소 (제조 조립 라인을 고려) 측면에서 설계되었습니다. 구성 요소 간의 인터페이스가 데이터 스트림이기 때문에 FBP는 기본적으로 언어 독립적이므로 혼합 언어 응용 프로그램과 도메인 별 언어를 지원합니다.

---

저의 대학원 작업은 베어 메탈 멀티 코어 작업을 수행하고 임베디드 시스템에서 동일한 교육을하기위한 개념을 개발하는 것입니다.

또한 F #을 사용하여 높은 수준의 다중 처리 가능 언어 기능을 사용하여 속도를 높이고 있습니다.

---

우리는 만들기 VivaMP의 병렬 OpenMP를 프로그램에서 감지 오류 코드 분석기를.

VivaMP는 OpenMP 기술을 기반으로 한 병렬 프로그램의 오류를 표시하기위한 Lint와 유사한 정적 C / C ++ 코드 분석기입니다. VivaMP 정적 분석기는 기존 컴파일러의 기능에 많은 것을 추가하고 일부 오류가 있거나 이러한 오류의 최종 원인이되는 모든 병렬 코드를 진단합니다. 분석기는 VisualStudio2005 / 2008 개발 환경에 통합됩니다.

VivaMP – OpenMP 용 도구

C ++ 개발자를위한 32 개의 OpenMP 트랩

---

나는 " 사이클은 엔지니어의 가장 친한 친구 " 라고 믿습니다 .

우리 회사는 많은 컴퓨터 언어로 된 매우 큰 소프트웨어 시스템을 분석하고 변환하기위한 상용 도구를 제공합니다. "Large"는 1,000 만 ~ 3 천만 줄의 코드를 의미합니다. 이 도구는 DMS 소프트웨어 리엔지니어링 툴킷 (줄여서 DMS)입니다.

이러한 거대한 시스템에 대한 분석 (및 변환까지)에는 오랜 시간이 걸립니다. C 코드에 대한 포인트 투 분석기는 16Gb RAM이있는 x86-64에서 CPU 시간 90 시간이 걸립니다. 엔지니어는 그보다 더 빠른 답변을 원합니다.

결과적으로 우리는 소규모 멀티 코어 공유 메모리 시스템을 활용하기 위해 자체 설계 한 병렬 프로그래밍 언어 인 PARLANSE로 DMS를 구현했습니다 .

구문 분석의 핵심 아이디어는 다음과 같습니다. a) 프로그래머가 병렬 처리를 노출하도록 허용, b) 컴파일러가 인식 할 수있는 부분을 선택하도록 허용, c) 컨텍스트 전환을 절대 최소로 유지합니다. 계산에 대한 정적 부분 순서는 3 가지 모두를 달성하는 데 도움이됩니다. 말하기 쉽고, 상대적으로 비용을 측정하기 쉽고, 컴파일러가 계산을 쉽게 예약 할 수 있습니다. (이와 함께 병렬 퀵 정렬을 작성하는 것은 간단합니다).

안타깝게도 1996 년에이 작업을 수행했습니다. (지난 몇 년은 마침내 증명이되었습니다. 이제 Fry 's에서 8 코어 머신을 $ 1,000 미만에 구입할 수 있고 24 코어 머신을 소형 자동차와 거의 같은 가격에 구입할 수 있습니다. 빠르게 떨어짐).

The good news is that DMS is now a fairly mature, and there are a number of key internal mechanisms in DMS which take advantage of this, notably an entire class of analyzers call "attribute grammars", which we write using a domain-specific language which is NOT parlanse. DMS compiles these atrribute grammars into PARLANSE and then they are executed in parallel. Our C++ front end uses attribute grammars, and is about 100K sloc; it is compiled into 800K SLOC of parallel parlanse code that actually works reliably.

Now (June 2009), we are pretty busy making DMS useful, and don't always have enough time to harness the parallelism well. Thus the 90 hour points-to analysis. We are working on parallelizing that, and have reasonable hope of 10-20x speedup.

We believe that in the long run, harnessing SMP well will make workstations far more friendly to engineers asking hard questions. As well they should.

---

Our domain logic is based heavily on a workflow engine and each workflow instance runs off the ThreadPool.

That's good enough for us.

---

I can now separate my main operating system from my development / install whatever I like os using vitualisation setups with Virtual PC or VMWare.

Dual core means that one CPU runs my host OS, the other runs my development OS with a decent level of performance.

---

Learning a functional programming language might use multiple cores... costly.

I think it's not really hard to use extra cores. There are some trivialities as web apps that does not need to have any extra care as the web server does its work running the queries in parallel. The questions are for long running algorythms (long is what you call long). These need to be split over smaller domains that does not depend each other, or synchronize the dependencies. A lot of algs can do this, but sometimes horribly different implementations needed (costs again).

So, no silver bullet until you are using imperative programming languages, sorry. Either you need skilled programmers (costly) or you need to turn to an other programming language (costly). Or you may have luck simply (web).

---

I'm using and programming on a Mac. Grand Central Dispatch for the win. The Ars Technica review of Snow Leopard has a lot of interesting things to say about multicore programming and where people (or at least Apple) are going with it.

---

I've decided to take advantage of multiple cores in an implementation of the DEFLATE algorithm. MArc Adler did something similar in C code with PIGZ (parallel gzip). I've delivered the philosophical equivalent, but in a managed code library, in DotNetZip v1.9. This is not a port of PIGZ, but a similar idea, implemented independently.

The idea behind DEFLATE is to scan a block of data, look for repeated sequences, build a "dictionary" that maps a short "code" to each of those repeated sequences, then emit a byte stream where each instance of one of the repeated sequences is replaced by a "code" from the dictionary.

Because building the dictionary is CPU intensive, DEFLATE is a perfect candidate for parallelization. i've taken a Map+Reduce type approach, where I divide the incoming uncompressed bytestreeam into a set of smaller blocks (map), say 64k each, and then compress those independently. Then I concatenate the resulting blocks together (reduce). Each 64k block is compressed independently, on its own thread, without regard for the other blocks.

On a dual-core machine, this approach compresses in about 54% of the time of the traditional serial approach. On server-class machines, with more cores available, it can potentially deliver even better results; with no server machine, I haven't tested it personally, but people tell me it's fast.

---

There's runtime (cpu) overhead associated to the management of multiple threads, runtime memory overhead associated to the buffers for each thead, and data overhead associated to concatenating the blocks. So this approach pays off only for larger bytestreams. In my tests, above 512k, it can pay off. Below that, it is better to use a serial approach.

---

DotNetZip is delivered as a library. My goal was to make all of this transparent. So the library automatically uses the extra threads when the buffer is above 512kb. There's nothing the application has to do, in order to use threads. It just works, and when threads are used, it's magically faster. I think this is a reasonable approach to take for most libbraries being consumed by applications.

---

It would be nice for the computer to be smart about automatically and dynamically exploiting resources on parallizable algorithms, but the reality today is that apps designers have to explicitly code the parallelization in.

---

---

I work in C# with .Net Threads. You can combine object-oriented encapsulation with Thread management.

I've read some posts from Peter talking about a new book from Packt Publishing and I've found the following article in Packt Publishing web page:

http://www.packtpub.com/article/simplifying-parallelism-complexity-c-sharp

I've read Concurrent Programming with Windows, Joe Duffy's book. Now, I am waiting for "C# 2008 and 2005 Threaded Programming", Hillar's book - http://www.amazon.com/2008-2005-Threaded-Programming-Beginners/dp/1847197108/ref=pd_rhf_p_t_2

I agree with Szundi "No silver bullet"!

---

You say "For web applications it's very, very easy: ignore it. Unless you've got some code that really begs to be done in parallel you can simply write old-style single-threaded code and be happy."

I am working with Web applications and I do need to take full advantage of parallelism. I understand your point. However, we must prepare for the multicore revolution. Ignoring it is the same than ignoring the GUI revolution in the 90's.

We are not still developing for DOS? We must tackle multicore or we'll be dead in many years.

---

I think this trend will first persuade some developers, and then most of them will see that parallelization is a really complex task. I expect some design pattern to come to take care of this complexity. Not low level ones but architectural patterns which will make hard to do something wrong.

For example I expect messaging patterns to gain popularity, because it's inherently asynchronous, but you don't think about deadlock or mutex or whatever.

---

1. How does this affect your software roadmap?
   It doesn't. Our (as with almost all other) business related apps run perfectly well on a single core. So long as adding more cores doesn't significantly reduce the performance of single threaded apps, we're happy

2. ...real stories...
   Like everyone else, parallel builds are the main benefit we get. The Visual Studio 2008 C# compiler doesn't seem to use more than one core though, which really sucks

3. What are you doing with your existing code to take advantage of multicore machines
   We may look into using the .NET parallel extensions if we ever have a long-running algorithm that can be parallelized, but the odds of this actually occurring are slim. The most likely answer is that some of the developers will play around with it for interest's sake, but not much else

4. how will you deal with hundreds or thousands of cores?
   Head -> Sand.

5. If your domain doesn't easily benefit from parallel computation, then explaining why is interesting, too.
   The client app mostly pushes data around, the server app mostly relies on SQL server to do the heavy lifting

---

I'm taking advantage of multicore using C, PThreads, and a home brew implementation of Communicating Sequential Processes on an OpenVPX platform with Linux using the PREEMPT_RT patch set's scheduler. It all adds up to nearly 100% CPU utilisation across multiple OS instances with no CPU time used for data exchange between processor cards in the OpenVPX chassis, and very low latency too. Also using sFPDP to join multiple OpenVPX chassis together into a single machine. Am not using Xeon's internal DMA so as to relieve memory pressure inside CPUs (DMA still uses memory bandwidth at the expense of the CPU cores). Instead we're leaving data in place and passing ownership of it around in a CSP way (so not unlike the philosophy of .NET's task parallel data flow library).

1) Software Roadmap - we have pressure to maximise the use real estate and available power. Making the very most of the latest hardware is essential

2) Software domain - effectively Scientific Computing

3) What we're doing with existing code? Constantly breaking it apart and redistributing parts of it across threads so that each core is maxed out doing the most it possibly can without breaking out real time requirement. New hardware means quite a lot of re-thinking (faster cores can do more in the given time, don't want them to be under utilised). Not as bad as it sounds - the core routines are very modular so easily assembled into thread-sized lumps. Although we planned on taking control of thread affinity away from Linux, we've not yet managed to extract significant extra performance by doing so. Linux is pretty good at getting data and code in more or less the same place.

4) In effect already there - total machine already adds up to thousands of cores

5) Parallel computing is essential - it's a MISD system.

If that sounds like a lot of work, it is. some jobs require going whole hog on making the absolute most of available hardware and eschewing almost everything that is high level. We're finding that the total machine performance is a function of CPU memory bandwidth, not CPU core speed, L1/L2/L3 cache size.

참고URL : https://stackoverflow.com/questions/363341/how-are-you-taking-advantage-of-multicore