아니, 맞아. 그리고 이것은 근본적인 요점입니다. 시간 비용이 매우 많이 드는 메인 스레드에서는 자동 삭제가 발생하지 않습니다. 병렬 스레드가 사용된 메모리를 회수할 때까지 기다리지 않고 새 실행을 시작할 수 있습니다. 예, 호출되기도 하고 CPU 리소스도 필요하지만 이는 백그라운드에서 수행되는 부수 작업입니다. 가장 적극적인 최적화를 사용하더라도 일부 CPU 리소스는 다른 스레드에서 사용할 수 있습니다. 이제 모든 최신 OS가 이러한 방식으로 작동하기 때문입니다. 최신 프로세서의 CPU 사용률 화살표를 100%로 설정하는 것은 이제 거의 불가능합니다.
--
다르게 쓰겠습니다. 5단위의 시간이 걸리는 작업이 있다고 가정해 보겠습니다. 하나의 스레드에서 5개 단위로 수행하거나 2개에서 3개 및 2개 단위로 수행할 수 있습니다. 분명히 총 실행 시간은 5단위로 동일하지만 두 번째 경우에는 작업이 병렬화되지만 첫 번째 경우에는 그렇지 않기 때문에 물리적 시간은 두 번째 경우에 2단위 적게 필요합니다. 최적화가 이미 사용 가능한 모든 물리적 CPU 코어를 사용한다는 반론이 있습니다. 그러나 이것은 사실이 아닙니다. 모든 최적화는 기껏해야 OS 코어 수와 동일한 수의 스레드를 할당합니다. 그러나 OS에서는 이러한 작업 외에도 수백 개의 다른 작업이 실행되고 옵티마이저에서 할당한 8개의 스레드가 아니라 8개의 프로세서 코어(8개가 있는 경우) 모두가 수백 개의 시스템 스레드로 분할됩니다. 따라서 응용 프로그램이 8개의 스레드를 할당했기 때문에 모든 CPU 리소스를 100%로 사용할 것이라고 순진하게 생각하는 것보다 8+1 또는 8+8 모드에서 하나 이상의 스레드를 할당하는 것이 항상 더 적절합니다.
--
일반적으로 " 우리는 전체 시스템의 총 시간이 포함되기 때문에 이번에는 계산하지 않는다 " 또는 " new를 통해 생성된 객체의 메서드가 더 느리게 호출 된다"와 같은 주장을 듣는 것이 좋습니다. 만약 그렇다면, 우리는 아마도 이 시간에 대한 벤치마크를 할인해야 할 것입니다. 왜냐하면 메소드가 어떤 면에서는 더 느리고 다른 면에서는 더 빠를 때 불공평하기 때문입니다.)))))) 글쎄, 그렇다면, 왜 우리가 성능을 위해 익사하는 척하는 걸까요? 우리가 90년대 사람이고 "어쨌든 어셈블러가 더 빠릅니다!"라는 잘못된 슬로건만 있음을 인정합시다. 또는 "포인터로 작업할 때 - 내가 모든 것을 제어합니다" 우리가 인식하지 못합니다.
--
두 번째 순간. V2에 주목하세요. 개체 삭제가 없으며 직접 메모리 누수가 의도적으로 허용됩니다. 이 경우에도 개체 선택에 1.4초가 걸립니다. V1의 1.2 대 1.2이지만 삭제에 시간이 전혀 낭비되지 않습니다.
말하기 어렵다. mql 가상 머신 사양을 알아야 합니다. 그리고 개발자 외에는 아무도 이것을 모릅니다. ProcessHacker의 분석에 따르면 * new를 통해 할당된 객체가 어떻게든 한 곳에서 교묘하게 하나씩 할당된 다음 이미 큰 배열로 다른 메모리 영역으로 이동되었다는 인상을 받습니다. 저것들. 일시적인 개체일 수도 있고 다른 것일 수도 있습니다.
아니, 맞아. 그리고 이것은 근본적인 요점입니다. 시간 비용이 매우 많이 드는 메인 스레드에서는 자동 삭제가 발생하지 않습니다. 병렬 스레드가 사용된 메모리를 회수할 때까지 기다리지 않고 새 실행을 시작할 수 있습니다. 예, 호출되기도 하고 CPU 리소스도 필요하지만 이는 백그라운드에서 수행되는 부수 작업입니다. 가장 적극적인 최적화를 사용하더라도 일부 CPU 리소스는 다른 스레드에서 사용할 수 있습니다. 이제 모든 최신 OS가 이러한 방식으로 작동하기 때문입니다. 최신 프로세서의 CPU 사용률 화살표를 100%로 설정하는 것은 이제 거의 불가능합니다.
--
다르게 쓰겠습니다. 5단위의 시간이 걸리는 작업이 있다고 가정해 보겠습니다. 하나의 스레드에서 5개 단위로 수행하거나 2개에서 3개 및 2개 단위로 수행할 수 있습니다. 분명히 총 실행 시간은 5단위로 동일하지만 두 번째 경우에는 작업이 병렬화되지만 첫 번째 경우에는 그렇지 않기 때문에 물리적 시간은 두 번째 경우에 2단위 적게 필요합니다. 최적화가 이미 사용 가능한 모든 물리적 CPU 코어를 사용한다는 반론이 있습니다. 그러나 이것은 사실이 아닙니다. 모든 최적화는 기껏해야 OS 코어 수와 동일한 수의 스레드를 할당합니다. 그러나 OS에서는 이러한 작업 외에도 수백 개의 다른 작업이 실행되고 옵티마이저에서 할당한 8개의 스레드가 아니라 8개의 프로세서 코어(8개가 있는 경우) 모두가 수백 개의 시스템 스레드로 분할됩니다. 따라서 응용 프로그램이 8개의 스레드를 할당했기 때문에 모든 CPU 리소스를 100%로 사용할 것이라고 순진하게 생각하는 것보다 8+1 또는 8+8 모드에서 하나 이상의 스레드를 할당하는 것이 항상 더 적절합니다.
--
일반적으로 " 우리는 전체 시스템의 총 시간이 포함되기 때문에 이번에는 계산하지 않는다 " 또는 " new를 통해 생성된 객체의 메서드가 더 느리게 호출 된다"와 같은 주장을 듣는 것이 좋습니다. 만약 그렇다면, 우리는 아마도 이 시간에 대한 벤치마크를 할인해야 할 것입니다. 왜냐하면 메소드가 어떤 면에서는 더 느리고 다른 면에서는 더 빠를 때 불공평하기 때문입니다.)))))) 글쎄, 그렇다면, 왜 우리가 성능을 위해 익사하는 척하는 걸까요? 우리가 90년대 사람이고 "어쨌든 어셈블러가 더 빠릅니다!"라는 잘못된 슬로건만 있음을 인정합시다. 또는 "포인터로 작업할 때 - 내가 모든 것을 제어합니다" 우리가 인식하지 못합니다.
--
두 번째 순간. V2에 주목하세요. 개체 삭제가 없으며 직접 메모리 누수가 의도적으로 허용됩니다. 이 경우에도 개체 선택에 1.4초가 걸립니다. V1의 1.2 대 1.2이지만 삭제에 시간이 전혀 낭비되지 않습니다.
말하기 어렵다. mql 가상 머신 사양을 알아야 합니다. 그리고 개발자 외에는 아무도 이것을 모릅니다. ProcessHacker의 분석에 따르면 * new를 통해 할당된 객체가 어떻게든 한 곳에서 교묘하게 하나씩 할당된 다음 이미 큰 배열로 다른 메모리 영역으로 이동되었다는 인상을 받습니다. 저것들. 일시적인 개체일 수도 있고 다른 것일 수도 있습니다.
글쎄요, 메인 쓰레드에서 삭제를 하지 않는다면 차원에 포함되든 없든 무슨 차이가 있을까요? 영향을 미치지 않습니다)))) 그러므로 진실을 보기 위해 켜는 것이 어떻습니까?
두 번 동안 비어 있고 제로 인코더임을 증명할 수 있습니다. 그러나 누가 그것을 필요로 하는지, 왜 1년 후 증명한다면 zasera는 말 그대로 이 포럼의 모든 지점에 있습니다. 나는 2년 동안 여기에 아무 것도 게시하지 않았고 가끔씩만 보았습니다. 그리고 매번, 어떤 스레드에서든, "당신은 여기 있는 모든 바보야, 당신은 이해하지 못하는" 스타일의 "권위 있는 의견"과 함께 당신이 있었습니다. 아무것도 아니지만 방법은 알려주지 않겠습니다.” 당신은 썩은 사람, 디마.
두 번 동안 비어 있고 제로 인코더임을 증명할 수 있습니다. 그러나 누가 그것을 필요로 하는지, 왜 1년 후 증명한다면 zasera는 말 그대로 이 포럼의 모든 지점에 있습니다. 나는 2년 동안 여기에 아무 것도 게시하지 않았고 가끔씩만 보았습니다. 그리고 매번, 어떤 스레드에서든, "당신은 여기 있는 모든 바보야, 당신은 이해하지 못하는" 스타일의 "권위 있는 의견"과 함께 당신이 있었습니다. 아무것도 아니지만 방법은 알려주지 않겠습니다.” 당신은 썩은 사람, 디마.
뭐라고요? 문제는 내가 당신에게 올바른 방법을 말하지 않는다는 것입니다.
예, 그리고 당신은 이미 여기에서 매우 멋진 것을 증명했습니다))
그리고 내가 썩었나? 이것은 내가 코드를 작성할 때 설사와 scrofula를 얻는 곳입니다.
잘못된 비교 때문에 개체의 자동 삭제 시간은 고려되지 않습니다.
변경됨.
V3 이후의 123MB는 어디에서 왔는지 - 모르겠습니다.
아니, 맞아. 그리고 이것은 근본적인 요점입니다. 시간 비용이 매우 많이 드는 메인 스레드에서는 자동 삭제가 발생하지 않습니다. 병렬 스레드가 사용된 메모리를 회수할 때까지 기다리지 않고 새 실행을 시작할 수 있습니다. 예, 호출되기도 하고 CPU 리소스도 필요하지만 이는 백그라운드에서 수행되는 부수 작업입니다. 가장 적극적인 최적화를 사용하더라도 일부 CPU 리소스는 다른 스레드에서 사용할 수 있습니다. 이제 모든 최신 OS가 이러한 방식으로 작동하기 때문입니다. 최신 프로세서의 CPU 사용률 화살표를 100%로 설정하는 것은 이제 거의 불가능합니다.
--
다르게 쓰겠습니다. 5단위의 시간이 걸리는 작업이 있다고 가정해 보겠습니다. 하나의 스레드에서 5개 단위로 수행하거나 2개에서 3개 및 2개 단위로 수행할 수 있습니다. 분명히 총 실행 시간은 5단위로 동일하지만 두 번째 경우에는 작업이 병렬화되지만 첫 번째 경우에는 그렇지 않기 때문에 물리적 시간은 두 번째 경우에 2단위 적게 필요합니다. 최적화가 이미 사용 가능한 모든 물리적 CPU 코어를 사용한다는 반론이 있습니다. 그러나 이것은 사실이 아닙니다. 모든 최적화는 기껏해야 OS 코어 수와 동일한 수의 스레드를 할당합니다. 그러나 OS에서는 이러한 작업 외에도 수백 개의 다른 작업이 실행되고 옵티마이저에서 할당한 8개의 스레드가 아니라 8개의 프로세서 코어(8개가 있는 경우) 모두가 수백 개의 시스템 스레드로 분할됩니다. 따라서 응용 프로그램이 8개의 스레드를 할당했기 때문에 모든 CPU 리소스를 100%로 사용할 것이라고 순진하게 생각하는 것보다 8+1 또는 8+8 모드에서 하나 이상의 스레드를 할당하는 것이 항상 더 적절합니다.
--
일반적으로 " 우리는 전체 시스템의 총 시간이 포함되기 때문에 이번에는 계산하지 않는다 " 또는 " new를 통해 생성된 객체의 메서드가 더 느리게 호출 된다"와 같은 주장을 듣는 것이 좋습니다. 만약 그렇다면, 우리는 아마도 이 시간에 대한 벤치마크를 할인해야 할 것입니다. 왜냐하면 메소드가 어떤 면에서는 더 느리고 다른 면에서는 더 빠를 때 불공평하기 때문입니다.)))))) 글쎄, 그렇다면, 왜 우리가 성능을 위해 익사하는 척하는 걸까요? 우리가 90년대 사람이고 "어쨌든 어셈블러가 더 빠릅니다!"라는 잘못된 슬로건만 있음을 인정합시다. 또는 "포인터로 작업할 때 - 내가 모든 것을 제어합니다" 우리가 인식하지 못합니다.
--
두 번째 순간. V2에 주목하세요. 개체 삭제가 없으며 직접 메모리 누수가 의도적으로 허용됩니다. 이 경우에도 개체 선택에 1.4초가 걸립니다. V1의 1.2 대 1.2이지만 삭제에 시간이 전혀 낭비되지 않습니다.
V3 이후의 123MB는 어디에서 왔는지 - 모르겠습니다.
말하기 어렵다. mql 가상 머신 사양을 알아야 합니다. 그리고 개발자 외에는 아무도 이것을 모릅니다. ProcessHacker의 분석에 따르면 * new를 통해 할당된 객체가 어떻게든 한 곳에서 교묘하게 하나씩 할당된 다음 이미 큰 배열로 다른 메모리 영역으로 이동되었다는 인상을 받습니다. 저것들. 일시적인 개체일 수도 있고 다른 것일 수도 있습니다.
아니, 맞아. 그리고 이것은 근본적인 요점입니다. 시간 비용이 매우 많이 드는 메인 스레드에서는 자동 삭제가 발생하지 않습니다. 병렬 스레드가 사용된 메모리를 회수할 때까지 기다리지 않고 새 실행을 시작할 수 있습니다. 예, 호출되기도 하고 CPU 리소스도 필요하지만 이는 백그라운드에서 수행되는 부수 작업입니다. 가장 적극적인 최적화를 사용하더라도 일부 CPU 리소스는 다른 스레드에서 사용할 수 있습니다. 이제 모든 최신 OS가 이러한 방식으로 작동하기 때문입니다. 최신 프로세서의 CPU 사용률 화살표를 100%로 설정하는 것은 이제 거의 불가능합니다.
--
다르게 쓰겠습니다. 5단위의 시간이 걸리는 작업이 있다고 가정해 보겠습니다. 하나의 스레드에서 5개 단위로 수행하거나 2개에서 3개 및 2개 단위로 수행할 수 있습니다. 분명히 총 실행 시간은 5단위로 동일하지만 두 번째 경우에는 작업이 병렬화되지만 첫 번째 경우에는 그렇지 않기 때문에 물리적 시간은 두 번째 경우에 2단위 적게 필요합니다. 최적화가 이미 사용 가능한 모든 물리적 CPU 코어를 사용한다는 반론이 있습니다. 그러나 이것은 사실이 아닙니다. 모든 최적화는 기껏해야 OS 코어 수와 동일한 수의 스레드를 할당합니다. 그러나 OS에서는 이러한 작업 외에도 수백 개의 다른 작업이 실행되고 옵티마이저에서 할당한 8개의 스레드가 아니라 8개의 프로세서 코어(8개가 있는 경우) 모두가 수백 개의 시스템 스레드로 분할됩니다. 따라서 응용 프로그램이 8개의 스레드를 할당했기 때문에 모든 CPU 리소스를 100%로 사용할 것이라고 순진하게 생각하는 것보다 8+1 또는 8+8 모드에서 하나 이상의 스레드를 할당하는 것이 항상 더 적절합니다.
--
일반적으로 " 우리는 전체 시스템의 총 시간이 포함되기 때문에 이번에는 계산하지 않는다 " 또는 " new를 통해 생성된 객체의 메서드가 더 느리게 호출 된다"와 같은 주장을 듣는 것이 좋습니다. 만약 그렇다면, 우리는 아마도 이 시간에 대한 벤치마크를 할인해야 할 것입니다. 왜냐하면 메소드가 어떤 면에서는 더 느리고 다른 면에서는 더 빠를 때 불공평하기 때문입니다.)))))) 글쎄, 그렇다면, 왜 우리가 성능을 위해 익사하는 척하는 걸까요? 우리가 90년대 사람이고 "어쨌든 어셈블러가 더 빠릅니다!"라는 잘못된 슬로건만 있음을 인정합시다. 또는 "포인터로 작업할 때 - 내가 모든 것을 제어합니다" 우리가 인식하지 못합니다.
--
두 번째 순간. V2에 주목하세요. 개체 삭제가 없으며 직접 메모리 누수가 의도적으로 허용됩니다. 이 경우에도 개체 선택에 1.4초가 걸립니다. V1의 1.2 대 1.2이지만 삭제에 시간이 전혀 낭비되지 않습니다.
말하기 어렵다. mql 가상 머신 사양을 알아야 합니다. 그리고 개발자 외에는 아무도 이것을 모릅니다. ProcessHacker의 분석에 따르면 * new를 통해 할당된 객체가 어떻게든 한 곳에서 교묘하게 하나씩 할당된 다음 이미 큰 배열로 다른 메모리 영역으로 이동되었다는 인상을 받습니다. 저것들. 일시적인 개체일 수도 있고 다른 것일 수도 있습니다.
글쎄요, 메인 쓰레드에서 삭제를 하지 않는다면 차원에 포함되든 없든 무슨 차이가 있을까요? 영향을 미치지 않습니다)))) 그러므로 진실을 보기 위해 켜는 것이 어떻습니까?
그리고 그건 그렇고, Vasily, 거기에 당신을 기다리고있는 질문이 있습니다 (마지막 줄).
... 또는 " new로 생성된 객체의 메소드가 더 느리게 호출된다 "는 주장...
측정하기에 부족합니까? 당신은 빈 shalabolka, Vasya, 딸랑이입니다.
측정하기에 부족합니까?
네, 드디어 잘 수 있습니다!
네, 드디어 잘 수 있습니다!
꿈을 꾸고 발을 구르다
글쎄요, 메인 쓰레드에서 삭제를 하지 않는다면 차원에 포함되든 없든 무슨 차이가 있을까요? 영향을 미치지 않습니다)))) 그러므로 진실을 보기 위해 켜는 것이 어떻습니까?
그런 다음 최적화 중에 Explorer, 텔레그램, Chrome이 실행되는 데 소요된 총 시간을 벤치마크에 포함합니다. 모두 죽이고 MT만 남겨두더라도 CPU 시간을 낭비할 다른 시스템 스레드가 수백 개 더 있으므로 켜십시오.
그런 다음 최적화 중에 Explorer, 텔레그램, Chrome이 실행되는 데 소요된 총 시간을 벤치마크에 포함합니다. 모두 죽이고 MT만 남겨두더라도 CPU 시간을 낭비할 다른 시스템 스레드가 수백 개 더 있으므로 켜십시오.
병렬 스트림에 있습니다))) (© Vasya)
Vasya, 당신은 정말 바보입니다!
하지만 계속, 계속 지속하십시오.
그리고 그건 그렇고, Vasily, 거기에 당신을 기다리고있는 질문이 있습니다 (마지막 줄).
두 번 동안 비어 있고 제로 인코더임을 증명할 수 있습니다. 그러나 누가 그것을 필요로 하는지, 왜 1년 후 증명한다면 zasera는 말 그대로 이 포럼의 모든 지점에 있습니다. 나는 2년 동안 여기에 아무 것도 게시하지 않았고 가끔씩만 보았습니다. 그리고 매번, 어떤 스레드에서든, "당신은 여기 있는 모든 바보야, 당신은 이해하지 못하는" 스타일의 "권위 있는 의견"과 함께 당신이 있었습니다. 아무것도 아니지만 방법은 알려주지 않겠습니다.” 당신은 썩은 사람, 디마.
두 번 동안 비어 있고 제로 인코더임을 증명할 수 있습니다. 그러나 누가 그것을 필요로 하는지, 왜 1년 후 증명한다면 zasera는 말 그대로 이 포럼의 모든 지점에 있습니다. 나는 2년 동안 여기에 아무 것도 게시하지 않았고 가끔씩만 보았습니다. 그리고 매번, 어떤 스레드에서든, "당신은 여기 있는 모든 바보야, 당신은 이해하지 못하는" 스타일의 "권위 있는 의견"과 함께 당신이 있었습니다. 아무것도 아니지만 방법은 알려주지 않겠습니다.” 당신은 썩은 사람, 디마.
뭐라고요? 문제는 내가 당신에게 올바른 방법을 말하지 않는다는 것입니다.
예, 그리고 당신은 이미 여기에서 매우 멋진 것을 증명했습니다))
그리고 내가 썩었나? 이것은 내가 코드를 작성할 때 설사와 scrofula를 얻는 곳입니다.