Measured DeepCFRMLP forward at bs={1,4,16,64,256,1024} on RTX 3090.
Per-state cost drops 232× from bs=1 (80 µs) to bs=256 (0.34 µs) while
per-call latency stays near 90 µs through bs=256. Policy-call supply
from a real run is ~368 states per traversal and ~200k per iteration,
well above the bs=64–256 plateau, so batched inference is not
supply-limited. GPU forward is not the limiter once batching exists.
Verdict: Optimization Priorities #5 (batched traversal inference) is
worth pursuing. End-to-end gain will still be bounded by encoding and
worker-GPU coordination overhead.
- scripts/profile_gpu_forward.py: standalone profiling script
- docs/performance.md: new "GPU forward profiling for batched traversal"
experiment section with table, supply estimate, and verdict
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Make the link from the failed torch.compile experiment to Optimization
Priorities #5 explicit, so a future revisit happens at the right time
(once compile is on the dominant phase, not just trainer optimization
steps).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Wrapping trainer networks with torch.compile produced a 4.8% regression
in iteration time on default.yaml (17.93s → 18.79s). Two causes: (1)
the dominant phase is CPU traversal which bypasses the compiled
wrapper, (2) DeepCFRMLP is too small for compile dispatch overhead to
pay back. Implementation kept on experiments/torch-compile for future
revisits when the trainer model or inference path changes.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
같은 hyperparameter (512x3, 2x updates, argmax_tiebreak)에 opponent_policy
만 self_play_league로 다른 run과의 iteration별 비교 표 추가. iter 350
시점에서 Random WR 38%p 격차 (network 34% vs league 72%) 확인 — 발산
가설을 실증.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
opponent_policy=network 설정으로 1000-iter 실험 두 개 (512x3, 1024x4)를
돌린 결과 두 실험 모두 policy collapse가 발생함을 확인. 큰 capacity는
plateau를 늘리지만 발산 자체를 막지 못함. 향후 학습은 self_play_league
기본값을 유지할 것을 권고.
- 실험에 사용한 config 두 개 추가
- 발견 분석 문서 추가 (원인, 비교, 권고)
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
맥락: 클래식 포트를 Python/Cython 구현과 pygame GUI 중심으로 정리한다.
변경: Rust 크레이트, proto 계약, Rust backend shim, 패리티 테스트를 삭제하고 문서와 backend factory를 Python 전용으로 갱신했다.
확인: uv run pre-commit run --all-files; uv run pytest tests/games/classic; uv run lost-cities-classic-gui --help
맥락:
- GUI 이식 전에 Rust crate와 proto schema 위치를 Python package 내부에서 분리한다.
- Cargo 작업, IDE 인식, 빌드 산출물 관리를 루트 구조에 맞춘다.
변경:
- rust_core를 rust/lost-cities-core로 이동하고 proto/lost_cities.proto를 루트 proto 디렉터리로 옮겼다.
- Rust build.rs, Python Rust backend, Rust parity 테스트의 경로를 새 위치로 수정했다.
- Python package-data에서 Rust crate와 proto 항목을 제거하고 README/port notes를 갱신했다.
확인:
- uv sync --extra gui --reinstall-package coolrl-lost-cities
- uv run pytest tests/games/classic
- uv run lost-cities-classic
맥락:
- 새 레포의 첫 범위를 RL 없는 Lost Cities classic 게임 구현으로 잡았다.
- 기존 tier0-3 실험 축은 제거하고 classic 5-expedition 룰을 기본값으로 둔다.
변경:
- games/classic 아래에 Cython 게임 엔진, env, bots, backend 경계, Rust core와 proto schema를 이식했다.
- setuptools/Cython 빌드 설정과 package data, README, classic port notes를 추가했다.
- 룰, 점수, 마스크, env, canonical state, bot, Rust parity 테스트를 새 경로로 가져왔다.
확인:
- uv run pytest tests/games/classic
- uv run lost-cities-classic
coolguyandClaude Opus 4.7