이동 평균 계산을 고루틴과 병렬화하면 성능이 저하되는 이유는 무엇입니까?

배경

이 문제는 슬라이스의 이동 평균을 계산하기 위해 Go 함수를 최적화하는 것과 관련이 있습니다. 이 함수는 본질적으로 당혹스러울 정도로 병렬적이므로 동시에 실행할 수 있는 독립적인 작업으로 쉽게 분할될 수 있습니다.

최적화 시도 및 결과

개발자는 두 가지로 고루틴을 사용하여 함수를 병렬화하려고 시도했습니다. 방법:

• Moving_avg_concurrent2: 슬라이스는 더 작은 조각으로 분할되었으며 각 조각은 별도의 고루틴에 의해 처리되었습니다.
• Moving_avg_concurrent3: 마스터 고루틴이 여러 워커를 생성하는 마스터/워커 패러다임이 채택되었습니다. 입력 슬라이스의 다양한 창에 대한 이동 평균을 계산하는 고루틴.

벤치마크에 따르면 두 동시 접근 방식 모두 원래 직렬 함수 moving_avg_serial4보다 성능이 떨어지는 것으로 나타났습니다.

Moving_avg_concurrent2가 확장되지 않는 이유는 무엇입니까?

이유 Moving_avg_concurrent2는 확장되지 않습니다. 즉, 고루틴을 생성하고 관리하는 오버헤드가 병렬 처리의 이점보다 크다는 것입니다. 이 경우 오버헤드에는 고루틴 생성 및 예약에 소요되는 시간뿐만 아니라 고루틴 간의 통신 및 동기화에 소요되는 시간도 포함됩니다.

moving_avg_concurrent3이 Moving_avg_serial4보다 훨씬 느린 이유는 무엇인가요?

마스터/워커 패러다임은 직접 고루틴 접근 방식에 비해 추가 오버헤드를 발생시킵니다. Moving_avg_concurrent3에서는 마스터와 워커 고루틴 간의 통신을 위한 채널을 생성하고 작업 단위의 송수신을 관리해야 합니다. 이 오버헤드는 함수의 성능을 더욱 저하시킵니다.

고루틴 오버헤드가 너무 많은 오버헤드를 생성하는 것이 가능합니까?

예, 고루틴 오버헤드가 프로그램 성능에 심각한 영향을 미칠 수 있습니다. 고루틴은 경량 스레드이지만 여전히 생성, 예약, 동기화와 관련된 오버헤드가 있습니다. Moving_avg_concurrent3의 경우 채널 관리 및 마스터/작업자 통신 관리에 따른 오버헤드가 함수 실행 시간에 추가됩니다.

위 내용은 이동 평균 계산을 고루틴과 병렬화하면 성능이 저하되는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!