태그: #performance

← 전체 글

• 벤치마크가 거짓말하는 세 가지 방식 — Rust CLI를 실제로 재보고 진 이야기

  Rust로 만든 검색 도구를 실제 코퍼스 11,483개 파일에 돌려 ripgrep, grep과 비교했습니다. 결과는 ripgrep이 약 10배 빨랐고 제 도구는 BSD grep과 비슷했습니다. 그런데 이 숫자에 도달하기까지 하니스 버그 세 개가 각각 그럴듯하지만 틀린 결과를 냈습니다. 셸 함수가 실제 도구를 가로챈 일, 프로세스 기준 타이머를 프로세스 간에 뺀 일, time의 출력을 스스로

  2026-08-19 · 16 분 읽기 #rust#cli#benchmark#performance#ripgrep

• Cerebras Ultrafast와 에이전트 루프의 병목 — 초당 750토큰이 줄이지 못하는 시간

  Cerebras와 OpenAI가 초당 최대 750토큰을 내는 추론 티어를 공개했습니다. 발표문이 밝히는 원리는 연산량이 아니라 데이터 이동이고, 가중치를 웨이퍼 위 SRAM에 올려 두는 방식입니다. 왜 배치 1의 디코딩이 메모리 대역폭에 묶이는지, 발표된 배속 수치가 무엇을 재고 무엇을 재지 않는지, 그리고 토큰 생성이 빨라져도 줄지 않는 시간이 여러분의 에이전트 루프에서 몇 퍼센트인지 계산

  2026-08-14 · 14 분 읽기 #llm#inference#hardware#latency#performance

• 지금 주목받는 오픈소스 (2) 빌드·에디터·CLI·터미널

  패키지 설치, 린트, 번들링처럼 하루에 수십 번 반복되는 작업이 네이티브 언어로 다시 쓰이면서 대기 시간이 초 단위에서 밀리초 단위로 내려갔습니다. 빌드 도구, 에디터, 터미널, CLI 영역에서 실제로 자리를 잡은 오픈소스 12개를 스타 순위가 아니라 역할별로 묶어 소개합니다. 무엇을 대체하는지, 성숙도가 어느 정도인지, 언제 쓰면 안 되는지를 함께 적었고, 저장소 경로와 라이선스, 스타 수

  2026-08-12 · 9 분 읽기 #open-source#developer-tools#cli#rust#performance

• 명령어 하나가 62초 걸릴 수 있다 — 지연은 명령어가 아니라 경로의 속성이다

  Assembly Hall of Shame는 단일 명령어를 가장 느리게 만드는 경쟁의 순위표입니다. 최하위 nop이 1사이클, 1위 fxrstor64가 1,980억 사이클로 62초입니다. 이 순위표를 아래에서 위로 읽으면 현대 CPU가 멈출 수 있는 모든 지점의 목록이 되는데, 마이크로코드 보조 경로, 캐시 라인을 걸친 원자 연산, TLB 무효화, 엔트로피 고갈, 그리고 다이 밖 PCIe 패브

  2026-08-09 · 19 분 읽기 #os-concepts#performance#cpu#microarchitecture#benchmark

• 300배는 PostgreSQL을 튜닝해서 나온 숫자가 아니다 — 화산 모델과 벡터화 실행

  pgrust 0.2 릴리스와 함께 공개된 300배라는 숫자를 정확히 해부합니다. 이 수치는 PostgreSQL 설정을 바꿔서 나온 것이 아니라 Rust로 새로 구현한 데이터베이스를 ClickBench에서 측정한 결과이며, 저자 본인이 별도로 제시한 SUM 쿼리 실험은 화산 모델 1.3초에서 SIMD 135밀리초까지 9.6배를 보여 줍니다. 배치, 연산자 융합, SIMD가 각각 무엇을 제거하는

  2026-08-09 · 15 분 읽기 #postgresql#database#performance#query-engine#simd

• GPU 커널을 직접 손본다는 것 — 전치 커널 하나를 5배 빠르게 만들기까지

  GPU 커널을 직접 수정한다는 것이 실제로 무엇을 뜻하는지, 스레드와 워프와 메모리 계층부터 짚습니다. 점유율이 왜 목표가 아니라 증상인지, 그리고 대부분의 커널이 연산이 아니라 메모리 대역폭에 묶여 있다는 사실을 루프라인 관점에서 설명합니다. 행렬 전치 커널 하나를 naive에서 코얼레싱, 셰어드 메모리 타일링, 뱅크 충돌 제거까지 네 단계로 고치면서 각 단계의 유효 대역폭을 직접 재는 하

  2026-08-02 · 32 분 읽기 #cuda#gpu-kernel#nsight-compute#memory-bandwidth#performance

• 평균은 아무것도 말하지 않는다 — 지연 시간을 분포로 디버깅하는 법

  2026년 7월 27일 공개돼 해커뉴스 상단에 오른 Farid Zakaria의 글 "The mean means nothing"은 캐싱 계층을 배포한 뒤 평균 지연이 112ms에서 122ms로 9% 나빠진 상황을 다룹니다. 같은 데이터에서 p50은 99ms에서 54ms로 46% 개선됐고, p99는 309ms에서 678ms로 119% 악화됐습니다. 하나의 데이터가 정반대 결론 두 개를 동시에 지

  2026-07-31 · 25 분 읽기 #observability#latency#performance#histogram#percentile

• 자바 Value Objects(JEP 401)가 바꾸는 것 — 아이덴티티를 버리면 얻는 것과 잃는 것

  2026년 7월 31일 00시 45분 UTC, JEP 401 Value Objects 구현이 OpenJDK 메인라인에 병합됐습니다. JEP 539(Strict Field Initialization)와 한 커밋으로 묶여 1,888개 파일에 20만 8천 줄이 추가됐고, Project Valhalla가 2014년에 시작된 지 12년 만입니다. 이 글은 아이덴티티 없는 객체가 정확히 무엇인지, 성능

  2026-07-31 · 28 분 읽기 #java#jvm#valhalla#jep-401#performance

• 로드 애버리지가 CPU 사용률이 아닌 이유 — load average 24에 CPU는 30%일 때

  uptime의 load average는 24를 넘겼는데 top의 CPU는 30%도 되지 않는 상황을 다룹니다. 리눅스의 로드 애버리지는 다른 유닉스와 달리 실행 대기(R) 태스크뿐 아니라 D 상태(uninterruptible sleep) 태스크까지 세기 때문에, 디스크나 NFS 대기만으로도 숫자가 치솟습니다. 세 숫자가 5초 샘플링과 지수이동평균으로 어떻게 만들어지는지, 코어 수로 나누는 관

  2026-07-26 · 21 분 읽기 #linux#performance#load-average#psi#troubleshooting

• 분산 트레이싱이 실제로 답하는 질문 — 스팬, 샘플링, 그리고 어디서 시간이 갔는가

  "느리다"는 신고는 들어오는데 열 개 서비스 중 어디가 범인인지 모를 때 필요한 것이 트레이싱입니다. 트레이스와 스팬, 컨텍스트 전파의 구조부터 시작해 로그와 메트릭으로는 원리적으로 답할 수 없는 질문이 무엇인지 정리합니다. 자동 계측이 커버하는 범위와 수동 스팬을 반드시 넣어야 하는 지점, 헤드 샘플링이 왜 필요한 트레이스를 우선적으로 버리는지, 테일 샘플링이 그것을 어떻게 풀고 대신 무엇

  2026-07-26 · 25 분 읽기 #observability#distributed-tracing#opentelemetry#tail-sampling#performance

• Core Web Vitals 실제로 고치기 — LCP, INP, CLS를 숫자로 내리는 순서

  라이트하우스 98점을 받고도 Search Console이 계속 빨간불인 이유는 두 도구가 서로 다른 것을 재기 때문입니다. LCP와 INP, CLS가 각각 무엇을 측정하는지, 임계값이 왜 75백분위 기준인지부터 정리합니다. LCP를 TTFB와 리소스 발견 지연, 로드 시간, 렌더 지연 네 조각으로 쪼개 어디를 고칠지 정하는 방법, INP가 FID를 대체한 이유와 긴 태스크를 실제로 양보하는

  2026-07-26 · 25 분 읽기 #performance#core-web-vitals#lcp#inp#cls

• git이 느려질 때 — 대형 저장소를 빠르게 만드는 구조적 처방

  저장소가 느려지는 이유는 하나가 아닙니다. 커밋 이력이 긴 것, 파일 수가 많은 것, 큰 바이너리가 들어 있는 것은 서로 다른 문제이고 처방도 다릅니다. 이 글은 먼저 원인을 구분하는 측정 명령부터 시작해, 얕은 클론과 부분 클론이 왜 대체재가 아니라 용도가 다른 도구인지, sparse-checkout과 파일 감시가 status를 어떻게 줄이는지, commit-graph가 로그와 병합 기준점

  2026-07-26 · 20 분 읽기 #git#performance#monorepo#git-lfs#version-control

• EXPLAIN ANALYZE 읽는 법 — 실행 계획에서 진짜 병목을 찾는 순서

  EXPLAIN ANALYZE 출력을 처음부터 끝까지 읽는 방법을 정리합니다. 노드를 어떤 순서로 읽어야 하는지, cost가 왜 시간 단위가 아닌지, 예상 행 수와 실제 행 수의 괴리가 무엇을 알려 주는지, loops가 곱해지는 함정은 어떻게 피하는지 실제 출력과 함께 설명합니다. Nested Loop, Hash Join, Merge Join이 각각 선택되는 조건과 BUFFERS로 캐시 적중을

  2026-07-26 · 21 분 읽기 #database#postgresql#explain#query-optimization#performance

• 커넥션 풀 크기, 크게 잡으면 손해인 이유 — 대기열을 어디에 세울 것인가

  커넥션 풀을 키웠더니 오히려 느려지는 현상의 원리를 정리합니다. PostgreSQL의 프로세스 모델에서 커넥션이 왜 비싼지, 디스크와 CPU 병렬성이 유한하므로 대기열을 데이터베이스 안이 아니라 풀에 세우는 편이 나은 이유, 자주 인용되는 코어 수 기반 공식의 근거와 한계를 다룹니다. 마이크로서비스에서 인스턴스 수와 풀 크기의 곱이 최대 커넥션을 넘기는 전형적 사고, PgBouncer 세 가

  2026-07-26 · 26 분 읽기 #database#postgresql#connection-pool#pgbouncer#performance

• HTTP Keep-Alive와 커넥션 재사용 — 간헐적 502를 만드는 타임아웃 경쟁 조건

  백엔드 로그에는 아무 오류가 없는데 로드밸런서에서만 간헐적으로 502가 섞여 나온다면 대부분 커넥션 재사용 경쟁 조건입니다. 서버가 유휴 커넥션을 닫는 바로 그 순간 클라이언트가 그 커넥션에 요청을 쓰면 FIN과 요청이 엇갈립니다. 왜 백엔드 keepalive 타임아웃을 로드밸런서 유휴 타임아웃보다 길게 잡아야 하는지, curl -w로 namelookup과 connect와 appconnect

  2026-07-26 · 26 분 읽기 #network#http#performance#load-balancer#tcp

• HTTP 캐싱 제대로 쓰기 — Cache-Control, ETag, stale-while-revalidate의 정확한 의미

  no-cache는 캐시하지 말라는 뜻이 아니라 캐시하되 쓰기 전에 검증하라는 뜻입니다. 이 한 글자 차이를 시작으로 Cache-Control 지시어의 정확한 의미, 조건부 요청과 304가 실제로 절약하는 것과 절약하지 못하는 것, 해시 파일명과 immutable이 프런트엔드 배포의 표준이 된 이유를 정리했습니다. 브라우저와 CDN과 리버스 프록시라는 세 계층이 서로 다른 방식으로만 무효화된다

  2026-07-26 · 20 분 읽기 #web#http-caching#cache-control#cdn#performance

• 중요한 순간에만 무너지는 이유 — 초킹의 심리학과 압박 훈련법

  연습에서는 완벽한데 실전에서 무너지는 현상, 초킹(choking)은 재능이나 노력의 문제가 아니라 주의 시스템의 오작동입니다. 1993년 윔블던 결승의 야나 노보트나 사례로 초킹의 실체를 보고, 실행 감시 이론과 주의 분산 이론이라는 두 가지 메커니즘, 그리고 스포츠 심리학이 검증해 온 해독제(압박 접종 훈련, 외적 초점, 프로세스 골)를 개발자의 라이브 데모, 코딩 인터뷰, 장애 대응 상황

  2026-07-20 · 13 분 읽기 #mindset#sports-psychology#pressure#performance#confidence

• Content-Encoding: zstd, Safari 26.3으로 3대 엔진이 채워졌다 — 그리고 다음 단계인 RFC 9842 사전 압축

  2026년 2월 Safari 26.3이 Content-Encoding: zstd를 지원하면서, Chrome 123(2024-03)·Firefox 126(2024-05)에 이어 3대 브라우저 엔진이 모두 zstd 응답을 받게 됐습니다. 협상 기반이라 도입 리스크는 낮지만, 서버 쪽은 아직 비대칭입니다 — nginx와 Apache httpd에는 공식 zstd 모듈이 없고, 현실적인 경로는 CDN

  2026-07-17 · 20 분 읽기 #performance#web#network#browser

• ClickHouse lazy materialization — LIMIT 10짜리 트릭이 FINAL과 JOIN까지 자란 과정

  ClickHouse의 lazy materialization은 정렬과 LIMIT이 끝나기 전에는 SELECT 컬럼을 읽지 않는 최적화로, 25.4(2025년 4월)에 LIMIT 10 이하에서만 켜지는 보수적인 기능으로 출발했습니다. 이후 행 단위 lookup을 조인 스타일 일괄 조회로 갈아엎은 25.12에서 게이트가 10,000까지 올라갔고, 2026년에는 26.2의 UNION ALL 전 브랜

  2026-07-17 · 24 분 읽기 #database#clickhouse#olap#query-optimization#performance

• Triton Gluon — 컴파일러가 숨기던 레이아웃을 손으로 쓰는 언어

  Gluon은 Triton과 같은 컴파일러 스택 위에 올라간 하위 레벨 GPU 언어로, Triton이 감춰 두던 레이아웃·공유 메모리·워프 특수화를 커널 작성자에게 그대로 넘깁니다. 존재 이유는 명확합니다 — Triton 컴파일러가 잘 못 뽑는 코드를 만났을 때, 지금까지는 손쓸 방법이 없었기 때문입니다. 이 글은 Gluon이 무엇을 노출하는지, BlockedLayout이 실제로 무엇을 뜻하는

  2026-07-16 · 33 분 읽기 #gpu#triton#kernel#compiler#performance