OnTimer()가 10-16밀리초 이상 호출될 수 없다는 것을 알고 있다고 생각합니다. 다른 OnXXX 함수가 더 이상 자주 호출되지 않는다고 가정하는 것이 논리적입니다. 이 때문에 지연이 발생합니까?
논리적이지 않고 핸들러는 GetTickCount 타이머의 빈도/해상도에 연결되지 않습니다. 이벤트는 발생하는 순간에 즉시 트리거됩니다.
OnTimer는 16ms 오류에도 연결되지 않습니다. 컴퓨터가 종료되지 않고 100% 로드되지 않은 경우 대부분의 경우 1ms의 타이머를 쉽게 얻을 수 있습니다.
거의 모든 fxsaber 테스트의 문제는 많은 평균을 내는 대신 단일 호출의 이상값을 측정하려고 하고 스레드 관리자의 현실을 이해하고 싶어하지 않는다는 것입니다.
그에게:
4/8 코어에서 최소 1500-2000 스레드
열악한 흐름 관리자가 그들을 극도로 적은 수의 수행자에게 분산시킵니다. 사람들은 자신의 작업에 수백 명의 경쟁자가 있다는 사실을 전혀 인식하지 못합니다.
때때로 우선 순위 스레드가 깨어나 짧은 시간 동안 다른 스레드보다 타임 슬라이스를 더 많이 먹습니다.
어떤 스레드라도 상당한 시간 동안 피더에서 멀리 이동할 수 있습니다. 여기에는 평범한 i ++에 밀리초가 있습니다(이를 몇 번이나 반복해야 할까요?)
실시간에 가까워지기 위한 전투 방법:
스레드 관리자를 언로드하기 위한 더 많은 코어
최신 캐시, 우수한 클럭 속도 및 증가된 IPC(사이클/클럭당 명령)를 갖춘 확실히 새로운 CPU
더 빠른 메모리 및 nvme 디스크는 타사 요구의 영향을 크게 제거합니다.
정상적인 네트워크 카드가 인터럽트를 조용히 방해하지 않도록 올바른 드라이버와 BIOS 병목 현상)
운영 체제 및 프로그램용 렌더링 인터페이스의 2D 로드를 제거할 수 있는 평범한 개별 비디오 카드(서버 및 가상 머신에서는 항상 골칫거리임)
사용하지 않는 프로세스/프로그램 수 감소
불필요한 주변 장비 및 해당 드라이버의 양을 줄입니다.
따라서 일반 클래식 VPS 터미널(다른 프로그램과 마찬가지로)에서는 예기치 않은 지연으로 인해 항상 문제가 발생합니다. 더 저렴하거나 과매도 된 VPS, 더 많은 문제.
SR-IOV가 활성화되어 있고 이에 대한 최신(수동으로만 설치된) 특수 네트워크 카드 드라이버가 있는지 VPS에 문의하십시오. 99%의 경우 그렇지 않습니다. 이것은 철 동물원 주변의 가상 머신 마이그레이션을 중단시키기 때문입니다. 그리고 그것 없이는 네트워크 패킷의 이중(호스트 및 가상 머신에서) 전송/처리 및 증가된 인터럽트 수로 인해 단순히 추가 지연이 보장됩니다.
우리의 VPS 서비스는 아키텍처 와 GUI가 없는 경량 터미널 측면에서 모두 이에 덜 민감합니다.
논리적이지 않고 핸들러는 GetTickCount 타이머의 빈도/해상도에 연결되지 않습니다. 이벤트는 발생하는 순간에 즉시 트리거됩니다.
OnTimer는 16ms 오류에도 연결되지 않습니다. 컴퓨터가 종료되지 않고 100% 로드되지 않은 경우 대부분의 경우 1ms의 타이머를 쉽게 얻을 수 있습니다.
거의 모든 fxsaber 테스트의 문제는 많은 평균을 내는 대신 단일 호출의 이상값을 측정하려고 하고 스레드 관리자의 현실을 이해하고 싶어하지 않는다는 것입니다.
그에게:
4/8 코어에서 최소 1500-2000 스레드
열악한 흐름 관리자가 그들을 극도로 적은 수의 수행자에게 분산시킵니다. 사람들은 자신의 작업에 수백 명의 경쟁자가 있다는 사실을 전혀 인식하지 못합니다.
때때로 우선 순위 스레드가 깨어나 짧은 시간 동안 다른 스레드보다 타임 슬라이스를 더 많이 먹습니다.
어떤 스레드라도 상당한 시간 동안 피더에서 멀리 이동할 수 있습니다. 여기에는 평범한 i ++에 밀리초가 있습니다(이를 몇 번이나 반복해야 할까요?)
실시간에 가까워지기 위한 전투 방법:
스레드 관리자를 언로드하기 위한 더 많은 코어
최신 캐시, 우수한 클럭 속도 및 증가된 IPC(사이클/클럭당 명령)를 갖춘 확실히 새로운 CPU
더 빠른 메모리 및 nvme 디스크는 타사 요구의 영향을 크게 제거합니다.
정상적인 네트워크 카드가 인터럽트를 조용히 방해하지 않도록 올바른 드라이버와 BIOS 병목 현상)
운영 체제 및 프로그램용 렌더링 인터페이스의 2D 로드를 제거할 수 있는 평범한 개별 비디오 카드(서버 및 가상 머신에서는 항상 골칫거리임)
사용하지 않는 프로세스/프로그램 수 감소
불필요한 주변 장비 및 해당 드라이버의 양을 줄입니다.
따라서 도덕적 - 일반 클래식 VPS 터미널(다른 프로그램과 마찬가지로)은 예기치 않은 지연으로 인해 항상 어려움을 겪을 것입니다. 더 저렴하거나 과매도 된 VPS, 더 많은 문제.
SR-IOV가 활성화되어 있고 이에 대한 최신(수동으로만 설치된) 특수 네트워크 카드 드라이버가 있는지 VPS에 문의하십시오. 99%의 경우 그렇지 않습니다. 이것은 철 동물원 주변의 가상 머신 마이그레이션을 중단시키기 때문입니다. 그리고 그것 없이는 네트워크 패킷의 이중(호스트 및 가상 머신에서) 전송/처리 및 증가된 인터럽트 수로 인해 단순히 추가 지연이 보장됩니다.
우리의 VPS 서비스는 GUI가 없는 아키텍처 와 경량 터미널 측면에서 훨씬 덜 민감합니다.
이제 프로그램의 핸들러가 비동기식으로 실행되는 경우 최적화된 머신에서 사용자 프로그램의 작업이 몇 번이나 가속화되는지 상상해 보십시오. 사용자 프로그램의 핸들러가 동기식으로 선험적으로 실행되는 경우 기계 하드웨어의 슈퍼 업그레이드 및 슈퍼 최적화의 의미를 이해하지 못합니다. 터미널 자체와 내부 작업의 경우 위에서 설명한 최적화가 유용할 수 있습니다. 전투 사용자 프로그램의 경우 의심스럽습니다. 사용자 프로그램에서 처리기의 순차 실행을 위해 초 최적화된 기계의 가능한 모든 가능성이 줄어듭니다. 문제는 하드웨어에 있는 것이 아니라 터미널의 내부 작동 아키텍처에 있습니다.
이제 프로그램의 핸들러가 비동기식으로 실행되는 경우 최적화된 머신에서 사용자 프로그램의 작업이 몇 번이나 가속화되는지 상상해 보십시오. 사용자 프로그램의 핸들러가 동기식으로 선험적으로 실행되는 경우 기계 하드웨어의 슈퍼 업그레이드 및 슈퍼 최적화의 의미를 이해하지 못합니다. 터미널 자체와 내부 작업의 경우 위에서 설명한 최적화가 유용할 수 있습니다. 전투 사용자 프로그램의 경우 의심스럽습니다. 사용자 프로그램에서 처리기의 순차 실행을 위해 모든 초 최적화된 기계의 가능한 모든 가능성이 줄어듭니다. 문제는 하드웨어에 있는 것이 아니라 터미널의 내부 작동 아키텍처에 있습니다.
가속은 없을 것입니다. 다중 가속도를 증명하는 계산을 최소한 대략적인 수치로 제시하십시오.
당신은 그것을 어떻게 상상합니까 - 하나의 스레드에서 병렬 처리?
이벤트 루프.
일반적으로 이것은 모든 것이 하나의 스레드에서 수행되는 개발자의 문제입니다.
Market Watch는 비동기식으로 처리되고 사용자 프로그램의 핸들러는 동기식으로 처리됩니다.
Shikardos는 단순히, 아무 말도 하지 않습니다.
통계 리뷰 감사합니다! 누구나 OnTick/OnBook 지연이 있는 것 같습니다. 절전 (1) 1ms 또는 15ms. 의존하는 이유는 명확하지 않습니다.
누구나 OnTick/OnBook 지연이 있는 것 같습니다.
OnTimer()가 10-16밀리초 이상 호출될 수 없다는 것을 알고 있다고 생각합니다. 다른 OnXXX 함수가 더 이상 자주 호출되지 않는다고 가정하는 것이 논리적입니다. 이 때문에 지연이 발생합니까?
OnTimer()가 10-16밀리초 이상 호출될 수 없다는 것을 알고 있다고 생각합니다. 다른 OnXXX 함수가 더 이상 자주 호출되지 않는다고 가정하는 것이 논리적입니다. 이 때문에 지연이 발생합니까?
논리적이지 않고 핸들러는 GetTickCount 타이머의 빈도/해상도에 연결되지 않습니다. 이벤트는 발생하는 순간에 즉시 트리거됩니다.
OnTimer는 16ms 오류에도 연결되지 않습니다. 컴퓨터가 종료되지 않고 100% 로드되지 않은 경우 대부분의 경우 1ms의 타이머를 쉽게 얻을 수 있습니다.
거의 모든 fxsaber 테스트의 문제는 많은 평균을 내는 대신 단일 호출의 이상값을 측정하려고 하고 스레드 관리자의 현실을 이해하고 싶어하지 않는다는 것입니다.
그에게:
실시간에 가까워지기 위한 전투 방법:
따라서 일반 클래식 VPS 터미널(다른 프로그램과 마찬가지로)에서는 예기치 않은 지연으로 인해 항상 문제가 발생합니다. 더 저렴하거나 과매도 된 VPS, 더 많은 문제.
SR-IOV가 활성화되어 있고 이에 대한 최신(수동으로만 설치된) 특수 네트워크 카드 드라이버가 있는지 VPS에 문의하십시오. 99%의 경우 그렇지 않습니다. 이것은 철 동물원 주변의 가상 머신 마이그레이션을 중단시키기 때문입니다. 그리고 그것 없이는 네트워크 패킷의 이중(호스트 및 가상 머신에서) 전송/처리 및 증가된 인터럽트 수로 인해 단순히 추가 지연이 보장됩니다.
우리의 VPS 서비스는 아키텍처 와 GUI가 없는 경량 터미널 측면에서 모두 이에 덜 민감합니다.
논리적이지 않고 핸들러는 GetTickCount 타이머의 빈도/해상도에 연결되지 않습니다. 이벤트는 발생하는 순간에 즉시 트리거됩니다.
OnTimer는 16ms 오류에도 연결되지 않습니다. 컴퓨터가 종료되지 않고 100% 로드되지 않은 경우 대부분의 경우 1ms의 타이머를 쉽게 얻을 수 있습니다.
거의 모든 fxsaber 테스트의 문제는 많은 평균을 내는 대신 단일 호출의 이상값을 측정하려고 하고 스레드 관리자의 현실을 이해하고 싶어하지 않는다는 것입니다.
그에게:
실시간에 가까워지기 위한 전투 방법:
따라서 도덕적 - 일반 클래식 VPS 터미널(다른 프로그램과 마찬가지로)은 예기치 않은 지연으로 인해 항상 어려움을 겪을 것입니다. 더 저렴하거나 과매도 된 VPS, 더 많은 문제.
SR-IOV가 활성화되어 있고 이에 대한 최신(수동으로만 설치된) 특수 네트워크 카드 드라이버가 있는지 VPS에 문의하십시오. 99%의 경우 그렇지 않습니다. 이것은 철 동물원 주변의 가상 머신 마이그레이션을 중단시키기 때문입니다. 그리고 그것 없이는 네트워크 패킷의 이중(호스트 및 가상 머신에서) 전송/처리 및 증가된 인터럽트 수로 인해 단순히 추가 지연이 보장됩니다.
우리의 VPS 서비스는 GUI가 없는 아키텍처 와 경량 터미널 측면에서 훨씬 덜 민감합니다.
이제 프로그램의 핸들러가 비동기식으로 실행되는 경우 최적화된 머신에서 사용자 프로그램의 작업이 몇 번이나 가속화되는지 상상해 보십시오.
사용자 프로그램의 핸들러가 동기식으로 선험적으로 실행되는 경우 기계 하드웨어의 슈퍼 업그레이드 및 슈퍼 최적화의 의미를 이해하지 못합니다.
터미널 자체와 내부 작업의 경우 위에서 설명한 최적화가 유용할 수 있습니다. 전투 사용자 프로그램의 경우 의심스럽습니다.
사용자 프로그램에서 처리기의 순차 실행을 위해 초 최적화된 기계의 가능한 모든 가능성이 줄어듭니다.
문제는 하드웨어에 있는 것이 아니라 터미널의 내부 작동 아키텍처에 있습니다.
이제 프로그램의 핸들러가 비동기식으로 실행되는 경우 최적화된 머신에서 사용자 프로그램의 작업이 몇 번이나 가속화되는지 상상해 보십시오.
사용자 프로그램의 핸들러가 동기식으로 선험적으로 실행되는 경우 기계 하드웨어의 슈퍼 업그레이드 및 슈퍼 최적화의 의미를 이해하지 못합니다.
터미널 자체와 내부 작업의 경우 위에서 설명한 최적화가 유용할 수 있습니다. 전투 사용자 프로그램의 경우 의심스럽습니다.
사용자 프로그램에서 처리기의 순차 실행을 위해 모든 초 최적화된 기계의 가능한 모든 가능성이 줄어듭니다.
문제는 하드웨어에 있는 것이 아니라 터미널의 내부 작동 아키텍처에 있습니다.
가속은 없을 것입니다. 다중 가속도를 증명하는 계산을 최소한 대략적인 수치로 제시하십시오.
자원 경쟁? 제어되지 않은 새 스레드 생성? 갑작스러운 갈등?
설명할 수 없는 브레이크를 원하십니까?
이벤트 모델 에서 모든 이벤트는 항상 차례로 형성되었습니다. 씹다 - 씹었다.
우리의 VPS 서비스는 아키텍처 와 GUI가 없는 경량 터미널 측면에서 모두 이에 덜 민감합니다.
VPS 서비스에 지연이 있는 경우 심각하게 받아들이겠습니까?
MQ에서 VPS를 사용하는 사람은 다음 프로그램의 결과를 거기에서 공유하십시오.
VPS 서비스에 지연이 있는 경우 심각하게 받아들이겠습니까?
제한된 수의 코어에 대해 그러한 (천) 수의 스레드로 몇 번이나 반복해야 하는지 궁금합니다. 스레드당 타임 슬라이스 할당의 안정성에 대해 이야기하는 것이 일반적으로 미친 짓입니까?
inc eax와 같은 가장 단순한 어셈블러를 포함하여 모든 명령의 무작위 단일 측정에서 항상 실패가 보장됩니다 . 이것은 아키텍처이며 "수천 스레드의 시간 조각을 소수의 코어에 정직하게 분배"하는 물리적 한계로 설명됩니다.
이미 어리석고 백만 요청당 단일 이상값을 계속 잡아내기에 충분합니다.
이미 어리석고 백만 요청당 단일 이상값을 계속 잡아내기에 충분합니다.
자세한 설명 덕분에 단일 방출로 명확합니다. 현재 우리는 SymbolInfoTick이 아니라 거의 모든 틱 에 쏟아지는 다른 특성의 지연에 대해 논의하고 있습니다.