+1을 한 번 더 할지라도 그걸 고려해야 할 만한 프로그램이 아니고 그게 영향을 주는 프로그램도 아니고
단지 그럴만한 프로그램이니까 이해도를 위하여 고려하지 않겠다는 말이다.
그 말이 모든 프로그램에서도 그렇게 고려하지 않아도 된다는걸 말하는것도 아니고
내가 아는게 전부라는 뜻도 아니다.
내가 하는 말이 들리긴 들림? 안들리겠지..
+1을 한 번 더 할지라도 그걸 고려해야 할 만한 프로그램이 아니고 그게 영향을 주는 프로그램도 아니고
단지 그럴만한 프로그램이니까 이해도를 위하여 고려하지 않겠다는 말이다.
그 말이 모든 프로그램에서도 그렇게 고려하지 않아도 된다는걸 말하는것도 아니고
내가 아는게 전부라는 뜻도 아니다.
내가 하는 말이 들리긴 들림? 안들리겠지..
집요하네. 그런 마음가짐으로 프로그래밍을 집요하게 하면 성공한다..
자기 변명이 너무 많음. 니 머릿속 모를것 같냐 ㅡ, .ㅡ
연습코드야 걍 돌면된다. 남한테 보여서 안쪽팔릴 코드가 되려면 더 노력하게 되고. 그런거지 뭐.
10글자 + null 이 입력되면요?
스도쿠가 9*9이기때문에 그건 애초에 잘못된 문제
몇 개의 대화로 니가 뭘 알고 뭘 모르는지도 대충 감 잡았다. 어떤 지식에 의존하는지도 알겠고. 네 템포가 있으니 잘 해 봐라.
그리고 충고하건데, 정말 처리속도를 원하면, int 배열로 만들어서 char 스트링을 복사해 넣어라.
bool 과 BOOL 이 구분된 이유랑 같은거야.
int 배열이 char 배열보다 빠르긴 하더라.. 왜인지까지는 모르고. 근데 보여준답시고 코드 간결하게 하는게 목적었어서 몇줄 더 늘면 보는사람이 보기 싫어할까봐
cpu 처리 단위라서
char 를 연산의 단위로 사용하면 내부적으로 32비트 연산 노드들에 0을 채워넣는 stall 이 발생하게 된다. 그래서 조금 느려지지.
32비트면 버스 하나에 4바이트 이거 말하는건강
이미지 처리할때도 RGB24 단위로 처리하면 3바이트씩 주소를 증가시키느라 char* 를 쓰게 되는데 RGB32 보다 느리다. 심하게.
그리고 이왕하는거 캐시라인에 정렬시키라구욧
포인터 찍어보니까 64비트 프로그램이면 버스가 8바이트씩 가던데 그럼 int쓰면 4바이트가 0으로 채워지나?
예외적으로 cache fail 이 자주 나는 인접 연산에선 용량 작은게 조금 유리한 경우도 있지. 즉 데이타의 배치와 구조를 보고 판단해야 하는데,
64비트라도 int는 32비트임..
아니 그렇진 않아. 버스들은 좀 더 효율적으로 움직인다. 더가져와서 덜 쓰지 내부 노드가 문제.
주소가 64비트일뿐..
버스는 범용 데이타 통로고, 여기서 말하는 노드는 연산단위 통로라고 보면돼
코세 급 친절해졌네 ㅋㅋㅋ
램에서 CPU 까지 Instruction Fetch 되어 읽어들인 명령들은 어차피 가변 바이트라 최적화하기 힘들고,
메모리에서 prefetch 한 데이타들이 문젠데
어 난 목적을 망각하지 않으니깐 ㅡㅡㅋ
메모리에서 CPU의 캐시메모리로 읽어온 데이타들에서 필요한 데이타를 뽑아쓸때, 그리고 그 데이타가 논리회로를 거칠때 stall 이 발생한다는거지.
int 배열이랑 char 배열은 진짜 간단한 알고리즘 테스트 케이스에도 연산 속도가 ms 단위로 차이나던데.. int가 그래서 빨랐구만
데이타가 교복을 안입고 있으면 교문에서 잡혀서 교복입고 들어가야 되기 땜에 느린거야. 그 교복이 시스템 워드 단위고 말야.
MSB 까지를 0으로 채우는 작업이 교복입히는거지.
ㅇㅇ 알아들었음 더 깊이 말해봐야 모름 ㄱㅅ
그리고 니가 스택에 1000 바이트를 할당한다고 해서 느려지는게 아님.
그렇게 해도 스택포인터에 1000 더하는 명령 하나 추가 되고 말아.
코세 츤데레 ㅋㅋㅋㅋㅋㅋㅋ
용량만큼 프로그램이 실행될때 전역 초기화를 수행하게 되는 전역변수 할당과는 다르다.
그리고 메모리 근접 참조가 유리한 경우가 많아. 원거리 주소인 전역보다 스택포인터 레지스터가 가리키고 있을 가능성이 큰 스택을 이용하는게 빠른 경우가 많다.
옛날엔 분기도 근거리가 원거리보다 빨랐음.
그래서 코드량이 커지면 원거리점프가 되는 시점에서 (127바이트 초과시) 더 느려질때도 있었지. 코드량을 줄이는게 효율적이었던 시절임.