이제 OnTesterInit에서 각 입력 매개변수에 대한 최적화 범위를 설정할 수 있습니다. 그 후 테스터 자체가 통과 테이블을 생성하고 이를 에이전트/패키지 수로 분할하여 에이전트에게 보냅니다. 이 테이블은 지금 어떤 식으로든 편집되지 않습니다.
그러나 실제로 최적화할 때 어떤 중요한 매개변수가 변경되고 다른 매개변수가 변경되는 경로 등에 대해 우려하는 상황이 실제로 매우 자주 발생합니다. 형성된 패스 테이블(스왑 요소(입력 매개변수 세트))을 편집하거나 직접 구성할 수 있는 경우 가장 흥미로운 패스가 에이전트에게 먼저 이동하고 다음으로 필요한 우선순위를 설정하는 것이 가능합니다. 덜 흥미로운 것들.
따라서 OnTesterInit에서 기본 패스 테이블을 변경하는 기능을 추가할 것을 제안합니다.
long PassesTotal(); // количество проходов в таблице для Оптимизации// Получает список входных параметров соответствующего проходаint PassesGet( constint Index, MqlParam & Parameters[] );
// Прописывает список входных параметров для соответствующего прохода,// если индекс не меньше размера таблицы, то идет дозапись в конец таблицы и размер ее увеличивается на единицуint PassesSet( constint Index, constMqlParam & Parameters[] );
Alexey Navoykov : 옵티마이저는 트레이스가 있는 영역을 잘라낼 수 없습니다.) 작업 논리에 영향을 주지 않는 영역만 잘라낼 수 있습니다.
글쎄, 주제가 소진되었습니다 ;-). 이 경우 최적화는 값이 반환 되는 코드 지점에서만 발생할 수 있으며 생성자에 작성된 내용에 의존하지 않습니다.
C++11 표준 : 특정 기준이 충족되면 개체의 복사/이동 생성자 및/또는 소멸자에 부작용이 있더라도 구현에서 클래스 개체의 복사/이동 생성을 생략할 수 있습니다. 이러한 경우 구현은 생략된 복사/이동 작업의 소스와 대상을 단순히 동일한 개체를 참조하는 두 가지 다른 방법으로 취급하고 해당 개체의 소멸은 두 개체가 다음과 같을 때 나중에 발생합니다. 최적화 없이 파괴됩니다.
글쎄, 주제가 소진되었습니다 ;-). 이 경우 최적화는 값이 반환 되는 코드 지점에서만 발생할 수 있으며 생성자에 작성된 내용에 의존하지 않습니다.
일반적으로 MQL 컴파일러가 내가 생각한 것만큼 똑똑하지 않다는 것을 유감스럽게 인정해야 합니다. ) 나는 심지어 말할 것입니다. - 전혀 똑똑하지 않습니다. 아무데도 사용되지 않고 아무 것도 하지 않는 더미 개체가 만들어지므로 컴파일러는 상관하지 않습니다. 최적화가 없습니다. 나는 순전히 일의 속도로 판단한다. 그리고 어떤 이유로 새 빌드에서는 이전 빌드보다 느리게 작동합니다.
다음은 일반 코드입니다.
class A { };
voidOnStart ()
{
uint starttick= GetTickCount ();
for ( int i= 0 ; i< 1 e8; i++)
{
A a;
}
Print ( GetTickCount ()-starttick, " ms" );
}
컴파일러는 여기에서 도움이 되지 않습니다. 확인됩니다. 로컬 개체는 반환에 의해 복제된 다음 못을 박습니다. 이 경우 최적의 이동이 없습니다.
속도 테스트는 해보셨나요? 아니면 객체 생성 사실을 진단하고 있습니까? 후자라면 당연히 코드에서 아무 것도 잘라내지 않을 것입니다. 당신은 당신의 자신의 검사로 그것을 방지합니다.
속도 테스트는 해보셨나요? 아니면 객체 생성 사실을 진단하고 있습니까? 후자라면 당연히 코드에서 아무 것도 잘라내지 않을 것입니다. 당신은 당신의 자신의 검사로 그것을 방지합니다.
어떤가요? 내 모든 검사는 생성자와 소멸자에서 전달된 추적으로만 구성됩니다. 중복 복사본이 생성 및 삭제된다면 이는 나에게 최적화가 부족하다는 충분한 증거입니다.
속도 테스트는 해보셨나요? 아니면 객체 생성 사실을 진단하고 있습니까? 후자라면 당연히 코드에서 아무 것도 잘라내지 않을 것입니다. 당신은 당신의 자신의 검사로 그것을 방지합니다.
글쎄, 이동이 문자열에서 발생하지 않는다면 더 복잡한 객체에 대해 무엇을 말할 수 있습니까?
어떤가요? 내 모든 검사는 생성자와 소멸자에서 전달된 추적으로만 구성됩니다. 중복 복사본이 생성 및 삭제된다면 이는 나에게 최적화가 부족하다는 충분한 증거입니다.
이제 OnTesterInit에서 각 입력 매개변수에 대한 최적화 범위를 설정할 수 있습니다. 그 후 테스터 자체가 통과 테이블을 생성하고 이를 에이전트/패키지 수로 분할하여 에이전트에게 보냅니다. 이 테이블은 지금 어떤 식으로든 편집되지 않습니다.
그러나 실제로 최적화할 때 어떤 중요한 매개변수가 변경되고 다른 매개변수가 변경되는 경로 등에 대해 우려하는 상황이 실제로 매우 자주 발생합니다. 형성된 패스 테이블(스왑 요소(입력 매개변수 세트))을 편집하거나 직접 구성할 수 있는 경우 가장 흥미로운 패스가 에이전트에게 먼저 이동하고 다음으로 필요한 우선순위를 설정하는 것이 가능합니다. 덜 흥미로운 것들.
따라서 OnTesterInit에서 기본 패스 테이블을 변경하는 기능을 추가할 것을 제안합니다.
옵티마이저는 트레이스가 있는 영역을 잘라낼 수 없습니다.) 작업 논리에 영향을 주지 않는 영역만 잘라낼 수 있습니다.
글쎄, 주제가 소진되었습니다 ;-). 이 경우 최적화는 값이 반환 되는 코드 지점에서만 발생할 수 있으며 생성자에 작성된 내용에 의존하지 않습니다.
C++11 표준 : 특정 기준이 충족되면 개체의 복사/이동 생성자 및/또는 소멸자에 부작용이 있더라도 구현에서 클래스 개체의 복사/이동 생성을 생략할 수 있습니다. 이러한 경우 구현은 생략된 복사/이동 작업의 소스와 대상을 단순히 동일한 개체를 참조하는 두 가지 다른 방법으로 취급하고 해당 개체의 소멸은 두 개체가 다음과 같을 때 나중에 발생합니다. 최적화 없이 파괴됩니다.
글쎄, 주제가 소진되었습니다 ;-). 이 경우 최적화는 값이 반환 되는 코드 지점에서만 발생할 수 있으며 생성자에 작성된 내용에 의존하지 않습니다.
일반적으로 MQL 컴파일러가 내가 생각한 것만큼 똑똑하지 않다는 것을 유감스럽게 인정해야 합니다. ) 나는 심지어 말할 것입니다. - 전혀 똑똑하지 않습니다. 아무데도 사용되지 않고 아무 것도 하지 않는 더미 개체가 만들어지므로 컴파일러는 상관하지 않습니다. 최적화가 없습니다. 나는 순전히 일의 속도로 판단한다. 그리고 어떤 이유로 새 빌드에서는 이전 빌드보다 느리게 작동합니다.
다음은 일반 코드입니다.
일반적으로 MQL 컴파일러가 내가 생각한 것만큼 똑똑하지 않다는 것을 유감스럽게 인정해야 합니다.)
손가락에서 빨려 나온 말도 안되는 소리가 아닌 대다수가 사용하는 실제의 최적화에 맞춰질 수 있다는 생각은 안 드셨나요?
글쎄, 주제가 소진되었습니다 ;-). 이 경우 최적화는 값이 반환 되는 코드 지점에서만 발생할 수 있으며 생성자에 작성된 내용에 의존하지 않습니다.
불과 2년 만에 복사 생성자가 도입되었습니다...
다음 라인은 RVO(반환 값 최적화) 및 NRVO(반환 값 최적화)를 기다리고 있습니다...
손가락에서 빨려 나온 말도 안되는 소리가 아닌 대다수가 사용하는 실제의 최적화에 맞춰질 수 있다는 생각은 안 드셨나요?