이것은 올바른 접근 방식이 아닙니다. 작업을 한 번에 하나씩 제공하는 것이 아니라 무료 리소스가 있는 경우 용량을 재분배해야 합니다. 이미 발행된 작업을 취소하고 실행을 위해 다른 사람에게 제공합니다. 동시에 커널에 실행에 필요한 수의 새 작업을 제공하기 위해 각 에이전트에 대한 성능 분석을 수행해야 합니다.
이것은 완전한 헛소리입니다, 죄송합니다
> 이미 발행된 작업을 취소하고 다른 사람에게 실행하도록 제공
나는 이것이 전혀 현실적이지 않다고 생각하며 왜 작업 배치를 생성하는 것이 더 쉬울 때 첫 번째 여유 스레드에 하나의 작업을 주고 완료될 때까지 기다렸다가 첫 번째 해제된 스레드에 다음 작업을 부여합니다(주의를 기울입니다. 프로세서 코어가 아닌 스레드라는 단어로 스레드에 대한 제한을 제거해야 합니다. 이것은 프로그래머의 권리가 아니라 사용자의 권리입니다. 이제 스레드가 아닌 실제 코어만 네트워크 스트림으로 작동한다는 것을 상기시켜 드리겠습니다. 인위적으로 성능을 절반으로 떨어뜨림)
> 커널에 실행에 필요한 수의 새 작업을 제공하려면 각 에이전트에 대한 성능 분석을 수행해야 합니다.
동일한 성능을 가진 동일한 프로세서의 코어는 작업에 따라 다른 속도로 계산되기 때문에 이것은 전혀 필요하지 않습니다.
나는 이것이 전혀 현실적이지 않다고 생각하며 왜 작업 배치를 생성하는 것이 더 쉬울 때 첫 번째 자유 스레드에 하나의 작업을주고 완료 될 때까지 기다렸다가 첫 번째 해제 된 스레드에 다음 작업을 제공합니다 (나는 지불합니다. 프로세서 코어가 아닌 스레드라는 단어에 주의하십시오. 스레드에 대한 제한은 제거해야 합니다. 이것은 프로그래머의 권리가 아니라 사용자의 권리입니다. 이제 스레드가 아닌 실제 코어만 네트워크 스트림으로 작동함을 상기시켜 드리겠습니다. , 성능을 인위적으로 절반으로 낮춤)
> 커널에 실행에 필요한 수의 새 작업을 제공하려면 각 에이전트에 대한 성능 분석을 수행해야 합니다.
동일한 성능을 가진 동일한 프로세서의 코어는 작업에 따라 다른 속도로 계산되기 때문에 이것은 전혀 필요하지 않습니다.
옵티마이저에 대한 경험이 거의 없고 완료된 패스에 대한 정보가 늦게 온다는 것, 작업이 완료된 후 에이전트가 매우 무거울 수 있는 프레임을 보낼 수 있다는 것을 이해하지 못하는 것 같습니다. 이 모든 것이 통신 지연 및 최적화 속도를 늦춥니다. 따라서 작업은 배치로 발행되어야 하고 구현의 역학을 따라야 합니다. 즉, 작업 완료에 가까운 에이전트에게 새 작업을 발행해야 합니다.
옵티마이저에 대한 경험이 거의 없고 완료된 패스에 대한 정보가 늦게 온다는 것, 작업이 완료된 후 에이전트가 매우 무거울 수 있는 프레임을 보낼 수 있다는 것을 이해하지 못하는 것 같습니다. 이 모든 것이 통신 지연 및 최적화를 늦추십시오. 따라서 작업은 배치로 발행되어야 하고 구현의 역학을 따라야 합니다. 즉, 작업 완료에 가까운 에이전트에게 새 작업을 발행해야 합니다.
> 최적화 프로그램에 대한 경험이 좋지 않은 것 같습니다.
농담??? 6년 연속
>완료된 패스에 대한 정보가 늦게 나오므로 작업을 완료한 후 에이전트 가 프레임을 전송합니다. 이 프레임 은 매우 무거울 수 있으며 이 모든 것이 통신 지연과 최적화 속도 저하로 이어집니다. 따라서 작업은 배치로 발행되어야 하고 구현의 역학을 따라야 합니다. 즉, 작업 완료에 가까운 에이전트에게 새 작업을 발행해야 합니다.
>이는 통신 지연으로 이어지고 최적화 속도가 느려집니다.
그리고 그것은 중요하지 않습니다. 네트워크는 이제 빠릅니다.
그러나 하나의 불행한 코어가 팩에서 많은 작업을 계산하는 동안 코어가 유휴 상태라는 사실은 다른 모든(수십 개의 코어)가 서 있기 때문에 최적화를 극도로 느리게 합니다. 코어는 멈추지 않고 지속적으로 계산해야 합니다.
많은 매개변수에 대해 최적화된 적이 없는 것 같습니다... 실제 경험이 없다고 주장하지 마십시오.
>완료된 패스에 대한 정보가 늦게 도착하여 작업을 완료한 후 에이전트가 매우 무거울 수 있는 프레임을 보내며 이 모든 것이 통신 지연과 최적화 속도 저하로 이어집니다. 따라서 작업은 배치로 발행되어야 하고 구현의 역학을 따라야 합니다. 즉, 작업 완료에 가까운 에이전트에게 새 작업을 발행해야 합니다.
>이는 통신 지연으로 이어지고 최적화 속도가 느려집니다.
그리고 그것은 중요하지 않습니다. 네트워크는 이제 빠릅니다.
그러나 불행한 코어 하나가 팩에서 많은 작업을 계산하는 동안 코어가 유휴 상태라는 사실은 나머지(수십 개의 코어)가 모두 서 있기 때문에 최적화가 극도로 느려집니다. 코어는 멈추지 않고 지속적으로 계산해야 합니다.
많은 매개변수에 대해 최적화된 적이 없는 것 같습니다... 실제 경험이 없다고 주장하지 마십시오.
당신은 자신만만한 이기주의자가 될 수 없습니다. 그의 그물은 빠르고 자기 중심적입니다. 반대로 네트워크는 수십, 수백 메가바이트에 이르면 빠르지 않습니다.
Primitive Expert Advisor 최적화 는 최적화가 사용되는 전부가 아닙니다. 지평을 확장하고 수학적 계산을 사용하십시오.
예, 이것은 주로 이익을위한 프로젝트이며 사용자를 기쁘게하지 않는다는 점을 명심하십시오. 이와 관련하여 메커니즘은 작업의 무작위 분배와 구현을 위한 올바른 재무 회계를 고려해야 합니다 ...
Скальперские автоматические системы по праву считаются вершиной алгоритмического трейдинга, но при этом они же являются и самыми сложными для написания кода. В этой статье мы покажем, как с помощью встроенных средств отладки и визуального тестирования строить стратегии, основанные на анализе поступающих тиков. Для выработки правил входа и...
이것은 올바른 접근 방식이 아닙니다. 작업을 한 번에 하나씩 제공하는 것이 아니라 무료 리소스가 있는 경우 용량을 재분배해야 합니다. 이미 발행된 작업을 취소하고 실행을 위해 다른 사람에게 제공합니다. 동시에 커널에 실행에 필요한 수의 새 작업을 제공하기 위해 각 에이전트에 대한 성능 분석을 수행해야 합니다.
이것은 완전한 헛소리입니다, 죄송합니다
> 이미 발행된 작업을 취소하고 다른 사람에게 실행하도록 제공
나는 이것이 전혀 현실적이지 않다고 생각하며 왜 작업 배치를 생성하는 것이 더 쉬울 때 첫 번째 여유 스레드에 하나의 작업을 주고 완료될 때까지 기다렸다가 첫 번째 해제된 스레드에 다음 작업을 부여합니다(주의를 기울입니다. 프로세서 코어가 아닌 스레드라는 단어로 스레드에 대한 제한을 제거해야 합니다. 이것은 프로그래머의 권리가 아니라 사용자의 권리입니다. 이제 스레드가 아닌 실제 코어만 네트워크 스트림으로 작동한다는 것을 상기시켜 드리겠습니다. 인위적으로 성능을 절반으로 떨어뜨림)
> 커널에 실행에 필요한 수의 새 작업을 제공하려면 각 에이전트에 대한 성능 분석을 수행해야 합니다.
동일한 성능을 가진 동일한 프로세서의 코어는 작업에 따라 다른 속도로 계산되기 때문에 이것은 전혀 필요하지 않습니다.
이것은 완전한 헛소리입니다, 죄송합니다
> 이미 발행된 작업을 취소하고 다른 사람에게 실행하도록 제공
나는 이것이 전혀 현실적이지 않다고 생각하며 왜 작업 배치를 생성하는 것이 더 쉬울 때 첫 번째 자유 스레드에 하나의 작업을주고 완료 될 때까지 기다렸다가 첫 번째 해제 된 스레드에 다음 작업을 제공합니다 (나는 지불합니다. 프로세서 코어가 아닌 스레드라는 단어에 주의하십시오. 스레드에 대한 제한은 제거해야 합니다. 이것은 프로그래머의 권리가 아니라 사용자의 권리입니다. 이제 스레드가 아닌 실제 코어만 네트워크 스트림으로 작동함을 상기시켜 드리겠습니다. , 성능을 인위적으로 절반으로 낮춤)
> 커널에 실행에 필요한 수의 새 작업을 제공하려면 각 에이전트에 대한 성능 분석을 수행해야 합니다.
동일한 성능을 가진 동일한 프로세서의 코어는 작업에 따라 다른 속도로 계산되기 때문에 이것은 전혀 필요하지 않습니다.
옵티마이저에 대한 경험이 거의 없고 완료된 패스에 대한 정보가 늦게 온다는 것, 작업이 완료된 후 에이전트가 매우 무거울 수 있는 프레임을 보낼 수 있다는 것을 이해하지 못하는 것 같습니다. 이 모든 것이 통신 지연 및 최적화 속도를 늦춥니다. 따라서 작업은 배치로 발행되어야 하고 구현의 역학을 따라야 합니다. 즉, 작업 완료에 가까운 에이전트에게 새 작업을 발행해야 합니다.
옵티마이저에 대한 경험이 거의 없고 완료된 패스에 대한 정보가 늦게 온다는 것, 작업이 완료된 후 에이전트가 매우 무거울 수 있는 프레임을 보낼 수 있다는 것을 이해하지 못하는 것 같습니다. 이 모든 것이 통신 지연 및 최적화를 늦추십시오. 따라서 작업은 배치로 발행되어야 하고 구현의 역학을 따라야 합니다. 즉, 작업 완료에 가까운 에이전트에게 새 작업을 발행해야 합니다.
> 최적화 프로그램에 대한 경험이 좋지 않은 것 같습니다.
농담??? 6년 연속
>완료된 패스에 대한 정보가 늦게 나오므로 작업을 완료한 후 에이전트 가 프레임을 전송합니다. 이 프레임 은 매우 무거울 수 있으며 이 모든 것이 통신 지연과 최적화 속도 저하로 이어집니다. 따라서 작업은 배치로 발행되어야 하고 구현의 역학을 따라야 합니다. 즉, 작업 완료에 가까운 에이전트에게 새 작업을 발행해야 합니다.
>이는 통신 지연으로 이어지고 최적화 속도가 느려집니다.
그리고 그것은 중요하지 않습니다. 네트워크는 이제 빠릅니다.
그러나 하나의 불행한 코어가 팩에서 많은 작업을 계산하는 동안 코어가 유휴 상태라는 사실은 다른 모든(수십 개의 코어)가 서 있기 때문에 최적화를 극도로 느리게 합니다. 코어는 멈추지 않고 지속적으로 계산해야 합니다.
많은 매개변수에 대해 최적화된 적이 없는 것 같습니다... 실제 경험이 없다고 주장하지 마십시오.
> 최적화 프로그램에 대한 경험이 좋지 않은 것 같습니다.
농담??? 6년 연속
>완료된 패스에 대한 정보가 늦게 도착하여 작업을 완료한 후 에이전트가 매우 무거울 수 있는 프레임을 보내며 이 모든 것이 통신 지연과 최적화 속도 저하로 이어집니다. 따라서 작업은 배치로 발행되어야 하고 구현의 역학을 따라야 합니다. 즉, 작업 완료에 가까운 에이전트에게 새 작업을 발행해야 합니다.
>이는 통신 지연으로 이어지고 최적화 속도가 느려집니다.
그리고 그것은 중요하지 않습니다. 네트워크는 이제 빠릅니다.
그러나 불행한 코어 하나가 팩에서 많은 작업을 계산하는 동안 코어가 유휴 상태라는 사실은 나머지(수십 개의 코어)가 모두 서 있기 때문에 최적화가 극도로 느려집니다. 코어는 멈추지 않고 지속적으로 계산해야 합니다.
많은 매개변수에 대해 최적화된 적이 없는 것 같습니다... 실제 경험이 없다고 주장하지 마십시오.
당신은 자신만만한 이기주의자가 될 수 없습니다. 그의 그물은 빠르고 자기 중심적입니다. 반대로 네트워크는 수십, 수백 메가바이트에 이르면 빠르지 않습니다.
Primitive Expert Advisor 최적화 는 최적화가 사용되는 전부가 아닙니다. 지평을 확장하고 수학적 계산을 사용하십시오.
예, 이것은 주로 이익을위한 프로젝트이며 사용자를 기쁘게하지 않는다는 점을 명심하십시오. 이와 관련하여 메커니즘은 작업의 무작위 분배와 구현을 위한 올바른 재무 회계를 고려해야 합니다 ...
당신은 자신만만한 이기주의자가 될 수 없습니다. 그의 그물은 빠르고 자기 중심적입니다. 반대로 네트워크는 수십, 수백 메가바이트에 이르면 빠르지 않습니다.
Primitive Expert Advisor 최적화 는 최적화가 사용되는 전부가 아닙니다. 지평을 확장하고 수학적 계산을 사용하십시오.
예, 이것은 주로 이익을위한 프로젝트이며 사용자를 기쁘게하지 않는다는 점을 명심하십시오. 이와 관련하여 메커니즘은 작업의 무작위 분배와 구현을 위한 올바른 재무 회계를 고려해야 합니다 ...
수십 및 수백 메가 바이트는 아무것도 아니며 소요된 시간은 최소이며 전혀 관련이 없습니다. 쓰기 전에 이 트래픽이 한 번에 하나씩 패킷으로 전송되어야 한다고 생각할 것입니다.
> Primitive Expert Advisor 최적화 는 최적화가 사용되는 전부가 아닙니다. 지평을 확장하고 수학적 계산을 사용하십시오.
나는 당신에게 지평선에 대해 같은 것을 기원합니다
그리고 이기심에 대해서도
그리고 내 것은 원시적인 것과는 거리가 멀고 일반적으로 그것이 필요한 이유는 무엇입니까?
시간 비용 및 최적화 속도 측면에서 귀하의 이니셔티브는 완전히 터무니없다고 생각합니다.
당신은 단순히 당신 자신의 특정 최적화 사례를 고려하고 Alexey는 자신의 것을 고려합니다(그는 수백 MB의 Expert Advisor를 가지고 있고 보내는 데 오랜 시간이 걸립니다).
그리고 MQ는 옵티마이저의 전반적인 사용을 살펴보고 당신과 Alexey가 아닌 대다수에 맞게 조정합니다.
적어도 로컬 코어에서는 작업이 재배포됩니다. 어딘가에 재배포되지 않는 경우 개발자가 이를 고려할 수 있도록 재현할 예제를 제공하십시오.
당신은 단순히 당신 자신의 특정 최적화 사례를 고려하고 Alexey는 자신의 것을 고려합니다(그는 수백 MB의 Expert Advisor를 가지고 있고 보내는 데 오랜 시간이 걸립니다).
그리고 MQ는 옵티마이저의 전반적인 사용을 살펴보고 당신과 Alexey가 아닌 대다수에 맞게 조정합니다.
적어도 로컬 코어에서는 작업이 재배포됩니다. 어딘가에 재배포되지 않는 경우 개발자가 이를 고려할 수 있도록 재현할 예제를 제공하십시오.
내 경우가 특별하다는 데 동의합니다.
새 원격 에이전트가 연결된 경우 작업 할당에 문제가 있습니다. 이는 다른 작업에서 리소스가 해제될 때 발생합니다.
당신은 단순히 당신 자신의 특정 최적화 사례를 고려하고 Alexey는 자신의 것을 고려합니다(그는 수백 MB의 Expert Advisor를 가지고 있고 보내는 데 오랜 시간이 걸립니다).
그리고 MQ는 옵티마이저의 전반적인 사용을 살펴보고 당신과 Alexey가 아닌 대다수에 맞게 조정합니다.
적어도 로컬 코어에서는 작업이 재배포됩니다. 어딘가에 재배포되지 않는 경우 개발자가 이를 고려할 수 있도록 재현할 예제를 제공하십시오.
나도 아마 개인이 있을 것 같지만 사실은 "아마도"
> 개발자도 이를 고려할 수 있도록 재현할 수 있는 예를 제공합니다.
not real ... 내 어드바이저를 올릴 수 없다, 나는 표준에 관심이 없다, 나는 그들이 재배포되지 않는 것을 볼 수 있도록 스크린 샷을 찍을 수 있습니다
그들이 재배포된다면 - 그것은 문제에 대한 해결책이 될 것입니다.
계산 시간의 세 배 .... 옵티마이저가 정상 작동하게 될까요???? 많은 무료 코어가 유휴 상태입니다 ...
둘째날은 아무 것도 계산하지 않고, 로컬 12개 정도, 네트워크 30개 정도의 모든 코어가 유휴 상태이고, 일부러 건드리지 않고...완전한 열거, 무슨 생각을 하는지 모르겠다 , 아마도 삶의 의미나 코로나바이러스 치료제를 찾고 있을 것입니다 :-)
옵티마이저의 작동불능과 느림으로 인해 옵티마이저를 포기할 필요가 있다고 생각합니다
물리적 코어만 제한하고 각 코어가 아닌 특정 코어에만 완고하고 어리석게 많은 작업을 분배하는 것과 같은 MT의 최신 결정(하나의 작업)은 고성능 계산 개발자의 완전한 오해를 말해줍니다.