Mixed Workload Probe 까지의 빌드업 문서

아래처럼 정리하면 됩니다. 핵심은 mixed_workload_probe를 갑자기 등장한 실험이 아니라, v0 → repeatability → permutation을 통과한 뒤에야 의미가 생기는 첫 번째 main follow-up probe로 배치하는 것입니다.

1. 연구 흐름 개요

현재 Warp Signature 계열 실험은 다음 순서로 진행되었다.

Warp Execution Signature v0
        ↓
Warp Signature Repeatability
        ↓
Warp Signature Permutation
        ↓
Mixed Workload Probe

 

이 흐름은 단순히 실험을 하나씩 추가한 것이 아니다.

각 단계는 이전 단계의 해석 한계를 제거하면서, 점진적으로 더 강한 질문으로 이동한다.

v0:
  서로 다른 execution pattern이 서로 다른 progress signature를 남기는가?

Repeatability:
  그 signature가 단일 run의 우연이 아니라 반복 가능한가?

Permutation:
  그 signature가 warp_id에 고정된 것이 아니라 workload pattern을 따라가는가?

Mixed Workload:
  그 signature가 isolated condition을 넘어 heterogeneous composition에서도 유지되는가?

따라서 mixed_workload_probe는 warp_execution_signature_v0의 단순 후속 실험이 아니다.
정확히는 검증된 workload execution signature를 혼합 workload 환경으로 확장한 첫 번째 main follow-up probe다.

---

2. Warp Execution Signature v0

역할

warp_execution_signature_v0는 최초 observation 단계다.

이 실험에서는 동일한 cycle budget 안에서 서로 다른 execution pattern을 가진 warp들이 서로 다른 progress 값을 남기는지 관찰했다.

관찰 대상은 다음과 같은 workload pattern이었다.

fast_independent_alu
dependent_alu_chain
shared_load
dependent_global_load

핵심 관찰

서로 다른 execution pattern은 서로 다른 progress signature를 남겼다.

특히 다음과 같은 상대적 ordering이 관찰되었다.

fast_independent_alu
> shared_load
> dependent_alu_chain
> dependent_global_load

의미

이 결과는 단순히 “ALU가 빠르고 memory가 느리다”는 식의 결과가 아니다.

핵심은 다음이다.

dependency structure
memory hierarchy
address dependency
latency hiding 가능성

이 요소들이 결합되어 warp-level progress에 구분 가능한 실행 서명을 남긴다는 것이다.

남은 한계

하지만 v0만으로는 아직 강한 evidence라고 보기 어렵다.

남은 불확실성은 다음과 같다.

단일 run noise
warp_id bias
warp position effect
compiler artifact
clock boundary effect
isolated condition 한계

따라서 v0는 다음처럼 정의하는 것이 적절하다.

v0 = execution pattern별 progress signature 후보를 발견한 observation node

---

3. Warp Signature Repeatability

역할

warp_signature_repeatability는 v0에서 관찰된 signature가 단일 run의 우연인지 확인하는 validation 단계다.

질문

v0에서 관찰된 progress signature는 반복 실행에서도 유지되는가?

실험 의미

동일한 launch shape, 동일한 cycle budget, 동일한 workload pattern 조건에서 반복 실행을 수행했다.

그 결과, warp별 progress signature가 반복 실행에서 안정적으로 재현되었다.

해석

이 단계에서 확인한 것은 다음이다.

v0 signature는 현재 조건에서 run-to-run noise가 아니다.

즉, repeatability는 새로운 workload behavior를 발견한 실험이 아니다.

이 실험의 목적은 v0 observation을 다음 단계로 끌어올리는 것이다.

단일 관찰값
  ↓
반복 가능한 관찰값

한계

Repeatability만으로는 아직 다음 질문이 남는다.

반복되는 signature가 workload 때문인가?
아니면 특정 warp_id 때문인가?

이 질문을 해결하기 위해 permutation 검증이 필요하다.

---

4. Warp Signature Permutation

역할

warp_signature_permutation은 반복 가능한 signature의 귀속 대상을 분리하는 attribution 단계다.

질문

progress signature는 warp_id에 고정되는가?
아니면 workload pattern assignment를 따라 이동하는가?

실험 의미

workload pattern을 warp_id에 회전 배치했다.

즉, 같은 pattern을 다른 warp_id에 배치했을 때 progress signature도 함께 이동하는지 확인했다.

핵심 관찰

높은 progress와 낮은 progress의 위치가 특정 warp_id에 고정되지 않았다.

대신 workload pattern assignment를 따라 이동했다.

해석

이 단계에서 확인한 것은 다음이다.

progress signature는 warp_id 자체보다 workload execution pattern에 더 강하게 귀속된다.

따라서 v0에서 관찰된 progress 차이는 단순 warp_id bias로 보기 어렵다.

의미

Permutation 검증을 통과하면서 Warp Signature 계열 실험은 다음 상태가 된다.

v0:
  execution pattern별 signature 후보 발견

repeatability:
  signature가 반복 가능한지 확인

permutation:
  signature가 workload pattern에 귀속되는지 확인

이제 비로소 다음 질문으로 넘어갈 수 있다.

그 signature는 혼합 workload 환경에서도 유지되는가?

이 질문이 mixed_workload_probe의 출발점이다.

---

5. Mixed Workload Probe

역할

mixed_workload_probe는 검증된 workload execution signature를 heterogeneous warp composition으로 확장하는 첫 번째 main follow-up probe다.

이전 실험들이 signature 자체의 신뢰성을 검증했다면, 이 실험은 signature가 더 복잡한 실행 조합 안에서도 유지되는지 확인한다.

핵심 질문

서로 다른 workload가 같은 block 안에서 공존할 때,
role별 warp progress signature는 유지되는가?
아니면 mixed composition에 의해 변형되는가?

추가로 다음 질문도 함께 본다.

memory-dependent workload는 run-to-run variability를 증가시키는가?

실험 목적

Mixed Workload Probe의 목적은 두 가지다.

첫째, isolated workload condition에서 확인된 role별 signature가 mixed composition에서도 유지되는지 확인한다.

둘째, global memory dependency가 단순히 낮은 progress만 만드는 것이 아니라 실행 간 변동성까지 증가시키는지 확인한다.

---

6. Mixed Workload Probe 결과 요약

핵심 결론

혼합 workload 조건에서도 role별 progress ordering은 안정적으로 유지되었다.

관찰된 ordering은 다음과 같다.

light_alu
> dependent_alu
> shared_load
> dependent_global_load

특히 dependent_global_load는 두 가지 특징을 동시에 보였다.

가장 낮은 평균 progress
가장 큰 run-to-run variability

즉, global memory dependency는 낮은 progress signature뿐 아니라 높은 variability signature도 남긴다.

---

주요 지표

all light ALU baseline:
  593

light ALU with dependent ALU:
  582.25

light ALU with shared load:
  583.891

light ALU with global load:
  588.188

mixed all roles ordering:
  590.812 > 539.688 > 325.625 > 103.219

global load variability:
  CV ≈ 0.10

해석

이 결과는 workload signature가 isolated pattern에서만 나타나는 것이 아니라, heterogeneous warp composition에서도 유지된다는 점을 보여준다.

또한 dependent_global_load는 평균 progress가 낮을 뿐 아니라 run 간 변동성이 크다.

따라서 global memory dependency는 다음 두 가지 흔적을 동시에 남긴다고 볼 수 있다.

낮은 progress signature
높은 temporal variability signature

---

7. 단계별 해석 강화 과정

현재까지의 연구 빌드업은 다음처럼 정리할 수 있다.

단계실험확인한 것제거한 의심

1	Warp Execution Signature v0	execution pattern별 progress 차이 관찰	없음. 최초 observation
2	Repeatability	동일 조건에서 signature 반복 재현	단일 run noise
3	Permutation	signature가 workload pattern을 따라 이동	warp_id 고정 bias
4	Mixed Workload	heterogeneous composition에서도 ordering 유지	isolated condition 한계

이 표가 중요하다.

mixed_workload_probe는 독립적으로 해석하면 약하다.
하지만 앞선 세 단계를 통과했기 때문에 의미가 강해진다.

즉, Mixed Workload 결과는 다음 문맥 안에서 해석해야 한다.

이미 반복 가능성이 확인되었고,
이미 warp_id bias 가능성이 낮아졌으며,
그 signature가 mixed composition에서도 유지되었다.

따라서 현재 결론은 다음처럼 세울 수 있다.

현재 조건에서 warp-level progress signature는 단일 run noise나 warp_id bias보다 workload execution pattern에 더 강하게 귀속되며, 이 signature는 혼합 workload composition 안에서도 role별 ordering을 유지한다.

---

8. Mixed Workload Probe의 의미

Mixed Workload Probe는 단순히 “여러 workload를 섞어봤다”는 실험이 아니다.

이 실험의 의미는 다음이다.

isolated signature
  ↓
validated signature
  ↓
attributed signature
  ↓
composition-resilient signature

즉, mixed_workload_probe는 signature가 단독 조건에서만 보이는 현상이 아니라, 같은 block 안에서 서로 다른 workload가 공존할 때도 관찰 가능한 구조적 실행 흔적이라는 점을 보여준다.

---

9. 해석 경계

다만 이 결과를 일반적인 scheduler policy로 확대하면 안 된다.

현재 결과가 말할 수 있는 것:

단일 block
고정 launch shape
synthetic workload
현재 cycle budget
현재 workload composition

안에서 role별 progress signature가 유지되었다는 것.

현재 결과가 아직 말할 수 없는 것:

일반적인 GPU warp scheduler 정책
모든 SM에서의 동일성
block scheduling 영향
occupancy 변화 영향
실제 application workload에서의 동일성
resource contention arbitration 규칙
barrier release 이후 issue priority

따라서 현재 결론은 다음처럼 제한해야 한다.

Mixed workload composition에서도 role별 warp progress signature는 유지되었다.
하지만 이것을 일반적인 scheduler law로 단정해서는 안 된다.

---

10. 다음 연구 방향

Mixed Workload Probe는 다음 두 계열의 후속 실험으로 자연스럽게 이어진다.

contention_amplification_probe
latency_hiding

10.1 Contention Amplification Probe

Mixed Workload에서 dependent_global_load가 낮은 progress와 높은 variability를 보였다.

이제 다음 질문은 이것이다.

자원 경합을 더 강하게 만들면 scheduler arbitration이 더 선명하게 드러나는가?

따라서 다음 실험은 memory contention, shared memory contention, 또는 global load dependency를 더 강하게 만드는 방향으로 갈 수 있다.

예상 관찰 포인트:

stall 발생 시점
stall 해제 이후 재진입 순서
ready warp의 progress 유지 여부
memory-dependent warp의 variability 증가 여부

10.2 Latency Hiding 분석

Mixed Workload에서 중요한 신호는 다음이다.

dependent_global_load가 매우 낮은 progress를 보이는 동안,
light_alu는 상대적으로 높은 progress를 유지했다.

이는 global-load warp가 stall되는 동안 ready warp가 실행 기회를 얻었을 가능성을 시사한다.

따라서 다음 질문은 이것이다.

memory-dependent warp가 stall되는 동안 scheduler는 ready warp를 얼마나 효과적으로 진행시키는가?

이 방향은 latency hiding node와 자연스럽게 연결된다.

---

11. Graph Canvas용 연구 흐름 설명

Graph Canvas에서는 이 흐름을 다음처럼 보여주는 것이 좋다.

Warp Execution Signature v0
  └─ observation
      ↓
Warp Signature Repeatability
  └─ signature-validation
      ↓
Warp Signature Permutation
  └─ signature-attribution
      ↓
Mixed Workload Probe
  └─ composition-probe
      ├─ Contention Amplification Probe
      └─ Latency Hiding

간선 label은 다음처럼 잡으면 좋다.

warpExecutionSignatureV0.connectsTo = [
  {
    id: "warp_signature_repeatability",
    type: "signature-validation",
    label: "observation → repeatability",
  },
];

warpSignatureRepeatability.connectsTo = [
  {
    id: "warp_signature_permutation",
    type: "signature-attribution",
    label: "repeatability → attribution",
  },
];

warpSignaturePermutation.connectsTo = [
  {
    id: "mixed_workload_probe",
    type: "composition-probe",
    label: "attribution → mixed composition",
  },
];

mixedWorkloadProbe.connectsTo = [
  {
    id: "contention_amplification_probe",
    type: "contention-amplification",
    label: "mixed signature → contention",
  },
  {
    id: "latency_hiding",
    type: "suggests",
    label: "global stall → latency hiding",
  },
];

---

12. Mixed Workload Probe의 최종 위치

mixed_workload_probe의 layer는 현재 probe-result로 되어 있다.

나쁘지는 않지만, 앞선 구조와 맞추면 더 명확하게 다음 중 하나를 추천한다.

추천 1안

layer: "composition-result",
order: 4,

의미:

혼합 workload composition에서 signature 유지 여부를 확인한 결과

추천 2안

layer: "main-followup-result",
order: 4,

의미:

v0 검증 이후 처음 수행된 본 후속 probe 결과

추천 최종안

layer: "composition-result",
order: 4,

이게 가장 정확합니다.

왜냐하면 이 실험의 핵심은 scheduler policy 단정이 아니라,

isolated signature가 mixed composition에서도 유지되는가?

이기 때문입니다.

---

13. 최종 요약

현재까지의 빌드업은 다음 한 문장으로 정리할 수 있다.

Warp Execution Signature v0에서 발견된 workload별 progress signature는 반복 실행에서 안정적으로 재현되었고, permutation 검증을 통해 warp_id가 아니라 workload pattern에 귀속됨이 확인되었으며, Mixed Workload Probe에서는 이 signature가 heterogeneous composition 안에서도 role별 ordering을 유지함이 관찰되었다.

따라서 현재 연구 상태는 다음이다.

signature 후보 발견
  ↓
반복성 검증
  ↓
귀속 검증
  ↓
혼합 composition 유지성 확인

그리고 다음 단계는 다음이다.

contention amplification
latency hiding 분석

즉, 이제부터의 연구는 단순히 signature가 존재하는지 확인하는 단계가 아니라,

그 signature가 stall, contention, latency hiding 상황에서 어떻게 변형되는가

를 보는 단계로 넘어가면 됩니다.