64비트 코드와 컴파일러를 고려할 때 이중 계산을 기반으로 하는 작업 클래스의 정수를 잊어버려야 합니다.
테스터는 이중 계산을 기반으로 합니다. 동시에, 각 틱에는 너무 많은 수가 있어서 빈 실행조차도 초당 7백만 틱의 속도로 진행됩니다.
각 틱에 대해 더 복잡한 작업으로 시뮬레이터를 작성할 수 있습니다. 그러나 테스터의 기본은 현재 틱 가격과 주문 가격을 비교하는 것인데, 이는 위의 코드가 하는 일입니다. 나는 아무데도 이 주장을 하는 것이 아니다. 재현 가능한 측정값과 대체 계산을 공개적으로 게시했습니다.
테스터는 이중 계산을 기반으로 합니다. 동시에, 각 틱에는 너무 많은 수가 있어서 빈 실행조차도 초당 7백만 틱의 속도로 진행됩니다.
각 틱에 대해 더 복잡한 작업으로 시뮬레이터를 작성할 수 있습니다. 그러나 테스터의 기본은 현재 틱 가격과 주문 가격을 비교하는 것인데, 이는 위의 코드가 하는 일입니다.
반박:
모든 것이 int로 변환되어야 합니다.
데이터 변환에 여러 브레이크를 걸다
야생 메모리 소비 얻기
각 작업에서 오버플로 및 전체 시스템 사망의 100% 확률을 얻습니다.
지표를 읽겠다고 제안한 개발자를 완전히 무시하고 모든 작업은 double 대신 int로 작동합니다.
그리고 예, 속도면에서 double과 int 사이에는 차이가 없습니다. 믿기 어렵지만 그렇습니다
모든 항목을 부탁드립니다.
하나의 항목 4 또는 5만으로도 정수 속도 향상의 아이디어를 병합하기에 충분합니다.
테스터가 for(i=0;i<limit;i++ ) { }가 아니라는 사실에 대해 말하는 것이 아닙니다.
그러나 정수 연산에서 로컬 마이크로코드 최적화의 결과를 보존하기를 바랄 수 없다는 점도 지적할 수 있습니다. 때로는 루프에 무해한 라인을 추가하고 수십 퍼센트의 속도를 잃는 것으로 충분합니다. 그리고 실제 작업으로 넘어가면 코드가 실제 작업에서 부풀어 오르면 모든 비교가 지옥에 떨어집니다.
형태 분석 - 죽은 세포 분석. 먼저 우리는 현미경으로 죽입니다.
형태 측정(그리스 형태 + ... 미터법)
모든 것. 주제를 어지럽히기에 충분합니다.
Int는 double보다 두 배 빠릅니다.
30개의 어셈블러 기능이 아니라 50k-100k 명령 배열의 결과를 고려하지 않고 규모를 인식하지 못하고 미세 합성에서 테스트를 잘못 수행합니다.
원래 답변에서 위의 각 요점을 반박하십시오.
30개의 어셈블러 기능이 아니라 50k-100k 명령 배열의 결과를 고려하지 않고 규모를 인식하지 못하고 미세 합성에서 테스트를 잘못 수행합니다.
원래 답변에서 위의 각 요점을 반박하십시오.
이 점을 반박했습니다(각 틱마다 원시적인 행동이 있음에도 불구하고)
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
캔버스 멋지다!
레나트 팻쿨린 , 2019.01.15 22:37
64비트 코드와 컴파일러를 고려할 때 이중 계산을 기반으로 하는 작업 클래스의 정수를 잊어버려야 합니다.
테스터는 이중 계산을 기반으로 합니다. 동시에, 각 틱에는 너무 많은 수가 있어서 빈 실행조차도 초당 7백만 틱의 속도로 진행됩니다.
각 틱에 대해 더 복잡한 작업으로 시뮬레이터를 작성할 수 있습니다. 그러나 테스터의 기본은 현재 틱 가격과 주문 가격을 비교하는 것인데, 이는 위의 코드가 하는 일입니다. 나는 아무데도 이 주장을 하는 것이 아니다. 재현 가능한 측정값과 대체 계산을 공개적으로 게시했습니다.
이 점을 반박했습니다(각 틱마다 원시적인 행동이 있음에도 불구하고)
테스터는 이중 계산을 기반으로 합니다. 동시에, 각 틱에는 너무 많은 수가 있어서 빈 실행조차도 초당 7백만 틱의 속도로 진행됩니다.
각 틱에 대해 더 복잡한 작업으로 시뮬레이터를 작성할 수 있습니다. 그러나 테스터의 기본은 현재 틱 가격과 주문 가격을 비교하는 것인데, 이는 위의 코드가 하는 일입니다.
반박:
모든 항목을 부탁드립니다.
하나의 항목 4 또는 5만으로도 정수 속도 향상의 아이디어를 병합하기에 충분합니다.
테스터가 for(i=0;i<limit;i++ ) { }가 아니라는 사실에 대해 말하는 것이 아닙니다.
그러나 정수 연산에서 로컬 마이크로코드 최적화의 결과를 보존하기를 바랄 수 없다는 점도 지적할 수 있습니다. 때로는 루프에 무해한 라인을 추가하고 수십 퍼센트의 속도를 잃는 것으로 충분합니다. 그리고 실제 작업으로 넘어가면 코드가 실제 작업에서 부풀어 오르면 모든 비교가 지옥에 떨어집니다.
반박:
각 항목을 부탁드립니다.
하나의 항목 4 또는 5만으로도 정수 속도 향상의 아이디어를 병합하기에 충분합니다.
목표는 속도를 높이기 위해 여전히 정수로 풀 수 있는 문제가 있다는 것을 보여주는 것이었습니다. 이러한 테스터는 보편적이지 않습니다. 5번 항목에도 해당되지 않습니다.
처음 4가지 점에 관해서는 문제가 너무 많습니다. 왜냐하면 테스터 속도는 최적화 중에만 필요합니다. 이것은 전체 패스에 대해 한 번만 틱 변환입니다.
목표는 속도를 높이기 위해 여전히 정수로 풀 수 있는 문제가 있다는 것을 보여주는 것이었습니다. 이러한 테스터는 보편적이지 않습니다. 5번 항목에도 해당되지 않습니다.
처음 4가지 점에 관해서는 문제가 너무 많습니다. 왜냐하면 테스터 속도는 최적화 중에만 필요합니다. 이것은 전체 패스에 대해 한 번만 틱 변환입니다.
즉, 4점도 5점도 반박할 수 없습니다.
그리고 변환을 저장하려는 경우에도 시간이 소요되는 시간이 즉시 증가합니다. 예, 때때로 변환을 위한 메모리를 포함합니다. 나는 이미 변환을 없애기 위해 전체 플랫폼을 예를 들어 int64의 가격으로 전송하겠다고 제안했다고 생각했습니다.
이론적으로 10년 동안 int로 전환해도 이득이 없습니다.테스터가 for(i=0;i<limit;i++ ) { }가 아니라는 사실에 대해 말하는 것이 아닙니다.
타이머가 없는 테스터에 관한 것이라면 그는 테스터가 틱에 의한 것임을 증명 했습니다.
타이머가 없는 테스터에 관한 것이라면 그는 테스터가 틱에 의한 것임을 증명 했습니다.
이것은 테스터가 아니라 공예품입니다. 지표도 없고 이익도 없고 아무 것도 없습니다. 그러나 정수 오버플로의 지속적인 위험이 있습니다.
토론하는 것조차 의미가 없습니다.
다시 한번:
그러나 정수 연산에서 로컬 마이크로코드 최적화의 결과를 보존하기를 바랄 수 없다는 점도 지적할 수 있습니다.
때로는 루프에 무해한 라인을 추가하고 수십 퍼센트의 속도를 잃는 것으로 충분합니다. 그리고 실제 작업으로 넘어가면 코드가 실제 작업에서 부풀어 오르면 모든 비교가 지옥에 떨어집니다.
즉, 4점이나 5점 모두 반박되지 않았습니다.
그리고 변환을 저장하려는 경우에도 시간이 소요되는 시간이 즉시 증가합니다. 예, 때때로 변환을 위한 메모리를 포함합니다. 나는 이미 변환을 없애기 위해 전체 플랫폼을 예를 들어 int64의 가격으로 전송하겠다고 제안했다고 생각했습니다.
말씀하신 내용에 오해가 있는 것 같습니다. 그것은 정수 가격이 특정 상황에서 이득을 줄 수 있는 특정 테스터의 문제의 예에 관한 것이었습니다. 보편적인 경우를 의미하지 않았습니다. 이것이 내가 위에 링크를 제공한 내 테스터가 이중으로 구현된 이유입니다. 만능인.
이론적으로 10년 동안 int로 전환해도 이득이 없습니다.
100% 동의할 수는 없습니다.
이것은 테스터가 아니라 공예품입니다. 지표도 없고 이익도 없고 아무 것도 없습니다. 그러나 정수 오버플로의 지속적인 위험이 있습니다.
이것은 고문의 코드를 변경하지 않고(표시기 포함) 모든 거래 및 이익을 완전히 통과하는 테스터용 추가 기능입니다. 그러나 일반 테스터보다 빠르게 수행합니다. 그는 재현 가능한 모든 증거를 인용했습니다. 리소스의 사람들이 이 진술을 확인했습니다.