답변:
아무리 훌륭하더라도 코드를 작성하는 언어와 컴파일러를 개발하는 팀 보다 스레드 관리 등의 체계가 더 좋을 것 같지 않습니다 .
응용 프로그램이 다중 스레드가 필요한 경우 필요한 스레드를 만들고 컴파일러와 OS가 작업을 수행하게하십시오.
리소스를 최대한 활용할 수 있도록 해당 스레드가 관리되는 방식을 알고 있어야합니다. 너무 많은 스레드를 만들지 않는 것이 하나의 예로 떠오르는 것입니다.
또한 스레드 관리에 대한 힌트를 제공하거나 특별한 경우에는 무시할 수 있도록 진행중인 작업을 알고 있어야합니다 (Lorenzo의 설명 참조).
저는 .NET 프로그래머이며 .NET에는 Tasks라는 멀티 스레딩에 대한 고급 추상화가 있다는 것을 알고 있습니다. 금속에 대해 적절한 멀티 스레딩을 수행하는 방법에 대해 너무 많이 알 필요가 없습니다. 다른 현재 개발 플랫폼에도 비슷한 추상화가 있다고 가정합니다. 따라서 멀티 스레딩으로 무엇이든 할 예정이라면 가능한 한 그 수준에서 일하려고 노력할 것입니다.
이제 특정 응용 프로그램의 멀티 스레딩에 관심 을 가져야하는지 에 대한 질문입니다 . 해당 질문에 대한 답변은 작성중인 응용 프로그램에 따라 매우 다릅니다. 수천 개 이상의 독립적 인 작업을 처리하는 응용 프로그램을 작성하고이 처리를 병렬로 수행 할 수 있다면 멀티 스레딩의 이점을 얻을 수 있습니다. 그러나 간단한 데이터 입력 화면을 작성하는 경우 멀티 스레딩이 그다지 사지 않을 수 있습니다.
최소한 UI에서 작업 할 때는 멀티 스레딩에 관심이 있어야합니다. UI에서 장기 실행 작업을 시작하지 않으려는 경우 해당 작업을 수행하기 위해 UI 스레드를 하이재킹했기 때문에 응답하지 않게됩니다. 백그라운드 스레드를 해제하고 최소한 사용자에게 취소 버튼을 제공하여 실수로 완료 될 때까지 기다릴 필요가 없도록합니다.
Objective-C 및 Mac OS X 및 iOS 환경에서 프레임 워크 (다른 많은 프레임 워크)는 프로세서 코어의 이러한 증가를 이용하여 개발자에게 유용한 인터페이스를 제공하기 위해 작성되었습니다.
Mac OS X 및 iOS의 예는 Grand Central 디스패치입니다. libc대기열 기반 멀티 스레딩을 용이하게하기 위해 (믿습니다)에 추가되었습니다 . 그런 다음 Cocoa 및 Foundation 프레임 워크 (다른 무엇보다도)가 GCD 위에 작성되므로 개발자는 아주 적은 보일러 플레이트 코드로 대기열을 전달하고 스레딩에 쉽게 액세스 할 수 있습니다.
많은 언어와 프레임 워크의 개념이 비슷합니다.
우리는 지금 엄청난 전환의시기에 있습니다 (2010 년 10 월).
오늘 12 코어 데스크탑을 구입할 수있었습니다.
오늘 448 개의 핵심 처리 카드 (NVIdia Tesla 검색)를 구입할 수 있습니다 .
가까운 시일 내에 프로그램이 작동 할 엄청나게 유사한 환경을 무시하고 개발자가 작업 할 수있는 양에는 한계가 있습니다.
운영 체제, 런타임 환경 및 프로그래밍 라이브러리는 그렇게 많은 일을 할 수 있습니다.
앞으로는 새로운 .NET "작업 프레임 워크"와 같은 추상화를 사용하여 독립적 인 처리를 위해 처리를 별도의 청크로 분할해야합니다.
캐시 관리 및 선호도와 같은 세부 정보는 계속 제공되지만 성능이 뛰어난 응용 프로그램의 장점 일뿐입니다. 동일한 개발자가 10k 코어 시스템에서 이러한 세부 정보를 수동으로 관리하기를 원하지 않습니다.
글쎄, 그것은 실제로 당신이 개발하고있는 것에 달려 있습니다. 대답은 개발중인 내용에 따라 "무의미한 것"에서 "절대적으로 중요한 것"까지 다양 할 수 있으며, 팀의 모든 사람이 병렬 구현에 대해 잘 이해하고 사용하기를 기대합니다.
대부분의 경우, 병렬 처리가 필요한 경우 잠금, 스레드, 작업 및 작업 풀을 제대로 이해하고 사용하는 것이 좋습니다. (lang / lib에 따라 다름)
사소한 멀티 프로세싱의 경우 여러 가지 새로운 프로그래밍 모델 또는 병렬화 전략을 배워야하는 디자인의 차이점을 추가하십시오. 이 경우, 배우고, 충분한 시간을내어 제대로 이해하지 못하고, 기존 프로그램을 업데이트하는 데 1 년 이상이 걸릴 수 있습니다. 일단 당신이 그 시점에 도달하면, 당신은 (당신이 아직 그 전환을하지 않았다면) 오늘날처럼 당신이 문제 / 구현을 이해하거나 접근하지 않을 것입니다.
또 다른 장애물은 특정 실행을 위해 프로그램을 효과적으로 최적화한다는 것입니다. 프로그램을 최적화 할 시간이 충분하지 않으면 실제로 필요한만큼의 혜택을받지 못할 것입니다. 높은 수준의 (또는 명백한) 병렬화는 상당히 적은 노력으로 프로그램의 인식 된 속도를 향상시킬 수 있으며, 오늘날 많은 팀이 진행할 수있는 한 "우리는 앱의 분명한 부분을 병렬화했습니다"는 경우가 있습니다. 낮은 매달린 과일을 섭취하고 간단한 병렬화를 사용하면 코어 수에 비례하는 이점이 있습니까? 종종 2 ~ 4 개의 논리 코어가 있지만 그 이상은 아닙니다. 많은 경우에, 그것은 시간 투자를 감안할 때 수용 가능한 수익입니다. 이 병렬 모델은 많은 사람들이 병렬 처리를 잘 활용하기위한 소개입니다.
이 사소한 병렬 모델을 사용하여 배우는 것은 모든 복잡한 병렬 시나리오에서 이상적이지는 않습니다. 복잡한 병렬 설계를 효과적으로 적용하려면 훨씬 다른 이해와 접근 방식이 필요합니다. 이러한 간단한 모델은 종종 분리되거나 시스템의 다른 구성 요소와 사소한 상호 작용을합니다. 또한 이러한 사소한 모델의 많은 구현은 복잡한 병렬 시스템으로 효과적으로 확장되지 못합니다. 나쁜 복잡한 병렬 설계는 단순한 모델처럼 실행하는 데 시간이 오래 걸릴 수 있습니다. ill : 단일 스레드 모델보다 2 배 빠르며 실행 중에 8 개의 논리 코어를 활용합니다. 가장 일반적인 예는 너무 많은 스레드와 높은 수준의 동기화 간섭을 사용 / 생성하는 것입니다. 일반적으로이를 병렬 속도 저하라고합니다. 모든 병렬 문제에 간단한 문제로 접근하면 쉽게 접할 수 있습니다.
그래서,하자가 당신이 말하는 정말 (오늘날의 기후에있는 소수 민족) 프로그램의 효율적인 멀티 스레딩을 활용한다 : 당신이 재 학습은 프로그램의 흐름과 상호 작용을 접근하는 방법을 다음 복잡한 모델을 배우고 효과적으로 간단한 모델을 고용해야합니다. 복잡한 모델은 오늘날 하드웨어가있는 곳에서 프로그램이 궁극적으로 있어야 할 곳이며 가장 많이 개선 된 곳입니다.
간단한 모델의 실행은 포크처럼 구상 될 수 있으며 복잡한 모델은 복잡한 어 생태계처럼 작동합니다. 나는 일반적인 잠금 및 스레딩을 포함한 간단한 모델에 대한 이해가 도메인 (개발중인)이 그것을 사용할 때 중간 개발자들에게 곧 예상 될 것이라고 생각합니다. 복잡한 모델을 이해하는 것은 오늘날 (대부분의 영역에서) 여전히 이례적인 일이지만 수요는 매우 빠르게 증가 할 것으로 생각합니다. 개발자로서 훨씬 더 많은 프로그램이 이러한 모델을 지원해야하며, 이러한 개념을 이해하고 구현하는 데있어 대부분의 사용이 훨씬 뒤쳐져 있습니다. 논리적 프로세서 수는 하드웨어 개선의 가장 중요한 영역 중 하나이므로 복잡한 시스템을 이해하고 구현할 수있는 사람들에 대한 수요는 확실히 증가 할 것입니다.
마지막으로 솔루션이 "병렬화 추가"라고 생각하는 사람들이 많이 있습니다. 종종 기존 구현을 더 빠르게 만드는 것이 좋습니다. 많은 경우에 훨씬 쉽고 간단합니다. 야생의 많은 프로그램은 결코 최적화 된 적이 없습니다. 일부 사람들은 언젠가는 하드웨어에 의해 최적화되지 않은 버전이 사라질 것이라는 인상을 받았습니다. 성능이 중요한 경우 기존 프로그램의 디자인이나 알고리즘을 개선하는 것도 중요한 기술입니다. 문제에 더 많은 코어를 던지는 것이 반드시 가장 좋은 해결책은 아닙니다.
현대적인 PC를 대상으로 할 때, 우수한 병렬 시스템을 구현해야하는 대부분의 사람들은 멀티 스레딩, 잠금, 병렬 라이브러리, 책의 가치가있는 책, 프로그램 작성 및 테스트 경험 (기본적으로 접근 프로그램 작성).
현재로서는 프로세서 주파수가 조만간 증가하지 않을 것입니다. 우리는 3GHz 마크 주위에 붙어 있습니다 (오버 클로킹 없음). 많은 응용 프로그램의 경우 기본 멀티 스레딩을 넘어 설 필요는 없습니다. 사용자 인터페이스 응용 프로그램을 작성하는 경우 백그라운드 스레드에서 집중적 인 처리를 수행해야합니다.
실시간이어야하는 대량의 데이터를 처리하는 응용 프로그램을 구축하는 경우에는 멀티 스레딩 프로그래밍을 고려해야합니다.
멀티 스레드 프로그래밍의 경우 성능에 대한 수익이 감소합니다. 시간을 보내고 프로그램을 15 % 개선 한 다음 1 주일을 더 보내고 5 % 만 향상시킬 수 있습니다.