작업 관리자에서 Metatrader(32비트)를 봅니다. 브레이크를 사용하는 이유는 시스템 용량과 관련이 있습니까? 결국, Metatrader는 이제 x64용으로만 선명해집니다. 그리고 개발자들에 따르면 32비트 버전은 더 이상 출시되지 않습니다.
그리고 비동기 데이터 처리 문제가 해결되었습니까?
이 모든 예는 MT4에 있습니다.
MT5는 훨씬 더 많이 그립니다. 그러나 잘못된 다시 그리기(예: 주문서)의 경우 프로세서도 로드합니다(선택됨). 문제는 다시 그리는 빈도와 면적으로, 반드시 줄여야 한다. 셀을 다시 그려야 하는 경우에만 해당됩니다. 그렇지 않으면 - 리소스 낭비(예를 들어, 셀을 초당 10번 다시 그려야 하는 경우 전체 캔버스를 다시 그리면 프로세서가 "종료"되고 속도가 느려지는 것은 비현실적입니다.) 그러나 이것은 이해할 수 있습니다.
설명하겠습니다. 테이블 셀은 기본, 텍스트, 아이콘의 세 가지 개체입니다. 셀의 내용이 변경되면 캔버스의 한 섹션에 대해 3주기를 수행해야 합니다. 첫 번째 사이클에서 우리는 두 번째 - 텍스트, 세 번째 - 아이콘에서 기본을 다시 그립니다. 세포 면적이 3배가 된 것과 같습니다. 이 정신으로 계속해서 전체 캔버스를 다시 그리면 강한 감속이 있을 것입니다. 따라서 다시 그리는 캔버스 영역의 주기 수를 고려해야 합니다. 이것은 단순한 프리미티브에서는 보이지 않지만 복잡한 요소에서는 분명해집니다. 일부 요소에는 10개의 개체(버튼 또는 목록 상자가 있는 입력 필드 또는 창 플랫폼)가 포함되며 다시 그릴 때 수행해야 하는 캔버스 배열의 주기를 계산할 수 있습니다. 다행히도 이 다시 그리기에는 높은 반복률이 필요하지 않습니다.
비동기 처리에서는 문제가 해결되지 않습니다. 생각은 있었지만 아직 해결책이 없습니다.
일반적으로 캔버스에 GUI를 만든 다음 별도로 다시 그린 요소에서 만듭니다. 그렇지 않으면 한계에 빠르게 도달한 후 간단한 작업에서 제동이 눈에 띄게 됩니다.
글쎄요, 간단한 단어로 이해하면 비동기(자원 경쟁) 또는 멀티스레딩(전용 자원)입니다. Nikolay의 예제 코드는 보지 않았지만 Metatrader의 비동기 및 다중 스레딩이 없기 때문에 픽셀 다시 그리기 코드가 동기식으로 실행됩니다. 그리고 Petera를 사용하면 출력 데이터 처리도 동기식으로 수행될 가능성이 큽니다. 그리고 두 경우 모두 대부분이 여전히 순환적으로 처리되고 있습니다. 이 때문에 프로세서의 부하가 증가합니다. 현재 적은 부하로 빠른 응답을 위해서는 데이터 처리와 다시 그리기를 병렬화해야 합니다.
글쎄요, 간단한 단어로 이해하면 비동기(자원 경쟁) 또는 멀티스레딩(전용 자원)입니다. Nikolay의 예제 코드는 보지 않았지만 Metatrader의 비동기 및 다중 스레딩이 없기 때문에 픽셀 다시 그리기 코드가 동기식으로 실행됩니다. 그리고 Petera를 사용하면 출력 데이터 처리도 동기식으로 수행될 가능성이 큽니다. 그리고 두 경우 모두 대부분이 여전히 순환적으로 처리되고 있습니다. 이 때문에 프로세서의 부하가 증가합니다. 현재 적은 부하로 빠른 응답을 위해서는 데이터 처리와 다시 그리기를 병렬화해야 합니다.
그렇지 않습니다)) 설명하겠습니다: 내 엔진은 리소스를 통해 사용자 프로그램에 연결됩니다. 즉, - 사용자 응용 프로그램은 자체 스레드에서 계산을 수행하고 다른 차트에 있을 수 있는 엔진(GUI 전달)에 데이터를 전달합니다. 매개변수 이벤트를 처리하고 GUI에 출력합니다. 즉, 처리를 두 개의 스레드로 나누는 것으로 나타났습니다. 그러나 내가 게시할 생성자에서는 그렇지 않습니다. 응용 프로그램은 자체 내부에 엔진을 포함하고 모든 것이 하나의 스레드에 있습니다. 그러나 프로세서의 로드는 동일합니다. 간단히 말해서, 기능 실행 순서에 대한 속도의 의존성은 더 커질 것입니다.
그렇지 않습니다)) 설명하겠습니다: 내 엔진은 리소스를 통해 사용자 프로그램에 연결됩니다. 즉, - 사용자 응용 프로그램은 자체 스레드에서 계산을 수행하고 다른 차트에 있을 수 있는 엔진(GUI 전달)에 데이터를 전달합니다. 매개변수 이벤트를 처리하고 GUI에 출력합니다. 즉, 처리를 두 개의 스레드로 나누는 것으로 나타났습니다. 그러나 내가 게시할 생성자에서는 그렇지 않습니다. 응용 프로그램은 자체 내부에 엔진을 포함하고 모든 것이 하나의 스레드에 있습니다. 그러나 프로세서의 로드는 동일합니다. 간단히 말해서, 기능 실행 순서에 대한 속도의 의존성은 더 커질 것입니다.
다시 예전 ... 약속, 발표, 잡담
이미 잊혀진 "코어 엔진"이 괜찮은 소프트웨어로 게시 되었습니까? 또는 Mr.처럼 댓글에 첨부 파일 형식으로
글쎄요, 간단한 단어로 이해하면 비동기(자원 경쟁) 또는 멀티스레딩(전용 자원)입니다. Nikolay의 예제 코드는 보지 않았지만 Metatrader의 비동기 및 다중 스레딩이 없기 때문에 픽셀 다시 그리기 코드가 동기식으로 실행됩니다. 그리고 Petera를 사용하면 출력 데이터 처리도 동기식으로 수행될 가능성이 큽니다. 그리고 두 경우 모두 대부분이 여전히 순환적으로 처리되고 있습니다. 이 때문에 프로세서의 부하가 증가합니다. 현재 적은 부하로 빠른 응답을 위해서는 데이터 처리와 다시 그리기를 병렬화해야 합니다.
MT의 모든 작업은 엄격하게 동기적으로 수행되며 개발자가 응용 프로그램에 스레드를 추가할 때까지 실제로 변경할 수 없습니다.
개발자가 데이터베이스 작업 측면에서 MT의 기능을 확장하려고 한다는 것은 매우 놀라운 일입니다. Python을 사용하여... 하지만 모두 동일한 스레드에서 모든 작업을 수행하도록 제안합니다... 놀랍습니다.
그렇지 않습니다)) 설명하겠습니다: 내 엔진은 리소스를 통해 사용자 프로그램에 연결됩니다. 즉, - 사용자 응용 프로그램은 자체 스레드에서 계산을 수행하고 다른 차트에 있을 수 있는 엔진(GUI 전달)에 데이터를 전달합니다. 매개변수 이벤트를 처리하고 GUI에 출력합니다. 즉, 처리를 두 개의 스레드로 나누는 것으로 나타났습니다. 그러나 내가 게시할 생성자에서는 그렇지 않습니다. 응용 프로그램은 자체 내부에 엔진을 포함하고 모든 것이 하나의 스레드에 있습니다. 그러나 프로세서의 로드는 동일합니다. 간단히 말해서, 기능 실행 순서에 대한 속도의 의존성은 더 커질 것입니다.
의미를 이해했습니다. 응용 프로그램이 분리되어 있고 GUI가 분리되어 있습니다. 그러나 GUI에서 출력 데이터 처리는 여전히 동기식으로 수행됩니다. 즉, 예를 들어 애플리케이션은 10,000개의 요소를 GUI로 보내고 GUI는 이러한 모든 요소를 순차적으로 처리합니다. 그게 문제 야. GUI에서 들어오는 요소의 처리와 출력을 병렬화하는 데 필요합니다. 기본, 텍스트, 아이콘입니다. 또한 셀당 3개의 사이클이 수행됩니다.
이 예에서는 일반적인 재생 빈도입니다. 그래서 느려지지 않습니다.
작업 관리자에서 Metatrader(32비트)를 봅니다.
그리고 비동기식 데이터 처리 문제가 해결되었습니까?브레이크를 사용하는 이유는 시스템 용량과 관련이 있습니까?
결국, Metatrader는 이제 x64용으로만 선명해집니다.
그리고 개발자들에 따르면 32비트 버전은 더 이상 출시되지 않습니다.
작업 관리자에서 Metatrader(32비트)를 봅니다.
그리고 비동기식 데이터 처리 문제가 해결되었습니까?브레이크를 사용하는 이유는 시스템 용량과 관련이 있습니까?
결국, Metatrader는 이제 x64용으로만 선명해집니다.
그리고 개발자들에 따르면 32비트 버전은 더 이상 출시되지 않습니다.
내가 제공한 Nikolai의 예는 예에서 개체를 이동할 때 특히 빠르게 수행되는 경우 실제로 CPU를 많이 사용한다는 것을 확인합니다. 부하가 35-40% 증가합니다. 테스트는 64비트 프로세서, Windows 7 64비트 및 MT5 64비트에서 수행되었습니다.
논의에서 비동기식 데이터 처리란 무엇을 의미합니까?
작업 관리자에서 Metatrader(32비트)를 봅니다.
그리고 비동기 데이터 처리 문제가 해결되었습니까?브레이크를 사용하는 이유는 시스템 용량과 관련이 있습니까?
결국, Metatrader는 이제 x64용으로만 선명해집니다.
그리고 개발자들에 따르면 32비트 버전은 더 이상 출시되지 않습니다.
이 모든 예는 MT4에 있습니다.
MT5는 훨씬 더 많이 그립니다. 그러나 잘못된 다시 그리기(예: 주문서)의 경우 프로세서도 로드합니다(선택됨). 문제는 다시 그리는 빈도와 면적으로, 반드시 줄여야 한다. 셀을 다시 그려야 하는 경우에만 해당됩니다. 그렇지 않으면 - 리소스 낭비(예를 들어, 셀을 초당 10번 다시 그려야 하는 경우 전체 캔버스를 다시 그리면 프로세서가 "종료"되고 속도가 느려지는 것은 비현실적입니다.) 그러나 이것은 이해할 수 있습니다.
설명하겠습니다. 테이블 셀은 기본, 텍스트, 아이콘의 세 가지 개체입니다. 셀의 내용이 변경되면 캔버스의 한 섹션에 대해 3주기를 수행해야 합니다. 첫 번째 사이클에서 우리는 두 번째 - 텍스트, 세 번째 - 아이콘에서 기본을 다시 그립니다. 세포 면적이 3배가 된 것과 같습니다. 이 정신으로 계속해서 전체 캔버스를 다시 그리면 강한 감속이 있을 것입니다. 따라서 다시 그리는 캔버스 영역의 주기 수를 고려해야 합니다. 이것은 단순한 프리미티브에서는 보이지 않지만 복잡한 요소에서는 분명해집니다. 일부 요소에는 10개의 개체(버튼 또는 목록 상자가 있는 입력 필드 또는 창 플랫폼)가 포함되며 다시 그릴 때 수행해야 하는 캔버스 배열의 주기를 계산할 수 있습니다. 다행히도 이 다시 그리기에는 높은 반복률이 필요하지 않습니다.
비동기 처리에서는 문제가 해결되지 않습니다. 생각은 있었지만 아직 해결책이 없습니다.
일반적으로 캔버스에 GUI를 만든 다음 별도로 다시 그린 요소에서 만듭니다. 그렇지 않으면 한계에 빠르게 도달한 후 간단한 작업에서 제동이 눈에 띄게 됩니다.
논의에서 비동기식 데이터 처리란 무엇을 의미합니까?
글쎄요, 간단한 단어로 이해하면 비동기(자원 경쟁) 또는 멀티스레딩(전용 자원)입니다.
Nikolay의 예제 코드는 보지 않았지만 Metatrader의 비동기 및 다중 스레딩이 없기 때문에 픽셀 다시 그리기 코드가 동기식으로 실행됩니다.
그리고 Petera를 사용하면 출력 데이터 처리도 동기식으로 수행될 가능성이 큽니다. 그리고 두 경우 모두 대부분이 여전히 순환적으로 처리되고 있습니다.
이 때문에 프로세서의 부하가 증가합니다. 현재 적은 부하로 빠른 응답을 위해서는 데이터 처리와 다시 그리기를 병렬화해야 합니다.
글쎄요, 간단한 단어로 이해하면 비동기(자원 경쟁) 또는 멀티스레딩(전용 자원)입니다.
Nikolay의 예제 코드는 보지 않았지만 Metatrader의 비동기 및 다중 스레딩이 없기 때문에 픽셀 다시 그리기 코드가 동기식으로 실행됩니다.
그리고 Petera를 사용하면 출력 데이터 처리도 동기식으로 수행될 가능성이 큽니다. 그리고 두 경우 모두 대부분이 여전히 순환적으로 처리되고 있습니다.
이 때문에 프로세서의 부하가 증가합니다. 현재 적은 부하로 빠른 응답을 위해서는 데이터 처리와 다시 그리기를 병렬화해야 합니다.
그렇지 않습니다)) 설명하겠습니다: 내 엔진은 리소스를 통해 사용자 프로그램에 연결됩니다. 즉, - 사용자 응용 프로그램은 자체 스레드에서 계산을 수행하고 다른 차트에 있을 수 있는 엔진(GUI 전달)에 데이터를 전달합니다. 매개변수 이벤트를 처리하고 GUI에 출력합니다. 즉, 처리를 두 개의 스레드로 나누는 것으로 나타났습니다. 그러나 내가 게시할 생성자에서는 그렇지 않습니다. 응용 프로그램은 자체 내부에 엔진을 포함하고 모든 것이 하나의 스레드에 있습니다. 그러나 프로세서의 로드는 동일합니다. 간단히 말해서, 기능 실행 순서에 대한 속도의 의존성은 더 커질 것입니다.
그렇지 않습니다)) 설명하겠습니다: 내 엔진은 리소스를 통해 사용자 프로그램에 연결됩니다. 즉, - 사용자 응용 프로그램은 자체 스레드에서 계산을 수행하고 다른 차트에 있을 수 있는 엔진(GUI 전달)에 데이터를 전달합니다. 매개변수 이벤트를 처리하고 GUI에 출력합니다. 즉, 처리를 두 개의 스레드로 나누는 것으로 나타났습니다. 그러나 내가 게시할 생성자에서는 그렇지 않습니다. 응용 프로그램은 자체 내부에 엔진을 포함하고 모든 것이 하나의 스레드에 있습니다. 그러나 프로세서의 로드는 동일합니다. 간단히 말해서, 기능 실행 순서에 대한 속도의 의존성은 더 커질 것입니다.
다시 예전 ... 약속, 발표, 잡담
이미 잊혀진 "코어 엔진"이 괜찮은 소프트웨어로 게시 되었습니까? 또는 Mr.처럼 댓글에 첨부 파일 형식으로
글쎄요, 간단한 단어로 이해하면 비동기(자원 경쟁) 또는 멀티스레딩(전용 자원)입니다.
Nikolay의 예제 코드는 보지 않았지만 Metatrader의 비동기 및 다중 스레딩이 없기 때문에 픽셀 다시 그리기 코드가 동기식으로 실행됩니다.
그리고 Petera를 사용하면 출력 데이터 처리도 동기식으로 수행될 가능성이 큽니다. 그리고 두 경우 모두 대부분이 여전히 순환적으로 처리되고 있습니다.
이 때문에 프로세서의 부하가 증가합니다. 현재 적은 부하로 빠른 응답을 위해서는 데이터 처리와 다시 그리기를 병렬화해야 합니다.
MT의 모든 작업은 엄격하게 동기적으로 수행되며 개발자가 응용 프로그램에 스레드를 추가할 때까지 실제로 변경할 수 없습니다.
개발자가 데이터베이스 작업 측면에서 MT의 기능을 확장하려고 한다는 것은 매우 놀라운 일입니다. Python을 사용하여... 하지만 모두 동일한 스레드에서 모든 작업을 수행하도록 제안합니다... 놀랍습니다.
다시 예전 ... 약속, 발표, 잡담
이미 잊혀진 "코어 엔진"이 괜찮은 소프트웨어로 게시 되었습니까? 또는 Mr.처럼 댓글에 첨부 파일 형식으로
잘하셨어요. 당신 같은 사람과의 싸움에서 나는 영감을 끌어하지만 그들은 항상 잃는다.)) 당신은 나에게 에너지를주고 이해하지 않습니다.
다시 예전 ... 약속, 발표, 잡담
이미 잊혀진 "코어 엔진"이 괜찮은 소프트웨어로 게시 되었습니까? 또는 Mr.처럼 댓글에 첨부 파일 형식으로
맥스, 좀 더 자제해.
그렇지 않습니다)) 설명하겠습니다: 내 엔진은 리소스를 통해 사용자 프로그램에 연결됩니다. 즉, - 사용자 응용 프로그램은 자체 스레드에서 계산을 수행하고 다른 차트에 있을 수 있는 엔진(GUI 전달)에 데이터를 전달합니다. 매개변수 이벤트를 처리하고 GUI에 출력합니다. 즉, 처리를 두 개의 스레드로 나누는 것으로 나타났습니다. 그러나 내가 게시할 생성자에서는 그렇지 않습니다. 응용 프로그램은 자체 내부에 엔진을 포함하고 모든 것이 하나의 스레드에 있습니다. 그러나 프로세서의 로드는 동일합니다. 간단히 말해서, 기능 실행 순서에 대한 속도의 의존성은 더 커질 것입니다.
의미를 이해했습니다. 응용 프로그램이 분리되어 있고 GUI가 분리되어 있습니다.
그러나 GUI에서 출력 데이터 처리는 여전히 동기식으로 수행됩니다.
즉, 예를 들어 애플리케이션은 10,000개의 요소를 GUI로 보내고 GUI는 이러한 모든 요소를 순차적으로 처리합니다.
그게 문제 야. GUI에서 들어오는 요소의 처리와 출력을 병렬화하는 데 필요합니다. 기본, 텍스트, 아이콘입니다.
또한 셀당 3개의 사이클이 수행됩니다.