삐에로의 지식창고

개요 이론 정리 - < 소유권과 수명 >에서 이 객체를 치울 책임은 누구에게 있는가를 정리했다. 이번 편은 그 한 층 아래다. 소유권을 이야기하려면 결국 포인터와 레퍼런스가 각각 무엇을 할 수 있는 이름인지, 그리고 객체를 넘길 때 실제로 뭐가 오가는지를 먼저 알아야 한다. 앞 편에서 이미 const T&가 복사를 줄이면서 수정을 막는다는 건 흐릿한 데 없이 나왔다. 그래서 이번엔 가볍게 갈 줄 알았는데, 정작 걸린 데는 예상 밖이었다. 방향은 맞는데 표현이 뭉개져 있던 것 — const Player*를 “읽기만 가능한 주소 변수”라고 말했다. 결론은 비슷하게 나오지만 const가 붙은... Read More

왜 검색부터 손봤나 내가 블로그를 작성하는 목적은 미래의 나 또는 AI가 잊어버린 기억을 빠르게 되찾는 데 쓰는 것이다. 기술 설명은 정돈하되, 내 혼잣말이나 삽질, 감정까지 없어지면 곤란하다. 무엇을 알았는지만큼 왜 그런 접근을 했고, 어디에서 생각이 달라졌는지도 남겨두고 싶다. 글을 다듬는 blog-post 스킬에도 이 기준을 먼저 반영했다. 이번에는 그 기록을 다시 꺼내는 쪽을 손봤다. 블로그 안의 검색 엔진과 WebMCP를 비교하고, 실제로 검증하고 구현하는 작업을 AI에게 요청했다. 검색에 넣을 주제로는 스레드, 멀티스레드, 컴퓨터 CS 지식을 골랐다. 구현과 실행 검증은 AI에게 맡겼고, 아래 결... Read More

개요 이론 정리 - < 멀티 스레드 심화 >에서 분량 때문에 잘라둔 절반이다. 앞 편이 여럿이 같은 값을 건드릴 때 무슨 일이 나는지였다면, 이번 편은 그 값이 언제까지 살아 있는지다. 앞 편에서 lock_guard를 쓰면서 이렇게 적고 넘어갔다. 중간에 return을 하든 예외가 터지든 똑같이 풀린다. 잠금의 수명을 lock 객체의 수명에 묶어둔 것이다 ( 이 방식이 다음 편에서 다룰 RAII 이다 ) 그 미뤄둔 이름부터 시작한다. 쓰고는 있었는데 이름을 몰랐던 것이라, 이번 편에서 제일 먼저 나올 자격이 있다. 이번 복습도 세 칸으로 갈렸다. 동적 메모리를 해제 안 하면 샌다는 건 그... Read More

개요 넥토리얼 대비로 CS 기본기를 다시 훑는 중이다. 멀티스레드는 이론 정리 - < OS >와 이론 정리 - < 멀티 스레드 >에서 이미 두 번 정리해뒀던 주제라, 이번엔 가볍게 복습만 하고 넘어갈 생각이었다. 그래서 방식을 조금 바꿔봤다. 눈으로 읽는 대신 말로 설명해봤다. 읽으면 다 아는 내용인데, 입 밖으로 꺼내니 속도가 확 달라진다.. 크게 세 종류로 갈렸다. 그대로 나오는 것 — Mutex가 하는 일, 임계 영역, 컨텍스트 스위칭 비용. 여기는 예전 정리가 잘 버텨줬다 잠시 잊고 있던 것 — 알고는 있었는데 바로 안 나오는 것들. Lock을 굵게 잡을지 잘게 잡을지 같... Read More

개요 15편에서 좀비 수에 뚜껑을 씌워 최악의 경우를 예산 안에 넣었다. 그런데 그건 원래 하려던 게 아니었다. 원래 목표는 오브젝트를 매번 새로 만들고 부수는 대신 만들어둔 걸 돌려쓰는 것이었다. 14편에서 잰 값에는 그게 겨냥하는 비용이 안 나왔는데, 나는 그게 조건을 잘못 잡아서라고 생각했다. 그래서 조건을 다시 설계해서 한 번 더 갔다. 그리고 이 편에서 네 번째 가설까지 틀린다. 마지막엔 재고 있던 값이 게임과 아무 상관 없는 값이었다는 걸 알게 된다. 이번 글이 답할 질문. 값이 안 변한다는 것은 무엇을 뜻하는가? 1. 조건을 또 바꾼 이유 돌려쓰기가 줄이려는 비용이 뭔지부터 다시 ... Read More

개요 14편에서 얻은 결론은 비용을 결정하는 건 좀비 마리 수가 아니라 얼마나 몰려 있느냐였다. 682마리에서 753마리 사이에 프레임 시간이 다섯 배로 뛰었다. 그러면 답은 둘 중 하나다. 몰리지 않게 하거나, 애초에 그만큼 안 만들거나. 앞의 것부터 검토했고, 보고 나서 접었다. 뒤의 것을 골라 상한을 넣었다. 그리고 마지막에 실제로 플레이해봤더니 그 상한이 걸릴 일이 없었다. 이번 글이 답할 질문. 최악의 경우를 막는 장치는 그 경우가 오지 않으면 무의미한가? 1. 먼저 나온 제안을 기각했다 멘토 역할로 쓰는 AI가 먼저 낸 안은 거리 기반 회수였다. 화면 밖으로 멀어진 좀비를 걷... Read More

개요 13편에서 좀비가 몇 마리 살아 있는지를 세는 값을 만들었다. 화면에 숫자 하나 띄우려던 거였는데, 그게 이 편에서는 자(尺)로 쓰인다. 원래 계획에 최적화 항목이 하나 있었다. 오브젝트를 매번 새로 만들고 부수는 대신 만들어둔 걸 돌려쓰는 것, 그리고 매 프레임 생기는 쓰레기 메모리를 없애는 것이다. 계획서에서 이 항목만 특별했다. 다른 항목은 “됐다/안 됐다”로 끝나는데 이건 전후를 숫자로 남길 수 있는 유일한 항목이라, 마감에 쫓겨도 이건 지키자고 못을 박아뒀었다. 그래서 오늘은 그 숫자를 재러 갔다. 그리고 세 번 세운 가설이 전부 틀렸다. 이번 글이 답할 질문. 계획한 최적화가 측정에 의... Read More

개요 12편에서 하루치 이야기를 여섯 편으로 나눠 마무리했다. 그날의 결론은 이름이 설계 결함을 알려줬다는 거였다. 이번 편은 그 다음 날 이야기다. 시작은 별거 아니었다. 화면에 남은 시간이랑 좀비가 몇 마리인지 띄우는 것. 딱 그거였는데, 끝에 가서는 그 숫자를 누가 가지고 있어야 하는가를 정하고 있었다. 그리고 이번에 방향이 틀렸다고 알려준 건 이름이 아니었다. 아무도 안 쓰는 인자 하나였다. 이번 글이 답할 질문. 화면에 숫자를 띄우는 일이 왜 소유권 문제가 되는가? 1. 남은 시간 — 소수점을 초로 바꾸는 일 타이머가 들고 있는 남은 시간은 297.4183... 같은 소수다. 화면... Read More