CPU 사용

Question

Q1. CPU를 소비하지 않지만 여전히 우수한 성능을 달성하는 코드를 작성하는 모범 사례는 무엇입니까? 질문은 매우 일반적입니다. 여기서 내가 추구하는 것은 다른 환경에 사용되는 다른 관행을 나열하는 것입니다. 프로세스 모니터/작업 관리자 외에 디버깅 팁

EDIT : IO 바인딩 프로세스에 대해 언급하지 않았습니다. 나는 CPU 바인딩 프로세스에 대해 말하고있다. 하지만 여기에서는 프로세스가 CPU를 계속 사용하는 것을 원하지 않습니다. 4 코어 머신이 있고 프로세스 내에서 4 개의 간단한 루프를 실행하는 경우 CPU 사용량은 응용 프로그램/프로세스가 실행될 때까지 최대 400 %까지 증가합니다.

저는 모두가 언젠가 직면하게 될 주제에 대한 경험을 찾고 있습니다. 예 : 존재하지 않는 파일을 검색하기 위해 반복적으로 루핑 할 때 응용 프로그램이 Windows에서 CPU를 호깅하면 디버깅했습니다.

두 개의 서로 다른 CPU 바운드 응용 프로그램이 원활하게 실행되는 방식으로 프로그램을 작성할 수 있습니까?

UPDATE : 제안 :

1. 는 최적화 후 응용 프로그램을 프로파일 링하고, 좋은 깨끗한 코드를 작성합니다. (팁을 주셔서 감사합니다)

2. 프로파일 링 및 리펙터 코드를 프로파일 링 및 수정하는 것보다 쉽게 ​​재 작성/리펙터링 코드를 작성할 수 있습니다.

3. 는

가

4. 긴 대기

는 이러한 제안은 초보자를 위해 먼 길을 갈

알고리즘 선택에 스레드 스핀 락을 사용하지 마십시오 응용 프로그램 디버깅하기 위해 프로파일 러를 사용하여 개념을 이해하기.

Answer 1

먼저 깨끗한 코드를 작성하십시오. 일을 가능한 한 가장 단순한 방법으로 수행하십시오.

1. 의 실행 프로필 :이 프로그램의 속도에 만족할 때까지 그 후 은 반복적으로 다음을 수행하십시오.
2. 가장 많은 시간을 소비하는 부품을 찾습니다.
3. 해당 부분의 속도를 높입니다.

최적화의 이름에서 앞 코드를 곡해의 함정에 하지 가을 마십시오.

Amdhal's Law을 기억하십시오. 이미 프로그램 시간의 1 % 만 소비하고있는 것을 가속화함으로써 눈에 띄는 향상을 얻지 못할 것입니다. 프로그램에서 가장 많이 소비하는 부분을 가속화하여 최적화 벅에 대한 최상의 결과를 얻을 수 있습니다.

Answer 2

• 사용 게으른 값 및/또는 캐싱
• 의 다른 종류의

Answer 3

• 종교적 프로파일 러를 사용하여주의하여 알고리즘을 선택합니다. 병목 현상을 찾을 때 상식에 의존하지 마십시오.
• big-O 표기법을 익히고 일반적인 알고리즘의 big-O를 기억하십시오.
• 혼잡 한 대기 루프를 피하십시오.
• 임베디드의 경우 코드 캐시에 코드를 삽입하는 방법을 배우면 때로는 빡빡한 루프에서 10 배의 속도 향상을 얻을 수 있습니다.
• 상위 수준의 계층화 된 개발을 수행 할 때 데이터를 효율적으로 캐시하는 방법 (예 : DB 문의 수를 최소화하는 방법)에 대해 알아보십시오.

Answer 4

• 코드 최적화 기술을 따르십시오.

• 작업 메모리를 계산하십시오.

• 각 작업 시간을 계산하십시오.
  (큰 O 표기법)

Answer 5

가능한 한 적은 일을. 당신이 당신의 원래 질문을 편집 한 이후

---

는 당신이 기술 한 특정 상황을 해결하기 위해 여기에 몇 가지 더 생각을 추가합니다.

디버깅 팁을 요구했기 때문에 프로세스가 차단되고있는 위치를 알지 못한다고 가정하면 디버거를 일시 중지함으로써 시작할 수 있습니다. 그러면 응용 프로그램이 무엇이든 멈추고 시작할 수 있습니다. 모든 스레드의 현재 위치를 확인하고 그 중 어떤 것이 긴밀한 루프에 있는지 확인하십시오.

둘째로 알맞은 프로파일 러는 이와 같은 상황을 쉽게 잡을 수 있습니다. 프로파일 러를 연결하고 응용 프로그램을 실행하여 총 런타임의 비율이 크게 증가하는 호출을 차단 된 지점에서 확인하십시오. 거기에서 당신은 당신의 방법을 차단 루프를 찾기 위해 다시 일할 수 있습니다.

문제를 찾았 으면 상황을 완전히 피하기 위해 알고리즘을 다시 생각하는 것이 이상적입니다. 이것이 가능하지 않다면 스레드에서 sleep 명령을 도입하십시오. 이렇게하면 다른 스레드가 CPU에 도달하여 응용 프로그램 및 운영 체제의 응답 속도가 향상되어 운영 런타임이 늘어날 수 있습니다. 멀티 코어 프로그래밍의 트릭은 모든 스레드가 다른 대기중인 작업에 대한 성능과 고려 사항 사이에서 타협하도록 보장하는 것입니다.

특정 언어 나 운영체제를 모르는 상태에서 문제에 대한 디버거/프로파일 러 조합에 대해서는 조언 할 수 없지만 대부분의 성숙한 언어에 대해서는 좋은 해결책이 있다고 생각합니다.

Answer 6

순전히 CPU 사용량이 증가하면 필요한만큼 큰 O 표기가됩니다. 가능한 최소한의 계산으로 알고리즘을 작동시키는 방법을 찾아야합니다.

그러나 일반적인 성능에 대해서는 CPU 사용이 병목 현상이 적은 것으로 나타났습니다.

좀 더 중요한 일 당신은 정면의 모든 데이터를 얻거나 필요에 따라 단지 그것을 어떻게해야합니까, 성능 데이터 바인딩

입니다으로 볼 수 있습니다. 이러한 메소드 중 하나를 선택하는 것이 앱의 성능을 좌우할 수 있습니다.

작업중인 데이터를 줄일 수 있습니까? 기억에 쉽게 맞출 수 있다면 여기에서 성과를 얻을 수 있습니다. 참고로, 메모리에 너무 많이 넣으면 반대 효과가 발생할 수 있습니다.

요약하면 성능에 대한 일반적인 해결책은 없습니다. 코드를 작성하고 (일부 인텔리전스로), 고투중인 부분을 살펴보십시오.

Answer 7

저는 CPU 바운드 프로세스에 대해 말하고 있습니다. 하지만, 여기에 내 프로세스가 호크를 계속하지 않기를 바랍니다. CPU. 내가 4 코어 머신을 가지고 있고 프로세스 내에서 4 개의 간단한 루프를 돌리면, 어플리케이션/프로세스가 실행될 때까지 CPU 소비가 최대 400 %까지 발생합니다.

당신은 아마 유휴 상태에있는 때 CPU 사용률을 줄이기 위해 조절 메커니즘을 보길 원하는 것

: 그것은 아무것도 할 필요가없는 경우 정상적인 상황

, 코드도 CPU 사이클을 소모합니다 (즉 "busy busy").

예를 들어 빈 무한 루프는 다른 작업을 수행 할 필요가 없으면 가능한 한 빨리 실행됩니다.

그러나 일부 상황에서는 바쁜 대기를 원하지 않거나 일부 플랫폼에서는 전혀 사용하지 않을 수 있습니다.

이렇게하는 방법 중 하나는 시스템 스케줄러가 실행중인 모든 스레드를 다시 예약 할 수 있도록 유휴 상태 일 때 절전 모드 호출을 사용하는 것입니다. 마찬가지로, 타이머를 사용하여 함수의 실제 업데이트 속도를 결정할 수 있으며 실행하지 않아도되는 코드를 호출하지 않아도됩니다 (이것은 게임이나 시뮬레이터에서 종종 사용되는 메커니즘입니다).

일반적으로 폴링을 피하고 대신 데이터 구조 자체를 영구적으로 확인할 필요없이 런타임 동작을 자동으로 조정할 수있는 지능형 데이터 구조 (예 : 작업 대기열)를 사용하는 것이 좋습니다.

Answer 8

CPU를 가장 효율적으로 사용하는 방법을 찾고 있는지, 아니면 CPU를 많이 사용하는 작업이 많을 때 컴퓨터가 느려지는 것을 방지 할 수있는 방법이 있는지는 분명하지 않습니다.

이들은 서로 호환되지 않습니다.

전자의 경우 원하는만큼 CPU를 완전히 인계 할 수있는 OS가 이상적입니다. 따라서 OS 자체에서 CPU주기를 낭비 할 필요가 없습니다. 실행중인 다른 프로세스에 대해 언급하십시오.

후자의 경우 최근에 CPU 바인딩 알고리즘을 잘못 디자인 한 일부 코드를 작성했으며 새로운 Intel I7 프로세서는 내 구세주였습니다. 각 스레드가 두 개의 스레드를 실행할 수있는 4 개의 코어가 있다고 가정하면 응용 프로그램 당 OS 스레드 사용을 5 개 또는 6 개로 제한하려고 시도하지만 여전히 다른 창으로 전환하여 kill 명령을 실행하기 위해 CPU를 사용할 수 있습니다. 적어도 내가 공간 유출로 시스템을 바꿀 때까지.

Answer 9

여기에 좋은 제안이 있습니다. 코드를 작성하는 것이 간단할수록 더 많은 시간을 절약 할 수 있습니다.

성능 튜닝을 extension of debugging으로 봅니다. 사람들은 측정, 측정, 측정을 말하지만, 그렇지 않습니다.나는 그 프로그램이 문제가 무엇인지 정확하게 알려주고, 필요하다면 예기치 않은 시간에 여러 번 놓아 두었다. 그것은 대개 놀라운 일이며 절대 잘못된 것이 아닙니다.

프로그램의 크기에 따라 일반적인 성능상의 차이점은 10 % ~ 50 %의 속도 향상 (나쁜 문제가있는 경우 더 많은)을 제공하는 일련의 성능 문제를 찾고 해결하는 것입니다. 이것은 아마도 10 배의 전체적인 스피드 업을 제공합니다.

그런 다음 샘플은 정확히 무엇을하는지 알려주지 만 기본적인 재 설계없이 문제를 해결하는 방법을 생각할 수 없습니다. 처음에 디자인을 다르게 수행했다면 빨리 시작할 수 있습니다.

재 설계를 할 수 있다면 다음과 같이 몇 차례 더 성능을 찾아 수정할 수 있습니다. 이 후, 내가 수익을 줄이는 시점에 도달했을 때, 나는 그것이 가능한 물리적 인만큼 빠르다는 것을 안다. 나는 어셈블리 수준에서 그것을 한 단계 돌릴 수 있고, 모든 지시가 "그 무게를 당기는 것"이 ​​대답에 도달하는 것을 지켜 볼 수있다.

이 점에 도달하는 데 큰 만족감이 있습니다.