반짝임과 불행 OOP

새 코멘트
 

기본 클래스, 여러 자손, 시작 시 설정한 매개변수에 따라 자손 중 하나가 사용됩니다. 이것은 보편적 프로그램의 잘 알려진 원리입니다. 아무리 많은 옵션(즉, 자손 클래스)이 있더라도 프로그램을 변경하기 위한 if 또는 switch 호출이 없으며 초기화 중에 원하는 자식 클래스가 선택되면 한 번만 선택되므로 이 비즈니스는 매우 빠르게 작동해야 합니다. 모든 것이 직접적이고 간단하게 작동합니다.

 class CBase{
   private :
   public :
       virtual void Fun(){
      
      }
};

class CClass1:CBase{
   private :
   public :
       void Fun(){
      
      }
};

CClass1 * cl;

void OnInit (){

   cl= new CClass1;

}

하지만...

얼마나 많은 다른 옵션이 있을 수 있습니까? 합리적인 수치? 10, 20, 100? 100개의 옵션이 있어도 스위치는 OOP보다 빠릅니다.

응용 프로그램에서 성능을 비교하기 위한 스크립트입니다. 위의 OOP를 비교하여 함수로 전환하면 됩니다(또한 두 개의 함수가 호출되고 함수 호출 중 하나는 쉽게 제거될 수 있음).

 void ff( int z){

       switch (z){
         case 0 :
         f0();
         break ;

         ...

         case 99 :
         f99();
         break ;

      }
     
}
결과(f99 호출):

파일:
test.mq4  9 kb
 
Integer :

얼마나 많은 다른 옵션이 있을 수 있습니까? 합리적인 수치? 10, 20, 100? 100개의 옵션이 있어도 스위치는 OOP보다 빠릅니다.

나는 지나친 일반화에 대해 경고하고 싶다. 가상 "의사 포인터"를 사용하기 때문에 mql에서 이러한 효과를 기대하는 것이 합리적입니다. 실제로 실제 주소의 내부(숨겨진) 해시 테이블을 참조하는 핸들입니다. 이러한 포인터를 해결하려면 포인터를 직접 지정하는 것보다 훨씬 더 많은 추가 시간이 필요합니다. 측정하지는 않았지만 유사한 포인터 "속도 저하" 효과가 dotNET 언어 및 기타 유사한 구현에서 발견될 가능성이 있습니다.

"실제"포인터가있는 언어에서는 그러한 효과가 없으며 스위치가 손실됩니다. 더 많을수록 선택 목록이 커집니다.

그래서 OOP는 그것과 아무 관련이 없습니다.

 
MetaDriver :

나는 지나친 일반화에 대해 경고하고 싶다. 가상 "의사 포인터"를 사용하기 때문에 mql에서 이러한 효과를 기대하는 것이 합리적입니다. 실제로 실제 주소의 내부(숨겨진) 해시 테이블을 참조하는 핸들입니다. 이러한 포인터를 해결하려면 포인터를 직접 지정하는 것보다 훨씬 더 많은 추가 시간이 필요합니다. 측정하지는 않았지만 유사한 포인터 "속도 저하" 효과가 dotNET 언어 및 기타 유사한 구현에서 발견될 가능성이 있습니다.

"실제"포인터가있는 언어에서는 그러한 효과가 없으며 스위치가 손실됩니다. 더 많을수록 선택 목록이 커집니다.

그래서 OOP는 그것과 아무 관련이 없습니다.

문제는 컴파일러 자체에만 있음이 분명하므로 "올바른" 컴파일을 사용하면 위의 예제 의 실행 시간 이 동일합니다.
 
icas :
문제는 컴파일러 자체에만 있음이 분명하므로 "올바른" 컴파일을 사용하면 위 예제 의 실행 시간 이 동일합니다.
"정확함"의 개념은 규칙에 따라 다르므로 의미가 없습니다. ;)
 

바로 오류를 지적하겠습니다. f는 더미 함수이며 컴파일러에서 완전히 잘라냈습니다. 즉, 실제로는 함수 호출 이 없습니다. 나는 또한 ff 함수가 어떤 상태로 퇴화하고 결국 for 루프 내부에 인라인되어 함수 호출조차 제거할 것인지 확신하지 못합니다.

그러나 가상 메서드는 잘라낼 수 없습니다. 항상 호출됩니다. 결과적으로 한 경우에는 사이클이 단순히 회전하고 다른 경우에는 호출이 사이클에 있습니다.

모든 테스트에서 우선 정확성을 증명한 다음 결과로 진행해야합니다.

 

비어 있지 않은 함수가 있는 경우:

파일:
test2.mq4  11 kb
 

여기에 모든 고유 함수가 있으며 switch 를 통해 호출되는 함수 는 클래스 메서드 보다 복잡합니다.

파일:
test3.mq4  12 kb
 
Integer :

여기에 모든 고유 함수가 있으며 switch 를 통해 호출되는 함수 는 클래스 메서드 보다 복잡합니다.

모든 것이 어떻게 시작되었는지...

인라인이라고 들어보셨나요? 공격적 인라이닝은 어떻습니까?

단순 함수 본체는 일반적으로 어떻게 되며 일반 최적화 컴파일러는 이 본체로 무엇을 합니까? 지금은 1995년이 아니다.

 
MetaDriver :

나는 지나친 일반화에 대해 경고하고 싶다. 가상 "의사 포인터"를 사용하기 때문에 mql에서 이러한 효과를 기대하는 것이 합리적입니다. 실제로 실제 주소의 내부(숨겨진) 해시 테이블을 참조하는 핸들입니다. 이러한 포인터를 해결하려면 포인터를 직접 지정하는 것보다 훨씬 더 많은 추가 시간이 필요합니다. 측정하지는 않았지만 유사한 포인터 "속도 저하" 효과가 dotNET 언어 및 기타 유사한 구현에서 발견될 가능성이 있습니다.

"실제"포인터가있는 언어에서는 그러한 효과가 없으며 스위치가 손실됩니다. 더 많을수록 선택 목록이 커집니다.

그래서 OOP는 그것과 아무 관련이 없습니다.

응. 여기 C 샤프입니다 :)


 7550021(스위치)
2250004 (OOP)
7325029(스위치)
2050015 (OOP)
7550049(스위치)
2150005 (OOP)
7575031(스위치)
2325009 (OOP)
8025038(스위치)
2200004 (OOP)
7150027(스위치)
2050014 (OOP)
7375029(스위치)
2200005 (OOP)
7550022(스위치)
1950003 (OOP)
7100021(스위치)
2695083 (OOP)
7360033(스위치)
2200008 (OOP)
7825029(스위치)
1925010 (OOP)
7325025(스위치)
2025006 (OOP)
6850035(스위치)
2525014 (OOP)
7750027(스위치)
1975007 (OOP)
8195225(스위치)
2050004 (OOP)
6950020(스위치)
2425006 (OOP)
7275029(스위치)
2225015 (OOP)
7050037(스위치)
2200007 (OOP)
7375030(스위치)

 

그것이 정확하고 진술된 것이 실제로 측정되었다는 증거로 모든 테스트를 시작하십시오.

위에 제시된 것은 놀라운 오류를 포함하고 있으며 컴파일 메커니즘의 작성자와 코드 작동 방식에 대한 완전한 이해 부족을 보여줍니다.

 
Renat :

그것이 정확하고 진술된 것이 실제로 측정되었다는 증거를 가지고 모든 테스트를 시작하십시오.

위에 제시된 것은 놀라운 오류를 포함하고 있으며 컴파일 메커니즘의 작성자와 코드 작동 방식에 대한 완전한 이해 부족을 보여줍니다.

컴파일 메커니즘을 이해해야 하는 이유는 무엇입니까? 나쁜 결과가 좋은 결과보다 낫다고 믿는 것뿐입니까? 결과가 중요합니다.
1234567
새 코멘트