2011-03-04 3 views
0

이 코드를 어떻게 최적화 할 수 있습니까? pAmmoOffset는 바이트 배열에 포인터가이것을 최적화하는 방법은 무엇입니까? 배열에 대한 포인터

*pAmmoOffset  = 0x89; 
*(pAmmoOffset + 1) = 0x70; 
*(pAmmoOffset + 2) = 0x04; 
+4

여기서는 최적화 할 사항이 없습니다. 결국 최선의 것은 컴파일러에 달려 있습니다. 최적화 플래그로 컴파일해야합니다. – stefan

+0

정확히 어떤 방식으로 이것을 최적화 하시겠습니까? 즉, 무엇을 개선하고 싶습니까? – Jon

+1

이미 나머지 프로그램을 최적화 했습니까? 이 코드 조각은 실제로 병목 지점입니까? 이것은 꽤 최적화되어 있고 컴파일러는 어쨌든 당신이 목표로하고있는 프로세서를 지정할 때 당신보다 더 잘 할 것입니다. –

답변

3

당신이 프로파일로이 코드를 측정하고 병목의 결정 적이있다? 그렇다면, 죄송 합니다만 컴파일러가 이미 할 수있는만큼 효율적으로 만들었 기 때문에 할 수있는 일이 없습니다.

+0

필자는 프로파일 러에서 그 3 개의 라인을봤을 때만 상상할 수 있습니다. – Blindy

0
*pAmmoOffset++ = 0x89; 
*pAmmoOffset++ = 0x70; 
*pAmmoOffst  = 0x04; 

물론 포인터를 수정합니다.

또한 포인터가 전역 변수 인 경우 생성 된 코드는 각 쓰기 후에 포인터를 다시 읽습니다. 이 문제를 해결하려면 로컬 변수에 복사하여 쓰기 문에서 사용하십시오.

+0

이것은 샘플 코드보다 느릴 수 있습니다. '++'함수는 이전 값을 저장하고 현재 값을 증가시킨 다음 이전 값을 되 돌리십시오. 물론, 이것은 컴파일러와 아키텍쳐에 특유하다. * (q ++) = * (p ++)와 같은 코드를 하나의 기계 명령어로 평가했습니다. – Hannesh

1

32 비트 플랫폼에서 한 번에 4 바이트를 파이프 라인 할 수 있습니다. 그러나을 수동으로 시도하는 것이 궁극적으로 컴파일러가 처음 생성 한 것보다 느리다면 놀랄 일이 아닙니다.

당신이하고있는 일은 아주 간단합니다. 당신이 제공 한 코드가 그다지 중요하지 않고 컴파일 타임 상수를 그 주소에 쓰지 않는 한, 이것을 더 이상 최적화하기 위해 무엇인가 할 수 있는지 의심 스럽다.

+0

+1 "수동으로 시도하는 것이 궁극적으로 컴파일러가 처음 생성 한 것보다 느리다면 놀라지 않을 것입니다." 특정 코드 생성 최적화에 대한 컴파일러보다 현저히 노력하는 것은 거의 항상 잃는 게임입니다. 나는 기발한 읽을 수없는 구조에 대해 "성능을 위해"말하는 코드 주석을 묶었 고, 프로필을 작성하면 간단한 코드보다 느립니다. –

1

코드를 최적화 할 이유가 거의 없습니다. 당신 해야하는 경우 그러나 당신은 다음과 같은 값의 블록을 할당 시도 할 수 :
*(int*) pAmmoOffset = 0x08040201;

하는 것과 같습니다
*pAmmoOffset = 0x01;
*(pAmmoOffset + 1) = 0x02;
*(pAmmoOffset + 2) = 0x04;
당신은 더 큰 블록을 할당 할 수 *(pAmmoOffset + 3) = 0x08;

필요한 경우 int64를 사용하십시오.

+0

이것은 엄격한 앨리어싱 규칙을 위반하며 기본 하드웨어의 바이트 순서에 따라 달라집니다. 이 집에 가보지 마십시오! –

+0

가아! 나는이 규칙들을 몰랐다. 그들을 지적 주셔서 감사합니다. – fmotis

관련 문제