예, 이 형식에서는 작업이 병렬 처리됩니다. 검색 날짜가 변경될 때마다 시퀀스 세트의 다른 부분에서 최상의 기준에 대한 동시 검색을 시작할 수 있습니다. 예를 들어, 그것들을 20개의 부분으로 나누고 20명의 고문에게 작업을 분배하십시오. 그리고 그들이 파일을 읽고, 거래를 찾고, 가장 좋은 순서(##, 기준 및 파일 위치)만 다시 보내도록 합니다.
모두 감사합니다!
디스크에서 읽는 것은 비용이 많이 드는 작업입니다. 여러 Expert Advisors에서 이 알고리즘을 실행하면 모든 것이 디스크에서 읽는 속도로 + 다른 위치에서 + 부분으로 + 다른 위치에서 제한되며 이 아이디어는 속도를 제공하지 않을 가능성이 큽니다.
번호의 용량은 시스템 용량이 아니라 레코드 코드의 고유성에 따라 결정됩니다. (숫자의 용량)이 1바이트의 배수여야 함은 분명합니다.
64비트는 제 생각에 과도합니다. :)
1,000,000개의 레코드가 있는 경우 고유 레코드 코드(최대 65536개의 레코드)에 대해 16자리 숫자로는 충분하지 않습니다. 이 시간.
Intel(Itanium), AMD(운영 체제에 대해 이야기하지 않음) 32비트 및 64비트 프로세서의 아키텍처를 보십시오. 32/64 - 주소 버스 분해능이지만 동시에 1바이트의 메모리에 액세스하는 경우에도 32/64비트(4/8바이트)를 한 기계 사이클에서 메모리에서 읽습니다.
따라서 메모리에서 2바이트 또는 8바이트를 읽는 것은 성능 측면에서 절대적으로 중요하지 않습니다.
2. 하나의 시퀀스에서 모든 트랜잭션에 대한 계수를 계산하는 방법과 답변을 저장할 데이터 구조
3. 이전 단락의 두 가지 답변을 새 답변으로 병합하는 방법을 좀 더 완벽하게
4. 포인트 3의 최종 답변을 필요한 간격으로 나누는 방법( 희망 날짜 = 거래 마감 시간 + 1)
간격 RequiredDate 를 나눌 추가 부분의 수를 선택하여 약간 다른 알고리즘을 얻을 수 있습니다.
원래 작성자의 알고리즘과 다른 오류가 발생할 수 있습니다.
4점 모두에 대해 - DBMS 측에서 데이터 처리.
"약간 다른" 알고리즘에 관해서는 당신이 의미하는 바가 완전히 명확하지 않습니다. 하지만. "작성자"의 알고리즘과 비교하여 이 "약간 다른" 알고리즘의 오류를 어떻게든 계산하려면 두 알고리즘을 모두 구현해야 합니다. 그리고 주제는 "저자"알고리즘을 구현하는 기술적 문제와 관련하여 만들어졌습니다.
디스크에서 읽는 것은 비용이 많이 드는 작업입니다. 여러 Expert Advisors에서 이 알고리즘을 실행하면 모든 것이 디스크에서 읽는 속도로 + 다른 위치에서 + 부분으로 + 다른 위치에서 제한되며 이 아이디어는 속도를 제공하지 않을 가능성이 큽니다.
HDD가 가장 느린 장치라고 가정해 보겠습니다. 사실입니다. 그러나 우리는 이러한 모든 계산을 사용하여 여러 Expert Advisor를 시작하는 것에 대해 이야기하지 않습니다. 가장 가능성 있는 응용 프로그램은 신호 생성인 것 같습니다. 필요한 성능 + MT4 + 이 개발 = 신호 제공자를 갖춘 Amazon의 클라우드 서버를 가정해 보겠습니다.
"약간 다른" 알고리즘에 관해서는 당신이 의미하는 바가 완전히 명확하지 않습니다. 하지만. "작성자"의 알고리즘과 비교하여 이 "약간 다른" 알고리즘의 오류를 어떻게든 계산하려면 두 알고리즘을 모두 구현해야 합니다. 그리고 주제는 "저자"알고리즘을 구현하는 기술적 문제와 관련하여 만들어졌습니다.
이 사실을 감안할 때 말하는 오류를 계산하기 위해 어떤 방법론을 사용할 것입니까?
저자로부터 내가 이해하는 한(어디서든 정확히 무엇이 필요한지에 대한 이해적이고 완전한 설명이 없기 때문에 갑자기 다시 뭔가 잘못되었습니다), 범위는 버전에서 이 범위에서 선택된 최대 계수로 잘립니다. 나는 이러한 각 범위를 N개의 하위 범위로 나누고 병합할 때 계수의 하나의 값만 맞출 수 있다고 제안했습니다. N = 5일 때 범위는 비율 0.2 0.4 0.6 0.8 1로만 나눌 수 있습니다. 그리고 저자의 것에서는 0에서 1 사이의 값이 잘립니다. 그것은 범위의 0.2의 오류입니다. N = 5에서 최대.
그리고 아직 완전한 명확성이 없기 때문에 작성자의 게시물이 얼마나 정확하게 해석되었는지에 관한 모든 것입니다.
저자로부터 내가 이해하는 한(어디서든 정확히 무엇이 필요한지에 대한 이해적이고 완전한 설명이 없기 때문에 갑자기 다시 뭔가 잘못되었습니다), 범위는 버전에서 이 범위에서 선택된 최대 계수로 잘립니다. 나는 이러한 각 범위를 N개의 하위 범위로 나누는 것을 제안했습니다. 여기에서 병합될 때 계수의 하나의 값만 적합할 수 있습니다. N = 5일 때 범위는 비율 0.2 0.4 0.6 0.8 1로만 나눌 수 있습니다. 그리고 저자의 것에서는 0에서 1 사이의 값이 잘립니다. 그것은 범위의 0.2의 오류입니다. N = 5에서 최대.
그리고 아직 완전한 명확성이 없기 때문에 작성자의 게시물이 얼마나 정확하게 해석되었는지에 관한 모든 것입니다.
예, 분명히 재무부가 프로젝트를 명령 했지만 특정 정보가 충분하지 않습니다. 그러나 모든 사람은 토론에서 자신에게 흥미로운 것을 찾을 수 있습니다. 이것에서 나는 긍정적인 토론을 봅니다.
범위의 이산화에 대해 귀하의 아이디어는 명확합니다. 그리고 N=100, 1000...(순수하게 수학적으로 가능함)인 경우 이러한 분할은 시스템 리소스의 성능 및 사용 측면에서 백래시를 유발할 것입니다. 수학 외에 물리학도 있음)
우리는 메모리에 파일 조각이 있고, 그것을 살펴보고 기준을 계산하는 데 필요한 길이를 선택하고 동일한 시퀀스에 속하는 거래만 선택합니다. 그런 다음 이 샘플을 기반으로 기준을 계산합니다. 그건 그렇고, 아이디어는 선택에서 재귀를 사용할 기회가 있다는 것입니다.
따라서 다른 시퀀스에서 수백만 개의 트랜잭션을 정렬해야 합니다! 그게 바로 내가 말하는 것입니다.
알시믹스 :
새 데이터 삽입 문제 - 어떻게든 해결하십시오.
문제가 없는 한 고정된 양의 데이터가 있습니다.
더엑스퍼트 : 그건 그렇고, 각 시퀀스의 시작 위치를 알면 원하는 날짜를 이진 검색으로 찾을 수 있습니다. 왜냐하면 거래는 시간순으로 정렬됩니다.
+1, 아이디어 주셔서 감사합니다.
자기소개서 :
1. 위의 " 기준을 시퀀스의 마지막 20개 거래에 대한 평균 이익으로 설정합니다. "에 따라 이익의 이동 기대치를 하나의 기준으로 이해해야 합니다. 또 뭐가 있나요?
데이터베이스에서 시퀀스 ID와 해당 이동 평균이 있는 테이블을 생성합니다. 부적절한 시퀀스는 즉시 제거해야 합니다. 이것은 로봇의 요청에 따라 로봇의 프로세스 상태를 표시하는 DBMS 수준에서 동시 모드의 절차에 의해 수행되어야 합니다.
FilterAvgProfit(pProfitValue, pTrades, pDeviation) 프로시저가 있다고 가정해 보겠습니다.
여기서 pProfitValue는 원하는 이익, pTrades는 이동 평균 이익에 대한 거래 수, pDeviation은 pProfitValue에서 허용되는 편차입니다.
결과는 시퀀스 ID와 평균 이익 값이 있는 완성된 테이블입니다.
1a. 다른 기준은 무엇입니까? 중요하지 않습니다. 계산이 지정된 길이의 일련의 트랜잭션을 기반으로 하는 것이 중요합니다.
1b. 거래 N 종료 시 기준 값이 나쁘다는 이유로 시퀀스를 어떻게 폐기할 수 있습니까? 그녀가 좋아지면? 기준이 "더하기"가 되지 않은 솔직히 실패한 시퀀스만 삭제할 수 있습니다. 그리고 너무 많아도 안됩니다.
자기소개서 :
4. 내가 이해하는 한, 전략을 선택하는 방향으로 보면 이 작업을 너무 자주 수행해서는 안 됩니다(예: 모든 바 또는 주문 열기 직전). 현재 전략이 N개의 손실 거래를 연속적으로 가져오는 경우 이 접근 방식을 사용하는 것이 합리적입니다. 그러면 다른 전략을 선택할 수 있으며 "결정을 내리는" 데 시간을 보내야 하므로 갈 곳이 없습니다. 또는 이러한 선택을 주 1회(시장이 닫히는 주말)에 수행하고 현재 선택한 전략을 확인하거나 다른 전략으로 이동합니다. 이러한 조건에서 최적의 권장 전략 목록을 거래자에게 표시할 수 있습니다. 그런 다음 시장이 열리고 새로운 마음으로 (월요일) 거래자가 선택을 확인합니다 (또는 더 일찍, 시장이 열리기 전에 ... 이메일로 알림 등).
글쎄, 그것은 이데올로기의 문제입니다. 이제 그에 관한 것이 아닙니다 ;)
알시믹스 :
구조 배열에 메모리를 할당하고 다음을 얻습니다.
기준 값배열과 파일 포인터 위치 배열이 필요한 이유는 무엇입니까? (하나의 기준과 마지막 거래를 유지할 생각이 없었습니까?)
기준 값의 배열 - 몇 가지 최상의 시퀀스를 정렬하고 선택하기 위한 것입니다(미래를 위해).
파일 포인터 위치 - 올바른 위치에서 각 시퀀스의 검색을 계속합니다(다른 방법은?).
알시믹스 :
내가 올바르게 이해 했습니까?
첫 번째 패스 - 0에서 SearchDate까지의 간격으로 검색
그런 다음 최상의 기준을 찾고 SearchDate = 거래 마감 시간 + 1
이제 "Trade Closing Time"에서SearchDate까지의 간격을 검색하고 있습니까 ???
예, 이 형식에서는 작업이 병렬 처리됩니다. 검색 날짜가 변경될 때마다 시퀀스 세트의 다른 부분에서 최상의 기준에 대한 동시 검색을 시작할 수 있습니다. 예를 들어, 그것들을 20개의 부분으로 나누고 20명의 고문에게 작업을 분배하십시오. 그리고 그들이 파일을 읽고, 거래를 찾고, 가장 좋은 순서(##, 기준 및 파일 위치)만 다시 보내도록 합니다.
모두 감사합니다!
디스크에서 읽는 것은 비용이 많이 드는 작업입니다. 여러 Expert Advisors에서 이 알고리즘을 실행하면 모든 것이 디스크에서 읽는 속도로 + 다른 위치에서 + 부분으로 + 다른 위치에서 제한되며 이 아이디어는 속도를 제공하지 않을 가능성이 큽니다.
데이터를 한 번만 읽으면 모든 것을 계산할 수 있습니다 - 주요 욕망
디스크에서 읽는 것은 비용이 많이 드는 작업입니다. 여러 Expert Advisors에서 이 알고리즘을 실행하면 모든 것이 디스크에서 읽는 속도로 + 다른 위치에서 + 부분으로 + 다른 위치에서 제한되며 이 아이디어는 속도를 제공하지 않을 가능성이 큽니다.
그리고 누가 분산 컴퓨팅 이 단일 워크스테이션에서 수행되어야 한다고 말했습니까? 그러한 제한은 없습니다.) 예, 위에서 언급한 대로 RAM 디스크가 도움이 됩니다.
알고리즘을 조금 바꿔보면 어떨까요?
1. 여러 시퀀스를 한 번에 다운로드하는 방법과 시작 위치와 끝 위치를 아는 방법
2. 하나의 시퀀스에서 모든 트랜잭션에 대한 계수를 계산하는 방법과 답변을 저장할 데이터 구조
3. 이전 단락의 두 가지 답변을 새 답변으로 병합하는 방법을 좀 더 완벽하게
4. 포인트 3의 최종 답변을 필요한 간격으로 나누는 방법( 희망 날짜 = 거래 마감 시간 + 1)
간격 RequiredDate 를 나눌 추가 부분의 수를 선택하여 약간 다른 알고리즘을 얻을 수 있습니다.
원래 작성자의 알고리즘과 다른 오류가 발생할 수 있습니다.
번호의 용량은 시스템 용량이 아니라 레코드 코드의 고유성에 따라 결정됩니다. (숫자의 용량)이 1바이트의 배수여야 함은 분명합니다.
64비트는 제 생각에 과도합니다. :)
1,000,000개의 레코드가 있는 경우 고유 레코드 코드(최대 65536개의 레코드)에 대해 16자리 숫자로는 충분하지 않습니다. 이 시간.
Intel(Itanium), AMD(운영 체제에 대해 이야기하지 않음) 32비트 및 64비트 프로세서의 아키텍처를 보십시오. 32/64 - 주소 버스 분해능이지만 동시에 1바이트의 메모리에 액세스하는 경우에도 32/64비트(4/8바이트)를 한 기계 사이클에서 메모리에서 읽습니다.
따라서 메모리에서 2바이트 또는 8바이트를 읽는 것은 성능 측면에서 절대적으로 중요하지 않습니다.
원칙적으로 이러한 종류의 파일 처리를 위해 Windows 서비스를 작성할 수 있습니다.
그러나 나는 여전히 DBMS를 사용하는 경향이 있습니다.
알고리즘을 조금 바꿔보면 어떨까요?
1. 여러 시퀀스를 한 번에 다운로드하는 방법과 시작 위치와 끝 위치를 아는 방법
2. 하나의 시퀀스에서 모든 트랜잭션에 대한 계수를 계산하는 방법과 답변을 저장할 데이터 구조
3. 이전 단락의 두 가지 답변을 새 답변으로 병합하는 방법을 좀 더 완벽하게
4. 포인트 3의 최종 답변을 필요한 간격으로 나누는 방법( 희망 날짜 = 거래 마감 시간 + 1)
간격 RequiredDate 를 나눌 추가 부분의 수를 선택하여 약간 다른 알고리즘을 얻을 수 있습니다.
원래 작성자의 알고리즘과 다른 오류가 발생할 수 있습니다.
4점 모두에 대해 - DBMS 측에서 데이터 처리.
"약간 다른" 알고리즘에 관해서는 당신이 의미하는 바가 완전히 명확하지 않습니다. 하지만. "작성자"의 알고리즘과 비교하여 이 "약간 다른" 알고리즘의 오류를 어떻게든 계산하려면 두 알고리즘을 모두 구현해야 합니다. 그리고 주제는 "저자"알고리즘을 구현하는 기술적 문제와 관련하여 만들어졌습니다.
이 사실을 감안할 때 말하는 오류를 계산하기 위해 어떤 방법론을 사용할 것입니까?
데이터를 한 번만 읽으면 모든 것을 계산할 수 있습니다 - 주요 욕망
디스크에서 읽는 것은 비용이 많이 드는 작업입니다. 여러 Expert Advisors에서 이 알고리즘을 실행하면 모든 것이 디스크에서 읽는 속도로 + 다른 위치에서 + 부분으로 + 다른 위치에서 제한되며 이 아이디어는 속도를 제공하지 않을 가능성이 큽니다.
HDD가 가장 느린 장치라고 가정해 보겠습니다. 사실입니다. 그러나 우리는 이러한 모든 계산을 사용하여 여러 Expert Advisor를 시작하는 것에 대해 이야기하지 않습니다. 가장 가능성 있는 응용 프로그램은 신호 생성인 것 같습니다. 필요한 성능 + MT4 + 이 개발 = 신호 제공자를 갖춘 Amazon의 클라우드 서버를 가정해 보겠습니다.
4점 모두에 대해 - DBMS 측에서 데이터 처리.
"약간 다른" 알고리즘에 관해서는 당신이 의미하는 바가 완전히 명확하지 않습니다. 하지만. "작성자"의 알고리즘과 비교하여 이 "약간 다른" 알고리즘의 오류를 어떻게든 계산하려면 두 알고리즘을 모두 구현해야 합니다. 그리고 주제는 "저자"알고리즘을 구현하는 기술적 문제와 관련하여 만들어졌습니다.
이 사실을 감안할 때 말하는 오류를 계산하기 위해 어떤 방법론을 사용할 것입니까?
저자로부터 내가 이해하는 한(어디서든 정확히 무엇이 필요한지에 대한 이해적이고 완전한 설명이 없기 때문에 갑자기 다시 뭔가 잘못되었습니다), 범위는 버전에서 이 범위에서 선택된 최대 계수로 잘립니다. 나는 이러한 각 범위를 N개의 하위 범위로 나누고 병합할 때 계수의 하나의 값만 맞출 수 있다고 제안했습니다. N = 5일 때 범위는 비율 0.2 0.4 0.6 0.8 1로만 나눌 수 있습니다. 그리고 저자의 것에서는 0에서 1 사이의 값이 잘립니다. 그것은 범위의 0.2의 오류입니다. N = 5에서 최대.
그리고 아직 완전한 명확성이 없기 때문에 작성자의 게시물이 얼마나 정확하게 해석되었는지에 관한 모든 것입니다.
저자로부터 내가 이해하는 한(어디서든 정확히 무엇이 필요한지에 대한 이해적이고 완전한 설명이 없기 때문에 갑자기 다시 뭔가 잘못되었습니다), 범위는 버전에서 이 범위에서 선택된 최대 계수로 잘립니다. 나는 이러한 각 범위를 N개의 하위 범위로 나누는 것을 제안했습니다. 여기에서 병합될 때 계수의 하나의 값만 적합할 수 있습니다. N = 5일 때 범위는 비율 0.2 0.4 0.6 0.8 1로만 나눌 수 있습니다. 그리고 저자의 것에서는 0에서 1 사이의 값이 잘립니다. 그것은 범위의 0.2의 오류입니다. N = 5에서 최대.
그리고 아직 완전한 명확성이 없기 때문에 작성자의 게시물이 얼마나 정확하게 해석되었는지에 관한 모든 것입니다.
예, 분명히 재무부가 프로젝트를 명령 했지만 특정 정보가 충분하지 않습니다. 그러나 모든 사람은 토론에서 자신에게 흥미로운 것을 찾을 수 있습니다. 이것에서 나는 긍정적인 토론을 봅니다.
범위의 이산화에 대해 귀하의 아이디어는 명확합니다. 그리고 N=100, 1000...(순수하게 수학적으로 가능함)인 경우 이러한 분할은 시스템 리소스의 성능 및 사용 측면에서 백래시를 유발할 것입니다. 수학 외에 물리학도 있음)
우리는 메모리에 파일 조각이 있고, 그것을 살펴보고 기준을 계산하는 데 필요한 길이를 선택하고 동일한 시퀀스에 속하는 거래만 선택합니다. 그런 다음 이 샘플을 기반으로 기준을 계산합니다. 그건 그렇고, 아이디어는 선택에서 재귀를 사용할 기회가 있다는 것입니다.
따라서 다른 시퀀스에서 수백만 개의 트랜잭션을 정렬해야 합니다! 그게 바로 내가 말하는 것입니다.
새 데이터 삽입 문제 - 어떻게든 해결하십시오.
문제가 없는 한 고정된 양의 데이터가 있습니다.
그건 그렇고, 각 시퀀스의 시작 위치를 알면 원하는 날짜를 이진 검색으로 찾을 수 있습니다. 왜냐하면 거래는 시간순으로 정렬됩니다.
+1, 아이디어 주셔서 감사합니다.
1. 위의 " 기준을 시퀀스의 마지막 20개 거래에 대한 평균 이익으로 설정합니다. "에 따라 이익의 이동 기대치를 하나의 기준으로 이해해야 합니다. 또 뭐가 있나요?
데이터베이스에서 시퀀스 ID와 해당 이동 평균이 있는 테이블을 생성합니다. 부적절한 시퀀스는 즉시 제거해야 합니다. 이것은 로봇의 요청에 따라 로봇의 프로세스 상태를 표시하는 DBMS 수준에서 동시 모드의 절차에 의해 수행되어야 합니다.
FilterAvgProfit(pProfitValue, pTrades, pDeviation) 프로시저가 있다고 가정해 보겠습니다.
여기서 pProfitValue는 원하는 이익, pTrades는 이동 평균 이익에 대한 거래 수, pDeviation은 pProfitValue에서 허용되는 편차입니다.
결과는 시퀀스 ID와 평균 이익 값이 있는 완성된 테이블입니다.
1a. 다른 기준은 무엇입니까? 중요하지 않습니다. 계산이 지정된 길이의 일련의 트랜잭션을 기반으로 하는 것이 중요합니다.
1b. 거래 N 종료 시 기준 값이 나쁘다는 이유로 시퀀스를 어떻게 폐기할 수 있습니까? 그녀가 좋아지면?
기준이 "더하기"가 되지 않은 솔직히 실패한 시퀀스만 삭제할 수 있습니다. 그리고 너무 많아도 안됩니다.
4. 내가 이해하는 한, 전략을 선택하는 방향으로 보면 이 작업을 너무 자주 수행해서는 안 됩니다(예: 모든 바 또는 주문 열기 직전). 현재 전략이 N개의 손실 거래를 연속적으로 가져오는 경우 이 접근 방식을 사용하는 것이 합리적입니다. 그러면 다른 전략을 선택할 수 있으며 "결정을 내리는" 데 시간을 보내야 하므로 갈 곳이 없습니다. 또는 이러한 선택을 주 1회(시장이 닫히는 주말)에 수행하고 현재 선택한 전략을 확인하거나 다른 전략으로 이동합니다. 이러한 조건에서 최적의 권장 전략 목록을 거래자에게 표시할 수 있습니다. 그런 다음 시장이 열리고 새로운 마음으로 (월요일) 거래자가 선택을 확인합니다 (또는 더 일찍, 시장이 열리기 전에 ... 이메일로 알림 등).
글쎄, 그것은 이데올로기의 문제입니다. 이제 그에 관한 것이 아닙니다 ;)
구조 배열에 메모리를 할당하고 다음을 얻습니다.
기준 값 배열과 파일 포인터 위치 배열이 필요한 이유는 무엇입니까? (하나의 기준과 마지막 거래를 유지할 생각이 없었습니까?)
기준 값의 배열 - 몇 가지 최상의 시퀀스를 정렬하고 선택하기 위한 것입니다(미래를 위해).
파일 포인터 위치 - 올바른 위치에서 각 시퀀스의 검색을 계속합니다(다른 방법은?).
내가 올바르게 이해 했습니까?
첫 번째 패스 - 0에서 SearchDate까지의 간격으로 검색
그런 다음 최상의 기준을 찾고 SearchDate = 거래 마감 시간 + 1
이제 "Trade Closing Time"에서 SearchDate까지의 간격을 검색하고 있습니까 ???
각 시퀀스에 대한 기준을 계산하려면 X 트랜잭션이 해당 간격에 맞아야 합니까?
1. 예, 먼저 0부터 SearchDate까지
2. 아니요. RequiredDate가 이동하고 시퀀스를 처리하고(배열에 트랜잭션 추가) "PreviousProcessedDeal - RequiredDate" 간격에 있습니다.
이상한 결과.
다음은 로드 중인 작업 서버 시스템에서 가져온 것입니다.
우리는 디스크 프레임 없이 몇 배나 더 오래 프로젝트를 수집합니다.
복잡해지기 시작합니다.
아마도 테스트 스크립트를 작성하고 유사한 작업에서 확인할 수 있도록 파일을 첨부해야 할 것입니다.
일반 하드 드라이브가 있습니다 - wdc wd1002FAEX-00Y9A0, 사양으로 판단하면 최대 속도는 126MB / s입니다.
리뷰로 판단하면 그 정도 정도는 짜낼 수 있습니다. 내가 뭔가 잘못하고 있는 건 아닐까?
대본을 보자..
그가 말하는 것 - 큰 파일을 큰 조각으로 읽어야 합니다. 그렇지 않으면 작은 파일이 최대 10배 이상 길어질 수 있습니다.
큰 부분을 읽는 방법?
제 생각에는 문제의 해결책은 소스 데이터를 인코딩하는 것입니다.
정보를 잃지 않고 완전한 거래 정보를 인코딩하는 방법은 무엇입니까?
이상한 결과.
다음은 로드 중인 작업 서버 시스템에서 가져온 것입니다.
우리는 디스크 프레임 없이 몇 배나 더 오래 프로젝트를 수집합니다.
나는 기억에 대해 쓰는 것을 잊었다.
DDR3, 1333MHz:
Softperfect RAM Disk 3.4.5, NTFS를 사용했지만(차이가 있나요?)
그리고 또 다른 세부 사항 - 12000MB RAM 디스크와 1-2GB의 여유 메모리(작업용)만 남습니다.