100Kb 소스 프로젝트는 1325 빌드에서 1초 미만으로 컴파일됩니다. 견고한 OOP, 많은 가상 함수 및 오버로드, 템플릿, 포인터, const 수정자(가능한 모든 곳). DLL 및 OpenCL 없이.
브레이크의 원인을 알고 싶습니다. 컴파일러가 빠르게 최적화하는 데 도움이 되는 것은 아마도 const일 것입니다. 나는 브레이크를 다룬 적이 없다. 속도가 느려지는 코드 기반의 소스 코드를 제공하십시오.
Well Duc 100kb - 정말 많습니까? 거의 메가바이트가 있습니다. 모든 것이 당신과 동일합니다. 게다가 매크로도 많다. const는 어디에나 붙지 않고 여기에만 붙습니다. 그러나 이것이 그러한 미친 브레이크의 이유는 아닙니다. 또한 빌드 1159에서는 모든 것이 거의 즉시 컴파일되었습니다.
빌드 1325에서 테스트할 수 없습니다. 프로젝트가 빌드 1325에서 전혀 컴파일되지 않고 오류가 산더미처럼 쌓여 있기 때문입니다. Vaughn과 A100 동지는 새 빌드에 나타난 많은 버그에 대해 구독을 취소했습니다. 나는 이 벌레를 고르는 데 시간을 낭비하고 싶지 않습니다. 나는 그들이 작동하는 빌드를 릴리스할 때까지 기다릴 것입니다.
따라서 내가 브레이크에 대해 말한 것은 1241 빌드를 참조했습니다. 테스트할 기회가 있으면 최신 빌드와 비교해 보십시오. 그러나 새 빌드에서는 속도가 크게 향상될 수 있는지 의심됩니다. 오히려 그 반대입니다. 결국 컴파일 속도는 MT 개발자에게 거의 문제가 되지 않으며 런타임에 추가 나노초만 짜내면 됩니다. 그러면 나중에 C++에 필적하는 MQL 프로그램의 속도에 대한 마케팅 설명을 할 수 있습니다(추상적인 예에만 해당). . 그리고 그들은 내가 이해하는 것처럼 최적화의 효율성에 대해 신경 쓰지 않습니다. 저것들. 촛불의 가치가있는 게임입니다.
코드 베이스에서 소스를 찾으려고 노력할 것이지만 비슷한 소스를 찾을 수 있다는 것은 사실이 아닙니다. 큰 프로젝트여야 합니다. 그리고 거기에는 무료 액세스를 위해 대부분 작은 공예품이 놓여 있습니다.
이러한 발판에서 최적화 프로그램은 많은 패스를 수행하여 코드를 계속해서 개선해야 합니다. 옵티마이저의 속도가 급격히 증가하도록 함수의 크기를 줄이는 것으로 충분합니다.
글쎄, 우리는 품질과 속도를 지속적으로 개선하고 있으므로 최신 빌드로 전환하십시오.
거창한 기능은 없습니다. 최대 150줄(또는 거대한 것으로 간주됩니까?). 그리고 그렇게 생각한다면, 컴파일러가 많은 작은 함수들을 통과할 수 있다면 함수의 크기가 함수와 어떤 관련이 있습니까? 그가 큰 기능을 10번 실행한다고 가정해 봅시다. 글쎄, 나는 그것을 5 개의 작은 것으로 나눌 것입니다. 그리고 그들 각각은 2 번 이상 얻을 것입니다. 우리는 같은 결과를 얻습니다. 저것들. 코드의 총량이 중요하지 않습니까? 하지만 큰 기능을 뭉개서 결과가 조금 빨라진다고 해도 그래서 어쩌지? 결국, 우리는 컴파일 속도를 10배(!)배 늦추는 것에 대해 이야기하고 있습니다.
가능한 한 빨리 프로그램을 실행 하고 싶기 때문에 무언가를 개선하기 위해 많은 노력을 기울이는 것은 이해할 수 있습니다. 그리고 언어를 복잡하게 만들수록 이러한 패스를 완료하는 데 시간이 더 오래 걸리고 프로그래머의 시간이 걸립니다. 그러면 자연스럽게 이 모든 것의 효과에 대한 의문이 생깁니다. 최적화 완료를 기다리는 프로그래머의 다운타임에 비해 최적화로 인한 프로그램 속도 향상이 얼마나 중요한가요?
물론 약간의 타협을 시도할 수 있지만 위에서 설명한 것처럼 다른 컴파일 모드를 만드는 것이 훨씬 더 효율적입니다. 모든 최적화가 포함된 프로그램 릴리스는 맨 마지막에만 필요합니다. 그리고 프로그래머는 최적화가 전혀 필요하지 않을 때 99%의 시간을 코드를 작성하고 디버깅하는 데 보냅니다.
빌드가 업데이트될 때마다 코드 컴파일이 중지되는 것이 얼마나 오래 지속됩니까? 그리고 컴파일하면 이전과 다르게 작동하기 시작합니다(더 나빠짐). 누가 그런 프로그래밍 언어를 필요로 합니까?
...
무슨 말인지 이해가 안 돼요. 코드 볼륨이 20,000,000라인이 넘는 비현실적으로 복잡한 MQL 프로젝트 가 여러 개 있습니다. 새 빌드에서는 두 번 컴파일됩니다. 지금까지 딱 두 가지 문제가 있었습니다. 한 번은 내 캔트 때문에, 다른 하나는 개발자의 캔트 때문입니다.
Vasiliy Sokolov : 무슨 말인지 이해가 안 돼요. 코드 볼륨이 20,000,000라인이 넘는 비현실적으로 복잡한 MQL 프로젝트가 여러 개 있습니다. 새 빌드에서는 두 번 컴파일됩니다. 지금까지 딱 두 가지 문제가 있었습니다. 한 번은 내 캔트 때문에, 다른 하나는 개발자의 캔트 때문입니다.
글쎄, 당신은 운이 좋은 사람입니다. 귀하의 코드는 내 코드에서 사용할 수 있는 구성을 충족하지 않습니다. 여기서 이상한 점은 무엇입니까?
위의 몇 페이지를 스크롤하여 새 빌드에서 많은 버그를 발견했습니다. 그 중 일부는 미묘합니다. 그가 의도적으로 그들을 찾고 있다고 생각합니까?
이것은 MQL5를 위한 새로운 최적화 컴파일러입니다(MQL4에는 존재하지 않음). 이것이 작동 방식입니다.
더 나은 대상 코드를 위해서는 더 긴 컴파일 비용을 지불해야 합니다.
글쎄요, 저를 포함해 몇몇 분들이 느린 컴파일에 대해 불평을 하고 계십니다. 그러나 귀하의 답변에서 귀하는 "더 나은 대상 코드"와 일부 신화적인 "실행 속도가 2배에서 10배로 증가"에만 관심이 있다는 것이 분명하지만 실제 작업 프로젝트에서는 그러한 가속을 관찰하지 못했습니다.
내가 말했듯이 마지막 빌드(4월 22일자)에서 테스트할 수 없었습니다. 컴파일하는 동안 버그가 있었습니다. 그러나 새 빌드의 어느 곳에서도 컴파일러 가속을 발표하지 않았기 때문에 컴파일 속도가 그만큼 느리다고 생각합니다.
100Kb 소스 프로젝트는 1325 빌드에서 1초 미만으로 컴파일됩니다. 견고한 OOP, 많은 가상 함수 및 오버로드, 템플릿, 포인터, const 수정자(가능한 모든 곳). DLL 및 OpenCL 없이.
브레이크의 원인을 알고 싶습니다. 컴파일러가 빠르게 최적화하는 데 도움이 되는 것은 아마도 const일 것입니다. 나는 브레이크를 다룬 적이 없다. 속도가 느려지는 코드 기반의 소스 코드를 제공하십시오.
Well Duc 100kb - 정말 많습니까? 거의 메가바이트가 있습니다. 모든 것이 당신과 동일합니다. 게다가 매크로도 많다. const는 어디에나 붙지 않고 여기에만 붙습니다. 그러나 이것이 그러한 미친 브레이크의 이유는 아닙니다. 또한 빌드 1159에서는 모든 것이 거의 즉시 컴파일되었습니다.
빌드 1325에서 테스트할 수 없습니다. 프로젝트가 빌드 1325에서 전혀 컴파일되지 않고 오류가 산더미처럼 쌓여 있기 때문입니다. Vaughn과 A100 동지는 새 빌드에 나타난 많은 버그에 대해 구독을 취소했습니다. 나는 이 벌레를 고르는 데 시간을 낭비하고 싶지 않습니다. 나는 그들이 작동하는 빌드를 릴리스할 때까지 기다릴 것입니다.
따라서 내가 브레이크에 대해 말한 것은 1241 빌드를 참조했습니다. 테스트할 기회가 있으면 최신 빌드와 비교해 보십시오. 그러나 새 빌드에서는 속도가 크게 향상될 수 있는지 의심됩니다. 오히려 그 반대입니다. 결국 컴파일 속도는 MT 개발자에게 거의 문제가 되지 않으며 런타임에 추가 나노초만 짜내면 됩니다. 그러면 나중에 C++에 필적하는 MQL 프로그램의 속도에 대한 마케팅 설명을 할 수 있습니다(추상적인 예에만 해당). . 그리고 그들은 내가 이해하는 것처럼 최적화의 효율성에 대해 신경 쓰지 않습니다. 저것들. 촛불의 가치가있는 게임입니다.
코드 베이스에서 소스를 찾으려고 노력할 것이지만 비슷한 소스를 찾을 수 있다는 것은 사실이 아닙니다. 큰 프로젝트여야 합니다. 그리고 거기에는 무료 액세스를 위해 대부분 작은 공예품이 놓여 있습니다.
아마도 그것은 텍스트의 발보 형태의 거대한 기능을 가지고 있습니다.
이러한 발판에서 최적화 프로그램은 많은 패스를 수행하여 코드를 계속해서 개선해야 합니다. 옵티마이저의 속도가 급격히 증가하도록 함수의 크기를 줄이는 것으로 충분합니다.
글쎄, 우리는 품질과 속도를 지속적으로 개선하고 있으므로 최신 빌드로 전환하십시오.
거창한 기능은 없습니다. 최대 150줄(또는 거대한 것으로 간주됩니까?). 그리고 그렇게 생각한다면, 컴파일러가 많은 작은 함수들을 통과할 수 있다면 함수의 크기가 함수와 어떤 관련이 있습니까? 그가 큰 기능을 10번 실행한다고 가정해 봅시다. 글쎄, 나는 그것을 5 개의 작은 것으로 나눌 것입니다. 그리고 그들 각각은 2 번 이상 얻을 것입니다. 우리는 같은 결과를 얻습니다. 저것들. 코드의 총량이 중요하지 않습니까? 하지만 큰 기능을 뭉개서 결과가 조금 빨라진다고 해도 그래서 어쩌지? 결국, 우리는 컴파일 속도를 10배(!)배 늦추는 것에 대해 이야기하고 있습니다.
가능한 한 빨리 프로그램을 실행 하고 싶기 때문에 무언가를 개선하기 위해 많은 노력을 기울이는 것은 이해할 수 있습니다. 그리고 언어를 복잡하게 만들수록 이러한 패스를 완료하는 데 시간이 더 오래 걸리고 프로그래머의 시간이 걸립니다. 그러면 자연스럽게 이 모든 것의 효과에 대한 의문이 생깁니다. 최적화 완료를 기다리는 프로그래머의 다운타임에 비해 최적화로 인한 프로그램 속도 향상이 얼마나 중요한가요?
물론 약간의 타협을 시도할 수 있지만 위에서 설명한 것처럼 다른 컴파일 모드를 만드는 것이 훨씬 더 효율적입니다. 모든 최적화가 포함된 프로그램 릴리스는 맨 마지막에만 필요합니다. 그리고 프로그래머는 최적화가 전혀 필요하지 않을 때 99%의 시간을 코드를 작성하고 디버깅하는 데 보냅니다.
빌드가 업데이트될 때마다 코드 컴파일이 중지되는 것이 얼마나 오래 지속됩니까? 그리고 컴파일하면 이전과 다르게 작동하기 시작합니다(더 나빠짐). 누가 그런 프로그래밍 언어를 필요로 합니까?
...
최대 150줄
무슨 말인지 이해가 안 돼요. 코드 볼륨이 20,000,000라인이 넘는 비현실적으로 복잡한 MQL 프로젝트가 여러 개 있습니다. 새 빌드에서는 두 번 컴파일됩니다. 지금까지 딱 두 가지 문제가 있었습니다. 한 번은 내 캔트 때문에, 다른 하나는 개발자의 캔트 때문입니다.
글쎄, 당신은 운이 좋은 사람입니다. 귀하의 코드는 내 코드에서 사용할 수 있는 구성을 충족하지 않습니다. 여기서 이상한 점은 무엇입니까?
위의 몇 페이지를 스크롤하여 새 빌드에서 많은 버그를 발견했습니다. 그 중 일부는 미묘합니다. 그가 의도적으로 그들을 찾고 있다고 생각합니까?
글쎄, 당신은 운이 좋은 사람입니다. 귀하의 코드는 내 코드에서 사용할 수 있는 구성을 충족하지 않습니다. 여기서 이상한 점은 무엇입니까?
위의 몇 페이지를 스크롤하여 새 빌드에서 많은 버그를 발견했습니다. 그 중 일부는 미묘합니다. 그가 의도적으로 그들을 찾고 있다고 생각합니까?
재현 가능한 브레이크의 예를 보여주세요.
불행히도 개발자에 대한 직접적인 공격을 포함하여 근거 없는 진술을 하는 동안.
함수의 크기와 프로그램의 일반적인 크기에 대해 잘못 알고 있습니다. 개별 함수의 크기는 구문 트리의 증가와 최적화 프로그램의 다중 패스로 인해 각 특정 함수의 최적화에 직접 및 비선형적으로 영향을 미칩니다. 작은 기능은 즉석에서 최적화됩니다.
글쎄, 당신은 운이 좋은 사람입니다. 귀하의 코드는 내 코드에서 사용할 수 있는 구성을 충족하지 않습니다. 여기서 이상한 점은 무엇입니까?
위의 몇 페이지를 스크롤하여 새 빌드에서 많은 버그를 발견했습니다. 그 중 일부는 미묘합니다. 그가 의도적으로 그들을 찾고 있다고 생각합니까?
1) 내 코드에 없는 어떤 종류의 구성을 사용했는지 흥미롭습니다. 내 코드의 양은 수천 줄이지만 당신의 디자인은 그렇지 않습니까? 이거 뭔가 굉장히 독특하죠?
2) 실제로 이전 빌드에서는 클래스를 상호 참조하는 경우 발생하는 내부 컴파일러 오류가 실제로 있었습니다. 개발자 버그이지만 수정되었습니다. 다른 실수는 기억나지 않는다.
2) 실제로 이전 빌드에서는 클래스를 상호 참조하는 경우 발생하는 내부 컴파일러 오류가 실제로 있었습니다. 개발자 버그이지만 수정되었습니다. 다른 실수는 기억나지 않는다.
https://www.mql5.com/ru/forum/1111/page1591#comment_2463820
그리고 서로에 대한 클래스의 상호 참조는 어디에 있습니까?
여기에서는 상호 링크를 찾고 사용하지 않는 구성을 이해하는 데 편의를 위해 더 단순화했습니다.
https://www.mql5.com/ru/forum/1111/page1591#comment_2463820
그리고 서로에 대한 클래스의 상호 참조는 어디에 있습니까?
여기에서는 상호 링크를 찾고 사용하지 않는 구성을 이해하는 데 편의를 위해 더 단순화했습니다.
당신은 리버스 엔지니어링에 있습니다. 이 작업은 컴파일러를 개선하는 데 유용하지만 실제 프로그래밍 관점에서는 적용되지 않습니다. 귀하가 제공한 코드를 실제로 사용할 프로그래머는 한 명도 없습니다.
재현 가능한 브레이크의 예를 보여주세요.
유감스럽게도 개발자에 대한 직접적인 공격을 포함하여 근거 없는 발언을 하는 동안 ..
나는 이것이 큰 프로젝트라고 썼습니다. 모든 소스의 총 볼륨은 약 1MB입니다. 브레이크를 어떻게 보여줄 수 있습니까? 모든 코드를 chtol로 보내시겠습니까? 당신은 이것이 불가능하다는 것을 이해합니다. 물론 개별 조각의 편집은 훨씬 빠릅니다.
그리고 "근거없는 진술"은 무엇을 의미합니까? 최적화 컴파일러가 상당히 느려진다는 사실? 그리고 당신이 상관하지 않는다는 사실? 여기서 근거가 없는 것은?
다음은 이 글로벌 최적화를 방금 도입한 지난 10월의 토론에 대한 링크입니다. https://www.mql5.com/ru/forum/1111/page1424#comment_1981722
남자는 다음과 같이 씁니다.
또 다른 코드 - 시간에주의하십시오 - 아마도 20 배 증가했을 것입니다.
그리고 다음과 같이 대답합니다.
이것은 MQL5를 위한 새로운 최적화 컴파일러입니다(MQL4에는 존재하지 않음). 이것이 작동 방식입니다.
더 나은 대상 코드를 위해서는 더 긴 컴파일 비용을 지불해야 합니다.
글쎄요, 저를 포함해 몇몇 분들이 느린 컴파일에 대해 불평을 하고 계십니다. 그러나 귀하의 답변에서 귀하는 "더 나은 대상 코드"와 일부 신화적인 "실행 속도가 2배에서 10배로 증가"에만 관심이 있다는 것이 분명하지만 실제 작업 프로젝트에서는 그러한 가속을 관찰하지 못했습니다.
내가 말했듯이 마지막 빌드(4월 22일자)에서 테스트할 수 없었습니다. 컴파일하는 동안 버그가 있었습니다. 그러나 새 빌드의 어느 곳에서도 컴파일러 가속을 발표하지 않았기 때문에 컴파일 속도가 그만큼 느리다고 생각합니다.