libstdc++에 있습니다. 저것들. 거의 베어 사이클의 배경에 대해 함수 호출 자체가 병목 현상이 됩니다(음, ...replaceEmmPKcm 에서 호출도 몇 개 있습니다). 컴파일러는 결국 하나의 번역 단위 내에서 최적화할 수 있습니다. 여기에서 LTO(링크 시간 최적화), 즉 이것은 연결 단계에서 최적화를 허용합니다. 하지만 많이 사용하지 않았으니 지금 당장은 하지 않겠습니다. 글쎄요, 특별히 복잡한 것은 없습니다 - 컴파일러/링커에 -flto 옵션을 전달하기 위해(비록 일종의 플러그인이 없지만) 간단히 말해서, 알아내기에는 너무 게으릅니다. + 다시 빌드해야 할 수도 있습니다. libstdc++.
Команда Visual C++ рада сообщить, что в Visual Studio 2017 было существенно улучшено качество реализации модулей C++ согласно технической спецификации; также мы добавили возможность подключать Стандартную Библиотеку C++ через интерфейсы модулей. Эти интерфейсы, как и поддержка модулей компилятором, являются экспериментальной разработкой и будут...
그래서 그들은 다음과 같은 경우에도 그가 매번 메모리를 할당하고 삭제한다는 것을 알게 된 것 같습니다.
그건 그렇고, 나는 지난 시간에 잘못된 결과를 제공했을 수도 있습니다. x86 모드일 가능성이 큽니다. 이제 x64에서 테스트 중입니다. C ++의 결과가 훨씬 좋습니다.
1) ~ 2000ms
2) ~200ms(3배 가속)
사실, Studio도 최신 버전으로 업데이트했는데, 분명히 이것 역시 영향을 받았기 때문입니다. x86도 이제 과거 측정보다 빠릅니다.
글쎄, 일반적으로 이제 C ++는 Sharpe를 그렇게 부끄럽게 배수하지 않습니다. 총 약 3회
당신은 이해하지 못합니다, 나는 다른 것에 대해 이야기하고 있습니다. 일반적으로 테스트는 페이로드가 없는 베어 사이클인 장난감입니다. 인라인할 수 없는 함수 호출 에서 손실이 발생한다고 말하려고 했습니다. 플러스 모듈을 더 잘 테스트하면 결과가 더 흥미로울 수 있지만 아직 완성되지 않았을 수 있습니다.
시간 = 1018
합계 = 894782460
시간=371
합계 = 894782460
헤이즈 하지만 µl은 훨씬 앞서 있습니다(그리고 rand()를 사용하는 더 멋진 옵션).
그리고 저에게는 사이클을 견디는 것이 분명합니다.
예, 맞습니다. VS에서도 시도했습니다. 어떤 이유로 든 빌어 먹을 것이 최적화되지는 않았지만 그런 간단한 옵션이 보일 것입니다 ... 실제로는 다음과 같이 요약됩니다.
예, 맞습니다. VS에서도 시도했습니다. 어떤 이유로 든 빌어 먹을 것이 최적화되지는 않았지만 그런 간단한 옵션이 보일 것입니다 ... 실제로는 다음과 같이 요약됩니다.
프로젝트 설정에서 모든 최적화를 켰습니까? 이해할 수 없는 경우에는 어셈블러 목록 생성을 켜고 매우 유익한 교훈을 봅니다.
관심을 끌기 위해 C#에서도 테스트하기로 결정했습니다. 결과는 속도 측면에서 실제로 서로 다르지 않을 뿐만 아니라 C ++보다 훨씬 빠르게 작동합니다.
결과:
합계: 894782460, 시간: 69ms
합계: 894782460, 시간: 56ms
다음은 C++에서 해당하는 내용입니다.
합계: 894782460, 시간: 2947ms
합계: 894782460, 시간: 684ms
VS 2019에서 테스트 . 모든 최적화가 활성화되었습니다.
용광로에서 C++)
ps C#의 결과는 테스트에서 테스트로 눈에 띄게 점프하지만 평균적으로 두 옵션의 속도가 동일한 것으로 나타났습니다.
여기서 먼저 브레이크의 원인을 이해해야 합니다. 나는 조금 팠다, 전화를 제외하고는 모든 것이 거기에 인라인되어있다.
libstdc++에 있습니다. 저것들. 거의 베어 사이클의 배경에 대해 함수 호출 자체가 병목 현상이 됩니다(음, ...replaceEmmPKcm 에서 호출도 몇 개 있습니다). 컴파일러는 결국 하나의 번역 단위 내에서 최적화할 수 있습니다. 여기에서 LTO(링크 시간 최적화), 즉 이것은 연결 단계에서 최적화를 허용합니다. 하지만 많이 사용하지 않았으니 지금 당장은 하지 않겠습니다. 글쎄요, 특별히 복잡한 것은 없습니다 - 컴파일러/링커에 -flto 옵션을 전달하기 위해(비록 일종의 플러그인이 없지만) 간단히 말해서, 알아내기에는 너무 게으릅니다. + 다시 빌드해야 할 수도 있습니다. libstdc++.
글쎄, 그것은 모듈의 다가오는 나사 결합(C ++ 20부터 시작)과 관련하여 코드의 최적화는 어떻게 될까요? 모든 것이 축축하고 실험적이긴 하지만, vs에서 뒤집을 수 있습니다. https://habr.com/en/company/pvs-studio/blog/328482/
C++'를 놓칠 것입니다)).
관심을 끌기 위해 C #에서도 테스트하기로 결정했습니다. 결과는 속도 측면에서 실제로 서로 다르지 않을 뿐만 아니라 C ++보다 훨씬 빠르게 작동합니다.
결과:
합계: 894782460, 시간: 69ms
합계: 894782460, 시간: 56ms
다음은 C++에서 해당하는 내용입니다.
합계: 894782460, 시간: 2947ms
합계: 894782460, 시간: 684ms
VS 2019에서 테스트 . 모든 최적화가 활성화되었습니다.
용광로에서 C++)
ps C#의 결과는 테스트에서 테스트로 눈에 띄게 점프하지만 평균적으로 두 옵션의 속도가 동일한 것으로 나타났습니다.
Br-rr-rr, 네 그럴 수 없습니다! 샤프는 항상 깨끗한 플러스와 두 번마다 병합되어 프로젝트 plz를 배치합니다.
작은 아이들 :)
그들은 장난감을 10 페이지로 늘렸습니다 ...
여기서 먼저 브레이크의 원인을 이해해야 합니다. 나는 조금 팠다, 전화를 제외하고는 모든 것이 거기에 인라인되어있다.
libstdc++에 있습니다.
그래서 그들은 다음과 같은 경우에도 그가 매번 메모리를 할당하고 삭제한다는 것을 알게 된 것 같습니다.
그건 그렇고, 나는 지난 시간에 잘못된 결과를 제공했을 수도 있습니다. x86 모드일 가능성이 큽니다. 이제 x64에서 테스트 중입니다. C ++의 결과가 훨씬 좋습니다.
1) ~ 2000ms
2) ~200ms(3배 빨라짐)
사실, Studio도 최신 버전으로 업데이트했는데, 분명히 이것 역시 영향을 받았기 때문입니다. x86도 이제 과거 측정보다 빠릅니다.
글쎄, 일반적으로 이제 C ++는 Sharpe를 그렇게 부끄럽게 배수하지 않습니다. 총 약 3회
그래서 그들은 다음과 같은 경우에도 그가 매번 메모리를 할당하고 삭제한다는 것을 알게 된 것 같습니다.
그건 그렇고, 나는 지난 시간에 잘못된 결과를 제공했을 수도 있습니다. x86 모드일 가능성이 큽니다. 이제 x64에서 테스트 중입니다. C ++의 결과가 훨씬 좋습니다.
1) ~ 2000ms
2) ~200ms(3배 가속)
사실, Studio도 최신 버전으로 업데이트했는데, 분명히 이것 역시 영향을 받았기 때문입니다. x86도 이제 과거 측정보다 빠릅니다.
글쎄, 일반적으로 이제 C ++는 Sharpe를 그렇게 부끄럽게 배수하지 않습니다. 총 약 3회
Br-rr-rr, 예, 그럴 수 없습니다! 샤프는 항상 깨끗한 플러스와 두 번마다 병합되어 프로젝트 plz를 배치합니다.
플러스 모듈을 더 잘 테스트하면 결과가 더 흥미로울 수 있지만 아직 완성되지 않았을 수 있습니다.
내가 보니 단일 컴파일러가 https://en.cppreference.com/w/cpp/compiler_support 모듈을 완료하지 않았으므로 볼 것이 없습니다.