Смотреть, читать и скачать бесплатно pdf, djvu и купить бумажную и электронную книгу по лучшей цене со скидкой: Техника развития внимания, Андреев О.А., 2007. Настоящая книга написана по Программе интеллектуального и духовного развития личности Школы Олега Андреева. Она посвящена тренировке внимания. Можно использовать книгу как часть Программы или как самостоятельное пособие по технике развития внимания. Настоящее издание является более полным, чем предыдущие, включает новые материалы для самостоятельной работы. Информация изложена в виде восьми уроков. Каждый содержит теоретический раздел, упражнения и инструкции к
이 문장의 작성자가 프로세서, 메모리 및 컴파일러가 어떻게 작동하는지 전혀 모르고 있다는 의심이 듭니다... 귀하의 코드 중 어떤 것이든 적어도 수십 배, 심지어 수백 배까지 가속될 수 있다고 장담할 수 있습니다.
따라서 먼저 논의된 코드와 관련하여 이를 증명해 보십시오. 또한 Igor가 인용한 위의 결과를 믿는다면 그 반대가 사실임을 알 수 있습니다. 루프 내부의 선언이 약간 더 빠릅니다.
따라서 컴파일러를 이기기 위한 이러한 모든 춤과 샤머니즘은 결국 더 비싸집니다. 컴파일러가 코드를 최적화하는 것이 더 어려워집니다. 변수가 블록 외부에서 선언되면 외부로 간주되어 반복 간에 상태를 유지합니다 . 따라서 컴파일러는 최적화 가능성이 제한됩니다. 함수형 프로그래밍 패러다임에 익숙하다면 깨끗한 코드는 항상 "더티"(부작용 있음)보다 최적화됩니다.
따라서 먼저 논의된 코드와 관련하여 이를 증명해 보십시오. 또한 Igor가 인용한 위의 결과를 믿는다면 그 반대가 사실임을 알 수 있습니다. 루프 내부의 선언이 약간 더 빠릅니다.
따라서 컴파일러를 이기기 위한 이러한 모든 춤과 샤머니즘은 결국 더 비싸집니다. 컴파일러가 코드를 최적화하는 것이 더 어려워집니다. 변수가 블록 외부에서 선언되면 외부로 간주되어 반복 간에 상태를 유지합니다. 따라서 컴파일러는 최적화 가능성이 제한됩니다. 함수형 프로그래밍 패러다임에 익숙하다면 깨끗한 코드는 항상 "더티"(부작용 있음)보다 최적화됩니다.
여가 시간에 내가 제안한 책을 읽으십시오. 컴파일러에 대해 많은 새로운 것을 배우게 될 것입니다.
따라서 먼저 논의된 코드와 관련하여 이를 증명해 보십시오. 또한 Igor가 인용한 위의 결과를 믿는다면 그 반대가 사실임을 알 수 있습니다. 루프 내부의 선언이 약간 더 빠릅니다.
따라서 컴파일러를 이기기 위한 이러한 모든 춤과 샤머니즘은 결국 더 비싸집니다. 컴파일러가 코드를 최적화하는 것이 더 어려워집니다. 변수가 블록 외부에서 선언되면 외부로 간주되어 반복 간에 상태를 유지합니다 . 따라서 컴파일러는 최적화 가능성이 제한됩니다. 함수형 프로그래밍 패러다임에 익숙하다면 깨끗한 코드는 항상 "더티"(부작용 있음)보다 최적화됩니다.
이미 홍수를 멈추고 먼저 재료를 마스터한 다음 자신의 경우를 증명하십시오. 프로세서와 메모리의 작동에 대한 책을 최소한 한 권 이상 읽었다면 테스트 없이도 결과가 명확했을 것입니다. 나는 그들 중 가장 독창적 인 것을 제안했습니다. 프로그래밍에서 조용히 발전하고 싶다면 분명히 읽을 것입니다.
이 문장의 작성자가 프로세서, 메모리 및 컴파일러가 어떻게 작동하는지 전혀 알지 못하는 것 같습니다...
제 생각에는 이 댓글 작성자가 너무 부주의해서 문제의 본질을 이해하지 못했습니다
그리고 여기에 메모리와 프로세서가 있습니다. 질문은 MQL5의 최적화에 대한 것이었습니다. 더 자세히 읽어야 합니다.
추신: 여가 시간에 재미있는 작은 책 읽기 " 주의력 개발을 위한 기술, Andreev O.A., 2007 "
그리고 여기에 메모리와 프로세서가 있습니다. 질문은 MQL5의 최적화에 대한 것이었습니다. 더 자세히 읽어야 합니다.
즉, 그 코드가 메모리나 프로세서를 사용하지 않는다고 생각하십니까? 그리고 나는 컴파일러에 대한 말에 대답했습니다 " 최신 컴파일러의 최적화를 능가하려면 매우 열심히 노력해야 합니다. "
이 문장의 작성자가 프로세서, 메모리 및 컴파일러가 어떻게 작동하는지 전혀 모르고 있다는 의심이 듭니다... 귀하의 코드 중 어떤 것이든 적어도 수십 배, 심지어 수백 배까지 가속될 수 있다고 장담할 수 있습니다.
따라서 먼저 논의된 코드와 관련하여 이를 증명해 보십시오. 또한 Igor가 인용한 위의 결과를 믿는다면 그 반대가 사실임을 알 수 있습니다. 루프 내부의 선언이 약간 더 빠릅니다.
따라서 컴파일러를 이기기 위한 이러한 모든 춤과 샤머니즘은 결국 더 비싸집니다. 컴파일러가 코드를 최적화하는 것이 더 어려워집니다. 변수가 블록 외부에서 선언되면 외부로 간주되어 반복 간에 상태를 유지합니다 . 따라서 컴파일러는 최적화 가능성이 제한됩니다. 함수형 프로그래밍 패러다임에 익숙하다면 깨끗한 코드는 항상 "더티"(부작용 있음)보다 최적화됩니다.
따라서 먼저 논의된 코드와 관련하여 이를 증명해 보십시오. 또한 Igor가 인용한 위의 결과를 믿는다면 그 반대가 사실임을 알 수 있습니다. 루프 내부의 선언이 약간 더 빠릅니다.
따라서 컴파일러를 이기기 위한 이러한 모든 춤과 샤머니즘은 결국 더 비싸집니다. 컴파일러가 코드를 최적화하는 것이 더 어려워집니다. 변수가 블록 외부에서 선언되면 외부로 간주되어 반복 간에 상태를 유지합니다. 따라서 컴파일러는 최적화 가능성이 제한됩니다. 함수형 프로그래밍 패러다임에 익숙하다면 깨끗한 코드는 항상 "더티"(부작용 있음)보다 최적화됩니다.
여가 시간에 내가 제안한 책을 읽으십시오. 컴파일러에 대해 많은 새로운 것을 배우게 될 것입니다.
따라서 먼저 논의된 코드와 관련하여 이를 증명해 보십시오. 또한 Igor가 인용한 위의 결과를 믿는다면 그 반대가 사실임을 알 수 있습니다. 루프 내부의 선언이 약간 더 빠릅니다.
따라서 컴파일러를 이기기 위한 이러한 모든 춤과 샤머니즘은 결국 더 비싸집니다. 컴파일러가 코드를 최적화하는 것이 더 어려워집니다. 변수가 블록 외부에서 선언되면 외부로 간주되어 반복 간에 상태를 유지합니다 . 따라서 컴파일러는 최적화 가능성이 제한됩니다. 함수형 프로그래밍 패러다임에 익숙하다면 깨끗한 코드는 항상 "더티"(부작용 있음)보다 최적화됩니다.
내 테스트는 반대를 보여줍니다. 루프 뒤에변수 선언 이 있는 코드가 더 빠릅니다.
https://www.mql5.com/ru/forum/320307/page2#comment_12886814
여러 번 실행하면 결과가 안정적이고 루프 뒤에 변수가 선언 된 코드가 더 빠르게 작동합니다.
내 테스트는 반대를 보여줍니다. 루프 뒤에 변수 선언 이 있는 코드가 더 빠릅니다.
이상하지만 조금 일찍 사람은 반대 결과를 얻었습니다
이미 홍수를 멈추고 먼저 재료를 마스터한 다음 자신의 경우를 증명하십시오. 프로세서와 메모리의 작동에 대한 책을 최소한 한 권 이상 읽었다면 테스트 없이도 결과가 명확했을 것입니다. 나는 그들 중 가장 독창적 인 것을 제안했습니다. 프로그래밍에서 조용히 발전하고 싶다면 분명히 읽을 것입니다.
이상하지만 조금 일찍 사람은 반대 결과를 얻었습니다
나는 이미 인공적인 예에 대한 그러한 속도 테스트가 전혀 암시적이지 않다고 말했습니다. 디버거에서 내 연구가 충분하지 않습니까? 내가 신뢰할 수 없습니까? 모두가 무시했습니다. 주인의 일이니 내가 가겠습니다.
또한 Igor가 인용한 위의 결과를 믿는다면 그 반대가 사실임을 알 수 있습니다.
나는 나 자신을 믿지 않고 항상 다시 확인합니다. 당신이 내 자존감을 높이면 안된다고 생각합니다 ... 역사에는 다른 경우가있었습니다. 지금은 나폴레옹 여성을 찾아 떠날 것입니다! ))))
이상하지만 조금 일찍 사람은 반대 결과를 얻었습니다
이상하지 않습니다. MQL에서 가장 간단한 연산자와 작업을 테스트할 수 있어야 합니다. 테스트에 srand( GetTickCount() )를 추가한 이유는 무엇입니까?
;)