Fast235 : 내가 왜 16GB의 램을 32로 변경했는지, 테스터는 16ram +16 가상 머신을 먹었고, 지금은 32ram +31 가상 머신을 먹고 있습니다. 일종의 말도 안되는 소리입니다. SSD를 언로드하고 수명을 연장하기 위해 32GB를 구입했습니다. 그리고 무화과 . 하루에 테라바이트 쓰기, 불쌍한 ssd
그리고 페이징 파일 생성을 비활성화하면? 그리고 또 다른 옵션은 16기가 램 디스크에 이 파일을 만드는 것입니다.
이 프로세서의 테스트 속도에 실제로 영향을 주는 것이 무엇인지 결코 알지 못했습니다. 그것은 시도하지 않았고 결과는 동일한 값 내에 있습니다. CPU의 기본 주파수를 마더보드에서 미리 설정한 + 600MHz로 변경해도 아무런 결과가 발생하지 않습니다. 외부의 도움 없이 시험을 가속하기 때문인 것 같습니다. 표에서 볼 수 있듯이 메모리 특성도 실제로 영향을 미치지 않습니다. 관심있는 아이디어가있을 것입니다 pliz를 작성하십시오!
MT5에서 테스트를 위해 이 프로세서를 실제로 사용하는 것과 관련하여 즉시 생각하지 못할 몇 가지 뉘앙스가 있습니다!
첫째, 어떤 이유로 각 MT5 에이전트는 테스트가 다른 쌍이 아닌 한 쌍에서 실행되더라도 자체적으로 별도의 RAM을 할당합니다. 또한 예를 들어 십자가에서 테스트하면 여전히 메이저를 로드합니다. 결과적으로 2년 동안 실제 틱에 대해 테스트할 때 각 에이전트는 7GB의 메모리를 사용합니다. 예, 70%의 틱이 반복되는(동일한 Ask 및 Bid 사용) 인기 있는 브로커에서 시도했다고 말할 가치가 있습니다. 나는 사용자 정의 기록에 다시 시도하고 나중에 숫자를 게시합니다. 따라서 64GB의 메모리를 로드하려면 8개의 에이전트에서만 테스트할 수 있습니다. 탈출구는 반복되는 틱 필터링, 메모리 양의 지속적인 제어, 따라서 테스트 기간, 128GB 메모리 및 16개 에이전트에 대한 테스트가 포함된 사용자 지정 기록입니다. 그래서 무슨 일이!? 그래서 2년동안 테스트를 해봤는데.... 더 오래걸리면...?!
둘째. 당분간 다른 EVO 860 컴퓨터에서 SSD를 임시로 설치했는데 다른 문제가 발생했습니다. 8개 패스에서라도 최적화를 시작할 때 에이전트는 틱 기록을 RAM에 펌프하기 위해 SSD에 동시에 액세스하려고 시도합니다. 주문이 제공되지 않으므로 SSD가 "빨간색"이 되고 MT5 로그에 오류가 쏟아집니다.
저것들. 테스터는 메모리가 충분하지 않다고 표시되지만 틱을 다운로드할 수 없기 때문에 패스를 완료할 수 없습니다! 실제로 제 SSD가 그 당시 시스템 판독값으로 판단해 최대 600MB/s를 밀고 있었다고 추정한다면 64GB RAM도 채우는 데 100초 이상 걸릴 것입니다. 그래서 구형 SSD는 전혀 맞지 않아 3500GB/s의 EVO 970을 기다리고 있는데 그걸로 해도 30초 이상 128GB를 채울 것입니다. 저것들. 오류가 남습니다.
따라서 GENTLEMEN DEVELOPERS. 이 문제에 주의를 기울여야 합니다. 그렇지 않으면 멀티 코어 프로세서를 사용하는 것이 불가능하지는 않더라도 매우 불편할 것입니다!
가능하면 RAM 메모리를 아껴서 사용하는 것이 좋습니다. 하나의 통화 쌍에서 최적화하는 경우에만! 결국 테스트가 한 쌍에서 실행되면 모든 에이전트가 동일한 메모리 영역에 액세스하는 것이 확실히 가능합니다. 왜 그들은 각자 자신을 위해 사본을 생산해야합니까?! 그러면 메모리 부족 문제, 하드 디스크에서 읽는 속도가 사라지고 디자인이 훨씬 저렴해집니다!
이것이 가능하지 않다면 최소한 에이전트가 하드 디스크에 액세스할 수 있는 일종의 대기열을 만들고(또는) 복사 대기 시간을 늘리십시오. 그러나 메모리 사용을 최적화하면 확실히 훨씬 더 효율적입니다!
이 프로세서의 테스트 속도에 실제로 영향을 주는 것이 무엇인지 결코 알지 못했습니다. 그것은 시도하지 않았고 결과는 동일한 값 내에 있습니다. CPU의 기본 주파수를 마더보드에서 미리 설정한 + 600MHz로 변경해도 아무런 결과가 발생하지 않습니다. 외부의 도움 없이 테스트에서 가속하기 때문인 것 같습니다. 표에서 볼 수 있듯이 메모리 특성도 실제로 영향을 미치지 않습니다. 관심있는 아이디어가있을 것입니다 pliz를 작성하십시오!
프로세서의 주파수는 성능에 영향을 미칩니다. 프로세서를 수리하거나 통로를 설정해 보십시오. 계산의 경우 보조 프로세서가 주로 중요하므로 멀티스레딩(XMP)에서 증가가 선형이 아닙니다. 보조 프로세서에 의한 계산을 위한 더 빠른 데이터 준비로 인한 가속화.
나머지 포스트 틱은 특히 크로스가 필요한 경우 악합니다. 잘못된 재생의 비율이 크게 증가합니다. 교차 및 기본 통화 의 변동은 동기화되지 않습니다.
SSD를 다룰 때 오류가 이상합니다. 그 순간에 RAM이 정말 충분합니까? 가상 메모리를 비활성화 했습니까?
프로세서의 주파수는 성능에 영향을 미칩니다. 프로세서를 수리하거나 통로를 설정해 보십시오. 계산의 경우 보조 프로세서가 주로 중요하므로 멀티스레딩(XMP)에서 증가가 선형이 아닙니다. 보조 프로세서에 의한 계산을 위한 더 빠른 데이터 준비로 인한 가속화.
나머지 포스트 틱은 특히 크로스가 필요한 경우 악합니다. 잘못된 재생의 비율이 크게 증가합니다. 교차 및 기본 통화 의 변동은 동기화되지 않습니다.
SSD를 다룰 때 오류가 이상합니다. 그 순간에 RAM이 정말 충분합니까? 가상 메모리를 비활성화 했습니까?
네 확실합니다. 프로세서를 다른 주파수로 고정하면 결과가 눈에 띄게 나타납니다. 연습에 따르면 수정하지 않는 것이 좋습니다. 최신 BIOS 펌웨어에는 아직 해당 프로세서 모델이 없으며 아래에 미리 설정된 고정 주파수는 분명히 수정하지 않고 터보 모드에서 최대 작동 주파수를 발생시킵니다. 아직 BIOS에 대해 자세히 알아보지는 않았지만 종속성 기준은 이미 명확합니다. 새로운 펌웨어를 기다리겠습니다.
"시스템에 의해 선택된" 가상 메모리. SSD를 evo 860에서 evo 970 plus로 변경했습니다. RAM을 채우는 것이 더 재미있어졌습니다(약 3-4배). 많은 수의 에이전트로 시작할 수 있지만 현재보다 더 많은 에이전트를 켜두면 여전히 오류가 남아 있습니다. 그들에게 충분한 메모리. 그러나 실제로는 다음과 같은 최적화 전략을 개발했습니다. 작업 관리자는 항상 활성화되어 있습니다. 먼저 8개의 에이전트를 실행하고 RAM의 로드를 제어한 다음 RAM이 80% 채워질 때까지 4개를 더 켭니다. 아무 것도 건드리지 않으면 나사를 만지작거리지 않고 모든 것이 최적화됩니다. 하지만 실수를 하고 에이전트를 더 추가하자마자 ssd가 즉시 최대로 켜지고 어떤 이유로 Windows는 메모리를 약 50% 정도 언로드합니다. 최적화가 눈에 띄게 느려지며 유일한 방법은 터미널을 다시 시작하고 다시 시작하는 것입니다. 이 같은.
내가 왜 16GB의 램을 32로 변경했는지, 테스터는 16ram +16 가상 머신을 먹었고, 지금은 32ram +31 가상 머신을 먹고 있습니다. 일종의 말도 안되는 소리입니다. SSD를 언로드하고 수명을 연장하기 위해 32GB를 구입했습니다. 그리고 무화과 . 하루에 테라바이트 쓰기, 불쌍한 ssd
그리고 페이징 파일 생성을 비활성화하면? 그리고 또 다른 옵션은 16기가 램 디스크에 이 파일을 만드는 것입니다.
그리고 페이징 파일 생성을 비활성화하면? 그리고 또 다른 옵션은 16기가 램 디스크에 이 파일을 만드는 것입니다.
페이징이 비활성화되면 테스터는 모든 틱 모드에서 메모리가 충분하지 않다고 씁니다.
페이징이 비활성화되면 테스터는 메모리가 충분하지 않다고 씁니다.
그런 다음 RAM 디스크 옵션이 있습니다.
Tree_Brut_TestPL_F_Fast를 컴파일할 수 없습니다.
16% 멈춥니다. 2대의 다른 컴퓨터에서 시도했습니다. 분명히 MetaEditor 빌드에 있습니다. 컴파일된 pliz를 재설정합니다.
Tree_Brut_TestPL_F_Fast를 컴파일할 수 없습니다.
16% 멈춥니다. 2대의 다른 컴퓨터에서 시도했습니다. 분명히 MetaEditor 빌드에 있습니다. 컴파일된 pliz를 재설정합니다.
얼마나 기다리셨어요? 여기에서 컴파일은 최대 1시간이 소요됩니다. 이는 프로세서 코어의 성능에 따라 다릅니다.
컴파일된 파일은 포럼에 던질 수 없습니다.
얼마나 기다리셨어요? 여기에서 컴파일은 최대 1시간이 소요됩니다. 이는 프로세서 코어의 성능에 따라 다릅니다.
컴파일된 파일은 포럼에 던질 수 없습니다.
흠, 10분을 기다렸다)))). 그러나 거의 같은 크기로 Tree_Brut_TestPL_F는 약 5분 만에 컴파일되는 것 같았습니다. 더 기다릴게...
Ryzen 9 3950X에 대한 결과
이 프로세서의 테스트 속도에 실제로 영향을 주는 것이 무엇인지 결코 알지 못했습니다. 그것은 시도하지 않았고 결과는 동일한 값 내에 있습니다. CPU의 기본 주파수를 마더보드에서 미리 설정한 + 600MHz로 변경해도 아무런 결과가 발생하지 않습니다. 외부의 도움 없이 시험을 가속하기 때문인 것 같습니다. 표에서 볼 수 있듯이 메모리 특성도 실제로 영향을 미치지 않습니다. 관심있는 아이디어가있을 것입니다 pliz를 작성하십시오!
MT5에서 테스트를 위해 이 프로세서를 실제로 사용하는 것과 관련하여 즉시 생각하지 못할 몇 가지 뉘앙스가 있습니다!
첫째, 어떤 이유로 각 MT5 에이전트는 테스트가 다른 쌍이 아닌 한 쌍에서 실행되더라도 자체적으로 별도의 RAM을 할당합니다. 또한 예를 들어 십자가에서 테스트하면 여전히 메이저를 로드합니다. 결과적으로 2년 동안 실제 틱에 대해 테스트할 때 각 에이전트는 7GB의 메모리를 사용합니다. 예, 70%의 틱이 반복되는(동일한 Ask 및 Bid 사용) 인기 있는 브로커에서 시도했다고 말할 가치가 있습니다. 나는 사용자 정의 기록에 다시 시도하고 나중에 숫자를 게시합니다. 따라서 64GB의 메모리를 로드하려면 8개의 에이전트에서만 테스트할 수 있습니다. 탈출구는 반복되는 틱 필터링, 메모리 양의 지속적인 제어, 따라서 테스트 기간, 128GB 메모리 및 16개 에이전트에 대한 테스트가 포함된 사용자 지정 기록입니다. 그래서 무슨 일이!? 그래서 2년동안 테스트를 해봤는데.... 더 오래걸리면...?!
둘째. 당분간 다른 EVO 860 컴퓨터에서 SSD를 임시로 설치했는데 다른 문제가 발생했습니다. 8개 패스에서라도 최적화를 시작할 때 에이전트는 틱 기록을 RAM에 펌프하기 위해 SSD에 동시에 액세스하려고 시도합니다. 주문이 제공되지 않으므로 SSD가 "빨간색"이 되고 MT5 로그에 오류가 쏟아집니다.
저것들. 테스터는 메모리가 충분하지 않다고 표시되지만 틱을 다운로드할 수 없기 때문에 패스를 완료할 수 없습니다! 실제로 제 SSD가 그 당시 시스템 판독값으로 판단해 최대 600MB/s를 밀고 있었다고 추정한다면 64GB RAM도 채우는 데 100초 이상 걸릴 것입니다. 그래서 구형 SSD는 전혀 맞지 않아 3500GB/s의 EVO 970을 기다리고 있는데 그걸로 해도 30초 이상 128GB를 채울 것입니다. 저것들. 오류가 남습니다.
따라서 GENTLEMEN DEVELOPERS. 이 문제에 주의를 기울여야 합니다. 그렇지 않으면 멀티 코어 프로세서를 사용하는 것이 불가능하지는 않더라도 매우 불편할 것입니다!
가능하면 RAM 메모리를 아껴서 사용하는 것이 좋습니다. 하나의 통화 쌍에서 최적화하는 경우에만! 결국 테스트가 한 쌍에서 실행되면 모든 에이전트가 동일한 메모리 영역에 액세스하는 것이 확실히 가능합니다. 왜 그들은 각자 자신을 위해 사본을 생산해야합니까?! 그러면 메모리 부족 문제, 하드 디스크에서 읽는 속도가 사라지고 디자인이 훨씬 저렴해집니다!
이것이 가능하지 않다면 최소한 에이전트가 하드 디스크에 액세스할 수 있는 일종의 대기열을 만들고(또는) 복사 대기 시간을 늘리십시오. 그러나 메모리 사용을 최적화하면 확실히 훨씬 더 효율적입니다!
고맙습니다!
Ryzen 9 3950X에 대한 결과
이 프로세서의 테스트 속도에 실제로 영향을 주는 것이 무엇인지 결코 알지 못했습니다. 그것은 시도하지 않았고 결과는 동일한 값 내에 있습니다. CPU의 기본 주파수를 마더보드에서 미리 설정한 + 600MHz로 변경해도 아무런 결과가 발생하지 않습니다. 외부의 도움 없이 테스트에서 가속하기 때문인 것 같습니다. 표에서 볼 수 있듯이 메모리 특성도 실제로 영향을 미치지 않습니다. 관심있는 아이디어가있을 것입니다 pliz를 작성하십시오!
프로세서의 주파수는 성능에 영향을 미칩니다. 프로세서를 수리하거나 통로를 설정해 보십시오. 계산의 경우 보조 프로세서가 주로 중요하므로 멀티스레딩(XMP)에서 증가가 선형이 아닙니다. 보조 프로세서에 의한 계산을 위한 더 빠른 데이터 준비로 인한 가속화.
나머지 포스트 틱은 특히 크로스가 필요한 경우 악합니다. 잘못된 재생의 비율이 크게 증가합니다. 교차 및 기본 통화 의 변동은 동기화되지 않습니다.
SSD를 다룰 때 오류가 이상합니다. 그 순간에 RAM이 정말 충분합니까? 가상 메모리를 비활성화 했습니까?
프로세서의 주파수는 성능에 영향을 미칩니다. 프로세서를 수리하거나 통로를 설정해 보십시오. 계산의 경우 보조 프로세서가 주로 중요하므로 멀티스레딩(XMP)에서 증가가 선형이 아닙니다. 보조 프로세서에 의한 계산을 위한 더 빠른 데이터 준비로 인한 가속화.
나머지 포스트 틱은 특히 크로스가 필요한 경우 악합니다. 잘못된 재생의 비율이 크게 증가합니다. 교차 및 기본 통화 의 변동은 동기화되지 않습니다.
SSD를 다룰 때 오류가 이상합니다. 그 순간에 RAM이 정말 충분합니까? 가상 메모리를 비활성화 했습니까?
네 확실합니다. 프로세서를 다른 주파수로 고정하면 결과가 눈에 띄게 나타납니다. 연습에 따르면 수정하지 않는 것이 좋습니다. 최신 BIOS 펌웨어에는 아직 해당 프로세서 모델이 없으며 아래에 미리 설정된 고정 주파수는 분명히 수정하지 않고 터보 모드에서 최대 작동 주파수를 발생시킵니다. 아직 BIOS에 대해 자세히 알아보지는 않았지만 종속성 기준은 이미 명확합니다. 새로운 펌웨어를 기다리겠습니다.
"시스템에 의해 선택된" 가상 메모리. SSD를 evo 860에서 evo 970 plus로 변경했습니다. RAM을 채우는 것이 더 재미있어졌습니다(약 3-4배). 많은 수의 에이전트로 시작할 수 있지만 현재보다 더 많은 에이전트를 켜두면 여전히 오류가 남아 있습니다. 그들에게 충분한 메모리. 그러나 실제로는 다음과 같은 최적화 전략을 개발했습니다. 작업 관리자는 항상 활성화되어 있습니다. 먼저 8개의 에이전트를 실행하고 RAM의 로드를 제어한 다음 RAM이 80% 채워질 때까지 4개를 더 켭니다. 아무 것도 건드리지 않으면 나사를 만지작거리지 않고 모든 것이 최적화됩니다. 하지만 실수를 하고 에이전트를 더 추가하자마자 ssd가 즉시 최대로 켜지고 어떤 이유로 Windows는 메모리를 약 50% 정도 언로드합니다. 최적화가 눈에 띄게 느려지며 유일한 방법은 터미널을 다시 시작하고 다시 시작하는 것입니다. 이 같은.
이에 대한 테스트 결과 " Tree_Brut_TestPL_F_Fast ":
코어당 에이전트:
흐름 에이전트:
Tree_Brut_TestPL
Tree_Brut_TestPL_F