MetaDriver : hrenfx 코드 'a(전생의 getch )를 구문 분석한 적이 있습니까? 4차 포럼의 코드 베이스에 있는 그의 모든 작업을 살펴보고 알고리즘을 완전히 이해할 때까지 몇 가지를 주의 깊게 분석하는 것이 좋습니다. 그리고 저는 "최고 수준의 전문성을 갖춘 사람들"로 구성된 고대비 팀 전체가 동일한 작업을 수행할 것을 강력히 권고합니다. 아마도 당신은 Ivan의 지적 능력에 대해 덜 칭찬하고 당신의 기술을 향상시킬 것입니다.
당신은 수치로 아무것도 보여주지 않았습니다. 당신은 막대에 세 개의 눈금이 있고 그는 LoAsk와 HiBid만 각각 하나씩 가지고 있습니다. 그는 여기에서 아주 오랫동안 선전했습니다. 따라서 루프에서 두 개의 추가 비교가 발생하고 컴파일러에서 범위 검사(RangeCheck)가 해제된 경우 선언된 그림은 루프 내에서 유용한(최소한의) 계산을 사용하더라도 이미 매우 현실적입니다.
나는 실제로 hrenfx 코드 중 일부를 발견했습니다. 코드는 매우 고품질이므로 아무 말도 할 수 없습니다. 일부는 여전히 사용합니다. 그러나 파리와 미트볼을 섞지 마십시오. 그래서 당신은 Gerika처럼 내가 제안한 테스트를 이해하지도 못한 채 글을 씁니다. 루핑은 C에 대한 깊은 지식이 부족하거나 어떤 이유로 hrenfx에 대한 하나의 막대가 두 개의 정수 길이에 불과하다는 사실에 초점을 맞추고 있다고 느꼈습니다. 실제로, 우리는 막대를 설명하는 구조에 대한 포인터를 전달합니다. 구조 자체는 값으로 전달되지 않습니다. 즉, 막대의 요소 수를 켜고 끄는 것이 성능에 실질적으로 영향을 미치지 않습니다. 내가 계층 자체의 성능 시간에 대해 이야기하고 있다는 점에 유의하십시오. 배열을 채우는 시간은 무시합니다.
구조 자체에 값이 하나만 남은 경우 성능 결과는 다음과 같습니다.
저것들. 실제로 하나의 long 값으로 구성된 경량 구조를 배포하는 데 걸리는 시간은 9초에서 2.35초로 몇 배 감소했지만 실행 시간 자체는 거의 동일하게 유지되었습니다. 확인하는 경우). 엔진이 실행을 계층에 위임하면 실제로 발생하며 실행 시간이 더 길어지고 막대를 설명 하는 구조의 크기 는 전혀 관련이 없습니다.
나누면 100,000,000 바의 속도에 도달 할 수 있지만 어쨌든 너무 추상적이고 추측적인 이야기입니다. 실제 테스터에서는 함수 호출 , 디스크에서 데이터 배포 및 읽기, 전략 내 수학적 계산, 매수 및 매도 신호 전송, 중간 데이터 기록 및 저장 등에 대한 비용이 발생합니다. 첫 번째 예에서 TradeSystem() 함수를 한 번만 호출하면 전략 실행 시간이 40% 증가했으며, 이러한 여러 호출, 다소 심각한 계산 및 성능은 한 자릿수만큼 떨어집니다. 따라서 그 결과를 8로 나누어도 선언된 한계에 가까워질 뿐이지만, 말 그대로 프로그래머가 아닌 하프킥으로 단 5시간 만에 달성했다고도 했다. 그러면 우리는 그가 다중 스레드 또는 단일 스레드 모드에서 hrenfx 성능을 의미했는지 여부를 오랫동안 알지 못할 것입니다.
나는 실제로 hrenfx 코드 중 일부를 발견했습니다. 코드는 매우 고품질이므로 아무 말도 할 수 없습니다. 일부는 여전히 사용합니다. 그러나 파리와 미트볼을 섞지 마십시오. 그래서 당신은 Gerika처럼 내가 제안한 테스트를 이해하지도 못한 채 글을 씁니다. Toli는 C에 대한 깊은 지식이 부족하거나 어떤 이유로 hrenfx에 대한 하나의 막대가 두 개의 정수 길이에 불과하다는 점을 강조하고 있습니다. 실제로, 우리는 막대를 설명하는 구조에 대한 포인터를 전달합니다. 구조 자체는 값으로 전달되지 않습니다. 즉, 막대의 요소 수를 켜고 끄는 것이 성능에 실질적으로 영향을 미치지 않습니다. 내가 계층 자체의 성능 시간에 대해 이야기하고 있다는 점에 유의하십시오. 배열을 채우는 시간은 무시합니다.
구조 자체에 값이 하나만 남은 경우 성능 결과는 다음과 같습니다.
저것들. 실제로 하나의 long 값으로 구성된 경량 구조를 배포하는 데 걸리는 시간은 9초에서 2.35초로 몇 배 감소했지만 실행 시간 자체는 거의 동일하게 유지되었습니다. 확인하는 경우). 엔진이 실행을 계층에 위임하면 실제로 발생하며 실행 시간이 더 길어지고 막대를 설명 하는 구조의 크기 는 전혀 관련이 없습니다.
따라서 다시 주장하려면 C를 먼저 공부하십시오. 그러면 이야기할 것이 있을 것입니다.
나는 절반 미만으로 발견된 불일치에 대해 논의하고 싶지 않습니다. // 예를 들어 컴파일러와 프로세서의 차이로 인한 것입니다.
Ivan이 표시하는 성능은 쉬운 전략을 위해 실제에 가깝고 각 전략에 대한 간단한 "카운터"를 작성하는 데 완전히 동기를 부여합니다.
이 성능은 일반 테스터의 보편적인 거상과 비교할 때 거대합니다. 그것이 Ivan이 말하고 싶었던 것입니다. 그리고 전혀 레나타가 아니라, 너와 나, 그리고 "바다의 날씨"를 기다리고 있는 다른 "유저들".
hrenfx 코드 'a(전생의 getch )를 구문 분석한 적이 있습니까? 4차 포럼의 코드 베이스에 있는 그의 모든 작업을 살펴보고 알고리즘을 완전히 이해할 때까지 몇 가지를 주의 깊게 분석하는 것이 좋습니다. 그리고 저는 "최고 수준의 전문성을 갖춘 사람들"로 구성된 고대비 팀 전체가 동일한 작업을 수행할 것을 강력히 권고합니다. 아마도 당신은 Ivan의 지적 능력에 대해 덜 칭찬하고 당신의 기술을 향상시킬 것입니다.
당신은 수치로 아무것도 보여주지 않았습니다. 당신은 막대에 세 개의 눈금이 있고 그는 LoAsk와 HiBid만 각각 하나씩 가지고 있습니다. 그는 여기에서 아주 오랫동안 선전했습니다. 따라서 루프에서 두 개의 추가 비교가 발생하고 컴파일러에서 범위 검사(RangeCheck)가 해제된 경우 선언된 그림은 루프 내에서 유용한(최소한의) 계산을 사용하더라도 이미 매우 현실적입니다.나는 실제로 hrenfx 코드 중 일부를 발견했습니다. 코드는 매우 고품질이므로 아무 말도 할 수 없습니다. 일부는 여전히 사용합니다. 그러나 파리와 미트볼을 섞지 마십시오. 그래서 당신은 Gerika처럼 내가 제안한 테스트를 이해하지도 못한 채 글을 씁니다. 루핑은 C에 대한 깊은 지식이 부족하거나 어떤 이유로 hrenfx에 대한 하나의 막대가 두 개의 정수 길이에 불과하다는 사실에 초점을 맞추고 있다고 느꼈습니다. 실제로, 우리는 막대를 설명하는 구조에 대한 포인터를 전달합니다. 구조 자체는 값으로 전달되지 않습니다. 즉, 막대의 요소 수를 켜고 끄는 것이 성능에 실질적으로 영향을 미치지 않습니다. 내가 계층 자체의 성능 시간에 대해 이야기하고 있다는 점에 유의하십시오. 배열을 채우는 시간은 무시합니다.
구조 자체에 값이 하나만 남은 경우 성능 결과는 다음과 같습니다.
저것들. 실제로 하나의 long 값으로 구성된 경량 구조를 배포하는 데 걸리는 시간은 9초에서 2.35초로 몇 배 감소했지만 실행 시간 자체는 거의 동일하게 유지되었습니다. 확인하는 경우). 엔진이 실행을 계층에 위임하면 실제로 발생하며 실행 시간이 더 길어지고 막대를 설명 하는 구조의 크기 는 전혀 관련이 없습니다.
따라서 다시 주장하려면 C를 먼저 공부하십시오. 그러면 이야기할 것이 있을 것입니다.
저것들. 실제로 하나의 long 값으로 구성된 경량 구조를 배포하는 데 걸리는 시간은 9초에서 2.35초로 여러 번 단축되었지만 실행 시간 자체는 거의 동일하게 유지되었습니다.
그리고 8(코어)로 나누면?
그리고 8(코어)로 나누면?
나는 실제로 hrenfx 코드 중 일부를 발견했습니다. 코드는 매우 고품질이므로 아무 말도 할 수 없습니다. 일부는 여전히 사용합니다. 그러나 파리와 미트볼을 섞지 마십시오. 그래서 당신은 Gerika처럼 내가 제안한 테스트를 이해하지도 못한 채 글을 씁니다. Toli는 C에 대한 깊은 지식이 부족하거나 어떤 이유로 hrenfx에 대한 하나의 막대가 두 개의 정수 길이에 불과하다는 점을 강조하고 있습니다. 실제로, 우리는 막대를 설명하는 구조에 대한 포인터를 전달합니다. 구조 자체는 값으로 전달되지 않습니다. 즉, 막대의 요소 수를 켜고 끄는 것이 성능에 실질적으로 영향을 미치지 않습니다. 내가 계층 자체의 성능 시간에 대해 이야기하고 있다는 점에 유의하십시오. 배열을 채우는 시간은 무시합니다.
구조 자체에 값이 하나만 남은 경우 성능 결과는 다음과 같습니다.
저것들. 실제로 하나의 long 값으로 구성된 경량 구조를 배포하는 데 걸리는 시간은 9초에서 2.35초로 몇 배 감소했지만 실행 시간 자체는 거의 동일하게 유지되었습니다. 확인하는 경우). 엔진이 실행을 계층에 위임하면 실제로 발생하며 실행 시간이 더 길어지고 막대를 설명 하는 구조의 크기 는 전혀 관련이 없습니다.
따라서 다시 주장하려면 C를 먼저 공부하십시오. 그러면 이야기할 것이 있을 것입니다.
나는 절반 미만으로 발견된 불일치에 대해 논의하고 싶지 않습니다. // 예를 들어 컴파일러와 프로세서의 차이로 인한 것입니다.
Ivan이 표시하는 성능은 쉬운 전략을 위해 실제에 가깝고 각 전략에 대한 간단한 "카운터"를 작성하는 데 완전히 동기를 부여합니다.
이 성능은 일반 테스터의 보편적인 거상과 비교할 때 거대합니다. 그것이 Ivan이 말하고 싶었던 것입니다. 그리고 전혀 레나타가 아니라, 너와 나, 그리고 "바다의 날씨"를 기다리고 있는 다른 "유저들".
프로그래머가 아니라 단 5시간.
아니요, hrenfix에는 단일 스레드 테스터가 있으며 그의 게시물에 작성되었습니다.
나는 그가 프로그래머가 아니라고 말한 것을 기억하지 못합니다. 그는 오랫동안 여기에서 프로그래머로 알려졌습니다.
1) .... 하지만 프로그래머가 아닌 반킥으로 단 5시간 만에 달성했다고도 한다.
2) 그리고 나서, 우리는 hrenfx가 다중 스레드 또는 단일 스레드 모드에서 성능을 의미하는지 여부를 오랫동안 알지 못할 것입니다.
1) 처음이 아닌 테스터를 작성하는 사람이 5시간 만에 결과를 얻었습니다. 매우 경험이 풍부한 "비 프로그래머". 예를 들어, 3년 전 그의 착취 중 하나에 대해.
2) 원문을 자세히 읽어보시면 금방 아실 것입니다. // 아니면.. "축치는 리더가 아니다.." ? ;)