v0.0.167

rePIU v0.0.167

이전 릴리스 v0.0.166 이후의 변경입니다. Linux가 왜 느린지 알아냈습니다.

답: 시그널 전달

같은 기계이므로 TSC cycle을 직접 비교했습니다. 프레임당, 100만 cycle 단위입니다.

버킷	Windows	Linux	배율	격차 기여
폴트 핸들러	2.065	88.072	42.6x	68.3%
Glide	1.618	26.480	16.4x	19.7%
미귀속	2.159	17.214	8.0x	12.0%
DOS 서비스	0.006	2.438	433.9x	1.9%

Linux 격차의 68%가 폴트 핸들러이고, Linux에서 그것은 시그널 전달입니다. 3회 재현되며
Windows 대조군은 35.35%입니다.

Glide 게이트는 그 전에 배제했습니다 — 호스트 왕복 횟수와 크로싱 횟수를 되돌려 놓아도
프레임률이 움직이지 않았고, 같은 노브가 Windows에서는 27.1%를 깎습니다.

실행이 실행 중에 자기 상태를 말합니다

REPIU_LIVE_PROFILE_INTERVAL_MS=1000을 주면 지정한 간격마다 한 줄이 나옵니다.

[repiu-live-profile] #5 frames=1706 window_frames=275 cycles_per_frame=133327684 veh=59.82% glide=22.86% dos=2.90% unaccounted=17.30%

REPIU_EXECUTION_TIME_PROFILE=1과 함께 씁니다. 이것이 필요했던 이유는 Linux에서 렌더까지 간
실행이 로더 요약에 닿지 못하기 때문입니다 — 게스트 스레드가 멈추지 않아 종료 갈래가
_Exit으로 끝납니다.

누적 평균으로는 안 보이는 것이 바로 나왔습니다: Linux 프레임당 비용이 실행 중 세 배가
됩니다(83M → 272M cycle). 일정하게 느린 것이 아니라 장면이 진행될수록 나빠집니다.

알려진 것

• 아직 성능을 고치지 않았습니다. 축을 찾는 데까지입니다.
• 시그널 전달이 횟수가 많은 것인지 회당 단가가 큰 것인지 가르지 않았습니다. 다음 작업입니다.
• probe 모음이 Release에서 검증된 적이 없습니다(v0.0.166에서 기록).

---

rePIU v0.0.167

Changes since v0.0.166. We now know why Linux is slow.

The answer: signal delivery

Both hosts are the same machine, so TSC cycles compare directly. Per frame, in millions of cycles:

Bucket	Windows	Linux	Factor	Share of the gap
The fault handler	2.065	88.072	42.6x	68.3%
Glide	1.618	26.480	16.4x	19.7%
Unaccounted	2.159	17.214	8.0x	12.0%
DOS services	0.006	2.438	433.9x	1.9%

68% of Linux's gap is the fault handler, and on Linux that is signal delivery. It reproduces over
three runs, against a Windows control of 35.35%.

The Glide gate was ruled out first: putting the host round trips and the gate crossings back
moved the frame rate not at all, while the same knob costs Windows 27.1%.

A run reports on itself while it is going

REPIU_LIVE_PROFILE_INTERVAL_MS=1000 gives one line at the interval you name.

[repiu-live-profile] #5 frames=1706 window_frames=275 cycles_per_frame=133327684 veh=59.82% glide=22.86% dos=2.90% unaccounted=17.30%

Use it with REPIU_EXECUTION_TIME_PROFILE=1. It was needed because a Linux run that reaches
rendering never reaches the loader summary -- its guest thread does not stop, so the shutdown arm
ends at _Exit.

It immediately showed what a cumulative average cannot: Linux's cost per frame triples during a
run (83M to 272M cycles). It is not uniformly slow; it gets worse as the scene proceeds.

Known

• No performance has been fixed yet. This goes as far as finding the axis.
• Whether signal delivery is a count problem or a price problem has not been separated. That is
  the next task.
• The probe suite has never been validated in Release (recorded in v0.0.166).