2026년 10월 31일 (토)
- 14:192026년 10월 31일 (토) 14:19 소목 포석 (역사 | 편집) [3,753 바이트] Ahn9807 (토론 | 기여) (새 문서: 분류: 포석 분류:소목 정석 == 개요 == '''소목(小目)'''은 귀의 실리를 중시하면서 변으로 발전할 수 있는 착점이다. 화점과 달리 비대칭적인 위치에 있으므로, 돌을 놓는 방향에 따라 이후의 발전 방향이 달라진다. 또한 귀를 적절히 굳히면 상대의 삼삼 침입에 대응하기 쉽다. 소목을 활용한 포석에서는 귀를 굳히는 대신 변으로 넓게 벌려 상대의 발전...)
- 13:562026년 10월 31일 (토) 13:56 화점 정석 2 (역사 | 편집) [3,923 바이트] Ahn9807 (토론 | 기여) (새 문서: 분류:화점 정석 == 개요 == '''화점 정석 2'''는 굳힘이 아니라 '''협공'''을 선택한 경우이다. 협공은 걸쳐 온 상대 돌을 바로 굳혀 주지 않고 압박하면서, 바깥 세력과 주도권을 얻기 위해 선택하는 수법이다. 보통 협공하는 쪽의 바깥에 이미 아군의 배석이 있을 때 효과가 크며, 이런 경우 협공을 통해 판을 넓게 운영할 수 있다. 협공은 즉시 집을 많이 얻는 진행...) 태그: 시각 편집: 전환됨
- 13:392026년 10월 31일 (토) 13:39 화점 정석 1 (역사 | 편집) [2,978 바이트] Ahn9807 (토론 | 기여) (새 문서: == 개요 == '''화점 정석 1'''은 화점에 날일자 걸침이 왔을 때, 날일자 굳힘으로 응하는 정석 계열이다. 날일자 굳힘은 귀를 안정시키고 바깥 모양을 정돈한 뒤, 선수로 손을 빼어 판을 넓게 쓰기 위해 주로 사용된다. <goban mode="player" from="0" autoplay="1000" loop="false" showMoveNumber="true" showControls="false" view="A10:T19" move="16" to="16"> (;GM[1]FF[4]CA[UTF-8]SZ[19] ;B[pd] ;W[qf] ;B[nc] ;W[pi] ;B[dd] ;...) 태그: 시각 편집
2026년 10월 30일 (금)
- 14:522026년 10월 30일 (금) 14:52 정석 (역사 | 편집) [8,053 바이트] Ahn9807 (토론 | 기여) (새 문서: index.php?title=분류:바둑 == 개요 == '''정석(定石)'''은 바둑의 초반에 주로 귀에서 벌어지는 접전에서 흑과 백이 서로 합리적인 수를 교환하여 만들어지는 대표적인 진행을 말한다. 바둑의 초반은 포석과 정석이 서로 밀접하게 연결되어 있다. 포석이 바둑판 전체의 돌 배치와 방향을 결정한다면, 정석은 주로 귀를 중심으로 벌어지는 국지적인 접전의 진행을 다...) 태그: 시각 편집
2026년 10월 28일 (수)
2026년 10월 19일 (월)
- 10:052026년 10월 19일 (월) 10:05 MTSan: A Feasible and Practical Memory Sanitizer for Fuzzing COTS Binaries (역사 | 편집) [9,300 바이트] Noribot (토론 | 기여) (Nori: update draft.wikitext)
2026년 10월 17일 (토)
- 08:082026년 10월 17일 (토) 08:08 CMASan: Custom Memory Allocator-aware Address Sanitizer (역사 | 편집) [8,004 바이트] Noribot (토론 | 기여) (Nori: update draft.wikitext)
2026년 10월 15일 (목)
- 04:312026년 10월 15일 (목) 04:31 Memory Sanitizer (역사 | 편집) [27 바이트] Ahn9807 (토론 | 기여) (Sanitizer 문서로 넘겨주기) 태그: 새 넘겨주기
2026년 10월 13일 (화)
- 08:172026년 10월 13일 (화) 08:17 RAPIDS Memory Allocator (역사 | 편집) [4,408 바이트] Ahn9807 (토론 | 기여) (새 문서: 분류: GPU 아키텍쳐 == 개요 == RAPIDS Memory Manager(RMM)는 High-frequency memory allocation/deallocation에서 발생하는 병목현상을 줄이고, 다양한 메모리 할당 전략을 제공하는 Memory management library이다. Pooling을 사용하는 경우, 큰 메모리 영역을 확보한 뒤 개별 Allocation 요청에 따라 Suballocation하고 재사용함으로써 <code>cudaMalloc</code>이나 <code>cudaFree</code>의 호출 빈도와 관련 Overhead...)
2026년 10월 3일 (토)
- 06:352026년 10월 3일 (토) 06:35 Scalable Address Spaces using Concurrent Interval Skiplist (역사 | 편집) [10,322 바이트] Noribot (토론 | 기여) (Nori: update draft.wikitext)
2026년 9월 25일 (금)
- 06:212026년 9월 25일 (금) 06:21 Securing GPU via Region-based Bounds Checking (역사 | 편집) [6,662 바이트] Noribot (토론 | 기여) (Nori: update draft.wikitext)
- 05:162026년 9월 25일 (금) 05:16 GPU Memory Architecture (역사 | 편집) [9,714 바이트] Ahn9807 (토론 | 기여) (새 문서: 분류: GPU == 개요 == GPU는 높은 memory bandwidth와 대규모 parallelism을 제공하기 위해 CPU와는 다른 형태의 memory hierarchy를 가진다. NVIDIA GPU의 memory는 크게 SM 내부의 on-chip memory와 GPU DRAM에 위치하는 off-chip memory로 나눌 수 있다. 일반적으로 Register와 Shared Memory는 SM 내부에 존재하며 매우 낮은 latency를 제공한다. 반면 Global Memory와 Local Memory는 GPU의 device memory(HBM 또는 GDDR 등...)
2026년 9월 3일 (목)
- 04:122026년 9월 3일 (목) 04:12 MDK: Rethinking the data center memory reclamation problem (역사 | 편집) [8,540 바이트] Noribot (토론 | 기여) (Nori: update draft.wikitext)
2026년 9월 2일 (수)
- 10:302026년 9월 2일 (수) 10:30 Memory Protection Keys (역사 | 편집) [45 바이트] Ahn9807 (토론 | 기여) (새 문서: #념겨주기 Intel Memory Protection Key)
- 09:202026년 9월 2일 (수) 09:20 Ichnaea: A Framework for Precise Tracking of Memory Objects (역사 | 편집) [5,372 바이트] Noribot (토론 | 기여) (Nori: update draft.wikitext)
- 05:562026년 9월 2일 (수) 05:56 Virtualizing eBPF with Late-Binding (역사 | 편집) [12,232 바이트] Noribot (토론 | 기여) (Nori: update draft.wikitext)
- 02:252026년 9월 2일 (수) 02:25 Jwmalloc: A Verified Memory Allocator for Mobile Devices (역사 | 편집) [12,419 바이트] Noribot (토론 | 기여) (Nori: update draft.wikitext)
2026년 9월 1일 (화)
- 09:272026년 9월 1일 (화) 09:27 PeeR: First-Class Scheduling for Latency-Critical eBPF Applications (역사 | 편집) [11,081 바이트] Noribot (토론 | 기여) (Nori: update draft.wikitext)