음, 여기에 표시된 예(사례 1: 반환 값1, 사례 2: 반환 값2, 사례 3: 반환 값3... 등)는 일반적으로 어리석음의 샘플입니다. 적절한 사람은 모든 값을 배열에 넣고 단순히 인덱스로 원하는 값을 얻습니다. 역 문제의 경우 이진 검색을 사용하십시오.
배열이 있는 아름다운 코드를 위해 두 손으로. 그러나 표준 것보다 더 빠른 NormalizeDouble 을 작성할 때 나는 옵티마이저 효과를 만났습니다. const 배열을 통한 아름다운 솔루션은 스위치 케이스를 통한 성가신 솔루션보다 눈에 띄게 느렸습니다. 테스터에서 NormalizeDouble을 많이 사용하기 때문에 두 번째 옵션을 남겼습니다. 나는 그것을 inkludnik에 넣고이 괴물을 보지 않습니다. 그러나 백테스트는 더 빠르게 실행됩니다.
fxsaber : 배열이 있는 아름다운 코드를 위해 두 손으로. 그러나 표준 것보다 더 빠른 NormalizeDouble을 작성할 때 나는 옵티마이저 효과를 만났습니다. const 배열을 통한 아름다운 솔루션은 스위치 케이스를 통한 성가신 솔루션보다 눈에 띄게 느렸습니다. 테스터에서 NormalizeDouble을 많이 사용하기 때문에 두 번째 옵션을 남겼습니다. 나는 그것을 inkludnik에 넣고이 괴물을 보지 않습니다. 그러나 백테스트는 더 빠르게 실행됩니다.
스위치가 개선된 것 같습니다. 개발자가 바이너리 검색 형태의 구현에 대해서만 이야기한 토론이 있었던 한 번만 기억합니다. 이것은 계산된 인덱스로 액세스하는 것보다 당연히 훨씬 느립니다. 그러나 이제는 분명히 현명하게 수행했습니다. 단계가 일정하면 인덱스 계산, 그렇지 않으면 이진 검색입니다. 물론 네이티브 구현은 래퍼 구현보다 항상 빠릅니다.
물론 여기에서는 우선 순위를 기반으로 구축하는 것이 이미 필요합니다. 그러나 IMHO, 속도가 너무 중요하여 목발을 발명할 준비가 되었다면 일반적으로 OOP 및 MQL을 포기해야 합니다.) 올바른 코드 구성을 사용하면 이러한 속도 차이가 그렇게 크지 않을 것이라고 확신합니다. . 테스트 측정에서 루프에서 수백만 번 어리석게 함수를 실행합니다. 그리고 실제 코드에서는 더 합리적으로 사용하지 않습니까?
스위치가 개선된 것 같습니다. 개발자가 이진 검색 형태의 구현에 대해서만 이야기한 토론이 있는 스레드가 있었던 것을 기억합니다. 이것은 계산된 인덱스로 액세스하는 것보다 당연히 훨씬 느립니다. 그러나 이제는 분명히 현명하게 수행했습니다. 단계가 일정하면 인덱스 계산, 그렇지 않으면 이진 검색입니다. 물론 네이티브 구현은 래퍼 구현보다 항상 빠릅니다.
컴파일러는 바보가 아니라면 배열을 구성하고 인덱스에 의한 유일한 일반적인 액세스를 스위치 코드로 전환해야 합니다.
물론 여기에서는 우선 순위를 기반으로 구축하는 것이 이미 필요합니다. 그러나 IMHO, 속도가 너무 중요하여 목발을 발명할 준비가 되었다면 일반적으로 OOP 및 MQL을 포기해야 합니다.) 올바른 코드 구성으로 속도의 차이가 그렇게 크지 않을 것이라고 확신하지만 . 테스트 측정에서 루프에서 수백만 번 어리석게 함수를 실행합니다. 그리고 실제 코드에서는 더 합리적으로 사용하지 않습니까?
속도는 중요하지 않은데 비합리적으로 글을 쓸 때 강한 불편함을 느낀다. 물론 OOP를 전혀 사용 하지 않는 것은 합리적이지 않습니다. 요컨대, 내가 게시한 코드베이스의 겸손한 시도를보고 수표에 거짓말을했는데 벌써 몇 일인지 셀 수 없습니다. 거기에서 동일한 NormalizeDouble 형태의 목발이 어디에서 왔는지 이해할 수 있습니다. 이것은 때때로 개발자의 비합리적인 구현에서 무작위 사실의 결과입니다.
fxsaber : 컴파일러는 바보가 아니라면 배열을 구성하고 인덱스에 의한 유일한 일반적인 액세스를 스위치 코드로 전환해야 합니다.
그래서 배열은 단지 const입니까? 정적은 어떻습니까? 그렇다면 정말 같아야합니다. 예, 그리고 왜 "스위치 코드"인지, 여기에서 결국 가장 간단한 작업: 인덱스 값을 배열/열거의 크기 와 비교하고, 작으면 원하는 요소의 주소를 해당 요소의 주소로 얻습니다. 배열 + 인덱스, 음, 거기에서 값을 읽습니다. 그런 넌센스도 같은 방식으로 컴파일되어야 한다고 생각했습니다.
요컨대, 내가 게시한 코드베이스의 겸손한 시도를보고 수표에 거짓말을했는데 벌써 몇 일인지 셀 수 없습니다. 거기에서 동일한 NormalizeDouble 형태의 목발이 어디에서 왔는지 이해할 수 있습니다. 이것은 때때로 개발자의 비합리적인 구현에서 무작위 사실의 결과입니다.
어떤 종류의 "끌어당김"을 의미하는지 명확하지 않습니다. 그런데 이 비교를 얼마나 오랫동안 하고 계셨습니까? 아마도 컴파일러는 여전히 "바보"였습니까?
그래서 배열은 단지 const입니까? 정적은 어떻습니까? 그렇다면 정말 같아야합니다. 예, 그리고 "스위치 코드"인 이유는 다음과 같습니다. 가장 간단한 작업은 다음과 같습니다. 인덱스 값을 배열/열거의 크기와 비교하고, 작으면 원하는 요소의 주소를 배열 + 인덱스의 주소로 얻습니다. , 글쎄, 우리는 거기에서 값을 읽습니다. 그런 넌센스도 같은 방식으로 컴파일해야 한다고 생각했습니다.
정적 배열을 const로 만드는 것이 가능한지 정확히 기억나지 않습니다. 방법 - 확실히 아닙니다. 기본적으로 정적이 아닌 정확히 const를 수행했습니다. 컴파일러의 마음을 기반으로 합니다. 컴파일 후 곱창에 배열의 힌트가 전혀 없어야 합니다. static은 const보다 훨씬 복잡한 구성입니다. 따라서 컴파일러가 정적에 대처할 수 없다고 확신했습니다. 하지만 시도해야 합니다.
어떤 종류의 "끌어당김"을 의미하는지 명확하지 않습니다. 그건 그렇고, 당신은 얼마나 오래 이러한 비교를 하고 있습니까? 아마도 컴파일러는 여전히 "바보"였습니까?
중재자 중 한 명이 몇 개의 버튼을 누르고 코드 기반에 코드를 게시하기 위해 계속 진행하므로 시도가 표시됩니다. 성능은 생각하지 않고 스스로 편리한 솔루션을 만들었지만 결과는 빌드 1383 32비트에서 거의 10배의 이득이었습니다.
정적 배열을 const로 만드는 것이 가능한지 정확히 기억나지 않습니다. 방법 - 확실히 아닙니다. 기본적으로 정적이 아닌 정확히 const를 수행했습니다. 컴파일러의 마음을 기반으로 합니다. 컴파일 후 곱창에 배열의 힌트가 전혀 없어야 합니다. static은 const보다 훨씬 복잡한 구성입니다. 따라서 컴파일러가 정적에 대처할 수 없다고 확신했습니다. 하지만 시도해야 합니다.
아, 그럼 모든 것이 명확해집니다. 컴파일러의 과도한 지능에 의존해서는 안 됩니다. 컴파일러는 잘못 설계된 솔루션을 다시 최적화할 것이라고 말합니다. 자신이 너무 게으르거나 제대로 할 생각을 하지 않았다면 "정적 작업이 훨씬 더 복잡합니다"라고 말합니다(비록 무엇이 복잡한지 명확하지 않지만). 그러면 그 뒤에 컴파일러를 탓할 이유가 무엇입니까?
아, 그럼 모든 것이 명확해집니다. 컴파일러의 과도한 지능에 의존해서는 안 됩니다. 컴파일러는 잘못 설계된 솔루션을 다시 최적화할 것이라고 말합니다. 자신이 너무 게으르거나 제대로 할 생각을 하지 않았다면 "정적 작업이 훨씬 더 복잡합니다"라고 말합니다(비록 무엇이 복잡한지 명확하지 않지만). 그러면 그 뒤에 컴파일러를 탓할 이유가 무엇입니까?
정적 배열에 추가되었습니다. 스위치보다 거의 3배 빠르게 작동하기 시작했습니다! 쓰레기통에서 그런 스위치 . 팁 고마워!
음, 여기에 표시된 예(사례 1: 반환 값1, 사례 2: 반환 값2, 사례 3: 반환 값3... 등)는 일반적으로 어리석음의 샘플입니다. 적절한 사람은 모든 값을 배열에 넣고 단순히 인덱스로 원하는 값을 얻습니다. 역 문제의 경우 이진 검색을 사용하십시오.
배열이 있는 아름다운 코드를 위해 두 손으로. 그러나 표준 것보다 더 빠른 NormalizeDouble을 작성할 때 나는 옵티마이저 효과를 만났습니다. const 배열을 통한 아름다운 솔루션은 스위치 케이스를 통한 성가신 솔루션보다 눈에 띄게 느렸습니다. 테스터에서 NormalizeDouble을 많이 사용하기 때문에 두 번째 옵션을 남겼습니다. 나는 그것을 inkludnik에 넣고이 괴물을 보지 않습니다. 그러나 백테스트는 더 빠르게 실행됩니다.
스위치가 개선된 것 같습니다. 개발자가 바이너리 검색 형태의 구현에 대해서만 이야기한 토론이 있었던 한 번만 기억합니다. 이것은 계산된 인덱스로 액세스하는 것보다 당연히 훨씬 느립니다. 그러나 이제는 분명히 현명하게 수행했습니다. 단계가 일정하면 인덱스 계산, 그렇지 않으면 이진 검색입니다. 물론 네이티브 구현은 래퍼 구현보다 항상 빠릅니다.
물론 여기에서는 우선 순위를 기반으로 구축하는 것이 이미 필요합니다. 그러나 IMHO, 속도가 너무 중요하여 목발을 발명할 준비가 되었다면 일반적으로 OOP 및 MQL을 포기해야 합니다.) 올바른 코드 구성을 사용하면 이러한 속도 차이가 그렇게 크지 않을 것이라고 확신합니다. . 테스트 측정에서 루프에서 수백만 번 어리석게 함수를 실행합니다. 그리고 실제 코드에서는 더 합리적으로 사용하지 않습니까?
스위치가 개선된 것 같습니다. 개발자가 이진 검색 형태의 구현에 대해서만 이야기한 토론이 있는 스레드가 있었던 것을 기억합니다. 이것은 계산된 인덱스로 액세스하는 것보다 당연히 훨씬 느립니다. 그러나 이제는 분명히 현명하게 수행했습니다. 단계가 일정하면 인덱스 계산, 그렇지 않으면 이진 검색입니다. 물론 네이티브 구현은 래퍼 구현보다 항상 빠릅니다.
컴파일러는 바보가 아니라면 배열을 구성하고 인덱스에 의한 유일한 일반적인 액세스를 스위치 코드로 전환해야 합니다.
물론 여기에서는 우선 순위를 기반으로 구축하는 것이 이미 필요합니다. 그러나 IMHO, 속도가 너무 중요하여 목발을 발명할 준비가 되었다면 일반적으로 OOP 및 MQL을 포기해야 합니다.) 올바른 코드 구성으로 속도의 차이가 그렇게 크지 않을 것이라고 확신하지만 . 테스트 측정에서 루프에서 수백만 번 어리석게 함수를 실행합니다. 그리고 실제 코드에서는 더 합리적으로 사용하지 않습니까?
컴파일러는 바보가 아니라면 배열을 구성하고 인덱스에 의한 유일한 일반적인 액세스를 스위치 코드로 전환해야 합니다.
그래서 배열은 단지 const입니까? 정적은 어떻습니까? 그렇다면 정말 같아야합니다. 예, 그리고 왜 "스위치 코드"인지, 여기에서 결국 가장 간단한 작업: 인덱스 값을 배열/열거의 크기 와 비교하고, 작으면 원하는 요소의 주소를 해당 요소의 주소로 얻습니다. 배열 + 인덱스, 음, 거기에서 값을 읽습니다. 그런 넌센스도 같은 방식으로 컴파일되어야 한다고 생각했습니다.
그래서 배열은 단지 const입니까? 정적은 어떻습니까? 그렇다면 정말 같아야합니다. 예, 그리고 "스위치 코드"인 이유는 다음과 같습니다. 가장 간단한 작업은 다음과 같습니다. 인덱스 값을 배열/열거의 크기와 비교하고, 작으면 원하는 요소의 주소를 배열 + 인덱스의 주소로 얻습니다. , 글쎄, 우리는 거기에서 값을 읽습니다. 그런 넌센스도 같은 방식으로 컴파일해야 한다고 생각했습니다.
정적 배열을 const로 만드는 것이 가능한지 정확히 기억나지 않습니다. 방법 - 확실히 아닙니다. 기본적으로 정적이 아닌 정확히 const를 수행했습니다. 컴파일러의 마음을 기반으로 합니다. 컴파일 후 곱창에 배열의 힌트가 전혀 없어야 합니다. static은 const보다 훨씬 복잡한 구성입니다. 따라서 컴파일러가 정적에 대처할 수 없다고 확신했습니다. 하지만 시도해야 합니다.
정적 배열을 const로 만드는 것이 가능한지 정확히 기억나지 않습니다. 방법 - 확실히 아닙니다. 기본적으로 정적이 아닌 정확히 const를 수행했습니다. 컴파일러의 마음을 기반으로 합니다. 컴파일 후 곱창에 배열의 힌트가 전혀 없어야 합니다. static은 const보다 훨씬 복잡한 구성입니다. 따라서 컴파일러가 정적에 대처할 수 없다고 확신했습니다. 하지만 시도해야 합니다.
아, 그럼 모든 것이 명확해집니다. 컴파일러의 과도한 지능에 의존해서는 안 됩니다. 컴파일러는 잘못 설계된 솔루션을 다시 최적화할 것이라고 말합니다. 자신이 너무 게으르거나 제대로 할 생각을 하지 않았다면 "정적 작업이 훨씬 더 복잡합니다"라고 말합니다(비록 무엇이 복잡한지 명확하지 않지만). 그러면 그 뒤에 컴파일러를 탓할 이유가 무엇입니까?
아, 그럼 모든 것이 명확해집니다. 컴파일러의 과도한 지능에 의존해서는 안 됩니다. 컴파일러는 잘못 설계된 솔루션을 다시 최적화할 것이라고 말합니다. 자신이 너무 게으르거나 제대로 할 생각을 하지 않았다면 "정적 작업이 훨씬 더 복잡합니다"라고 말합니다(비록 무엇이 복잡한지 명확하지 않지만). 그러면 그 뒤에 컴파일러를 탓할 이유가 무엇입니까?
천만에요. 목발을 발명하기 위해 달리기 전에 7 번 생각해야 할 미래에 대한 교훈이 있습니다)
이제 내가 스위치를 일찍 칭찬했거나 오히려 개발자를 칭찬했다는 것이 밝혀졌습니다. 따라서 열거형에 여러 단계가 있는 경우에도 이진 검색 을 통해서만 모든 것이 구현됩니다. 안좋다.
천만에요. 목발을 발명하기 위해 달리기 전에 7 번 생각해야 할 미래에 대한 교훈이 있습니다)