예, 이 형식에서는 작업이 병렬 처리됩니다. 검색 날짜가 변경될 때마다 시퀀스 세트의 다른 부분에서 최상의 기준에 대한 동시 검색을 시작할 수 있습니다. 예를 들어, 그것들을 20개의 부분으로 나누고 20명의 고문에게 작업을 분배하십시오. 그리고 그들이 파일을 읽고, 거래를 찾고, 가장 좋은 순서(##, 기준 및 파일 위치)만 다시 보내도록 합니다.
파일이 시퀀스 내에서가 아니라 전역적으로(모든 시퀀스에서) 거래 시간별로 정렬된 경우 다음 알고리즘이 가능합니다.
- 우리는 거래의 기준을 계산하고 그것을 후보로 간주합니다.
- 우리는 이 거래 내에서 시작되는 거래에 대한 기준을 계산하고, 가장 좋은 것이 발견되면 후보를 변경하고, 그렇지 않은 경우 후보를 선택한 것으로 간주하고 마감 날짜부터 새 주기를 시작합니다.
마감 시간으로 정렬할 수도 있습니다. 그러면 끝에서 이동합니다.
기준을 계산하려면 파일에 각 트랜잭션의 시퀀스 번호가 있어야 합니다.
이러한 파일을 다시 정렬하는 것도 재미가 없을 수 있습니다. "필요한 대로" 바로 작성해 볼 수 있습니다. 즉, 전체 시퀀스를 차례로 생성하는 것이 아니라 각 시퀀스에 대해 차례로 하나의 거래를 생성하고 작성 시 지능이 있는 작은 캐시를 사용합니다. 일부 생성 알고리즘의 경우 이는 물론 허용되지 않을 수 있습니다.
결국, 나는 내가 필요한 것을 깨달았습니다. 이 버전이 최종 버전이 되길 바랍니다.
말했듯이 모든 것은 매우 간단하게 분해되고 병렬화되며 주요 단계는 다음과 같습니다.
1. 각 시퀀스의 시작과 끝을 아는 것이 매우 유용할 것입니다.
비. 자신을 구문 분석할 수 있지만 이전의 잘린 시퀀스를 읽으려면 디스크에서 파일의 다음 부분을 읽을 때 반환해야 합니다.
또한 옵션 1.a를 고려할 것입니다. 최적이 아닐 수도 있지만 더 좋아합니다.
2. 파일의 일부(500mb)에 대한 시퀀스의 크기와 메모리 크기를 알면 다운로드해야 하는 파일 부분의 크기를 계산할 수 있습니다.
3. 병렬로 각 시퀀스의 시작과 끝을 알고 있기 때문에 시퀀스에 대한 계수를 계산합니다.
4. 각 시퀀스의 시작과 끝은 다중 스레드 대기열에 저장할 수 있습니다(포인트 2를 계산할 때 채워짐).
5. 계산 결과 - 구조(구조에서 시간과 계수 + 시퀀스 번호가 있는 배열))
6. 할당된 메모리 의 초기 크기의 절반(250MB)이 처리되면 시작과 끝이 있는 두 번째 큐의 형성으로 추가 프로세스가 시작됩니다.
7. 첫 번째 턴이 끝날 때까지 계산한 후 - 우리는 두 번째 턴에서 읽습니다. 두 번째 끝까지 세면서 - 우리는 첫 번째 차례부터 읽습니다.
8. 계수의 병렬 계산과 파일 읽기를 구성할 수 있습니다.
9. 그러나 계수를 계산한 각 결과는 저장해야 하며 여기가 응답으로 즉시 병합하는 것이 좋습니다.
병합 기능을 작성해야 합니다. 두 개의 계수 시퀀스를 하나의 하위 결과로, 두 개의 하위 결과를 하나의 약간 완전한 하위 결과로
10. 병합 프로세스를 병렬로 수행할 수도 있습니다.
11. 결과는 언제입니까? 추가 파일에서 읽은 시퀀스의 크기가 끝나면 두 스택이 비어 있고 계수 계산이 종료되고,
그런 다음 하위 결과 병합 프로세스가 끝날 때까지 기다려야 합니다(스레드 안전 대기열을 사용할 수도 있음).
마지막으로 다른 스트림의 하위 결과를 병합합니다.
여기에 가능한 모든 것의 최대 부하가 있는 옵션이 있습니다. 아마도 더 나은 것이 있을 것입니다. 기쁠 것입니다.
기능 필요:
입력 시퀀스에서 계수 시퀀스 생성
두 개의 계수 시퀀스를 하나의 하위 결과로 병합(여기서 정밀도 손실 가능)
두 개의 하위 결과를 하나의 약간 완전한 하위 결과로 병합(여기서 정밀도 손실 가능)
까다로운 부분 로딩 메커니즘을 발명하는 것이 가능하다고 생각하지만 발명해야 합니다.
예를 들어, 첫 번째 읽기 동안 시작 날짜 이전에 마지막 거래가 마감된 각 패스를 찾아 X개의 이전 거래를 읽고 이 거래가 끝나는 파일 지점을 기억합니다.
그 후, 결과에 나타나는 첫 번째 거래를 찾은 다음 새로운 데이터로만 작업합니다. 원하는 지점에서 새로운 실제 날짜로 파일을 읽고 배열의 거래를 이동할 때마다 (고정 배열을 얻습니다. 크기 - X 요소).
이것은 다중 읽기 문제(그냥 필요하지 않음)와 메모리 문제(X백만 거래를 맞출 수 있는 경우에만)를 모두 해결할 것입니다.
예, 이것이 알고리즘입니다.
X백만 트랜잭션에 대한 메모리를 할당할 수 있는 경우( 구조의 크기는 미리 알고 있음) 파일을 한 번 읽을 수 있습니다.
그렇지 않은 경우 기억된 포인터로 돌아갈 때마다 마지막 X 거래의 판독값을 추가해야 합니다. 그러면 파일을 여러 번 읽지만 여전히 드물게 읽습니다.
시퀀스의 구조는 고정되어 있습니다: ##, Transactions[X], Criterion, PositionFilePointer. 추가 사항은 없습니다.
코드로 남아 있습니다 =)
그리고 더 바람직한 결과는 무엇입니까?
dll 또는 여전히 mql로 계산합니까?
예, 이 형식에서는 작업이 병렬 처리됩니다. 검색 날짜가 변경될 때마다 시퀀스 세트의 다른 부분에서 최상의 기준에 대한 동시 검색을 시작할 수 있습니다. 예를 들어, 그것들을 20개의 부분으로 나누고 20명의 고문에게 작업을 분배하십시오. 그리고 그들이 파일을 읽고, 거래를 찾고, 가장 좋은 순서(##, 기준 및 파일 위치)만 다시 보내도록 합니다.
모두 감사합니다!
그리고 더 바람직한 결과는 무엇입니까?
dll 또는 여전히 mql로 계산합니까?
나는 반년 동안 mql을 사용하지 않았습니다. 조금 바보 일 수 있습니다. 내가 틀렸는지 확인하십시오.
Открываем файл, начинаем читать, последовательно заполняя массив сделок первого прохода
각 패스에 대해 디스크에서 별도로 읽을 계획입니까? 디스크에서 10^6번 읽으시겠습니까?
한 번에 전체를 읽는 것이 아니라 개별적으로 읽는 데 문제가 있지 않을까요? 아니면 예비로 솔리드 버퍼링을 사용하여 모든 것이 최고 수준에서 구현됩니까?
거래에 도달하면 개시 시간이 >= SearchedDate입니다(배열에 추가되지 않음).
나는 당신의 기억이 어디에서 해방되었는지 보지 못하고 계속 축적되고 축적됩니다.
하나의 기준에 대해 전체 배열을 유지하는 이유는 무엇입니까? 새 기준을 계산할 때 간단히 비교하고 적절한 기준을 남길 수도 있습니다.
상위 10개 기준을 찾고 싶다면 10개 기준의 배열을 만든 다음 값으로 채우고 정렬하고 이진 검색 으로 다음 기준을 삽입하는 것이 더 최적입니다.
각 패스에 대해 디스크에서 별도로 읽을 계획입니까? 디스크에서 10^6번 읽으시겠습니까?
당신은 여전히 모든 것을 읽어야합니다. 한 번에(처음부터 끝까지) 작동하지 않으므로 조각으로 읽습니다(그러나 여전히, 결국에는 전체 파일).
한 번에 전체를 읽는 것이 아니라 개별적으로 읽는 데 문제가 있지 않을까요? 아니면 예비로 솔리드 버퍼링을 사용하여 모든 것이 최고 수준에서 구현됩니까?
한 조각을 읽고 있습니다. 청크 크기는 검색 날짜 이전에 특정 순서로 있었던 거래 수에 따라 결정됩니다.
나는 당신의 기억이 어디에서 해방되었는지 보지 못하고 계속 축적되고 축적됩니다.
메모리는 시퀀스 구조의 배열에 대해 한 번 할당됩니다.
시퀀스의 구조에는 다음이 포함됩니다. #, 시퀀스의 모든 거래 구조 배열 [X], 기준 값, 파일 포인터 위치.
다음 단계는 구조의 요소(거래 배열 포함)만 채우는 것입니다. 배열의 거래는 이동되므로 메모리의 각 시퀀스에는 항상 X 거래만 있습니다.
상위 10개 기준을 찾고 싶다면 10개 기준의 배열을 만든 다음 값으로 채우고 정렬하고 이진 검색으로 다음 기준을 삽입하는 것이 더 최적입니다.
병렬화 포함.
그러나 작업의 프레임워크 내에서 트랜잭션 구조의 배열이 있는 구조에서 이중 하나를 제거해도 차이가 없습니다.
연구 결과를 공유합니다.
7529MB 바이너리 캐시 파일은 다음과 같습니다.
결론: RAM 디스크를 사용하여 하나의 큰 파일을 읽는 속도는 약 2.5배입니다.
파일이 시퀀스 내에서가 아니라 전역적으로(모든 시퀀스에서) 거래 시간별로 정렬된 경우 다음 알고리즘이 가능합니다.
- 우리는 거래의 기준을 계산하고 그것을 후보로 간주합니다.
- 우리는 이 거래 내에서 시작되는 거래에 대한 기준을 계산하고, 가장 좋은 것이 발견되면 후보를 변경하고, 그렇지 않은 경우 후보를 선택한 것으로 간주하고 마감 날짜부터 새 주기를 시작합니다.
마감 시간으로 정렬할 수도 있습니다. 그러면 끝에서 이동합니다.
기준을 계산하려면 파일에 각 트랜잭션의 시퀀스 번호가 있어야 합니다.
이러한 파일을 다시 정렬하는 것도 재미가 없을 수 있습니다. "필요한 대로" 바로 작성해 볼 수 있습니다. 즉, 전체 시퀀스를 차례로 생성하는 것이 아니라 각 시퀀스에 대해 차례로 하나의 거래를 생성하고 작성 시 지능이 있는 작은 캐시를 사용합니다. 일부 생성 알고리즘의 경우 이는 물론 허용되지 않을 수 있습니다.
파일이 시퀀스 내에서가 아니라 전역적으로(모든 시퀀스에서) 거래 시간별로 정렬된 경우 다음 알고리즘이 가능합니다.
- 우리는 거래의 기준을 계산하고 그것을 후보로 간주합니다.
내가 그러한 파일을 작성한다고 가정해 봅시다(컴퓨터 시간이 15시간이 걸리더라도 현재 파일을 변환하기만 하면 됩니다).
그러나 바로 거기에 - 첫 번째 지점에 - 플러그가 있습니다. 그러한 파일이 있는 시퀀스의 마지막 X 거래에 대한 기준을 계산하는 방법은 무엇입니까?
반복합니다. 기준은 한 번 계산할 수 없으며 매개변수가 변경될 수 있습니다.