memcpy 에 직결해 놓은건 그저께 새벽에 내가 참고하라고 던져준 안정성 처리 코드처럼 별 다른 메카니즘이 없기 때문.
애초에 성능테스트에 memcpy를 타는 경우는 넣지도 않았음. (그랬으면 스샷에 속도가 같게 나오겠지)
총 8가지 케이스가 있음.
tgt 주소가 align 되지 않은 경우 -> 일단 한쪽을 맞추는건 쉬움. 포인터가 두개이기에 문제가 되는것. strlen 으로 시비걸었던 ㅉㅉ의 멍청함
두 사람 다 tgt 주소는 간단히 맞추고 시작함.
src 주소가 align 되지 않은 경우
모두 align 된 경우 -> 순풍순풍
모두 align 되지 않은 경우 -> 루프만 맞추고 짜투리 처리는 하다가 나가야했음
위의 4가지 것들에 대해 각각 32비트, 64비트인 경우가 있음
내가 작성해서 올린 코드 중
case 0: 즉 src 주소가 align 된 경우의 코드에 case 1: 2: 3: 을연결시켜도 모두 잘 돌고 모두 ㅉㅉ보다 빠름. 당연한거임.
넌 4바이트 정렬 밖에 쓴게 없거든.
그나마도 니가 segmentation fault 지랄 헛소리 나불거린거 비트 연산으로 시작주소 풀었던
내 코드랑 전혀 다를바 없게 짠 코드로 말야.
(하지만 windows vc++ 컴파일러로 세그먼테이션 자체를 재연할 수 없없음. -> 이건 애초에 ㅉㅉ 가 딴지건거지 내가 딴지건게 아님.)
거기에 난 non-breaking switch 와 loop unrolling 을 썼고 캐시 크기를 고려해서 작성함. <- 캐시 메카니즘에 대한 고려는 부족 이부분은 개선의 여지가 있음.
그 결과 니 코드 보다 거의 2배 빠름.
src 가 정렬되지 않은 케이스에 대해 작성하다가, (1, 2, 3 나머지가 있는 경우를 각각 짜줘야 되는데 생긴 모양은 똑같음 비트 연산 자릿수만 달라지는 경우)
loop 부분은 코딩해놓고 짜투리 자릿수 계산중이었기 땜에 그냥 성능비교만 올려놓고 간거임.
애초에 case 0 의 코드로 32비트 64 비트 다 맞고 둘 다 너보다 빠른데 성능 오작동 이야기 하는게 웃김.
다른케이스는 덜짰다고 말했잖나?
아니 코세님이 하나로 족하게 짜던 ㅉㅉ님이 세개로 짜던 제대로 돌아가기만 하면 저는 상관 없고요.
아까는 ㅉㅉ님 코드가 오류 난다면서요.
그러니까 그 증거를 가지고 오라고요. 참고로 저는 알고 있는데 코세님은 한세월 걸리실듯.
그 오류는, 다시 말하지만 정렬하지 않은 다른 포인터 하나의 문제. 그건 오류 나는 시스템도 있고 안나는 시스템도 있다.
기초적인거니까 찾아봐. linux, unix 장비들에서 pipe 가지고 놀때 흔히 겪던 문제야.
최근 10분간 다신 댓글에서 ㅉㅉ님의 코드가 폴트 발생할수 있다면서요 그가능성이 있는 부분을 지적 하시라고요. 근데 이제는 사실상 그냥 변수하나 왜 못줄였나 와일문 하나로 족한데 왜 세개로 했나 이런 부가적인거만 얘기 하시네요?
그 포인터가 먼데요? 몇번째 줄에서 어떻게 사용되고 있는데요? 헛다리 짚어도 한참 헛다리 짚으신듯.
아니 라인 번호만 불러 주시면 되는데 왜 못하실까?
char a[1000]; int* v = (int*)(a + 1); 에서 *v 를 읽거나 *v 에 쓰면 읽을때 에러나는 넘 읽거나 쓸 때 에러나는넘 갖가지임. 내가 다른 애 코드 올려 놓은거에 거기에 대한 처리가 다 들어있음.
여기에 숫자 댓글 쓰기가 그렇게 어렵나요?
윈도에서 잘 도는데 시스템 문제라니깐?
알아들을 생각을 안하는거냐 머리가 나쁜거냐?
지금 코드 보고 있는데 그런 코드는 있지도 않고요. 혹시 *(int *)d = *(int *)s; s += WORD_SIZE; d += WORD_SIZE; c -= WORD_SIZE; 이부분을 예를들어 말씀 하신 거면. 아시다 시피 저 모든곳에 접근할수 있는지는 와일문 조건에서 count로 판단하고 들어 갑니다.
내가 링크 올린 소스랑 비교해봐. 그 링크 올린 소스를 분석해라. 제발. 좀. 난 또 여친한테 꾸사리들으러 감.
진짜 ㅉㅉ님 코드 이해는 하신거에요? C일주일만 배워도 다 이해하도록 엄청 쉽게 짜져 있는데요? 왜 이해를 못하세요? 차라리 여기 C배우러 새로 오신분들 하고 얘기하는게 더 좋겠네요. ㅋㄷㅋㄷ
또 토꼈네 ㅋㅋㅋ
40줄도 안되는 코드에서 라인번호 부르고 오류날 조건 제시 하라는데 그게 그렇게 어렵나 ㅋㅋㅋ
야이 병신아 얼라인 하지 않은 코드에서 읽는부분 전부가 오류 대상이라고.
두번째 부터 세번째 while 문 전부가 오류대상이라고 좀.
아니지 세번째는 짜투리 처리니 두번째 제일 큰 루프블럭에서 읽는 부분이 다 에러 대상이라고.
그니까 니가 예로 든 부분에서 *(int*)s 가 에러 대상이라고. 못알아듣겠냐?
*d = *s; <-- 이부분. 매크로에 들어있음.
당연히 문제가 되는건 backward 처리 부분임.
destination 주소가 source 보다 크다고 무조건 backward 처리하는것도 웃김. 그래서 자기가 짰다는거임.
destination 이 source + length 보다 크면 중첩도 아닌데.
ㄴ 크거나 같으면.
(destination 이 source + length 보다 크면 중첩도 아닌데.) 이경우를 따로 처리하면 조건문이 하나더 늘겠지요?
왜 그런 쓸데 없는 짓을 하나요? 걍 오버랩이라고 가정하고 백워드로 처리하면 끝인데 굳이 중첩인지 아닌지 판단해서 포워드로 해야되나요? 그런 쓸데 없는 짓을 왜하죠? 어차피 백워드 처리 코드는 필요한 것인데 여기다가 쓰면 나쁠거 있나요?
그리고 백워드 처리할때도 두번째 와일문에서 여전히 카운트 판단하고 들어가는데 무슨 헛소리세요?
그리고 두번째 와일문은 백워드이든 포워드 이든 무조건 얼라인 구간에만 들어 갑니다.
시작 조건 한 번이지 바보야. 그 뒤로 얻는 이익이 크니까 문제.
통계나 확률이 머리로 바로 계산 안되는 니문제를 내가 고민해줄 필욘 없다.
두번째 와일문에서 포인터 하나는 정렬되어 있고 나머지 하난 아니라고 좀... 멍청아.
두번째 와일문에서 c >= WORD_SIZE 이조건 보이시죠? 워드 사이즈가 4라고 치면 *(int *)s; 여기에서 4바이트를 읽어 오겠지요. 이때 s가 가르키는 지점은 무조건 얼라인된 4바이트의 시작점이고 거기에는 정상적인 데이터가 가득 들어 있습니다. 왜냐하면 그 앞 와일문에서 짜투리는 다 처리 했고 count>=4인것도 확인하고 들어가니까요. 그러니까 문제 될거 없죠.
야이 븅신아.
int temp[65536]; int* src = temp + 1; int* tgt = temp + 3; 이라고 치자
캐스팅 귀찮아서 생략.
src 와 tgt 이 둘 다 정렬 안된 상태로 움직이게 되어 있어. 그걸 맞춰주는게 이 문제의 핵심이고.
ㅉㅉ 는 하나만 맞췄다고.
애초에 ㅉㅉ 는 문제를 다 풀지 않았다고 뭔 말이 많냐.
char temp[65536]; int* src = (int*)(temp + 1); int* tgt = (int*)(temp + 3);
windows 에선 잘 돌아가. 몇 몇 시스템에선 세그먼테이션 폴트를 낼꺼고.
그래서 일일이 src, tgt 다 맞춘 버전의 코드를 먼저 예시로 올린거라고 좀 ㅡㅡ
애초에 세그먼테이션 fault 는 strlen 에서 ㅉㅉ 가 먼저 내게 딴지건 주제임. 몇 번 말을 해야되냐.
그 예시 코드가 너무 느리고 불합리하게 되어 있어서 최적화 코드 짜 올리다가 여친님 호출에 나온거라니깐.
오 그나마 근접 하셨네요 ㅋㅋ *(int*)s 아까 이부분이 문제라고 하셨는데 이부분이 소스 에서 얼라인 단위로 읽어오는 부분입니다. 제가 방금 설명 드린대로 읽어 올때는 얼라인 단위가 맞쳐줘서 문제 없다는거 *(int*)s 이부분 문제 없다는거 인정 하시는 거죠? 그럼 쓰는 부분 (*(int *)d=) 이부분이 문제 라는거죠? 예 맞습니다. 쓸때는 얼라인이 안 맞을 수 있지요. 자 CPU랑 램 내부적으로 얼라인이 안 맞게 쓸때는 어떻게 되느냐? 아무 문제 없습니다. 얼라인에 안 맞게 4바이트를 쓰면 4바이트를 읽어 올때 처럼 걸쳐있는 두 얼라인 단위가 한번에 읽어와지는 문제와 비슷한 문제가 발생 할것 같죠?
ㅋㅋ 시스템 제대로 안배운거 티내세요? 쓸때는 두 얼라인 단위에 걸쳐 있어도 다른 부분은 전혀 엑세스 되거나 덮어 써지거나 그런거 없이 바로 지정한 4바이트만 덮어 써집니다. 메모리가 read와 write시에 어떻게 다르게 작동 하는지 공부 하셔야 할듯.
ㅉㅉ님이 괜히 소스쪽에 얼라인을 맞췄겠나요?
그건 니가 똑바로 안배운거임. 시스템 각각임. 멍청아. ㅉㅉ
src 가 정렬 안된 경우에도 case 0 1 2 3 모두 내 코드의 case 0 로 직결하면 정상적으로 돔, 그게 되는 시스템이 있고 아닌 시스템이 있음.
허접은 그냥 인방갤로 꺼져 ㅡㅡ 공부해야 겨우 이해하는 주제에 나한테 시비걸지 말고.
ㅋㅋㅋ 이분 웃기신 분이네. CPU와 RAM과 사이의 규약등등 아키텍트를 설계하는 사람은 바보가 아닌이상 읽기든 쓰기든 적어도 둘중 하나는 저렇게 작동 하도록 설계할 수 밖에 없습니다. 제가 아는 모든 시스템은 쓰기시 저렇게 작동하도록 선택 했고요. 혹시 어떤 개인이 취미로 만든게 아니라면요. 진짜 어떤 개인이 취미로 그렇게 만들었다고 칩시다. 이 시스템에서는 논리적으로 어느 누구도 님이 말한 문제 해결 못합니다. 불가 입니다. 예를 들어 볼까요? 바이트 거의다 처리하고 마지막 바이트 하나 딱 남았다고 생각해보죠. 그런데 직전에 처리한 데이터는 한 얼라인 단위에 딱 들어 맞았고 이 남은 바이트는 다음 얼라인의 시작점에 넣어야 한다면 그 시작점에 해당하는 번지 1바이트만 라이트 해야 되는데
가서 니 허언들이나 반성하고 오렴. 니가 아는게 전부가 아니란다.
여기 댓글로 니가 적은 허언들 바보같은 소리 정렬해볼래? 몇 줄이냐 대체.
니 공부 니가 해라 싸가지 없는 새끼 공부 안시켜준다.
이 개인이 만든 시피유 자체가 얼라인에 존재하는 4바이트를 다 억세스 해버린다면 부작용을 막지 못하는 거죠. 그래서 RAM은 쓸때라도 정확하게 지정한곳을 지정한 사이즈 만큼만 부작용 없이 쓰도록 작동하게 설계된겁니다.
사람들은 할말이 없으면 욕을 한다 - 볼테르 -
가서 니가 말한 코드 자동 생성 예제나 올리도록 한다 - 코세 -
12시간 줄게 수고.
또 토꼈네.ㅋㄷㅋㄷ
코세는 안되면 토낀다. -DoWhile-
뭔 쓸데없는 소리나 늘어놓으면서 토꼈네 남발 하는 이새낀 뭐임 지가 말한것도 못짜는주제에.
인방갤로 꺼져 허접아.
둘 다 맞춰야 되는 시스템 많으니까 너혼자 소설쓰지 말고.
제가 님을 위해서 코드 생성으로 짜주겠다고 한적 없는데요? ㅋㅋ
아 맞다 ㅋㄷㅋㄷ 이지. ㅋㄷㅋㄷ ㅋㄷㅋㄷ
전 님이 틀렸다는걸 지적 하고 있는데 왜 저보고 짜오라고 하시나요? 전 허접이라서 할수는 있지만 부끄러워서 안짤래요.
또 토낌?
코세는 안되면 토낀다. ㅋㄷㅋㄷ -DoWhile-
dat > src + size 비용 계산도 못하는새끼가 ㅉㅉ
dst 아씨 아이폰 키보드 진짜 혈압오르네
난 바빠서 이만 공부는 자기가.
휴일에 여친도 없어 찌질대는 찐따가 불쌍하다만 정 원하면 나중에 놀아주마.
아 그리고 웃긴건 먼지 알아요? 코세님도 똑같이 짰잖아요.자가당착에 빠지셨네요. 님코드를 크게 보면 스위치문 세개로 이루어져있고 가운데 스위치문 안에는 와일문이 있죠. 이 가운데 스위치문 안에서 대부분의 데이터가 처리되고 나머지 두개는 앞뒤 짜투리 튀어 나온걸 처리하는 구조죠. 처음이랑 마지막 스위치 문 안에서 결국 실행되는 것은 db[n] = sb[n] 이 문장이죠. 방금 제가 말한 상황처럼 앞의 데이터가 얼라인에 딱 맞아 떨어졌고 지금 마지막으로 써야될 바이트가 새로운 얼라인을 시작하는 바이트가 되어야 한다면 님도 그 얼라인 전체를 억세스 하는 거잖아요? 물론 실제론는 그렇게 작동 안하니까 문제는 없지만요. ㅋㄷㅋㄷ
사람은 논리적으로 밀리면 되도 안하는 인신공격을 한다. - DoWhile -
또 토낌? ㅋㅋ
정신 차려 memmove 는 memmove 야. 애초에 for 문 한둘로 되는걸 저렇게 짜는덴 이유가 있어. 알량하게 system word 단위 전송 하나 짜라고 낸 문제가 아님.
위에 다 말한거 되풀이 시키니까 패스.
난 여친이랑 논다 열심히 찌질거려도 못 봄.
돌아와서 하나 하나 씹어주마 니가 쓴 개소리 다 리스트로 정리해서.
코세님 여친(가상)이랑 잘 노시고 오세요. 그리고 제가 방금 제기한 문제는 해명 안하시나요?
코세님 죄송한데 제가 떡밥 하나 쳐서 저한테 낚이신거 있는데... 죄송하구요. 부끄러운줄 아세요. 다음에 밝혀 드릴게요 ㅋㄷㅋㄷ
착각도 유분수지 떡밥이고 뭐고 낚인거 없음. 코드를 볼 수 없어서 src 냐 tgt 이냐 헷갈리는 했다만. 니가 부끄러운 줄 알아.
니가 쓴 허접한 오류들 일일이 열거해줄게 두고보렴. ㅋㄷ
형 확실히 낚였음 ㅋㅋ 설마 이런 헛소리가 통할까 하고 진지하게 해봤는데 통함 ㅋ.
글구 형 솔직히 프로그래밍 이만 접어야 할듯. 감각도 떨어진것 같고 헛소리도 아무 반박없이 받아 들이는거 보면...
dowhile 니가 멍청한게 한둘이어야지 ㅋㄷ 감각떨어진건 맞지만 너보단 나음
아 택시 안에서 폰 보기 속뒤집.
ㅋㅋㅋ 이분 웃기신 분이네. CPU와 RAM과 사이의 규약등등 아키텍트를 설계하는 사람은 바보가 아닌이상 읽기든 쓰기든 적어도 둘중 하나는 저렇게 작동 하도록 설계할 수 밖에 없습니다. 제가 아는 모든 시스템은 쓰기시 저렇게 작동하도록 선택 했고요. 혹시 어떤 개인이 취미로 만든게 아니라면요. 진짜 어떤 개인이 취미로 그렇게 만들었다고 칩시다. 이 시스템에서는 논리적으로 어느 누구도 님이 말한 문제 해결 못합니다. 불가 입니다. 예를 들어 볼까요? 바이트 거의다 처리하고 마지막 바이트 하나 딱 남았다고 생각해보죠. 그런데 직전에 처리한 데이터는 한 얼라인 단위에 딱 들어 맞았고 이 남은 바이트는 다음 얼라인의 시작점에 넣어야 한다면 그 시작점에 해당하는 번지 1바이트만 라이트 해야 되는데
라고 개솔 적어놓은거 웃기네 논리적으로 누구도 해결못한다고? 내가 첨 올려놓은 예제에 해결되어 있음.
다만 느릴뿐.
ㅋㅋ 바보=코세형 맞죠? 낚인거 확실히 해주셔서 감사합니다. 저런 경우 displacement only addressing mode 로 작동 하기 때문에 해결할 문제가 없는데 뭐를 해결 한다는 거죠? 저 말 자체가 다 헛소리 였는데요???
니 말 헛소리인걸 니가 확인해서 뭐?
개념글중 프갤의 절대 법칙 사실로 확인됐습니다
걍 흉들 날잡아서 스카이프같은걸로 대화하고 아프리카로 방송하셈
DoWhile흉도 좀 웃긴게 해결못한다는거 해결했다고하니 함정카드발동도 웃기고 내가 봤을때 코세흉도 흉발언한거 걍ㅉㅉ흉이 문제제기한거랑 같은 걸로 이해한거같음. 그리고 코세흉도 포터빌리티랑 좀 거리가 있었는데 그걸로 미는 것도 있고 해당 문제 자체에서 흉들이 얘기하는 논지에서 점점 멀어지고 걍 감정쌈인듯.
애시당초 댓글로 해보면 서로 빠지는 부분도 있고 서로 오해한 것도 많을 듯 걍 서로 함정파면서 감정쌈할꺼면 리얼타임으로 공개적으로 하셈
displacement only addressing mode 가 뭔지도 모르면서 아는척 잼. ㅋ
DoWhile 저런새끼들 존나 흔함 입으로는 지가 아는거 다 씨부리는데 실제로는 만들지도 못함 ㅋㅋㅋ 지금 말하는 꼬라지만 봐도 자기가 왜 만들어야하냐며 토끼는데 그냥 한심할 뿐임 ㅋ
역시 코세는 대단해.. 암 ^^ ㅋㄷㅋㄷ