따라서 다른 시퀀스에서 수백만 개의 트랜잭션을 정렬해야 합니다! 그게 바로 내가 말하는 것입니다.
글쎄, 우리는 하나의 단일 숫자 (시퀀스 번호)를 확인하는 것에 대해 이야기하고 있습니다. 백만은 그러한 기본 작업에 그다지 많지 않습니다. 기준을 재귀적으로 고려한다면 이것은 파일의 한 패스일 뿐이므로 어쨌든 수행해야 합니다. 또 다른 점은 재귀를 위한 데이터의 "맵"이 동일한 수백만 요소(한 시퀀스에 대한 매개변수 수를 곱함)가 된다는 것입니다.
대안도 가능합니다. 정렬하기 전에 암기하여 기준을 계속 계산합니다. 다시 말하지만, 재귀를 사용하는 능력은 매우 중요합니다.
X = 20(20개 거래에 대한 기준 계산)에서 내 데이터를 처리하는 데 약 112분이 걸렸고(정확히 눈치채지 못함) 어레이 시프트(프로파일러로 판단하면 40%)가 가장 큰 몫을 차지했습니다.
배열 및 기타 최적화를 반복한 후 처리가 시작되었습니다.
X = 20에서: 48분
X = 50에서: 60분
65번의 거래(백만 시퀀스를 곱한 값)를 위한 충분한 메모리만 있었습니다. 물론 이것은 충분하지 않습니다. 나는 적어도 100을 세었습니다.
다음 단계는 거래에 대한 불필요한 정보를 모두 버리는 것이었습니다. 개장 시간과 폐장 시간, 이익 포인트만 남기고 X = 185에서 벗어날 수 있었습니다.
다음 - 파일 작업 속도를 높이면 FileReadXXX가 시간의 30%를 차지합니다(디스패처는 디스크에 대한 작업이 없고 프로세서만 로드된다고 말합니다).
FileRead - 특히 FileSeek 다음의 첫 번째 것, 즉 순차 읽기가 빠릅니다.
새로운 결과를 알려드립니다.
kazakov.v : C ++에서 이것은 64K-128K 버퍼로 확장하여 수행되며 sscanfs가 매우 느리기 때문에 자체 파서로 이를 구문 분석하는 것이 좋습니다.
저는 WinAPI를 통해 파일 작업을 시도할 것입니다. 사실 이 서비스 데스크는 다음과 같이 조언했습니다.
알시믹스 :
나는 아이디어를 10번 추진하고 있습니다. 다른 파일에 있는 시퀀스 위치의 시작 값으로 다른 파일을 생성하려면 시퀀스 구조 에 트랜잭션 수를 저장할 필요조차 없습니다.
나는 색인이 무엇을 줄 것인지 이해하지 못한다.
거래 건수 기록이 안 되고, 순차 읽기가 빨리 되는데, 문제는 파일을 이동한 후 블록을 읽는 데 있다.
제안된 행동 알고리즘을 작성하십시오.
C-4 :
작업은 사소하지 않지만 아직 한 줄의 코드도 없습니다. Andrey, 여기 많은 사람들이 관심을 갖고 있습니다. 문제를 공식화하고 테스트 데이터를 제공합니다. 스포츠 프로그램을 준비하십시오.
데이터 작업에 대한 일반적인 원칙과 함께 테스트 데이터 + 의사 코드가 필요합니다.
작업은 from 및 to에서 공식화됩니다.
그리고 테스트 데이터는 내가 이전에 게시한 약간 수정된 스크립트로 생성할 수 있습니다.
조금 있다가 할게요.
주 : 기본에서 옵션을 정렬하려면 어떻게 해야 합니까? 기준에 따라 기록에 대한 거래를 생성하는 것이 더 나을 수 있습니까? 아니다? 요구되는 것과 동일하지 않습니까?
테스트의 경우 물론 예이지만 문제 해결의 경우 물론 아니오)
솔직한 :
글쎄, 우리는 하나의 단일 숫자 (시퀀스 번호)를 확인하는 것에 대해 이야기하고 있습니다. 백만은 그러한 기본 작업에 그다지 많지 않습니다. 기준을 재귀적으로 고려한다면 이것은 파일의 한 패스일 뿐이므로 어쨌든 수행해야 합니다. 또 다른 점은 재귀를 위한 데이터의 "맵"이 동일한 수백만 요소(한 시퀀스에 대한 매개변수 수를 곱함)가 된다는 것입니다.
대안도 가능합니다. 정렬하기 전에 암기하여 기준을 계속 계산합니다. 다시 말하지만, 재귀를 사용하는 능력은 매우 중요합니다.
어떤 작업이든 많은 작업이 있을 것이 분명하지만 원래 버전에서는 작업이 실제로 더 적습니까?
원래 버전에서는 통과된 이력에서 마지막 거래를 찾을 때 기준을 한 번 계산할 수 있습니다.
그리고 귀하의 버전에서는 모든 시퀀스의 X 트랜잭션에 맞도록 파일의 그러한 조각을 읽어야 합니다. 이것은 X * 시퀀스 수보다 훨씬 많을 것입니다. 트랜잭션 수가 다르며 고르게 분배되지 않을 수 있습니다.
업데이트된 스크립트를 첨부하고 있습니다. 이제 동일한 트랜잭션을 기록할 뿐만 아니라 지정된 설정( 평생 - 시작 및 종료, 이익 - 시작 및 종료)으로 임의의 시퀀스를 생성합니다.
내 것과 비슷한 파일을 얻으려면 기본 옵션으로 스크립트를 실행하십시오.
2014.08.28 04:12:36.044sTest_ReadWriteBIN EURUSD,M15: 57.1초 에 작성된 140000 개 시퀀스 2014.08.28 04:13:20.688sTest_ReadWriteBIN EURUSD,M15: 44.0초 에 6632MB 로드(150.7MB /초 )
1. 오리지널 버전에서는 통과된 이력에서 마지막 거래를 찾을 때 기준을 한 번 계산할 수 있습니다.
2. 그리고 당신의 버전에서는 모든 시퀀스의 X 트랜잭션에 맞는 파일 조각을 읽어야 합니다. 이것은 X * 시퀀스 수보다 훨씬 많을 것입니다. 트랜잭션 수가 다르며 고르게 분배되지 않을 수 있습니다.
1. 이것은 매우 명확하지 않습니다. 기준의 최대(최소)를 찾고 있다면 결국 모든 후보에 대한 기준을 계산해야 합니다. 국지적 또는 글로벌 극한값을 추구하는지 여부는 중요하지 않습니다.
2. 더 많을수록 요구되는 메모리의 크기가 허용 가능한 크기인지 아닌지는 분명합니다. 또한 디스크 읽기 속도 측면에서 블록 크기가 클수록 이론상 더 좋습니다. 물론 지금까지는 RAM에 문제가 발생하지 않습니다. 읽기는 한 번만 순차적으로 발생하는 것이 기본적으로 중요합니다.
정렬하기 전에 기준을 계산하는 옵션은 실제로 두 번 읽어야합니다. 그러나 특히 데이터를 여러 개의 더 작은 파일로 분할하고 후속 공동 처리를 할 수 있는 가능성을 고려할 때 이점이 있습니다.
그러나 구현이 없으면 모든 인수가 추상적으로 유지됩니다. 그래서 이 논의의 시점에서 제가 휴직을 하는 것이 적절할 것 같습니다. :)
MQL4/5의 파일 작업은 매우 효율적인 캐싱 메커니즘을 거치므로 매우 효율적이고 높은 읽기 및 쓰기 속도를 달성할 수 있습니다.
바이트 단위로 데이터를 스트리밍할 수도 있습니다. 모든 데이터는 먼저 내부 버퍼에 빠르게 수집되고 큰 조각으로만 디스크에 기록됩니다. WinAPI 호출 횟수가 최소화되어 빠른 속도를 제공합니다. 읽기도 비슷합니다. 사전에 작동하고 큰 덩어리에서 빼며 WinAPI에 매우 드물게 액세스하고 최소한의 오버헤드로 캐시에서 데이터를 매우 빠르게 반환합니다.
대략적으로 말하자면, 509개 빌드와 비교하여 MQL4/5의 파일 작업 속도가 10배 증가했습니다. 속도 측정").
따라서 다른 시퀀스에서 수백만 개의 트랜잭션을 정렬해야 합니다! 그게 바로 내가 말하는 것입니다.
글쎄, 우리는 하나의 단일 숫자 (시퀀스 번호)를 확인하는 것에 대해 이야기하고 있습니다. 백만은 그러한 기본 작업에 그다지 많지 않습니다. 기준을 재귀적으로 고려한다면 이것은 파일의 한 패스일 뿐이므로 어쨌든 수행해야 합니다. 또 다른 점은 재귀를 위한 데이터의 "맵"이 동일한 수백만 요소(한 시퀀스에 대한 매개변수 수를 곱함)가 된다는 것입니다.
대안도 가능합니다. 정렬하기 전에 암기하여 기준을 계속 계산합니다. 다시 말하지만, 재귀를 사용하는 능력은 매우 중요합니다.
어떤 작업이든 많은 작업이 있을 것이 분명하지만 원래 버전에는 작업이 더 적습니까?
C++에서는 다음과 같은 경우 파서 없이 가능합니다.
나는 아이디어를 10번 추진하고 있습니다. 다른 파일에 있는 시퀀스 위치의 시작 값으로 다른 파일을 생성하려면 시퀀스 구조 에 트랜잭션 수를 저장할 필요조차 없습니다.
앞에서 이미 언급한 일반적인 색인을 얻을 수 있습니다.
위에서 설명한 알고리즘을 구현했습니다.
X = 20(20개 거래에 대한 기준 계산)에서 내 데이터를 처리하는 데 약 112분이 걸렸고(정확히 눈치채지 못함) 어레이 시프트(프로파일러로 판단하면 40%)가 가장 큰 몫을 차지했습니다.
배열 및 기타 최적화를 반복한 후 처리가 시작되었습니다.
65번의 거래(백만 시퀀스를 곱한 값)를 위한 충분한 메모리만 있었습니다. 물론 이것은 충분하지 않습니다. 나는 적어도 100을 세었습니다.
다음 단계는 거래에 대한 불필요한 정보를 모두 버리는 것이었습니다. 개장 시간과 폐장 시간, 이익 포인트만 남기고 X = 185에서 벗어날 수 있었습니다.
다음 - 파일 작업 속도를 높이면 FileReadXXX가 시간의 30%를 차지합니다(디스패처는 디스크에 대한 작업이 없고 프로세서만 로드된다고 말합니다).
FileRead - 특히 FileSeek 다음의 첫 번째 것, 즉 순차 읽기가 빠릅니다.
새로운 결과를 알려드립니다.
C ++에서 이것은 64K-128K 버퍼로 확장하여 수행되며 sscanfs가 매우 느리기 때문에 자체 파서로 이를 구문 분석하는 것이 좋습니다.
저는 WinAPI를 통해 파일 작업을 시도할 것입니다. 사실 이 서비스 데스크는 다음과 같이 조언했습니다.
나는 아이디어를 10번 추진하고 있습니다. 다른 파일에 있는 시퀀스 위치의 시작 값으로 다른 파일을 생성하려면 시퀀스 구조 에 트랜잭션 수를 저장할 필요조차 없습니다.
나는 색인이 무엇을 줄 것인지 이해하지 못한다.
거래 건수 기록이 안 되고, 순차 읽기가 빨리 되는데, 문제는 파일을 이동한 후 블록을 읽는 데 있다.
제안된 행동 알고리즘을 작성하십시오.
작업은 사소하지 않지만 아직 한 줄의 코드도 없습니다. Andrey, 여기 많은 사람들이 관심을 갖고 있습니다. 문제를 공식화하고 테스트 데이터를 제공합니다. 스포츠 프로그램을 준비하십시오.
데이터 작업에 대한 일반적인 원칙과 함께 테스트 데이터 + 의사 코드가 필요합니다.
작업은 from 및 to에서 공식화됩니다.
그리고 테스트 데이터는 내가 이전에 게시한 약간 수정된 스크립트로 생성할 수 있습니다.
조금 있다가 할게요.
기본에서 옵션을 정렬하려면 어떻게 해야 합니까? 기준에 따라 기록에 대한 거래를 생성하는 것이 더 나을 수 있습니까? 아니다? 요구되는 것과 동일하지 않습니까?
테스트의 경우 물론 예이지만 문제 해결의 경우 물론 아니오)
솔직한 :
글쎄, 우리는 하나의 단일 숫자 (시퀀스 번호)를 확인하는 것에 대해 이야기하고 있습니다. 백만은 그러한 기본 작업에 그다지 많지 않습니다. 기준을 재귀적으로 고려한다면 이것은 파일의 한 패스일 뿐이므로 어쨌든 수행해야 합니다. 또 다른 점은 재귀를 위한 데이터의 "맵"이 동일한 수백만 요소(한 시퀀스에 대한 매개변수 수를 곱함)가 된다는 것입니다.
대안도 가능합니다. 정렬하기 전에 암기하여 기준을 계속 계산합니다. 다시 말하지만, 재귀를 사용하는 능력은 매우 중요합니다.
어떤 작업이든 많은 작업이 있을 것이 분명하지만 원래 버전에서는 작업이 실제로 더 적습니까?
원래 버전에서는 통과된 이력에서 마지막 거래를 찾을 때 기준을 한 번 계산할 수 있습니다.
그리고 귀하의 버전에서는 모든 시퀀스의 X 트랜잭션에 맞도록 파일의 그러한 조각을 읽어야 합니다. 이것은 X * 시퀀스 수보다 훨씬 많을 것입니다. 트랜잭션 수가 다르며 고르게 분배되지 않을 수 있습니다.
2 모두:
어쨌든 지원에 감사드립니다.
어렵지 않다면 테스트 스크립트 를 실행하고 결과를 공유하십시오.
그리고 테스트 데이터는 이전에 내가 게시한 약간 수정된 스크립트로 생성할 수 있습니다.
업데이트된 스크립트를 첨부하고 있습니다. 이제 동일한 트랜잭션을 기록할 뿐만 아니라 지정된 설정( 평생 - 시작 및 종료, 이익 - 시작 및 종료)으로 임의의 시퀀스를 생성합니다.
내 것과 비슷한 파일을 얻으려면 기본 옵션으로 스크립트를 실행하십시오.
2014.08.28 04:12:36.044 sTest_ReadWriteBIN EURUSD,M15: 57.1초 에 작성된 140000 개 시퀀스
2014.08.28 04:13:20.688 sTest_ReadWriteBIN EURUSD,M15: 44.0초 에 6632MB 로드(150.7MB /초 )
그 후에 알고리즘을 해결할 수 있습니다.
가장 게으른 경우 - Google 드라이브에 파일이 있는 아카이브.
komposter :
1. 오리지널 버전에서는 통과된 이력에서 마지막 거래를 찾을 때 기준을 한 번 계산할 수 있습니다.
2. 그리고 당신의 버전에서는 모든 시퀀스의 X 트랜잭션에 맞는 파일 조각을 읽어야 합니다. 이것은 X * 시퀀스 수보다 훨씬 많을 것입니다. 트랜잭션 수가 다르며 고르게 분배되지 않을 수 있습니다.
1. 이것은 매우 명확하지 않습니다. 기준의 최대(최소)를 찾고 있다면 결국 모든 후보에 대한 기준을 계산해야 합니다. 국지적 또는 글로벌 극한값을 추구하는지 여부는 중요하지 않습니다.
2. 더 많을수록 요구되는 메모리의 크기가 허용 가능한 크기인지 아닌지는 분명합니다. 또한 디스크 읽기 속도 측면에서 블록 크기가 클수록 이론상 더 좋습니다. 물론 지금까지는 RAM에 문제가 발생하지 않습니다. 읽기는 한 번만 순차적으로 발생하는 것이 기본적으로 중요합니다.
정렬하기 전에 기준을 계산하는 옵션은 실제로 두 번 읽어야합니다. 그러나 특히 데이터를 여러 개의 더 작은 파일로 분할하고 후속 공동 처리를 할 수 있는 가능성을 고려할 때 이점이 있습니다.
그러나 구현이 없으면 모든 인수가 추상적으로 유지됩니다. 그래서 이 논의의 시점에서 제가 휴직을 하는 것이 적절할 것 같습니다. :)
파일을 스티칭할 수 있습니까? 파일의 시작과 끝 비트를 인덱싱합니다.
예를 들어, lam 파일에서 초기 메타파일 1000개 중 메타파일 1000개를 만들고, 기준을 알면 통계적 순서를 지정하여 유사한 파일이 하나의 메타파일로 성형되도록 합니다.
위협은 FileOpen 으로 실험하는 것이 더 낫습니다. 1000개의 작은 파일과 동일한 볼륨으로 큰 파일을 1000번 열거나 작은 파일을 1000000번 여는 의미에서 큰 파일이나 작은 파일을 여는 것이 어떻게 더 빨리 작동합니까?
그리고 파일을 스티칭할 필요가 없고 분할할 필요가 있는 것으로 판명될 수 있습니다.
파일을 스티칭할 수 있습니까? 파일의 시작과 끝 비트를 인덱싱합니다.
예를 들어, lam 파일에서 초기 메타파일 1000개 중 메타파일 1000개를 만들고, 기준을 알면 통계적 순서를 지정하여 유사한 파일이 하나의 메타파일로 성형되도록 합니다.
위협적이지만 FileOpen으로 실험하는 것이 더 좋습니다. 큰 파일을 1000번 열면 작은 파일 1000개와 같거나 작은 파일을 1000000번 여는 의미에서 큰 파일이나 작은 파일을 열 때 어떻게 더 빨리 작동합니까?
그리고 파일을 스티칭할 필요가 없고 분할할 필요가 있는 것으로 판명될 수 있습니다.
저는 현재 하나의 큰 파일을 작업 중이지만 백만 개의 작은 파일로 가고 싶었습니다.
첫째, 추가할 수 있고 둘째, 이름으로 액세스할 수 있습니다("각 시퀀스의 시작"을 저장할 필요가 없음).
서비스 데스크에서 그는 다른 파일을 백만 개 정도 여는 것에 대해 질문했습니다(이것이 캐시가 구현되는 방식입니다). 대답은 명확하고 이해할 수 있습니다.
하나의 큰 파일에 대해 API 함수를 테스트하고 백만 개의 작은 파일에 대해 결과를 게시합니다.
그러나 구현이 없으면 모든 인수가 추상적으로 유지됩니다. 그래서 이 논의의 시점에서 제가 휴직을 하는 것이 적절할 것 같습니다. :)
여기에서 시작했어야 했습니다 ;)
그러나 어쨌든 입력 덕분에 코드가 없는 아이디어도 가치가 있습니다.
백만 개의 파일이 있으면 ntfs를 너무 많이 파괴하여 파일 시스템의 엄청나게 느린 구현으로 모든 사람을 영원히 가두는 이 미친 Microsoft 제품에서 울음을 터뜨릴 것입니다.
ms가 그의 파일 시스템에 한 모든 것은 엄청난 무게, 부진 및 어리석음입니다. 젠장, 이 멍청이들은 최적화와 속도를 위한 노력을 전혀 하지 않았으며 API는 원시적일 뿐입니다. 2014년에 이것은 분명하게 말할 수 있습니다. 글쎄, 울어.
Windows에서 파일 묶음으로 작업하는 효율성을 향상시키려는 사람은 우선 단일 파일 내에서 그룹화 및 자체 데이터 구조 와 같은 청크로 이동합니다.
Windows에 흩어져 있는 파일을 천 개 이상(심지어 수십만 개) 저장하기 시작하면 바로 시작됩니다.
MQL4/5의 파일 작업은 매우 효율적인 캐싱 메커니즘을 거치므로 매우 효율적이고 높은 읽기 및 쓰기 속도를 달성할 수 있습니다.
바이트 단위로 데이터를 스트리밍할 수도 있습니다. 모든 데이터는 먼저 내부 버퍼에 빠르게 수집되고 큰 조각으로만 디스크에 기록됩니다. WinAPI 호출 횟수가 최소화되어 빠른 속도를 제공합니다. 읽기도 비슷합니다. 사전에 작동하고 큰 덩어리에서 빼며 WinAPI에 매우 드물게 액세스하고 최소한의 오버헤드로 캐시에서 데이터를 매우 빠르게 반환합니다.
대략적으로 말하자면, 509개 빌드와 비교하여 MQL4/5의 파일 작업 속도가 10배 증가했습니다. 속도 측정").