모든 배열의 데이터는 메모리에 선형으로 위치합니다. 첫 번째부터 마지막까지 요소 x[15]를 참조하는 동안 이 변수를 계산하기 위해 컴파일러는 배열의 시작 주소에 변수의 주소가 될 오프셋 15를 더한 값을 계산합니다. 2차원 배열(예: x[2][5])의 경우 먼저 두 번째 행에 대한 오프셋을 계산한 다음 다섯 번째 요소에 대한 오프셋을 추가해야 합니다. 즉, 두 배의 연산이 필요합니다.
x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)]
x[15] --> x(+15)
이것은 모두 컴파일러 수준이지만 정적 배열에 대한 ArrayRange(x[0]) 는 항상 변경되지 않고 지속적으로 계산할 필요가 없으며 한 번 계산하고 컴파일 단계에서 저장하면 충분합니다.
당신은 어셈블러에 있습니까? 왜 이러한 문제? 어셈블러에 종사하고 있다면 아아-러시아 문서, Pentium-I보다 오래된 프로세서에 대한 명령 파이프라인의 올바른 로드를 보지 못했고 프로세서의 올바른 로드는 컴파일러 개발자가 아니라 OS 및 프로세서 아키텍처 개발자
곱셈 연산이 더하기 연산보다 더 긴 프로세서 주기에서 수행될 것이 걱정된다면, 슬프게도 486번째 프로세서가 남아 있는 기차, 캐시 및 명령 파이프라인 로드는 산술 및 논리 연산을 수행하는 것보다 더 오래 걸립니다.
추신: 다시 한 번 호소합니다. 여기에서 기본 소스를 읽기 시작합니다. https://www.mql5.com/ru/docs/basis/types/classes mql5 개발자는 데이터 정렬을 올바르게 구성하는 방법을 설명합니다. 동일한 정보를 모두 사용할 수 있습니다. 컴파일러, Windows 시스템 기능 호출 등을 올바르게 사용하는 것과 같은 정보가 있습니다. - 나는 OS 및 프로세서의 현대적인 기능에 해당하는 러시아어 문서가 거의 없다는 사실에 이것을 쓰고 있습니다. 그렇지 않으면 정크(대학에서 가르치는 자료)가 이 단계의 현실과 일치하지 않습니다. OS 및 하드웨어 개발
컴파일 단계에서는 첫 번째 요소의 주소만 계산됩니다. 다른 모든 요소는 매번 다른 오프셋을 통해 카운팅 모드에서 카운팅됩니다.
2차원 배열을 사용하면 행 번호를 곱한 열과 행의 두 오프셋을 계산해야 하며 물론 계산 과정에서도 계산해야 합니다. 어셈블러와 컴파일러는 전혀 관련이 없으며, 이는 calc를 올바르게 사용하기 위한 메모리 주소 지정의 기본일 뿐입니다. 실제 자원.
여기에서 1차원 배열과 2차원 배열 사이에 상당한 성능 손실이 있더라도 개체와 같은 더 복잡한 경우에는 주소 지정 시간이 훨씬 더 느려진다는 것을 쉽게 이해할 수 있습니다.
일어나고 있는 일의 본질과 생산성 손실을 이해하는 데 성공
컴파일러를 최적화하고 자체 데이터 액세스 구조를 작성하는 데 문제가 없습니다.
추신: 개체는 복잡한 경우가 아닙니다. 링크를 생성하는 모든 조작은 모두 컴파일러 수준에서 이루어집니다. 아아, 프로세서는 개체인지 아닌지 상관하지 않습니다. 정렬된 데이터에 상대적인 오프셋을 계산하는 데 문제가 없습니다. "경이로운 프로그래머"는 메모리를 절약합니다. 데이터를 바이트 유형의 배열에 쓰지만 컴파일러에 대한 설명서를 살펴보지 않으면 이러한 코드의 효과는 이 프로그래머의 자기 만족된 생리학의 반영에서만 볼 수 있습니다. 거울이지만 사실은 가짜
모든 것이 컴파일러 수준에 있습니다. 아아, 프로세서는 그것이 객체인지 아닌지 상관하지 않습니다. 정렬된 데이터에 상대적인 오프셋을 계산하는 데 문제가 없습니다.
간단한 예제를 사용하는 것처럼 보이지만 컴파일이 아닌 프로그램 실행 과정에서 상대적인 1차원 배열의 2차원 배열이 얼마나 느려지는지 설명했습니다. 나는 나 자신을 반복할 이유가 없다고 본다. 이것은 어느 정도 최적의 계산 코드를 작성하는 작업에 자신을 크게 귀찮게 하지 않는다는 것을 보여줍니다. 아마도 필요하지 않을 수도 있습니다. 이 경우 OOP는 당신만을 위해 만들어집니다. :)
간단한 예제를 사용하는 것처럼 보이지만 컴파일이 아닌 프로그램 실행 과정에서 상대적인 1차원 배열의 2차원 배열이 얼마나 느려지는지 설명했습니다. 나는 나 자신을 반복할 이유가 없다고 본다. 이것은 어느 정도 최적의 계산 코드를 작성하는 작업에 자신을 귀찮게 하지 않는다는 것을 보여줍니다. 아마도 필요하지 않을 수도 있습니다. 이 경우 OOP는 당신만을 위해 만들어집니다. :)
최적의 코드는 무엇입니까? 컴파일러와 가상 머신이 어떻게 작동하는지 전혀 모릅니다.
프로그래머는 물리적 메모리 요소에 대한 액세스 및 주소 지정이 각 특정 컴파일러에서 어떻게 진행되고 있는지 파악할 필요가 없습니다. 프로그래머가 코드에 만족하지 않으면 코드를 최적화합니다.
- 코드 크기를 늘리고 데이터 크기를 줄임으로써 계산 속도를 잃음
- 코드의 데이터 크기를 늘리고 속도를 높입니다.
- 대안으로 다른 컴파일러를 사용합니다.
모든 옵션이 사라졌습니다!
OOP는 EFFECTIVE 코드를 작성하기 위한 또 다른 분기이며, OOP의 효율성은 프로그래머가 특정 아키텍처의 형태로 수학적 모델을 컴파일할 수 있다는 것입니다. 데이터에 대한 액세스 - 당신은 착각하고 있습니다. 그 미세한 추가 데이터 양 - 개체의 링크 테이블은 메모리의 물리적 데이터에 대한 액세스 시간을 결코 증가시키지 않으며 초과 데이터는 다기능에 의해 상쇄됩니다.
나는 충격을 받았습니다. 당신은 OOP를 다루기 시작했고, 다차원 및 1차원 배열에서 주소 지정에 대한 추론으로 전환했습니다. 이것을 어딘가에서 가르쳤습니까, 아니면 모두 추측과 환상입니까?
다차원 배열 작업은 오랫동안 하드웨어 수준에서 구현되었습니다. - 비디오 카드로 작업할 때 동일한 Z 버퍼, 오, 예, "양 하드웨어 개발자" - 그들은 귀하와 상의하지 않았고 알아내지 못했습니다. 당신과 상의하지 않고 다차원 배열을 다루는 것이 얼마나 효과적인지 - 그것이 전부입니다 프로그래머는 다차원 배열을 사용하는 것을 주저하지 말고 1차원 배열로 작업할 때 상상의 효율성을 위해 코드를 늘리는 행복을 추구하지 마십시오
최신(특히 64비트) 프로그램의 효율성은 주로 개발 환경과 컴파일러에 의해 결정됩니다. 최신 프로그램은 이미 중앙 프로세서의 성능과 코드의 효율성에 덜 의존하고 있습니다. 나는 이것이 왜 그런지 알고 싶어하는 모든 사람들에게 E. Tanenbaum의 기념비적인 작품 " Computer Architecture ", 특히 5장, "Intel IA-64" 섹션을 읽어보라고 추천합니다. 이전 컴파일러에서 절차 코드를 사용하는 트릭은 단순히 일반 개발 환경으로 전환하는 것과 비교하여 이러한 성능 향상을 제공하지 않습니다. 내가 말할 수있는 것은 동일한 어셈블러를 사용하는 것입니다. 예, 그것은 일입니다. 그는 분명히 영원히 살 것입니다. 그러나 멀티 코어 프로세서, 확장 명령어 세트 등과 같은 최신 하드웨어 리소스를 사용하여 일반 IA-64 코드보다 성능이 뛰어난 IA-386 코드를 어셈블러로 작성할 수 있을지는 매우 의심스럽습니다. 따라서 결론은 다음과 같아야 합니다. 동일 - 당신은 그 줄에 쓸 필요가 있습니다. 우리에게 .NET이 주어진다면 우리는 그것에 쓸 필요가 있습니다. 수천 명의 다른 프로그래머가 CIL 코드의 성능을 높이는 방법, 스레드를 병렬화하는 방법 등에 대해 생각하게 하십시오. MQL4와 마찬가지로 시간이 지나고 MQL5가 제공되었습니다. MetaQuotes가 지원합니다. 그들은 그들의 언어 능력을 향상시키는 방법에 대해 생각할 것입니다.
코드 최적화 를 위해서는 프로그래머가 수행되는 기본 연산(덧셈, 곱셈, 메모리 액세스, 주소 계산 등) 측면에서 특정 코드 조각이 얼마나 리소스 집약적인지 최소한의 이해가 필요합니다. 이것이 없으면 원칙적으로 최적화가 불가능하며 아무리 좋은 컴파일러라도 그런 불행한 프로그래머에게 무력할 수 없습니다. 당연한 일처럼 보이지만 이것이 많은 사람들에게 큰 뉴스가 될 수 있습니다. :)
가장 단순한 것을 모르기 때문에 착각하는 것입니다.
모든 배열의 데이터는 메모리에 선형으로 위치합니다. 첫 번째부터 마지막까지 요소 x[15]를 참조하는 동안 이 변수를 계산하기 위해 컴파일러는 배열의 시작 주소에 변수의 주소가 될 오프셋 15를 더한 값을 계산합니다. 2차원 배열(예: x[2][5])의 경우 먼저 두 번째 행에 대한 오프셋을 계산한 다음 다섯 번째 요소에 대한 오프셋을 추가해야 합니다. 즉, 두 배의 연산이 필요합니다.
x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)]
x[15] --> x(+15)
이것은 모두 컴파일러 수준이지만 정적 배열에 대한 ArrayRange(x[0]) 는 항상 변경되지 않고 지속적으로 계산할 필요가 없으며 한 번 계산하고 컴파일 단계에서 저장하면 충분합니다.
당신은 어셈블러에 있습니까? 왜 이러한 문제? 어셈블러에 종사하고 있다면 아아-러시아 문서, Pentium-I보다 오래된 프로세서에 대한 명령 파이프라인의 올바른 로드를 보지 못했고 프로세서의 올바른 로드는 컴파일러 개발자가 아니라 OS 및 프로세서 아키텍처 개발자
곱셈 연산이 더하기 연산보다 더 긴 프로세서 주기에서 수행될 것이 걱정된다면, 슬프게도 486번째 프로세서가 남아 있는 기차, 캐시 및 명령 파이프라인 로드는 산술 및 논리 연산을 수행하는 것보다 더 오래 걸립니다.
추신: 다시 한 번 호소합니다. 여기에서 기본 소스를 읽기 시작합니다. https://www.mql5.com/ru/docs/basis/types/classes mql5 개발자는 데이터 정렬을 올바르게 구성하는 방법을 설명합니다. 동일한 정보를 모두 사용할 수 있습니다. 컴파일러, Windows 시스템 기능 호출 등을 올바르게 사용하는 것과 같은 정보가 있습니다. - 나는 OS 및 프로세서의 현대적인 기능에 해당하는 러시아어 문서가 거의 없다는 사실에 이것을 쓰고 있습니다. 그렇지 않으면 정크(대학에서 가르치는 자료)가 이 단계의 현실과 일치하지 않습니다. OS 및 하드웨어 개발
x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)]
x[15] --> x(+15)
이것은 모두 컴파일러 수준이지만 정적 배열의 ArrayRange(x[0]) 는 항상 변경되지 않고 지속적으로 계산할 필요가 없으며 한 번 계산하고 컴파일 단계에서 저장하면 충분합니다.
컴파일 단계에서는 첫 번째 요소의 주소만 계산됩니다. 다른 모든 요소는 매번 다른 오프셋을 통해 카운팅 모드에서 카운팅됩니다.
2차원 배열을 사용하면 행 번호를 곱한 열과 행의 두 오프셋을 계산해야 하며 물론 계산 과정에서도 계산해야 합니다. 어셈블러와 컴파일러는 전혀 관련이 없으며, 이는 calc를 올바르게 사용하기 위한 메모리 주소 지정의 기본일 뿐입니다. 실제 자원.
여기에서 1차원 배열과 2차원 배열 사이에 상당한 성능 손실이 있더라도 개체와 같은 더 복잡한 경우에는 주소 지정 시간이 훨씬 더 느려진다는 것을 쉽게 이해할 수 있습니다.
컴파일 단계에서는 첫 번째 요소의 주소만 계산됩니다. 다른 모든 요소는 매번 다른 오프셋을 통해 카운팅 모드에서 카운팅됩니다.
2차원 배열을 사용하면 행 번호를 곱한 열과 행의 두 오프셋을 계산해야 하며 물론 계산 과정에서도 계산해야 합니다. 어셈블러와 컴파일러는 전혀 관련이 없으며, 이는 calc를 올바르게 사용하기 위한 메모리 주소 지정의 기본일 뿐입니다. 실제 자원.
여기에서 1차원 배열과 2차원 배열 사이에 상당한 성능 손실이 있더라도 개체와 같은 더 복잡한 경우에는 주소 지정 시간이 훨씬 더 느려진다는 것을 쉽게 이해할 수 있습니다.
일어나고 있는 일의 본질과 생산성 손실을 이해하는 데 성공
컴파일러를 최적화하고 자체 데이터 액세스 구조를 작성하는 데 문제가 없습니다.
추신: 개체는 복잡한 경우가 아닙니다. 링크를 생성하는 모든 조작은 모두 컴파일러 수준에서 이루어집니다. 아아, 프로세서는 개체인지 아닌지 상관하지 않습니다. 정렬된 데이터에 상대적인 오프셋을 계산하는 데 문제가 없습니다. "경이로운 프로그래머"는 메모리를 절약합니다. 데이터를 바이트 유형의 배열에 쓰지만 컴파일러에 대한 설명서를 살펴보지 않으면 이러한 코드의 효과는 이 프로그래머의 자기 만족된 생리학의 반영에서만 볼 수 있습니다. 거울이지만 사실은 가짜
모든 것이 컴파일러 수준에 있습니다. 아아, 프로세서는 그것이 객체인지 아닌지 상관하지 않습니다. 정렬된 데이터에 상대적인 오프셋을 계산하는 데 문제가 없습니다.
간단한 예제를 사용하는 것처럼 보이지만 컴파일이 아닌 프로그램 실행 과정에서 상대적인 1차원 배열의 2차원 배열이 얼마나 느려지는지 설명했습니다. 나는 나 자신을 반복할 이유가 없다고 본다. 이것은 어느 정도 최적의 계산 코드를 작성하는 작업에 자신을 크게 귀찮게 하지 않는다는 것을 보여줍니다. 아마도 필요하지 않을 수도 있습니다. 이 경우 OOP는 당신만을 위해 만들어집니다. :)
당신은 아메바의 관점에서 생각합니다 :) .
"우리 는 작은 효율성, 예를 들어 97%의 경우를 잊어야 합니다. 너무 이른 최적화는 모든 악의 근원입니다. 그러나 중요한 3%에서 기회를 놓치지 않아야 합니다." (c) Donald Knuth
나는 이미 이 포럼에서 네 번째로 인용하고 있습니다.
간단한 예제를 사용하는 것처럼 보이지만 컴파일이 아닌 프로그램 실행 과정에서 상대적인 1차원 배열의 2차원 배열이 얼마나 느려지는지 설명했습니다. 나는 나 자신을 반복할 이유가 없다고 본다. 이것은 어느 정도 최적의 계산 코드를 작성하는 작업에 자신을 귀찮게 하지 않는다는 것을 보여줍니다. 아마도 필요하지 않을 수도 있습니다. 이 경우 OOP는 당신만을 위해 만들어집니다. :)
최적의 코드는 무엇입니까? 컴파일러와 가상 머신이 어떻게 작동하는지 전혀 모릅니다.
프로그래머는 물리적 메모리 요소에 대한 액세스 및 주소 지정이 각 특정 컴파일러에서 어떻게 진행되고 있는지 파악할 필요가 없습니다. 프로그래머가 코드에 만족하지 않으면 코드를 최적화합니다.
- 코드 크기를 늘리고 데이터 크기를 줄임으로써 계산 속도를 잃음
- 코드의 데이터 크기를 늘리고 속도를 높입니다.
- 대안으로 다른 컴파일러를 사용합니다.
모든 옵션이 사라졌습니다!
OOP는 EFFECTIVE 코드를 작성하기 위한 또 다른 분기이며, OOP의 효율성은 프로그래머가 특정 아키텍처의 형태로 수학적 모델을 컴파일할 수 있다는 것입니다. 데이터에 대한 액세스 - 당신은 착각하고 있습니다. 그 미세한 추가 데이터 양 - 개체의 링크 테이블은 메모리의 물리적 데이터에 대한 액세스 시간을 결코 증가시키지 않으며 초과 데이터는 다기능에 의해 상쇄됩니다.
나는 충격을 받았습니다. 당신은 OOP를 다루기 시작했고, 다차원 및 1차원 배열에서 주소 지정에 대한 추론으로 전환했습니다. 이것을 어딘가에서 가르쳤습니까, 아니면 모두 추측과 환상입니까?
다차원 배열 작업은 오랫동안 하드웨어 수준에서 구현되었습니다. - 비디오 카드로 작업할 때 동일한 Z 버퍼, 오, 예, "양 하드웨어 개발자" - 그들은 귀하와 상의하지 않았고 알아내지 못했습니다. 당신과 상의하지 않고 다차원 배열을 다루는 것이 얼마나 효과적인지 - 그것이 전부입니다 프로그래머는 다차원 배열을 사용하는 것을 주저하지 말고 1차원 배열로 작업할 때 상상의 효율성을 위해 코드를 늘리는 행복을 추구하지 마십시오
그러나 정보의 신뢰성은 정보를 제공하는 사람에 달려 있습니까? 정보는 주관적인 것이 아니라 객관적인 것임을 제정신인 사람이라면 이해해야 할 것 같습니다. :)
프로그래머가 코드에 만족하지 않으면 코드를 최적화합니다.
- 코드 크기를 늘리고 데이터 크기를 줄임으로써 계산 속도를 잃음
- 코드의 데이터 크기를 늘리고 속도를 높입니다.
- 대안으로 다른 컴파일러를 사용합니다.
모든 옵션이 사라졌습니다!
코드 최적화 를 위해서는 프로그래머가 수행되는 기본 연산(덧셈, 곱셈, 메모리 액세스, 주소 계산 등) 측면에서 특정 코드 조각이 얼마나 리소스 집약적인지 최소한의 이해가 필요합니다. 이것이 없으면 원칙적으로 최적화가 불가능하며 아무리 좋은 컴파일러라도 그런 불행한 프로그래머에게 무력할 수 없습니다. 당연한 일처럼 보이지만 이것이 많은 사람들에게 큰 뉴스가 될 수 있습니다. :)
그리고 문제를 이해하기 시작하는 사람은 정보와 그 양은 객관적인 것이 아니라 주관적인 것임을 이해할 것입니다. :))
글쎄, 당신은 폭발 혼합물로 다른 것들을 혼동하고 혼합해야합니다. :)
하나는 객관적인 정보의 출처이고, 다른 하나는 모든 정보를 항상 인식할 수는 없고 일부만 인식할 수 있기 때문에 주관적인 수신자입니다.