코드 최적화를 위해서는 프로그래머가 수행되는 기본 연산(덧셈, 곱셈, 메모리 액세스, 주소 계산 등) 측면에서 특정 코드 조각이 얼마나 리소스 집약적인지 최소한의 이해가 필요합니다. 이것이 없으면 원칙적으로 최적화가 불가능하며 아무리 좋은 컴파일러라도 그런 불행한 프로그래머에게 무력할 수 없습니다. 당연한 일처럼 보이지만 이것이 많은 사람들에게 큰 뉴스가 될 수 있습니다. :)
나는 그것을 감당할 수 없지만, 나는 정말로 당신의 방향으로 나를 강하게 표현하고 싶지만, 오 글쎄, 우리는 당신의 어리석음과 완고함의 예를 사용하면 많은 사람들이 맑아 질 것이라고 가정 할 것입니다.
당신은 간단한 주소 지정의 명백한 효과, 내가 제시한 예제 및 효율적인 코드 작성의 기초에 사로잡혀 있습니다. 당신은 읽고 이해할 수 없습니다. 2x2 영역에서 살펴보겠습니다.
작업이 있지만 까다로운 작업)) - 인생의 트릭 - 고객은 항상 그렇듯이 작업 과정에서 보편성을 획득하는 최소한의 코드를 요구합니다. - 아래 목록의 항목 수:
- "논리"를 사용하여 - 배열 X[4] 및 Y[4]와 X[4] * Y[4]를 곱하는 함수 및 물론 변환하는 함수로 구성된 엄청나게 빠른 코드를 작성합니다. 2차원 배열 형태의 어리석은 입력/출력 데이터를 올바른 데이터 - 1차원 배열로 만들고, 1차원 행렬에 대해 등가 변환을 작성하여 행렬 대수학을 공부합니다.
- 첫 번째 프로그래머는 자신의 기능에 보편성을 추가하기 시작합니다. 여러분은 상상조차 할 수 없는 일을 하게 됩니다(1차원 배열로 변환된 2차원 행렬의 곱을 연필로 확인하는 것은 어려울 것입니다). 그리고 마지막으로 기본 클래스를 설정하고 행렬 곱셈 방법을 작성하는 OOP를 가진 프로그래머가 나타납니다.
- 네 번째 작업으로 무엇을 할 것인지 상상조차 하고 싶지 않습니다. 왜냐하면 이 "새로운 밝은 아이디어를 가진 교활한 고객"은 이미 수평선에 어렴풋이 나타나고 있습니다. OOP 프로그래머는 단순히 역행렬을 찾는 방법을 추가하고 나중에 증기 목욕을하지 않도록 모든 행렬을 추가했습니다. 작업을 수행하고 나머지 프로그래머는 증기 목욕을하지 않도록 흩어졌습니다.
코드가 일반 프로그래밍, OOP 및 "밝은 아이디어"로 어떻게 바뀔지 깨닫는 경우(귀하의 코드는 두 번째 작업에서 이미 대량의 눈사태처럼 성장할 것이며 효율성에 대한 의문의 여지가 없습니다) - 효과적으로 프로그래밍하는 것이 무엇인지 이해하게 될 것입니다. 오, 예, 완전히 잊었습니다. 행렬 작업의 오류도 제어해야 합니다. 조금 더 작업해야 합니다.)))))))))))))) )
당신이 논하고자 하는 것 - 전 세계에서 수년간의 프로그래머 경험이 이미 지나갔고, 어떤 Bill Gates도 OOP 프로그래밍이 효과적이지 않다면 강제할 수 없다고 믿으며, 모든 것은 프로젝트의 개발 전망에 달려 있습니다 - 만약 프로젝트 확장 - OOP가 없으면 시간이 손실되고 유연성과 보편성 없이 광범위한 코드가 작성됩니다.
하나는 객관적인 정보의 출처이고, 다른 하나는 모든 정보를 항상 인식할 수는 없고 일부만 인식할 수 있기 때문에 주관적인 수신자입니다.
이 같은 아무것도. 정보는 특정 소스 및 대상에 적용될 때만 의미가 있습니다. 우리에게 "절대적인" 정보는 있을 수 없습니다. 그것을 만지거나 측정한 우리는 즉시 주관적인 수용자가 된다. 어떤 출처에서 객관적인 정보의 존재를 증명하거나 반증하는 것은 근본적으로 불가능합니다. 그것은 신의 존재/부재에 대해 논쟁하는 것과 같습니다.
- "논리"를 사용하여 - 배열 X[4] 및 Y[4]와 X[4] * Y[4]를 곱하는 함수 및 물론 변환하는 함수로 구성된 엄청나게 빠른 코드를 작성합니다. 2차원 배열 형태의 어리석은 입력/출력 데이터를 올바른 데이터 - 1차원 배열로 만들고, 1차원 행렬에 대해 등가 변환을 작성하여 행렬 대수학을 공부합니다.
불행히도, 당신은 여전히 내가 당신에게 전달하려고 했던 간단한 것을 이해하지 못했지만, 배관공(예를 들어)이 갑자기 일시적으로 프로그래머로 재교육하기로 결정했다면 그는 여전히 배관공으로 남아 다음과 같이 생각하기 때문에 소용없다는 것을 알았습니다. 배관공은 현장에 놓인 파이프의 길이가 가장 중요합니다. :)
프로그램의 최적성의 기준은 코드의 길이가 아니라 특정 작업에 대한 연산의 수입니다. 2차원 행렬만 곱해야 하고 훨씬 더 일반적이고 불필요한 경우를 구현해야 한다면 아무도 그런 아마추어 성능에 감사하지 않을 것입니다.
Andrei01 : 정보를 받는 사람은 항상 주관적이지만 모든 정보를 왜곡 없이 인식하면 무한한 정확도로 객관성에 접근할 수 있습니다.
수신기의 주관성은 소스에서 오는 것을 부정확하게 받아들이는 것이 아니라 이 들어오는 스트림을 다른 방식으로 해석할 수 있다는 것입니다. 동일한 비트스트림이 완전히 다른 정보일 수 있습니다.
Andrei01 , 죄송합니다만 왜 여기에 글을 쓰는지 이해가 되지 않습니다. rorobating, 또는 무엇을 위해? 귀하의 게시물은 이 스레드에 대한 유용한 신호를 포함하지 않는 일종의 홍수 소음으로 인식됩니다. 나가는 스트림을 필터링하십시오: 로봇이 아닌 사람들이 계속 읽습니다...
1. 수신기의 주관성은 소스에서 오는 것을 부정확하게 받아들이는 것이 아니라 이 들어오는 스트림을 다르게 해석할 수 있다는 것입니다. 동일한 비트 스트림이 완전히 다른 정보일 수 있습니다.
Andrei01 , 죄송합니다만 왜 여기에 글을 쓰는지 이해가 되지 않습니다. rorobating, 또는 무엇을 위해? 귀하의 게시물은 이 스레드에 대한 유용한 신호를 포함하지 않는 일종의 홍수 소음으로 인식됩니다. 나가는 스트림을 필터링하세요. 사람은 여전히 읽고 있고 로봇은 읽지 않습니다...
1. 수신자가 이유에 따라 정보를 다르게 해석한다는 사실은 그가 주관적이라고 말할 뿐입니다.
2. 수학, 불행히도 나는 이 구절의 의미를 파악하지 못했습니다. 노이즈를 너무 많이 추가했습니다. :) 그건 그렇고, 이것은 정보 소스가 범람 할 수 있다는 사실의 예입니다. 즉, 의도적으로 의미없는 정보를 의도적으로 생성합니다. :)
Andrei01 : 1. 수신자가 이유에 따라 정보를 다르게 해석한다는 사실은 그가 주관적이라고 말할 뿐입니다.
다시 그렇지 않습니다. 들어오는 스트림의 해석은 수신기 위에 서서 게임의 조건을 설정하는 사람의 작업입니다. 수신기는 철이며 Game Master가 설정한 알고리즘에 따라 정보를 연마합니다. 그런 의미에서 그것은 완전하고 엄밀한 객관입니다. 왜냐하면 그것은 멍청한 철 조각이기 때문입니다. 그리고 마스터는 주관적입니다.
해결되는 문제의 맥락에 따라 정보를 다양한 방식으로 정의할 수 있다는 사실을 알고 계십니까?
당신은 아메바의 관점에서 생각합니다 :) .
"우리 는 작은 효율성, 예를 들어 97%의 경우를 잊어야 합니다. 너무 이른 최적화는 모든 악의 근원입니다. 그러나 중요한 3%에서 기회를 놓치지 않아야 합니다." (c) Donald Knuth
나는 이미 이 포럼에서 네 번째로 인용 하고 있습니다.
마음을 많이 인용하고 복사하여 붙일 필요가 없으며 원숭이에게 이것을 가르치려고 할 수도 있습니다. :)
그러나 당신의 생각을 의미 있게 설명하는 것은 더 어렵고 이미 호모 사피엔스 수준을 주장하고 있습니다.
글쎄, 의미있는 방식으로 자신의 생각을 표현하려고합니까, 아니면 여전히 개발 수준이 동일하지 않습니까? :)
몇 년 동안 나는 다중 통화 전략 테스터를 구현한다는 아이디어에 주기적으로 괴로워했습니다.
몇 가지 구현을 보았고 아이디어를 읽었으며 MT5도 보았습니다.
이미 단말기에 다중통화가 존재하는 MT5가 있다면 많은 이유가 있을 것이므로 많은 사람들이 즉시 설명하려고 합니다.
오류 없이 자신만의 다중 통화 전략 테스터를 작성하는 것은 매우 어려운 작업이며 거의 완료되지 않습니다.
64비트 버전에서 MetaTrader 5를 다시 시도하는 것이 좋습니다.
- 다중 통화 및 세부 거래 전략 테스터
- 스프레드 기록을 포함한 모든 분 기록 데이터가 준비되었습니다.
- 64비트 버전의 MetaTrader 5 를 사용하면 엄청난 양의 데이터 작업이 가능합니다(8/12/16Gb 메모리면 충분합니다).
- MQL5 코드의 속도는 MQL4보다 몇 배 빠름(SSE2를 적극적으로 사용하여 네이티브 코드로 컴파일)
- 객체 지향 MQL5 를 사용하면 훨씬 더 복잡한 Expert Advisors를 작성할 수 있습니다.
- 분산 테스터를 사용하면 테스트를 위해 많은 원격 에이전트 를 사용할 수 있습니다.
개발자가 적극적으로 개발하고 지원 하는 전체 보기에서 반복적으로 입증된 도구를 사용하는 것이 좋습니다.코드 최적화를 위해서는 프로그래머가 수행되는 기본 연산(덧셈, 곱셈, 메모리 액세스, 주소 계산 등) 측면에서 특정 코드 조각이 얼마나 리소스 집약적인지 최소한의 이해가 필요합니다. 이것이 없으면 원칙적으로 최적화가 불가능하며 아무리 좋은 컴파일러라도 그런 불행한 프로그래머에게 무력할 수 없습니다. 당연한 일처럼 보이지만 이것이 많은 사람들에게 큰 뉴스가 될 수 있습니다. :)
나는 그것을 감당할 수 없지만, 나는 정말로 당신의 방향으로 나를 강하게 표현하고 싶지만, 오 글쎄, 우리는 당신의 어리석음과 완고함의 예를 사용하면 많은 사람들이 맑아 질 것이라고 가정 할 것입니다.
당신은 간단한 주소 지정의 명백한 효과, 내가 제시한 예제 및 효율적인 코드 작성의 기초에 사로잡혀 있습니다. 당신은 읽고 이해할 수 없습니다. 2x2 영역에서 살펴보겠습니다.
작업이 있지만 까다로운 작업)) - 인생의 트릭 - 고객은 항상 그렇듯이 작업 과정에서 보편성을 획득하는 최소한의 코드를 요구합니다. - 아래 목록의 항목 수:
1. 2차원 행렬 2개를 곱하는 함수 작성
2. 3차원 행렬을 곱하는 함수 작성
3. 범용 기능인 X * Y를 사용할 수 있습니까?
4. 역행렬을 찾을 수 있습니까?
- 일반 프로그래머는 배열 X[2] [2] * Y[2][2]를 곱하는 함수를 작성합니다.
- "논리"를 사용하여 - 배열 X[4] 및 Y[4]와 X[4] * Y[4]를 곱하는 함수 및 물론 변환하는 함수로 구성된 엄청나게 빠른 코드를 작성합니다. 2차원 배열 형태의 어리석은 입력/출력 데이터를 올바른 데이터 - 1차원 배열로 만들고, 1차원 행렬에 대해 등가 변환을 작성하여 행렬 대수학을 공부합니다.
- 첫 번째 프로그래머는 자신의 기능에 보편성을 추가하기 시작합니다. 여러분은 상상조차 할 수 없는 일을 하게 됩니다(1차원 배열로 변환된 2차원 행렬의 곱을 연필로 확인하는 것은 어려울 것입니다). 그리고 마지막으로 기본 클래스를 설정하고 행렬 곱셈 방법을 작성하는 OOP를 가진 프로그래머가 나타납니다.
- 네 번째 작업으로 무엇을 할 것인지 상상조차 하고 싶지 않습니다. 왜냐하면 이 "새로운 밝은 아이디어를 가진 교활한 고객"은 이미 수평선에 어렴풋이 나타나고 있습니다. OOP 프로그래머는 단순히 역행렬을 찾는 방법을 추가하고 나중에 증기 목욕을하지 않도록 모든 행렬을 추가했습니다. 작업을 수행하고 나머지 프로그래머는 증기 목욕을하지 않도록 흩어졌습니다.
코드가 일반 프로그래밍, OOP 및 "밝은 아이디어"로 어떻게 바뀔지 깨닫는 경우(귀하의 코드는 두 번째 작업에서 이미 대량의 눈사태처럼 성장할 것이며 효율성에 대한 의문의 여지가 없습니다) - 효과적으로 프로그래밍하는 것이 무엇인지 이해하게 될 것입니다. 오, 예, 완전히 잊었습니다. 행렬 작업의 오류도 제어해야 합니다. 조금 더 작업해야 합니다.)))))))))))))) )
당신이 논하고자 하는 것 - 전 세계에서 수년간의 프로그래머 경험이 이미 지나갔고, 어떤 Bill Gates도 OOP 프로그래밍이 효과적이지 않다면 강제할 수 없다고 믿으며, 모든 것은 프로젝트의 개발 전망에 달려 있습니다 - 만약 프로젝트 확장 - OOP가 없으면 시간이 손실되고 유연성과 보편성 없이 광범위한 코드가 작성됩니다.
글쎄, 당신은 폭발 혼합물로 다른 것들을 혼동하고 혼합해야합니다. :)
하나는 객관적인 정보의 출처이고, 다른 하나는 모든 정보를 항상 인식할 수는 없고 일부만 인식할 수 있기 때문에 주관적인 수신자입니다.
이 같은 아무것도. 정보는 특정 소스 및 대상에 적용될 때만 의미가 있습니다. 우리에게 "절대적인" 정보는 있을 수 없습니다. 그것을 만지거나 측정한 우리는 즉시 주관적인 수용자가 된다. 어떤 출처에서 객관적인 정보의 존재를 증명하거나 반증하는 것은 근본적으로 불가능합니다. 그것은 신의 존재/부재에 대해 논쟁하는 것과 같습니다.
그리고 정보의 개념 자체는 일반적으로 소스와 수신자가 모두 선택될 때만 발생합니다.
이 같은 아무것도. 정보는 특정 소스 및 대상에 적용될 때만 의미가 있습니다. 우리에게 "절대적인" 정보는 있을 수 없습니다. 그것을 만지거나 측정한 우리는 즉시 주관적인 수용자가 된다.
물론 항상 정보 소스가 있다는 것을 Duc씨는 알고 있습니다. 그렇지 않으면 정보를 고려할 의미가 없습니다.
출처가 없는 정보는 단순히 존재할 수 없습니다. :) 글쎄, 정보의 객관적인 출처가 있다면 그 정보 자체가 객관적일 것입니다. 정보를 받는 사람은 항상 주관적이지만 모든 정보를 왜곡 없이 인식한다면 무한정 정확하게 객관성에 접근할 수 있습니다.
- "논리"를 사용하여 - 배열 X[4] 및 Y[4]와 X[4] * Y[4]를 곱하는 함수 및 물론 변환하는 함수로 구성된 엄청나게 빠른 코드를 작성합니다. 2차원 배열 형태의 어리석은 입력/출력 데이터를 올바른 데이터 - 1차원 배열로 만들고, 1차원 행렬에 대해 등가 변환을 작성하여 행렬 대수학을 공부합니다.
불행히도, 당신은 여전히 내가 당신에게 전달하려고 했던 간단한 것을 이해하지 못했지만, 배관공(예를 들어)이 갑자기 일시적으로 프로그래머로 재교육하기로 결정했다면 그는 여전히 배관공으로 남아 다음과 같이 생각하기 때문에 소용없다는 것을 알았습니다. 배관공은 현장에 놓인 파이프의 길이가 가장 중요합니다. :)
프로그램의 최적성의 기준은 코드의 길이가 아니라 특정 작업에 대한 연산의 수입니다. 2차원 행렬만 곱해야 하고 훨씬 더 일반적이고 불필요한 경우를 구현해야 한다면 아무도 그런 아마추어 성능에 감사하지 않을 것입니다.
수신기의 주관성은 소스에서 오는 것을 부정확하게 받아들이는 것이 아니라 이 들어오는 스트림을 다른 방식으로 해석할 수 있다는 것입니다. 동일한 비트스트림이 완전히 다른 정보일 수 있습니다.
Andrei01 , 죄송합니다만 왜 여기에 글을 쓰는지 이해가 되지 않습니다. rorobating, 또는 무엇을 위해? 귀하의 게시물은 이 스레드에 대한 유용한 신호를 포함하지 않는 일종의 홍수 소음으로 인식됩니다. 나가는 스트림을 필터링하십시오: 로봇이 아닌 사람들이 계속 읽습니다...
1. 수신기의 주관성은 소스에서 오는 것을 부정확하게 받아들이는 것이 아니라 이 들어오는 스트림을 다르게 해석할 수 있다는 것입니다. 동일한 비트 스트림이 완전히 다른 정보일 수 있습니다.
Andrei01 , 죄송합니다만 왜 여기에 글을 쓰는지 이해가 되지 않습니다. rorobating, 또는 무엇을 위해? 귀하의 게시물은 이 스레드에 대한 유용한 신호를 포함하지 않는 일종의 홍수 소음으로 인식됩니다. 나가는 스트림을 필터링하세요. 사람은 여전히 읽고 있고 로봇은 읽지 않습니다...
1. 수신자가 이유에 따라 정보를 다르게 해석한다는 사실은 그가 주관적이라고 말할 뿐입니다.
2. 수학, 불행히도 나는 이 구절의 의미를 파악하지 못했습니다. 노이즈를 너무 많이 추가했습니다. :) 그건 그렇고, 이것은 정보 소스가 범람 할 수 있다는 사실의 예입니다. 즉, 의도적으로 의미없는 정보를 의도적으로 생성합니다. :)
불행히도, 당신은 여전히 내가 당신에게 전달하려고 했던 간단한 것을 이해하지 못했지만, 배관공(예를 들어)이 일시적으로 프로그래머로 재교육하기로 결정했다면 그는 여전히 배관공으로 남아서 배관공은 바닥에 놓인 파이프의 길이가 가장 중요합니다. :)
프로그램의 최적성의 기준은 코드의 길이가 아니라 특정 작업에 대한 연산의 수입니다. 2차원 행렬만 곱해야 하고 훨씬 더 일반적이고 불필요한 경우를 구현해야 한다면 아무도 그런 아마추어 성능에 감사하지 않을 것입니다.
불행히도, 당신은 "즉시 문제"를 해결하는 관점에서만 생각하고 프로그램 기능의 알고리즘에서 미래의 변화에 대해서는 생각하지 않습니다
이동 중 문제 해결 - 고도로 전문화된 작업으로 구현의 용이성으로 인해 20-30분 이내에 해결되거나 이러한 작업이 이미 대규모 프로젝트에서 구현되었습니다.
C-4 는 이미 MACD 기반 거래 알고리즘이 과거의 일이 되고 있다고 말했습니다. 반복하지 않겠습니다.
추신: 코드 최적화에서 최소한 몇 가지 개발 사항을 연구하십시오. 이것이 골치 아픈 점이라면 여기 사람들이 자료를 해결했습니다. http://www.realcoding.net/article/rubric/code_optim?page=6
다시 한 번 이 주제에서 작별인사를 합니다. OOP가 무엇인지, 프로그램을 효과적으로 작성하는 방법을 이해하고 싶어 했던 제 자신을 반복할 필요가 없다고 생각합니다.
다시 그렇지 않습니다. 들어오는 스트림의 해석은 수신기 위에 서서 게임의 조건을 설정하는 사람의 작업입니다. 수신기는 철이며 Game Master가 설정한 알고리즘에 따라 정보를 연마합니다. 그런 의미에서 그것은 완전하고 엄밀한 객관입니다. 왜냐하면 그것은 멍청한 철 조각이기 때문입니다. 그리고 마스터는 주관적입니다.
해결되는 문제의 맥락에 따라 정보를 다양한 방식으로 정의할 수 있다는 사실을 알고 계십니까?