이 모든 자전거는 한 번 여러 번 재건 된 것이 분명합니다. asm 구현까지 책도 나왔습니다.
이제 기본을 찾기가 어렵습니다. 왜냐하면. 거의 모든 사람이 모든 경우에 적절한 API를 사용합니다.
따라서 포럼에 등록하고 질문하기만 하면 됩니다.
어려운 일입니다. 아무튼 못 찾았습니다. 제가 검색을 잘 못했을 수도 있습니다. 포럼에서 모든 사람은 표준 폐쇄 라이브러리로 보내지고 모든 것이 있을 때 이것이 왜 필요한지 의아해합니다. 물론 자바, 자바스크립트 등으로 글을 썼다면 세뇌를 하지 않았을 것이다. , 또는 시장이 필요하지 않은 경우.
좋아, 나는 이 문제에서 내가 여전히 훌륭하게 고립되어 있다는 사실에 이미 익숙해져 있다. 특히 이 방향의 거의 모든 구현을 이해하는 데 공백이 거의 없기 때문에 계속할 것입니다. 그러나 그는 독특한 기술을 습득했습니다.
LONG_MAX/MIN 을 사용하지 않는 이유는 무엇입니까? 어떻게 든 더 좋아 보일 것입니다. 아무것도 아닌 것 같습니다. 나는 당신의 테스트를 gcc에서 실행했습니다.
예, 예쁘지 않습니다. 그러나 LONG_MAX = 9223372036854775807은 9007199254740992보다 큽니다. ulong 유형에서만 볼 수 있습니다. 어떻게 하면 좋아질지 조차 모르겠습니다. (ulong)(1<<53)을 쓰지 마십시오. 이것은 시간이 걸리는 작업입니다.
double 유형은 LONG_MAX 값이 아니라 가능한 최대 가수에서 소수 부분 없이 정수를 포함하기 시작합니다. 그리고 가수에 대해 53비트가 할당됩니다. 2^53=9007199254740992.
파블릭_ :
귀하의 코드에서 시간 계산은 정크입니다. 출력은 밀리초(나노가 아님) 단위이며 마이너스 t0이 필요한 이유를 여전히 이해하지 못합니다.
t0은 단순 두 배의 합을 1000000번 통과하는 전체 주기의 시간입니다.
t는 동일한 이중 값의 합계의 동일한 주기의 시간이지만 ceil, Ceil, round 등의 함수를 통해 전달됩니다.
차이(t-t0)가 이러한 기능에 소요된 순 시간이라는 논리에서 진행했습니다.
물론 몇 가지 측정을 통해서만 더 큰 객관성을 얻을 수 있습니다.
- nano에서는 1,000,000개 중 1개 기능의 실행 시간을 기준으로 계산합니다. nano에서는 정확합니다.
파블릭_ :
나는 당신의 테스트를 gcc에서 실행했습니다.
1. -O3로 컴파일
2. -Ofast로 컴파일하기
이것은 효과가 있는 것입니다. 컴파일된 MQL5 코드가 Ofast보다 빠르다고? 믿기 어렵습니다. 아마도 거기에 32비트 컴파일러가 있었을 것입니다.
Nikolai Semko : 이것은 효과가 있는 것입니다. 컴파일된 MQL5 코드가 Ofast보다 빠르다고? 믿기 어렵습니다. 아마도 거기에 32비트 컴파일러가 있었을 것입니다.
나는 모든 곳에서 마이너스 t0를 버렸고(나는 그것이 일종의 실수라고 생각했습니다) 내 출력에서 한 번의 패스가 아니라 전체 사이클이 동결되었습니다. 반복당 나노초 단위로 출력 형식으로 가져오면(첫 번째 줄 "반올림 없는 사이클 시간" - 계산 방법은 우리와 동일함) 다음을 얻습니다.
-O3
Время цикла без округления = 1.099 наносекунд, сумма = 1.15583114 e+ 23
-Ofast
Время цикла без округления = 0.552 наносекунд, сумма = 1.15583114 e+ 23
gcc에는 특별한 가속이 없습니다(-Ofast에서는 더 느림). 귀하의 테스트에 따르면 µl당 중요하지만:
1'000'000 중 985'651이 있습니다. 거의 모든 반복이 x < MIN || 조건을 충족합니다. x > 최대.
-Ofast는 inf/nan에 대한 모든 검사를 비활성화하고 errno를 설정합니다. 그리고 이 네이키드 반올림은 가장 간단한 비교 x < MIN || x > 최대.
어떻게 말하지만. 아름다운 숫자를 위해 우리는 t0을 버리고 20배의 차이를 얻었습니다. 주기(+t0) 형태의 최소한의 추가 코드라도 2배의 영역에서 아름다운 결과를 수십 배 덜 매력적으로 만듭니다. 이것이 베어 사이클이 아니라 유용한 것을 수행하는 실제 알고리즘이라면 무엇이라고 말할 수 있습니까? 예, 그 차이는 전혀 보이지 않을 것이며, 소수점 이하 어딘가에 매달려 있을 것이며 병목 현상이 되지 않을 것입니다. 실제 응용 프로그램에서 뮤텍스, CPU 장벽을 사용하여 메모리를 할당 하는 것은 반올림보다 훨씬 더 비용이 많이 듭니다. 일반적으로 IMHO는 촛불의 가치가 없습니다.
예, 그 차이는 전혀 보이지 않을 것이며, 소수점 이하 어딘가에 매달려 있을 것이며 병목 현상이 되지 않을 것입니다. 실제 응용 프로그램에서 뮤텍스, CPU 장벽을 사용하여 메모리를 할당 하는 것은 반올림보다 훨씬 더 비용이 많이 듭니다. 일반적으로 IMHO는 촛불의 가치가 없습니다.
이것은 99% 사실입니다. 그렇습니다.
최적화하기 전에 무엇을 최적화할지 고민할 가치가 있습니다.
실제로 atof를 직접 구현한 것이 도움이 된 경우는 한 번만 기억합니다. 그것이 보일지라도.
그리고 모든 최적화(최적화 *** 제외)는 결코 무료가 아니라는 점을 기억할 가치가 있습니다.
링크 내려주세요
저장하지 않았습니다. 여기 포럼에서 언급되었습니다. 검색 엔진을 통해 검색했습니다.
저장하지 않았습니다. 여기 포럼에서 언급되었습니다. 검색 엔진을 통해 검색했습니다.
이 모든 자전거는 한 번 여러 번 재건 된 것이 분명합니다. asm 구현까지 책이 나왔습니다.
이제 기본을 찾기가 어렵습니다. 왜냐하면. 거의 모든 사람이 모든 경우에 적절한 API를 사용합니다.
따라서 포럼에 등록하고 질문하기만 하면 됩니다.
이 모든 자전거는 한 번 여러 번 재건 된 것이 분명합니다. asm 구현까지 책도 나왔습니다.
이제 기본을 찾기가 어렵습니다. 왜냐하면. 거의 모든 사람이 모든 경우에 적절한 API를 사용합니다.
따라서 포럼에 등록하고 질문하기만 하면 됩니다.
LONG_MAX/MIN 을 사용하지 않는 이유는 무엇입니까? 어떻게 든 더 좋아 보일 것입니다. 아무것도 아닌 것 같습니다. 나는 당신의 테스트를 gcc에서 실행했습니다.
예, 예쁘지 않습니다. 그러나 LONG_MAX = 9223372036854775807은 9007199254740992보다 큽니다. ulong 유형에서만 볼 수 있습니다. 어떻게 하면 좋아질지 조차 모르겠습니다. (ulong)(1<<53)을 쓰지 마십시오. 이것은 시간이 걸리는 작업입니다.
double 유형은 LONG_MAX 값이 아니라 가능한 최대 가수에서 소수 부분 없이 정수를 포함하기 시작합니다. 그리고 가수에 대해 53비트가 할당됩니다. 2^53=9007199254740992.
귀하의 코드에서 시간 계산은 정크입니다. 출력은 밀리초(나노가 아님) 단위이며 마이너스 t0이 필요한 이유를 여전히 이해하지 못합니다.
t0은 단순 두 배의 합을 1000000번 통과하는 전체 주기의 시간입니다.
t는 동일한 이중 값의 합계의 동일한 주기의 시간이지만 ceil, Ceil, round 등의 함수를 통해 전달됩니다.
차이(t-t0)가 이러한 기능에 소요된 순 시간이라는 논리에서 진행했습니다.
물론 몇 가지 측정을 통해서만 더 큰 객관성을 얻을 수 있습니다.
- nano에서는 1,000,000개 중 1개 기능의 실행 시간을 기준으로 계산합니다. nano에서는 정확합니다.
파블릭_ :
나는 당신의 테스트를 gcc에서 실행했습니다.
1. -O3로 컴파일
2. -Ofast로 컴파일하기
(ulong)(1<<53)을 쓰지 마십시오. 이것은 시간이 걸리는 작업입니다.
이 작업은 문자열을 포함하여 상수가 있는 모든 작업과 마찬가지로 시간이 걸리지 않습니다.
이 작업은 문자열을 포함하여 상수가 있는 모든 작업과 마찬가지로 시간이 걸리지 않습니다.
와 멋있다! 고맙습니다. 그리고 저는 생각했습니다. 모든 시간이 중요합니다. 네, 논리적입니다. 이미 컴파일 단계에서 계산할 수 있습니다.
다음과 같이:
사실, 53 대신 DBL_MANT_DIG 를 쓰는 것이 더 정확할 것입니다.
모든 이중 값이 소수인 경우 최소 승리 사례입니다.
이것은 효과가 있는 것입니다. 컴파일된 MQL5 코드가 Ofast보다 빠르다고? 믿기 어렵습니다. 아마도 거기에 32비트 컴파일러가 있었을 것입니다.
나는 모든 곳에서 마이너스 t0를 버렸고(나는 그것이 일종의 실수라고 생각했습니다) 내 출력에서 한 번의 패스가 아니라 전체 사이클이 동결되었습니다. 반복당 나노초 단위로 출력 형식으로 가져오면(첫 번째 줄 "반올림 없는 사이클 시간" - 계산 방법은 우리와 동일함) 다음을 얻습니다.
gcc에는 특별한 가속이 없습니다(-Ofast에서는 더 느림). 귀하의 테스트에 따르면 µl당 중요하지만:
1'000'000 중 985'651이 있습니다. 거의 모든 반복이 x < MIN || 조건을 충족합니다. x > 최대.
-Ofast는 inf/nan에 대한 모든 검사를 비활성화하고 errno를 설정합니다. 그리고 이 네이키드 반올림은 가장 간단한 비교 x < MIN || x > 최대.
gcc에는 특별한 가속 이 없습니다(-Ofast에서는 더 느림). μl당 유의미한
어떻게 말하지만. 아름다운 숫자를 위해 우리는 t0을 버리고 20배의 차이를 얻었습니다. 주기(+t0) 형태의 최소한의 추가 코드라도 2배의 영역에서 아름다운 결과를 수십 배 덜 매력적으로 만듭니다. 이것이 베어 사이클이 아니라 유용한 것을 수행하는 실제 알고리즘이라면 무엇이라고 말할 수 있습니까? 예, 그 차이는 전혀 보이지 않을 것이며, 소수점 이하 어딘가에 매달려 있을 것이며 병목 현상이 되지 않을 것입니다. 실제 응용 프로그램에서 뮤텍스, CPU 장벽을 사용하여 메모리를 할당 하는 것은 반올림보다 훨씬 더 비용이 많이 듭니다. 일반적으로 IMHO는 촛불의 가치가 없습니다.
예, 그 차이는 전혀 보이지 않을 것이며, 소수점 이하 어딘가에 매달려 있을 것이며 병목 현상이 되지 않을 것입니다. 실제 응용 프로그램에서 뮤텍스, CPU 장벽을 사용하여 메모리를 할당 하는 것은 반올림보다 훨씬 더 비용이 많이 듭니다. 일반적으로 IMHO는 촛불의 가치가 없습니다.
이것은 99% 사실입니다. 그렇습니다.
최적화하기 전에 무엇을 최적화할지 고민할 가치가 있습니다.
실제로 atof를 직접 구현한 것이 도움이 된 경우는 한 번만 기억합니다. 그것이 보일지라도.
그리고 모든 최적화(최적화 *** 제외)는 결코 무료가 아니라는 점을 기억할 가치가 있습니다.