위는 어제 kukyakya가 작성한 코드 회사컴 맥프로 ( 인텔 제온 ) 에서 테스트한거
아래는 방금, 쿠캬캬가 새로 올린 코드를 i5 에서 테스트한거
32비트
64비트
정상적인 테스트라면 intrinsic 위주로 된 코드는 32 / 64 비트에서 성능차이가 거의 나지 않는다.
대신 size_t 가 64비트가 되기 때문에 약간의 오버헤드가 생겨 64비트가 느려지는 경우도 있고,
산술 연산에서 64비트 단위가 약간 득을 볼 수 있지만 어쨌든 큰 차이는 없어야 된다는거다.
저새끼가 올린 데이타는 모조리 엉터리고, 일관성도 없고, std:memcpy 성능이 오락가락한다.
니 문제나 똑바로 교차검증하고 올려 이것아. 자꾸 니 문제를 나더러 풀어달라고 하지 말고 등신아.
두 하드웨어에서 돌려본 결과 192000 : 221000 정도로 memcpy 도, unaligned 도 별다른 성능차이 없지?
이게 테스트 환경과 결과의 일관성이란거다.
걍 열심히 계속 삽질해 보거라.
안 읽었냐?
이 븅신새끼는 며칠째 개소리한거 한줄 한줄 복사해 와서 지적해 주고 니가 한 말 맞냐고 확인해 줘야 아가리를 닥칠건가... 응?
코드 깔 자신 없으면 입털지 말아라, 아무리 이야기를 해도 코드를 안까는거보니 그냥 벽보고 이야기 하는거 같아서 답답하네
똑같은 븅신새끼 둘이 아주 외롭지 않겠구만 ㅋㄷ
그간 코드는 많이 깠다 아갈털지 마라.
이거 봐 ㅋㅋㅋ memcpy 코드를 까라는데 뭔 지금까지 니가 코드를 뭘 깠던 무슨 상관이여?
니가 짠 unaligned 나 이기고 오라고 등신아. 최적화에서 unaligned 가 선택이라니까 개소리라고 하던게 너 아님?
야 글고 까페까지 가서 봤는데 시발 역시나..
https://en.wikipedia.org/wiki/Time_Stamp_Counter
읽어봐라. "TSC cannot be relied on to provide accurate results"라면서 "Under Windows platforms, Microsoft strongly discourages using the TSC for high-resolution timing for exactly these reasons, providing instead the Windows APIs QueryPerformanceCounter and QueryPerformanceFrequency" 테스트베드나 다시 짜고 와라.
사실 포토샵으로 슥슥한거라 소스 코드가 없거든요 ㅎㅎㅎ
글고 시발 천번 테스트해보면서 최소값이 젤 중요하단 얘기는 내가 진짜 첨 듣는다. 거기다 rdtsc. 시발 high_resolution_clock까진 안바래도 QueryPerformanceCounter 정도는 쓸 줄 알았더만..
그건 니가 몰라서지 ㅋㄷ 그 이유가 왜 나왔는지도 모르지
내 지난글들에 QueryPerformanceCounter 에서나 rdtsc 가 이상동작하던 보드들 문제 다~~~~~~~ 언급했다.
그런데 병신아 내가 저걸 왜 쓰냐하면, 수회 try 에서는 정확한 값이 나오고, QueryPerformanceCounter 는 한 번 호출에 수백 클럭을 쳐먹기 때문에 작은 코드 테스트에 부적합하기 때문이다.
검색 존나 때려봐라 얼빵한 새끼. 쯧.
니 테스트베드나 고쳐 등신아. 내껀 내가 알아서 잘 고쳐 쓰니까.
암요 수백클럭 잡아먹는것보단 부정확한 rdtsc가 짱입죠. 평균테스트 시간보다는 최소 시간이 더 중요합죠. 이 새끼는 일단 지 코드라도 가져오면 모르겠는데 주댕이만 좆나게 털어서 짜증나. 애초에 intrin.h 인클루드하고선 __rdtsc() 놔두고 인라인 어셈블리 쓰는 꼬라지 하며..
야이 등신아 rdtsc 가 오작동 했던 보드들도 오차가 10클럭이야. ㅉㅉ 뭘 알고 떠들어.
QueryPerformanceCounter 가 monotone 을 만족하기 땜에 그나마 reliable 하다는거지. 그 안에 품고 있는 오버헤드가 컨텍스트를 흐리니까 난 안쓴다고.
QueryPerformanceCounter 는 QueryPerformanceFrequency 랑 같이 쓸 때, 절대 소요시간과 유사한 값이 나온단거야. 근데 과거엔 대부분 클럭베이스였지만, 매크로클럭 단위로 바꼈고, rdtsc 는 가끔 멈칫 멈칫 하는 경우가 있었기에 게임 등에 사용할때 클럭이 뒤로 가는 오작동이 걱정되었다는거지. 그거 다 알고 필요에 맞춰서 쓰는거니 너같은 허접한 것이 검색해서 까댈바가 아니란다. 공부는 좀 니 혼자해. 나한테 점검받지 말고.
그래서 시방 니가 짠 테스트 베드가 신뢰할 수 있다고 지금 개소리하는거임? ㅋㄷ
아.. 이 병신은 진짜 뭐 갖다 줘도 읽질 않네.
http://abipictures.tistory.com/353
봐바.
RDTSC를 사용하는 것은 스레드가 항상 같은 프로세서에서 실행된다고 바로 가정을 합니다. 멀티 프로세서와 듀얼-코어 시스템들은 코어들 사이에 그들의 사이클 카운터들이 동기화 된다고 가정하지 않습니다. 이것은 다른 시간들에서 다양한 코어들을 휴지 시키고 깨우는 현대의 전원 관리 기술들과 결합될 때 코어들에서 보통 동기화가 벗어나는 결과가 발생되어 더욱 악화됩니다. 어플리케이션이서, 이것은 일반적으로 전류의 이상이나 프로세서들 사이에서 스레드 점프에 따라 가능한 충돌들내에서의 결과이고 큰 델타값, 음수 델타값, 타이밍 종료의 결과를 얻게 됩니다.
임마 QueryPerformanceCounter 도 RDTSC 베이스거든? 정신좀 차리고 오렴?
그걸 안전하게 가공해서 쓰냐 못쓰냐는 사용자 재량이야 ㅉㅉ
글고 누가 쿼리퍼포먼스카운터를 매 번 호출하래? 100번 테스트하면 앞뒤로 한번씩만 넣고 100으로 나누면 되잖아? 평균 내는게 그렇게 어렵고 싫으냐
그래. 그걸 안전하게 가공해서 쓰냐 못쓰냐는 사용자 재량인데 어째 니 코드에는 안전하게 가공하는 코드가 안뵌다? 내 눈이 하루아침에 장님이 됐나
내가 위에 올린 보고들이 reliable 한가 니가 작성한 결과가 reliable 한가는 양심에 손을 얹고 판단하길. ㅋㄷ
넌 검색충이니까 ㅋㄷ 그럼 그렇지.
니가 멍청한게 뭐냐하면, OS 가 현재 테스트 중인 코어를 사용할때 시간이 불어버리는걸 어떻게 막을거냐는거야. 넌 mean 과 median, min 과 max 의 효과도 모르니?
자꾸 공부시켜달라고 조르지 말고 니가 알량하게 믿는 인터넷 검색이나 실컷해서 니 테스트 베드나 좀 고치고 쓰라니깐?
이 새끼는 남들보다 특출나게 코드를 잘 짜는것도 아닌것 같은데 왜케 자신감이 넘치지?? 하.. #define T_T template <class T> 라니 진짜 T_T다...
자 저 테스트에서 확률적으로 시간이 큰 델타값이 뜨면 min 에서 걸러지겠지. 음수 델타값이 뜰 수 있는건 더 느린 넘이 확률적으로 높지. 내가 사용하는 장비들은 그런 문제 없으니 아예 걱정을 말어 한 두대에서 테스트 한게 아냐. 저 테스트들에 일관성이 없다고? ㅋㄷ
얌마 classic C++ 에서 modern 으로 넘어가는 중인건 스타일 문제고 니나 잘해 니 코드 하나 하나 짚으면 온통 쓰레기니까.
당장 클럭도 똑바로 못새는 코드 가지고 뭔 누구한테 훈수질을 하는거여? ㅋㄷ
보니까 코세가 말돌리네 어정쩡하게 아는거 같음
아...진짜좆같은새끼들 좀 닥쳐라
뭔 말을 돌려? 저새끼가 올린 자료 다 틀렸고 말바꾸는건 저새낀데. 조목 조목 한 줄씩 따져서 밤새도록 까줄수 있음.
짚어달라 그러면 공부시켜달라고 조르지 말라면서 도망가겠지? 가르침 좀 주십쇼 형님. 난 어째 공부하면 공부할 수록 내가 잘 못하는거 같아서 스스로 잘한다는 얘기 하기 부끄럽던데 넌 어째 니 코드 모양새랑은 좀 안어울리게 자신감이 넘친다?? 템플릿이 모던C++이라는 얘기는 또 뭔지.. 90년대에서 타임머신 타고 오셨나
아..존나 보기만해도 좆같네 어떻게 이렇게 좆같을수가있을까
개소리 털지말고 오작동중인 니 테스트 베드나 잘 고치세유?
니가 원하면 니가 며칠동안 했던 개소리 한줄씩 복사해 올려주고 확인받아 준다니깐?
개소리는 충분히 했으니까 이제 니 코드나 가져와봐 제발 좀. 가져오라는건 안가져오고 좆나 도망치네. 내가 앵간하면 남의 코드 갖고 잘짰네 못짰네 안하는데 니 코드는 좀 못짠거 같다. 까페에서 좀 더 보고 올게.
니 코드는 어련히 잘짜서 저모양이겠수~
코세형 왜 코드보여주시는걸 꺼려하시는지 모르겠네요
음? 그거 일부러 약올리는거.
어차피 대여섯줄이면 끝남. 근데 저새끼가 때마침 첫 코드부터 지 스스로 느린 코드 짜놓고 빠르다고 올려놓고 있더만 ㅋㄷ. 저 새끼 특징이 온갖 잡 소리 다 끌고 나오면서 지가 개소리한거 말돌리는 스타일이니 스스로랑 싸우라고 냅두는거지.
원래 첨 이야기할땐 C++ 로 짜라고 했고 intrinsic, inline assembly 같은건 엄밀히 C++ 이 아니라고 이야기 했거든? 그 뒤 내가 글써서 명시적최적화와 묵시적 최적화 에 대해 이야기하고 intrinsic 이야기 했더니 그걸 지가 깨달은양 삽푸고 있음. ㅋㄷ 문제 자체는 C++ 기본 문법으로 작성하는거였고 이미 범위는 벗어났고, 하지만 그러고도 아직 unaligned 를 못 깨고 계시지.
첨부터 말했지만, C++ 문법으로 Visual Studio 에서 unaligned 두 개의 주소를 받는 memcpy 를 구현할 때 unaligned 보다 최적화 시키긴 어려움. 특정 메모리 크기 단위로 순위 변동은 있을 수 있지. 하지만 첨부터 말했듯, unaligned 는 최적화를 위한 선택이고, 복잡하게 unaligned 를 구현하는 것 보다 아주 단순하고, 당연히 코드 유지보수도 쉬움.
ㅋㅋㅋ 그럼 컴파일러가 memcpy로 치환하는건 엄밀히 unaligned access냐? 이 새끼는 최초의 논지가 뭐였는지를 자꾸 까먹나봐? gcc는 memcpy로 치환하는거 옵션으로 꺼서 보여줬고, vs에서는 그게 안되니까 차선책으로 intrinsic쓴거 아냐 등신아. 왜 intrinsic을 썼는지 그 돌대가리로 곰곰히 생각이나 좀 해봐.
단순히 memcpy 로 inline 되는게 아니라고 예시를 보였다만 =_= 넌 글을 안 읽냐?
약올리는게 아니라 코드가 없는거겠지 ㅋㅋㅋㅋ 정말로 이 상황에 '사실은 코드가 있는데 약올리려고 안올리는거구나'라고 진지하게 빋으면 병신 아니겠냐?
이제야 1.68 배 느린 코드 그것도 intrinsic 써서 만들어낸 주제에 니 주장이 맞다고 나불거리는거냐?
니가 짠 코드보다 느리니 놀리는거지 내 말이 틀림?
코드가 있다 없다로 이야기 하는거 참 웃기네 ㅋㄷ 지가 댓줄 짠 unaligned 보다 느린 코드가지고 웃긴 조건으로 논문쓰고 딸치는 주제에 그나마도 테스트 베드 다 틀렸고.
단순히 memcpy로 inline되는게 아니란게 무슨 소리야? 내가 못봤나보다 링크 좀. 뭔 소린지를 알아야 반박을 하지. 글고 이참에 다른 컴퓨터에서도 테스트해봤는데 std::memcpy 8.36768 GiB/s my_memcpy : 13.229GiB/s my_memcpy_unaligned : 9.05075 GiB/s 나오는데? 천번씩 다섯번 해봤는데 얼추 비슷하네. 1000번 앞뒤로 high_resolution_clock 한번씩만 호출해서 평균낸거니까 오버헤드같은 개소리는 하지 말구.
자 1메가 때려보렴.
그전의 니 모든 데이타가 다 틀렸다는건 지금 니 말로 증명하고 있는거고.
난 분명히 처음부터 선택이라고 이야기 했고, 메가단위도 언급했고 처음부터 지금까지 한번도 1MB 64KB 외의 테스트를 한적 없음 위에 저 기준 다 1MB
그리고 평균은 옳지 않음. 특히나 대용량일수록. 그건 니가 경험으로 깨닫길 ㅋㄷ
글구 매번 얘기하지만 unaligned access가 UB라서 컴파일러가 지맘대로 aligned instruction 생성할 수 있는 경우도 테스트해서 뻑나는거 확인했으니까 이것도 개소리는 하지 말구. high_resolution_clock이 이상한거라는 개소리도 몇번씩 테스트해봐도 같은 결과였으니까 하지 말고. 걍 닥치고 내가 올린 그대로 돌려봐. 뭐 high_resolution_clock 구현에 버그가 있을 수도 있겠지만 VS 2015 정도 되는 애가 설마 그럴까
니 입으로 UB 는 둘째치고 랬지 맞아 틀려?
자꾸 개소리 섞지 말고.
이거 봐 이 새끼는 꼭 뭐 레퍼런스도 없이 지 경험만으로 이런다니까? ㅋㅋㅋ 평균이 왜 옳지 않다고 생각하는지 물어보면 막상 근거도 없이 제대로 말도 못하고 '혼자 잘 생각해보렴?' 이지랄하겠지?
1MB 돌리고 결과 니 눈으로 확인해.
니가 존나 구글링해 제시한 레퍼런스 거의 다 경험으로 확인했으니 하나 하나 지적했던거다.
이 새끼는 꼭 뭐 물어보면 선문답질이여. 인터넷의 수많은 레퍼런스보다 지 생각이 무조건 옳다고 생각하는것도 병이다 병.
CPU 가 특정코드를 실행하는데 소요되는 클럭은 늘면 늘었지 줄진 않아. rtos 와 물리적으로 linear memory 가 아닌 이상 말야.
그래서 최소값을 선택하는거고, 커널이 소비해버려서 시간이 편중되는걸 막기 위함이야.
일정 용량 이상 무거운 메모리를 테스트 할때는 자주 쓰는 작은 단위 결과들과 전혀 다른 결과가 나오기도 하니까 경험적으로 64KB 1MB 4MB 정도로 테스트 하고 있는거다.
야 글고 시발 ㅋㅋㅋ 대용량일 수록 더 평균이 중요하지 병신아 대용량일 수록 시간이 오래 걸리고 그 동안 스케쥴링 될 가능성도 커지는데 뭔 대용량일 수록 최소가 더 중요해. 어디 DOS 쓰시나 시발 깜빡 속을뻔했네
니가 테스트 좀만 돌리면 알게 되겠지.
무슨 함수를 먼저 세우든 첫 테스트 케이스가 대체로 몇 천~ 몇 만 클럭은 더 느려지는 경우가 잦고,
일정 시간 이상수행하게 되면 kernel 도 해당 core 를 사용하곤 한다.
그리고 요즘 CPU들은 turbo boost 를 지원하기 때문에, 수동으로 끄지 않는 이상은
글고 용량이 작으면 aligned/unaligned보다 캐쉬 영향에 더 좌우된다니까? aligned/unaligned를 비교하려면 용량을 크게 잡아야지 뭔 자꾸 딴 요인을 끌어다쓸라고 용을 쓰고 있어
처음 부하를 걸어주는 코드보다, 이미 웜업이 된 경우가 더 빠르단거야.
야 그래서 내 테스트 코드에 실제 테스트 전에 루프 몇번씩 돌리는거 안보이냐?
그래서 4MB 까지 쓰는거고, 등신아 memcpy 가 확률적으로 가장 많이 수행될 크기가 어느정돈지 가정해서 최적화 한다고 엉뚱한 최적화를 하지 않기 위해서
그게 니 삽질이지. 그리고 나서 OS 가 뜬금없이 잠시 니 테스트 중인 core 를 쓰는걸 막을 수 있음?
하.. 인터넷의 수많은 레퍼런스보다 본인의 경험이 더 정확하다는 분이시니 본인이 짠 소스코드나 좀 올려보시죠.
그걸 강제로 막는다 쳐, 그게 실제 실행환경임?
누군 생각 안하고 짜나 니 지식의 짧음을 논리적으로 반박하고 있는거지.
OS 가 뜬금없이 잠시 니 테스트 중인 core 를 쓰는걸 막을 수 없으니까 평균을 내야지 이 븅신새꺄 지 말을 지 말로 반박을 하고 앉았네
얌마
1번째 함수가 돌때 OS 가 건들고, 2, 3 번째 함수는 안건들면
평균이 어떻게 되냐?
최소 수행시간은 실제 필요 수행 클럭 보다 줄어들 수 없다니깐? 이새끼 CPU를 제대로 이해하고 있는거야 뭐야
min 을 아주 많이 돌리면 아주 stable 해진다. 니가 돌려보고 느껴.
명령어 하나 단위로 3 클럭이 늘고 주는게 눈에 보인단 말이다. 바보야.
그건 average 로 절대 얻을수 없는 정밀도야. ㅉㅉ
니가 한거 내가 다~~~~~~ 해보고 결정한게 지금의 내 테스트 베드니 좀 더 연구해 보시게.
내가 왜 for 문 돌려서 클럭 계산 안하고 한 번에 18클럭 정도 소요하는 rdtsc 를 사용해 성능을 측정하는가 하면, 또 하나의 이유는 for 문 조차도 context 를 흐리기 때문이다. 아주작은 swap 수준의 명령 성능을 측정할 때 말야.
그게 루프 안에서 일일이 매번 rdtsc 를 구할때 얻을 수 있는 장점 중 하나야. 멋지지. 키둑.
물론 작은 코드 테스트를 위해 루프 언롤링을 좆 빠지게 한다고 해서 컨텍스트가 흐려지지 않는건 아니지 엄밀히 말하면, 그렇게 반복적으로 실행되는 경우는 드무니까. ( 다른 코드와 화합할때의 성능을 측정해야 하니까 ) 하지만, QueryPerformanceCounter 나 내부 for 문이 흐리는 정도의 branch hazard 와는 차원이 다르지.
위에서 루프 언롤링을 언급한건, 단일 rdtsc 쌍 안에서 18클럭이 소요되지만 꽤 많은 량의 코드가 파이프라인과 스칼라를 통해 코어 내부 병렬처리되어버리기 땜에 어지간히 조금은 볼륨이 있어야 18클럭을 뚫고 나오기 때문임.
암요 수백클럭 잡아먹는것보단 부정확한 rdtsc가 짱입죠. 평균테스트 시간보다는 최소 시간이 더 중요합죠. 이 새끼는 일단 지 코드라도 가져오면 모르겠는데 주댕이만 좆나게 털어서 짜증나. 애초에 intrin.h 인클루드하고선 __rdtsc() 놔두고 인라인 어셈블리 쓰는 꼬라지 하며.. <-- 이거 이제 읽었는데 병신아 원래 다른 컴파일러용으로 만들었던 코드를 가져와서 그렇게 되었던거고 최신버전엔 정리 다 되어 있다. ㅉㅉ
컨텍스트 같은 소리 하고 앉았다 뭔 또 혼자 뜬구름 잡는 소리여? 루프언롤링하면 코드 크기 커져서 오히려 캐쉬미스 땜에 느려질 수 있다고 하면 이해나 하지. 다른 코드와 화합한다는건 무슨 소리여? 이 새끼는 뭔가 개념이 좆나 지좆대로인것 같아.
머리가 무척 나쁜 아이로구나. ㅋㄷ
18 clock 뚫는것에 대한 이야기지 멍청아. ㅉㅉ CPU 내부 연산 블럭들이 어떻게 운용되는지 전혀 모르니 내 말을 알아들을 수가 있나?
일일이 설명해주기도 귀찮다. 머리도 나쁘고 싸가지도 없고. 뭘 보고 너한테 가르쳐주겠냐? ㅋㄷ