hyelie

[Study] 가상 면접 사례로 배우는 대규모 시스템 설계 기초 1 - 11장 뉴스피드 시스템

hyelie — Mon, 28 Jul 2025 22:32:42 +0900

스터디를 진행하기로 했다. 책은 유명한 가상 면접 사례로 배우는 대규모 시스템 설계 기초 1이다. 책에는 단순하게 아키텍처 정도만 설명되어 있고 부하를 실제로 어느 정도로 받을 수 있는지 실제 코드와 아키텍처를 간단하게 구성하면서 배워보기로 했다. (다른 스터디 멤버들은 어떻게 생각할지 모르겠지만)

https://github.com/hyelie/Virtual-Interview-01

GitHub - hyelie/Virtual-Interview-01

Contribute to hyelie/Virtual-Interview-01 development by creating an account on GitHub.

github.com

1회차

코드만 짰고, 실제로 인프라(NCP)에 올리는 건 다음 회차에 진행할 것이다.

먼저 책에서 한 것과 실 구현은 조금 다르다. 해당 내용은 GitHub에 올려둠.

포스팅 생성 시
1. fan-out 및 news feed cache, post cache, user cache에 모두 값을 넣음
2. 인데... 나는 news feed cache에는 넣고 post cache, user cache에는 값을 넣지 않았다.
3. 만약 해당 글이 자주 읽히지 않는 글이라면, cache에 넣지 않는 것이 맞다.
4. 해당 글이 자주 읽힐 글이라면, 읽을 때 caching하고 다음 번에는 cache에서 가져온다.
5. news feed cache에 넣은 이유는, 해당 cache는 간단할 뿐더러 특정 사용자가 어떤 news feed를 읽어야 하는지 알아오는 단계가 제일 병목이라 생각했기 때문. post, user는 PK id로 쉽게 찾아올 수 있다고 생각했다.
포스트 조회 시
1. news feed cache 조회, 없으면 DB에서 조회 및 caching
2. news feed에 들어갈 post, user 각각을 cache에서 조회, 없는 것은 DB에서 조회 및 caching

이정도이다.

다음 번에 할 일

infra (NCP)에 server, worker 등을 올리기
RabbitMQ는 지금 1대만 쓰는데 여러 대 사용해서 locking 등 이슈 없는지 보기
Redis를 cache 용도로 쓰고 있는데, lock 문제 없는지 보기
monitoring system 구축하기 (각 WAS, RabbitMQ message consume하는 Worker, Redis, RabbitMQ) - CPU 사용량, memory 사용량, storage 사용량 등등 그래프로 볼 수 있게
이후 jmeter같은 요청을 1초에 몇천 ~ 몇만 건 정도 보내서 부하 테스트하기

[Git] 환경 분리

hyelie — Sat, 26 Jul 2025 23:36:56 +0900

Git 계정 2개 이상 사용하고, 특정 폴더에서만 다른 Git 계정 쓰는 방법

1. 폴더(Local) 단위 계정 설정

원하는 폴더(또는 해당 git 저장소)로 이동해서 아래 명령어를 입력하세요.

git config --local user.name "원하는이름"
git config --local user.email "원하는메일@example.com"

# 설정 확인
git config user.name
git config user.email

2. SSH Key 분리

push도 별도 github 계정으로 하고 싶다면, 해당 계정용 SSH Key를 새로 만들고, 원격 repo 주소도 SSH로 맞춰줘야 함.

1. SSH 키 생성 및 해당 public key르f GitHub 계정에 등록

ssh-keygen -t ed25519 -C "your_email@example.com"

2. ~/.ssh/config 파일 설정

아래처럼 Host명을 구분해서 설정

# 계정 1
Host github-main
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_main
  IdentitiesOnly yes

# 계정 2
Host github-sub
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_sub
  IdentitiesOnly yes

이후 sub계정 사용 git folder에서 아래 명령어 쓰면 ssh-config에서 `github-sub`를 찾아 ssh 정보를 가져오고, 해당 repo에 접근 및 인증을 진행한다.

git remote set-url origin git@github-sub:원하는이름/repo.git

Java 면접대비 질문

hyelie — Mon, 15 Apr 2024 23:23:12 +0900

Data type

종류

string ?

primitive : stack에 저장. byte, char, short, int, long, float, double, boolean

reference : 주소값 가리킴.

string : reference이지만 primitive처럼 동작. immutable이기 때문

new로 생성: heap에 새 객체, literal : string constant pool에서 intern() method 호출

Pass by value

primitive, reference, wrapper, string은 각각 어떻게 넘어가는지

primitive는 값 자체를 복사해 넘김

reference는 참조하는 주소를 복사해서 넘김

string을 넘긴 후 assign하면 주소가 바뀐 것이기 때문에 원래 값은 불변. immutable이기 때문.

Identity & Equality & hashCode()

각각의 정의

identity : 참조 비교. 동일한 객체를 가리키는지

equality : logical equality. 내용이 같은지

override하지 않는 경우 equals() method가 작동, ==와 같게 동작. (identity 비교)

address를 hash해 추출한 값. 사용 이유 : hash 값을 사용하느s collection에서 사용하기 때문.

1) hashCode() 비교 -> 이후 equals() 비교

객체 & class

객체, class, instance?

method signature?

overloading

access modifier

객체란 개념을 추상화하고 모델링한 요소. state와 behavior를 가짐.

class는 instance를 만들기 위한 설계도, instance는 class라는 설계도로 만들어진 메모리에 할당된 실체.

method signature : 이름과 parameter로 identify

overloading : 같은 이름의 method 여러 개 정의

access modifier : default, private, protected, public

Static & Final

각각의 정의,

final 종류 및 정의

static : 모든 instance에서 같은 값, class가 memory에 올라갈 때 heap으로 올라감.

final variable : 상수

static final : class의 유일 상수.

final method : override 불가

final class : extend 불가

Inheritance

overriding

다중상속

parent method를 재정의, dynamic binding. private override 시, 그냥 새로 정의 한 것이 됨.

다중상속 : diamond problem, A-B, A-C, B-D, C-D면 D는 B/C 중 골라 상속해야 하는데 뭘 고를지 모름.

Polymorphism

overloading vs overriding

static의 overloading vs overriding

overloading : 이름만 같게, static polymorphism, (정해짐)

overriding : 부모 method를 child method에서 재정의해 dynamic binding하는 것. (dynamic polymorphism) runtime에 어떤 게 실행될지 결정됨. upcasting / downcasting

static은 overloading만 가능.

abstract class, interface

추상화의 정의

abstract class 정의, interface 정의

abstraction : 불필요한 정보를 숨기고 중요한 정보만을 보여주는 것.

객체에서 : 공통된 속성, 행위 추출하는 것.

abstract class : abstract 로 정의됐거나 method 중 하나가 abstract인 것. extend한 것에서 abstract method를 구현 강제시킨다. instantiation 불가.

interface : 모든 method가 abstract method. default, static 정도는 가질 수 있다. method 구현 강제.

- 같은 default method를 interface를 다중상속하는 경우 override 필수.

둘 다 abstraction, upcasting으로 polymorphism 구현.

abstract class는 상속 관계, 따라서 확장에 주로 사용.

interface는 공통 행위 지정 시 유용.

1. interface 사용

2. 공통 함수만 필요한 경우, static이나 default 사용

- 만약 static으로 처리 가능하면 interface

- 불가능하면 abstract 사용 고려.

Exception handling

error vs exception

처리 방식

예외처리 방법

error: 치명적 오류, 수습 불가.

exception : 프로그램 내에서 수습 가능

try-catch-finally : return문 직전까지 수행하다 finally문을 수행.

try-with-resource : 괄호 안에 resource 넣음. 그러면 try 끝난 후 알아서 정리.

예외처리 방법

- 복구 : while + try-catch 사용해 복구

- 회피 : 위로 올려줌.

JVM

java virtual machine

구성요소

java 실행 과정

class loader : loading, linking, initializing

컴파일된 class 파일을 참조되는 순간에 올려줌.

runtime data area : thread (pc register, stac, native method stack), heap (object + static + runtime constant pool), metaspace (method)

- pc register : 실행 중인 instruction 주소값 담음

- stack : paramter, local variable, 리턴값 (method frame)

- native method stack : native code.

- heap : object, static, runtime constant pool. static이나 constant pool 많아지면서 바뀐 걸로.

execution engine : interpreter, JIT co mpiler, GC

1. 작성한 .java 파일을 java compiler가 .class 파일(byte code)로 변경한다.

2. JVM의 class loader가 .class 파일을 JVM에 로딩한다.

3. Execution engine이 로딩된 .class 파일을 실행한다.

Java에서 main 실행 과정

0. App.java 파일을 compiler가 .class 파일로 변환한다.

1. JRE가 static void main() method를 찾는다.

2. JVM이 실행된다.

- Class Loader가 App.class 파일을 JVM에 로딩한다.

- 추가로 App.class에서 import하는 java.lang package를 method area에 올린다.

3. main method가 stack에 올라간다.

- 이 때, main의 리턴 타입과 parameter 등이 frame으로 묶여 stack에 올라간다.

- Hello World!가 출력된다.

- 이후에는 main method가 실행 종료되었기 때문에 stack에서 해제된다.

4. main method가 끝났기 때문에 JRE는 JVM을 종료시키고 JRE도 종료된다.

GC

구조

삭제 방법

young : eden, survivor 0, survivor 1

old : old

삭제 방법 : reachability 사용. 참조되면 살리고 아니면 냅둠

minor gc : eden이 가득 차면 GC 수행. 살아남은 것은 survivor 0으로 이동, survivor 0에서 산 것은 survivor 1로 이동. survivor 1에서 산 것은 old로 이동.

major jc : old가 가득 차면 GC 수행. mark-sweep-compact. 지울 것 마킹, 삭제, memory fragmentation 막기 위한 compact.

Generic

type을 parameter화하는 것.

wildcard

memory pollution

유의점 : static은 generic 불가. 정의되기 전부터 사용하기 때문.

wildcard : 아무 타입 가능. ? extend T : T를 상속하는 것, ? super T : T 상위의 것.

?로 쓰는 경우에는 type 사용 불가

컴파일 한 후에는 T로 적은 것들도 다 Object로 변경. 그래서 잘못된 메모리 참조 가능할 수도 있음. 막기 위해서는 checkedList() 사용.

Wrapper class

정의

특징

constant pool

primitive type을 object로 감싼 것. boxing / unboxing 일어나며 성능 떨어질 수도 있음.

특징

- immutable

- wrapper class 비교는 ==가 아니라 equals() 사용.

constant pool

boolean은 t, f

숫자는 -128 ~ 127까지 constant pool에 들어가서 string과 같은 방식으로 동작. 때문에 127 비교는 true지만 128 비교는 false로 뜸.

String vs StringBuffer vs StringBuilder

비교

string : immutable, literal 사용 시 constant pool 사용. new 사용 시 heap 사용. thread-safe.

stringbuffer : mutable. 직접 값 변경, synchronization 보장.

stringbuilder : synchronization 보장 X

Java Thread

JVM은 static main() method class를 찾아 main thread를 만들고, 내부 코드 따라 thread 필요 시 thread 생성함.

java app은 모든 thread가 종료되어야 종료함. thread 끝 대기 함수는 .join()

Thread class를 override하거나 lambda function 사용하는 방식 : start() 호출. return value X, exception X

Callable interface를 implement하는 방식 : start() 호출. return value O, exception O

시작 method 호출 시 ready queue에 넣음.

java thread scheduling : first come, first serve / priority가 높은 것부터 처리 / round robin (quantum 값은 JVM이 조절)

너무 많은 thread로 성능 저하가 발생할 수 있기 때문에 thread pool에서는 thread 개수를 정해두고 ready queue에 있는 thread를 처리. 동시 처리 속도를 보장한다.

Collection

List

- arraylist : index. 조회 빠름, thread unsafe

- linkedlist : doubly linked list

- vector : thraed safe

- stack : vector의 구현체

Queue

- priorityqueue : heap, thread unsafe

- arraydeque : thread unsafe

Set : 중복 허용 X

- hashset : hash 사용, thread unsafe, hashCode() method 사용

- linkedhashset : 순서 O, thread unsafe

- treeset : thread unsafe, rb tree

Map : key 중복 X

- hashmap : hashCode(), equals() 사용해 equality 판단, thread unsafe

- linkedhashmap : 순서 O, thread unsafe

- hashtable : thread safe

thread safe를 위해서는 synchroizeXXX() 쓰면 됨.

[Spring] DTO와 Entity 간의 변환

hyelie — Tue, 12 Mar 2024 23:22:04 +0900

Spring을 쓴다면 MVC 구조를 사용한다는 것을 전제로 깔고 갈 것이다. 따라서 Controller, Service, Repositoy, DB 순으로 flow가 이동하며, 이 과정에서 entity라는 객체와 DTO라는 객체를 사용한다. 정의를 먼저 살펴보자면, entity는 DB의 row 하나와 매핑되는 객체인 반면, DTO는 Data Transfer Object, 데이터를 옮기는 데 사용하는 객체이다.

DTO의 필요성

DTO의 필요성에 대해서는 말할 필요도 없다.

만약 DTO가 없다고 가정해 보자. 그러면 entity를 사용자에게 노출시켜야 하는데, entity는 DB의 모든 column에 대한 정보를 가지고 있기 때문에 이를 사용자에게 노출시키는 것은 좋지 않다. 또한 entity에 내용이 부족해 추가적인 요청을 해야 할 수도 있고(underfetching), 필요없는 내용이 있어 네트워크 낭비가 일어날 수도 있다.(overfetching)

사용자 요청이 복잡한 경우 (2개 이상 table을 조인해 리턴하는 경우), 해당 entity를 또 만들어야 한다. 사용자 요청이 entity에 영향을 끼치게 되는데, entity는 그 자체로서 이미 핵심 로직을 가지고 있다. 때문에 entity로만 통신할 수는 없다.

Overfetching은 응답받은 정보에 필요없는 값이 있어 네트워크 낭비가 일어나는 것을,
Underfecthing은 응답받은 정보가 부족해서 추가적인 요청을 해야 하는 상황을 의미한다.

DTO를 사용함으로써 encapsulation을 할 수 있고, overfetching/underfetching을 막을 수 있다. validation을 사용해 입력에 대한 검증 로직을 controller와 분리할 수도 있다. 이 때, repository는 entity를 persistence context에 넣고, persistence context에서 entity를 가져오는 조작을 한다. 앞서 살펴봤듯 controller는 사용자에게 DTO를 돌려줘야 한다. 어딘가에서는 entity를 DTO로 변환해 줘야 한다.

어디서 DTO와 entity를 변환해야 하는가?

Repository에서 DTO와 entity를 변환해야 할까?

앞서 살펴봤듯 repository는 persistence context에 관한 조작을 하기 때문에 여기에 변환까지 추가되면 repository의 일이 너무 많아지게 된다. 때문에 일반적인 경우에서는 repository는 entity를 받아 조작하는 것이 좋다고 본다.

예외

단, 몇 가지 예외가 있을 수 있다고 생각한다.

예를 들어 JPQL로 해결할 수 없는 복잡한 쿼리(inline view 같은)를 날리는 경우를 생각해 보자. 예를 들어 A join B join C에 paging도 걸고 filtering도 걸고, ... 이런 상황에 모든 정보를 가져오고 싶다고 생각해 보자. DTO를 사용하지 않았을 때 이 결과가 entity와 매핑되지 않는 경우 Object[]나 Map을 사용해야 한다. 이 경우 repository에서 Object[]로 리턴하게 되고, service도 Object[]를 받아 정보를 파싱해야 하며, 쿼리를 보아야 어떤 위치에 어느 데이터가 있는지 알 수 있다. 이런 경우는 유지보수가 너무 어려워지고, 변환 코드도 중복되기 때문에 DTO를 사용해 리턴하는 방식이 좋은 것 같다.

또한, QueryDSL의 @QueryProtection을 사용하는 경우 DTO가 repository에서 생성되어 나가기도 한다.

일단 repository는 아닌 것 같다.

그러면 남은 것은 service와 controller이다. 일단 service는 비즈니스 로직을 다루는 layer이고, controller는 클라이언트 요청을 받고 service에게 받은 처리 결과를 클라이언트에게 응답하는 역할을 한다.

일단 Spring을 사용하는 이유는 "유연한 확장과 유지보수의 용이성"을 목적으로 가져가는 경우가 대부분일 것이다. 이를 위해서는 dependency를 줄이는 것이 제일 중요하다. dependency가 어떻게 되는지 살펴보자.

dependency가 있는 경우, 하나를 수정하면 연관된 모든 것을 수정해야 하기 때문이다.

Controller에서 변환

controller에서 DTO를 entity로 바꾼다고 해 보자.

controller가 입력으로 DTO를 받으면 controller 내부에서 entity로 바꾸고 service를 호출한다.
이후 service가 리턴한 entity를 DTO로 바꾸어 리턴한다.

controller에서 Entity - DTO 변환 시 dependency tree

그러면 controller는 DTO, entity, service에 의존한다. service는 entity와 repository에 의존하게 된다.

비즈니스 로직을 다루는 service가 특정 DTO에 의존하지 않고, entity에만 의존하기 때문에 service에 대한 재사용성이 높다.

이 경우, controller가 하는 역할에 비즈니스 로직이 섞일 수도 있다! 예를 들어 복잡한 통계를 응답해야 하는 상황을 가정해 보자. 여러 service로부터 entity list를 받아오고 이를 합쳐 DTO를 만들어야 한다고 치면, 이것 자체도 비즈니스 로직이 포함되어 있는 것이다. 그러면 사용자 요청을 담당하는 controller에 추가적인 일이 생긴다. 또한 하나의 controller가 여러 개의 service에 의존하게 된다.

Service에서 변환

service에서 DTO를 entity로 바꾼다고 해 보자.

controller가 입력으로 받은 DTO를 그대로 service에 넘긴다.
service 내부에서 DTO를 entity로 변환한 후 비즈니스 로직을 실행하고, 필요 시 repository를 호출한다.
이후 service는 repository가 리턴한 entity를 DTO로 변환하고, controller에게 돌려준다.

service에서 Entity - DTO 변환 시 dependency tree

그러면 controller는 DTO, service에 의존한다. service는 DTO, entity, service에 의존한다.

controller는 받은 DTO를 사용자에게 바로 넘겨주기만 하면 된다. 여러 entity를 합쳐야 하는 복잡한 비즈니스 로직도 service에서 모든 것을 처리한 후 controller로 넘겨주면 된다. 요구사항이 바뀌는 경우를 생각해 보자. controller는 받은 DTO를 그대로 넘겨주기만 하면 되므로 변하지 않을 가능성이 매우 높다.

반면 모든 요청에서 다른 DTO를 사용해야 하기 때문에 API 개수만큼 DTO 개수가 늘어난다는 단점이 있다. (같은 DTO를 사용하는 경우 overfetching이 일어날 수도 있기 때문에 나누는 것이 좋다.) 또한 service가 DTO에 의존하고 있기 때문에 해당 DTO가 아닌 경우 그 service를 쓸 수 없으므로 service에 대한 재사용성이 매우 떨어진다는 단점도 있다.

결론

애플리케이션에 복잡한 로직이 아예 없는 경우는 없다고 봐도 무방하므로, controller에서 entity와 DTO를 변환하는 방식은 비즈니스 로직이 controller로 넘어오게 되므로 별로인 것 같다. 그렇다고 두 번째 방법을 채택하자니 service가 DTO에 의존하기 때문에 service에 대한 재사용성이 떨어진다는 딜레마가 발생한다. 모든 경우에서 딱 좋은 압도적인 하나의 결론이 없다. 때문에 상황에 맞춰 써야 한다. 그러면 어떤 상황에서 어떤 방식을 써야 할까?

만약 복잡한 쿼리가 적거나 없는 소규모 프로젝트라면 controller에서 entity를 변환하더라도 비즈니스 로직이 controller로 오지 않는다. 그러면 controller에서 변환하는 것이 더 좋을 것이다!

반면 복잡한 쿼리가 많고, service를 재사용하지 않을 경우 service에서 변환하는 것이 더 좋을 것이다!

일반적으로는 한 종류의 controller가 하나의 service를 사용하는 경우가 대부분이기 때문에 service에 대한 재사용성을 크게 기대하지 않아도 될 것이다.

다른 방법

진짜 silver bullet은 없나? service의 재사용성/완벽히 분리된 비즈니스 로직 두 가지를 모두 달성할 수 있는 방법은 없을까?

controller가 service에 값을 보낼 때는 DTO를 보내고, 받을 때는 entity를 쓰는 방식은? 음... 이 경우는 두 방식의 단점만 모두 가져온 것 같다. service의 재사용성은 떨어지고, entity를 합쳐야 할 때는 비즈니스 로직이 controller로 오게 된다.

그렇다면 위 방식을 flip해서 controller가 service에 값을 보낼 때는 entity로 변환해서 보내고, 받을 때는 DTO를 받고 리턴하는 형식은 어떨까? 그러면 service의 재사용성도 확보할 수 있고, 비즈니스 로직을 service에 모두 넣을 수 있게 된다! 단... controller가 입력으로 받는 형식과 출력으로 주는 형식이 다를 수 있기 때문에, 하나의 로직에서 2개의 DTO가 필요하게 된다. DTO 관리가 매우 힘들어질 것이다. controller, service가 DTO와 entity에 모두 의존하게 되므로 DTO가 entity와 비슷한 역할을 하게 된다.

DTO-entity mapper

mapper에서 Entity - DTO 변환 시 dependency tree

controller와 service 사이에 매핑만 전문으로 다루는 class를 추가하는 방식은 어떨까? 그러면 service는 mapper와 entity에만 의존하고, controller는 mapper와 DTO에만 의존하게 된다. 일단 dependency는 꽤 좋다!

service는 entity에만 의존하므로 service에 대한 재사용성이 좋다! controller는 입력으로 받은 DTO를 mapper에 의존해 entity로 변환하고, service를 호출한다. 복잡한 비즈니스 로직도 service에서 모든 것을 처리한 후 mapper에 의존해 DTO로 바꾼다. service에서 변환하는 방식, controller에서 변환하는 방식 2개의 장점만 모았고, dependency 문제도 해결한 것 같다! entity나 DTO가 바뀌면 mapper만 바꿔주면 되므로 유지보수도 좋을 것이다.

단... mapper class가 매우 비대해질 수 있다는 단점이 있다. 변환이라는 게 말이 간단하지 요청이 조금만 복잡해져도 로직이 생기고, 모든 변환 로직이 mapper에 집중될 경우 크기에서 문제가 생길 것이다.

정리

일반적인 경우 controller와 service에서만 DTO를 사용하되, repository에서 DTO를 반환할 수도 있다.

변환 위치는, case by case이다.

controller에서 변환: 만약 복잡한 쿼리가 적거나 없는 프로젝트라면 controller에서 entity를 변환하더라도 비즈니스 로직이 controller로 오지 않는다. 그러면 controller에서 변환하는 것이 더 좋을 것이다!
service에서 변환: 반면 복잡한 쿼리가 많고, service의 재사용을 하지 않을 것이라 예상되는 경우 service에서 변환하는 것이 더 좋을 것이다!
mapper 사용: 요구사항이 매우 자주 바뀌는 경우 controller와 service 사이에 mapper를 두고 mapper에서 entity와 DTO를 변환하면 유지보수가 간편해진다.

참고: 순환 참조

DTO의 위치를 설정할 때 package dependency가 cycle을 이루지 않게 조심히 설정해야 한다. 아래 2가지 경우를 보자.

service에서 Entity - DTO 변환 시 dependency tree

service에서 DTO-entity 변환 시, DTO 위치를 controller package에 두었다고 하자. controller package는 service package에 의존하는데, service가 DTO에 의존하기 떄문에 controller package에 의존하게 된다! dependency가 cycle을 이루게 된다. 이렇게 두면 안 된다. DTO 위치를 잘 생각해 두어야 할 것이다!

controller에서 Entity - DTO 변환 시 dependency tree

controller에서 DTO-entity 변환 시, DTO 위치를 controller package 내에 두던, service 내에 두던 큰 문제가 생기지 않는다. 다만 service에서는 DTO를 사용하지 않으므로 controller package에 두는 것이 자연스럽다!

[이종병렬컴퓨팅] Accelerators for Deep Learning

hyelie — Wed, 20 Dec 2023 00:19:27 +0900

이 글은 포스텍 성효진 교수님의 이종병렬컴퓨팅(CSED490C) 강의를 기반으로 재구성한 것입니다.

이 글에서는 deep learning을 위한 가속의 motivation, domain-specific accelerator의 기본, efficiency metric 그리고 4가지 case study(Google TPU, GraphCore, DianNao series, Reconfigurable accerlerator)를 살펴본다.

heterogeneity의 Motivation

single core CPU의 경우 moore의 법칙/dennard의 scaling이 거의 끝이 났을 정도로 발전이 끝에 다다랐다.

heterogeneity의 motivation

때문에 performance와 watt를 향상시키기 위해 single core CPU를 넘어, multi core CPU, GPU, FPGA 등으로 나아가고 있다. 그러나, CPU의 경우에는 target domain이 general purpose, 범용성을 가지는 것이 목표인데, GPU는 범용으로 사용할 수 없다.

Domain Specific Accelerator

domain specific accelerator는 그래픽, 딥러닝, 시뮬레이션 등 특정 분야에 특화된 하드웨어를 말한다.

특정 분야에 특화되었기 때문에 전문화된 연산, parallelism, 효율적인 메모리 시스템, 오버헤드 감소 등으로 성능이나 소모 전력량이 훨씬 향상되었다.

domain specific accelerator 설계와 parallel program을 작성하는 것의 주된 차이는 cost model이다.

일반적으로 arithmetic이나 logical 연산은 무시할 수 있을 정도로 빠르기 때문에 memory가 dominate한다. 따라서 효율성을 최대화하기 위해서는 프로그램을 재구성해야 하며, granularity나 memory footprint에서 차이가 만들어진다.

Acceleration의 source

data specialization
- 특정 domain에 특화된 hardware operator set을 제공한다.
- 이를 통해 overhead를 줄이고 에너지를 아낄 수 있다.
- overhead 감소로 인해 area와 power는 memory에 의해 dominate되는데, 따라서 global memory access를 줄이는 것이 domain specific accelerator의 핵심이다. 따라서 domain specific accelerator는 algorithm과 동시에 설계되어야 한다.
parallelism
- parallelism을 domain에 특화시키는 방식이다. 이를 통해 PE의 synchronization과 communication이 단순화되고, 이를 통해 overhead를 줄이고 utilization을 높일 수 있다.
Local and Optimized memory
- 계산은 작은 local memory에서 수행해야 한다.
- 높은 bandwidth를 얻기 위해 global memory로의 access pattern을 최적화한다.
- 특정 데이터 구조를 앞축해 local memory의 유효 크기와 bandwidth를 올리는 방식도 있다.
- memory access를 load balance해서 memory utilization을 최대화하는 것이다.
reduce overhead
- instruction overhead가 높기 때문에 복잡하고 전문화된 특수 instruction을 만든다.

Balancing Specialization and Generality

일반성과 효율성은 tradeoff를 가진다.

special instruction vs special engine

special instruction은 general purpose processor에 추가되었다.
dedicated accelerator는 on chip memory에서 data stating이나 data 이동을 최적화하는 데 효과적이다.

Accelerator 프로그래밍

domain specific accelerator는 firmware와 software 개발 인터페이스가 필요하다. API based 또는 compiler based이다.

더 유연한 domain specific language를 지원하는 accelerator는 domain specific compiler에 backend를 추가한다.

Efficiency Metrics

효울적인 deep neural network를 처리하기 위해서는 다음과 같은 것들을 고려해야 한다.

어떤 것을 측정하고 비교해야 하는지 (metric)
어떤 것이 주요 과제인지 (challenge)
설계 고려사항과 tradeoff (consideration, tradeoff)

Key Metrics

accuraty : 결과의 품질
throughput : 큰 데이터를 가진 것들에 대해
latency : interactive한 것들에 대해
energy and power : embedded device는 한정된 배터리를 가지고 있기 때문. 또한 data center는 cooling cost가 있다.
hardware cost
flexibility : deep neural network model의 작업 범위
scalability : resource 양에 따른 성능의 확장

Key Operation

weighted sum을 계산하기 위한 multiply and accumulate (MAC)가 중요하다. 계산의 90% 이상을 차지하기 때문.

deep neural network SW/HW의 핵심 설계 목표

throughput을 증가시키고 latency를 최소화하는 것이다.
- MAC 연산의 reduce를 줄이는 것. critical path를 줄임으로써 overhead를 줄일 수 있다.
- 필요 없는 MAC 연산을 줄여 cycle을 아끼는 것
- processing element (PE)의 개수를 늘리는 것. 이를 통해 더 많은 MAC 연산을 병렬로 수행할 수 있다.
- PE utilization을 증가시키는 것. 가능한 한 많은 PE에 작업을 분산하고, 부하를 균형있게 유지해 utilization을 높게 유지하는 것이다. 추가로 PE에 작업을 전달하기 위한 memory bandwidth
낮은 latency는 작은 batch size를 가져야 한다는 제약이 있다.
전력 소비량 감소
- 에너지 소비를 dominate하는 data 이동을 줄이기
- MAC 연산당 소모 전력 줄이기
- 필요 없는 MAC 연산 없애기
전력 소비는 열 방출에 의해 제한되어 있으며, 이는 parallel하게 수행할 수 있는 최대 MAC 연산의 개수를 한정한다.

Metric 측정을 위한 명세

accuracy : dataset 작업의 어려움을 고려해야 함. 어려운 작업은 더 복잡한 deep neural network model을 필요로 한다.
throughput : utilization과 processing element의 개수, 특정 deep neural network model의 수행시간
latency : 평가를 위한 batch size
energy와 power : 특정 deep neural network model을 수행할 때 전력 소모량, off chipe memory access
hardware cost : on chip storage, processing element의 개수, chip area와 process 기술
flexibility : 다양한 deep neural network에 대한 성능 비교

이 때 모든 metric은 설계 tradeoff를 공정하게 비교해야 한다. 특정 metric이 생략되었을 때는 문제가 발생하기 때문

accuracy는 주어진 작업을 정확하게 수행하는지,
latency와 throughput은 작업이 빠르고 실시간으로 수행되는지,
energy와 power consumption은 기기 형태에 따라 결정되며,
cost는 chip area에 의해 결정되며 각 solution에 얼마인지 결정되며
flexibility는 작업 범위를 말한다.

비교

GPU의 경우

ASIC accelerator의 경우

FPGA/CGRA accelerator의 경우

GraphCore의 경우

In memory computing의 경우

Case study : Google TPU

Systolic array

목표는 다음 요건들을 달성하는 accelerator를 만드는 것이다.

간단하고 규칙적인 설계
높은 concurrency
균형잡힌 computation과 I/O

핵심 아이디어는 하나의 processing element를 processing element의 regular array로 대체하고, processing element 간의 data flow를 잘 조절하는 것이다. 이를 통해 memory에서 가져온 input data를 출력하기 전에 변환한다.

이를 통해 memory에서 가져온 single data element에 대해 computation을 maximize한다.

장단점

장점 : memory bandwidth를 더 쓸 수 있고, concurrency를 높인다. 또한 regular한 설계이다.
단점으로는 irregular parallelism을 활용하는 데는 별로이고, specialize되었기 때문에 general하게 적용할 수 없다.

지난 10년간 lesson

DNN은 memory와 compute에서 급격하게 성장했다.
DNN 워크로드는 DNN의 혁신과 함께 성장했다.
DNN을 compiler나 hardware만큼 최적화할 수 있다.
inference slo는 batch size가 아니라 p99 latency에 의해 한정된다.
production infernce는 multi tenacy이다.
FLOPs가 아니라 memory의 문제다.
DSA challenge : domain에 최적화하면서 flexible을 유지하기
logic, wire, SRAM & DRAM은 불균등하게 개선된다.
compiler를 최적화하고 ML 호환성을 유지해야 한다.
TCO 대비 성능 대 CapEX 성능을 설계해야 한다.

Lesson 6: It's the memory

transistor의 수가 아니라 external memory access energy가 현대 칩의 한계를 결정한다. external memory access energy는 on chip memory access보다 100배 더 크고, arithmetic operation의 1만배 정도 더 크다.

memory access의 균형을 맞추기 위해 ALU를 추가해 FLOPs/s를 늘일 수 있다.

Lesson 7: DSA optimizes for domain while being flexible

TPU v2는 학습에 어려움이 있다.

더 많은 backpropagation, transpose, derivative
더 많은 memory : backpropagation을 위해 data를 유지한다.
더 넓은 operand : int8보다 더 큰 동적 범위가 필요하다.
어려운 parallelization : scale out 대신 scale up
programmability

Lesson 8 : Unequal changes in semiconductor technology

logic은 무료이기 때문에 wire나 SRAM보다 더 빨리 발전한다.

VLIW XLA compiler

TPU v2와 이후 버전은 XLA 컴파일러에 의존한다.

TPU v2와 v3는 322 bit의 VLIW instruction을 생성한다. 이를 통해 8개의 작업을 수행할 수 있다.
- 2개의 scalar, 2개의 vector ALU, vector load와 store, 행렬 곱셈 및 전치
TPU v4 VLIW는 25% 더 넓다.
compiler와도 호환된다.

표준 VLIW compilation 기술 사용 : loop unrolling, instruction scheduling, software pipelining

Reconfigurable Accelerators

Field Programmable Gate Array, FPGA

적은 개발 비용으로 custom hardware 기능을 구현할 수 있는 유연한 platform을 제공하는 판매용 프로그래밍 장치. logic block, programmable interconnection network, programmable input/output cell을 지원한다.

Coarse Grained Reconfigurable Architecture, CGRA

domain specific flexibility
- general purposed와 fixed function 사이에서 flexibility를 유지한다.
- coarse grained level에서 재구성할 수 있다.
- hardware를 목적 domain에 맞게 재구성한다.
spatial과 temporal computation의 결합
- spatial : 여러 processing element에서 병렬로 계산하고 데이터를 전공한다.
- temporal : 계산을 shared processing element에서 실행할 section으로 분할한다.
data driven execution

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

[이종병렬컴퓨팅] Heterogeneous Parallel Computer를 위한 기술 스택

hyelie — Mon, 18 Dec 2023 00:16:09 +0900

이 글은 포스텍 성효진 교수님의 이종병렬컴퓨팅(CSED490C) 강의를 기반으로 재구성한 것입니다.

이 글에서는 이종 시스템을 위한 고수준 프로그래밍을 가능하게 하는 software stack에 대해 설명한다. compiler-based, library-based, framework-based로 나눠 설명하고, OpenCL에 대한 compile/runtime 지원을 살펴본다.

Compiler란?

compiler는 source code를 기계어로 번역하는 일을 한다.

source code는 high level abstraction, low level detail을 숨긴다. 떄문에 알고리즘에 대한 이해가 쉽고, fine-grained performance tuning이 제한된다.
기계어는 코드를 짜고 유지보수하기 어렵지만, 성능을 직접적으로 제어할 수 있다.

compiler는 lexical analysis, syntatic analysis, semantic analysis, IR generation, IR optimization, code generation, code optimization의 과정을 거쳐 기계어를 생성한다.

더 깊은 software stack에 대한 동기

언제, 그리고 왜 abstraction layer를 사용할 수 있을까? 크게 3가지가 있다. detail을 숨기고 싶을 때는 programmability를, 최적화된 기능을 제공하고 싶을 땐 performance를, portable code를 작성하고 싶을 땐 portability이다.

그러나 이것은 heterogeneous system을 위한 것일까? CPU와 GPU는 서로 다른 contraint와 기능을 가지고 있기에 설계가 복잡하고, 때문에 성능을 추정하기 어렵다.

General Purpose Compiler

general compose compiler

Application Programming Interface: API

API

software 객체 간의 상호작용을 정의하는 library 기반 interface이다. 이를 통해 기본 구현을 추상화하고, 개발자가 필요로 하는 객체나 동작만 노출시켜 programming을 간단하게 만든다. 언어에서 만든 추가적인 abstraction layer라고 생각하면 된다.

Domain Specific Language

domain specific language

domain specific language는 특정 domain에 대한 더 높은 abstraction을 제공한다.

맞춤형 추상화라고 불리우며, 이를 통해 domain 전문가들에 대한 접근성과 신뢰성을 향상시킬 수 있다. 코드가 더 짧아지고 compiler는 정해진 boilerplate code를 생성하기 때문이다. 또한 표현력을 일부 제한해서 domain 수준에서 유효성을 검사하고 최적화를 할 수 있다.

Library와의 비교

복잡한 libaray는 사용하기 어려울 수 있다. type checking은 host language level에서만 사용할 수 있다. domain 지식을 활용하거나 여러 artifact를 생성하기 더 어렵다.

Framework

framework

framework는 프로그램을 구축하고 배포하는 표준 방식을 사용해 개발을 용이하게 한다. compiler, code library, toolset, API, 개발환경, 테스팅 환경, 실행환경 등이 포함된다.

framework는 domain specific language 그 이상의 구현이다. 다양한 engineering 장점들을 제공한다.

modularity : 다른 시스템이 작업을 수행하는 방식에 대한 자유로운 모듈
extensibility : 작업의 실행과 구현이 분리된다.
flexbility : 언어가 부여한 구조나 규칙이 없다.
development support : 개발/디버그 환경이나 utility 등 프로그램이 있다.

Inversion of Control: IoC

inversion of control

기존 코드에서는 사용자가 모든 library를 호출한다. 그러나 framework는 framework가 사용자가 작성한 코드를 호출한다. 때문에 dependency의 책임을 higher-level code에게 전가한다.

HPC를 위한 software stack

heterogeneous system을 위한 programming

high level 언어 기반 프로그래밍

왼쪽은 host를 직접 짜는 경우이다. 이 경우 구현이 더 투명해지며, 실행 동작을 직접 관리할 수 있고 platform에 indepdent하게 동작할 수 있다.

오른쪽은 framework에서 짜는 경우이다. framework는 scheduling과 mapping을 제어해 높은 runtime flexibility와 시스템 전반적인 최적화를 제공한다.

AMD ROCm

GPU 가속화된 HPC, 과학 계산, CAD를 위해 디자인되었다.
모듈로 나누고, 최소한의 소프트웨어 개발
framework, library, driver, programming model, linux kernel support로 구성되었다.
성능이나 확장성에 최적화되어 있다.
특히 ROCm 5.6의 경우 LLM을 위한 최적화된 library를 제공한다.

Intel OneAPI

heterogeneous processing architecture를 위한 프로그램 개발을 위한 통일되고 간소화된 프로그래밍 모델을 위한 industry
Intel Xeon이나 Core processor, Intel FPGA를 목표로 한다.
기존 AI나 HPC 프로그래밍 모델과 호환된다.

NVICIDA CUDA와 CUDA-X

고성능 AI 및 HPC를 위한 library와 도구의 collection.

GPU library

CUDA library

CUDA math library
- exponential, logarithmic, trrigonometric, hyperbolic, vector norm 등 기본적인 수학 함수를 지원한다.
cuBLAS
- dense matrix를 위한 선형대수 subroutine 지원
- matrix-vector나 matrix-matrix 곱셈 지원
- user kernel에서 cuBLAS 호출 가능. (device API이다.)
- CUDA stream 지원
- cuBLASxt는 multiple GPU도 지원한다.
cuFFT
- 1D, 2D, 3D FFT
- cuBLAS와 유사하게 user host code에서 호출된다.
- batch로 독맂벅인 변환을 수행하는 기능을 지원한다. 예를 들어 3D dataset에서 1D transform 등
cuTENSOR
- tensor 선형대수 library
- 새로운 tensor core를 활용한다.
cuSPARSE
- sparse matrix를 위한 작업 지원
- sparse matrix-vector와 matrix-matrix 곱셈 포함
cuRAND
- 난수 생성
cuSOLVER
- cuBLAS나 cuSPARSE library를 기반으로 한 고수준 package
- LAPACK dense solver를 제공하며, Intel MKL보다 3-6배 빠르다. sparse direct solver는 CPU보다 2-14배 빠르다.
- 최신 버전은 low-precision tensor core 연산을 사용한다.
CUTLASS (CUDA Template for Linear Algebra Subroutines)
- GEMM 행렬 곱을 구현하기 위한 CUDA C++ 템플릿 추상화 collection
cuDNN
- deep neural network를 위한 library
nvGraph
- 그래프 분석 library
- page rank, single source shortest path, single source widest path 등을 지원한다.
NPP (NVIDIA Performance Primitive)
- imaging이나 video 처리를 위한 library
- filtering, JPEG decoding 등을 지원한다.
NCCL
- NVIDIA GPU 및 네트워킹에 최적화된 multi GPU 및 multi node 통신을 구현한다.
- all-gather, all-reduce, broadcase, reduce, reduce-scatter, P2P 등 지원
Thrust
- C++ STL 기반 interface를 갖는 고수준 C++ template library
- 사용자는 CUDA 코드 없이 표준 C++ 코드를 작성하지만 GPU 병렬화의 이점을 가질 수 있다.
- x86도 지원한다.
- memory 관리나 data movement를 간소화한다.

AMD ROCc Library

AMD의 ROCm 런타임 및 toolchain에서 매우 유사한 library set을 제공한다.
- HIP 프로그래밍 언어로 구현되어 AMD GPU에 최적화되어 있다.
- rocBLAS, rocFFT, rocSPARSE, RCCL 등이있다.
- hipBLAS나 hipSPARSE는 backend를 지원하는 marshalling library이다.
- rocThrust는 thrust를 위한 HIP backend이다.

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

[이종병렬컴퓨팅] OpenMP

hyelie — Sun, 17 Dec 2023 23:42:31 +0900

이 글은 포스텍 성효진 교수님의 이종병렬컴퓨팅(CSED490C) 강의를 기반으로 재구성한 것입니다.

이 글에서는 OpenMP 프로그래밍 모델의 기본 개념과 pragma, 간단한 예제들을 살펴본다.

OpenMP

OpenMP API는 pragma(컴파일러 지시문), library routine, 환경변수 등을 제공한다. 이를 통해 multithread parallel fortran이나 C/C++ 프로그램을 쓸 수 있다.

programmability와 portability를 위한 high-level parallel structure를 제공한다. 때문에 low-level thread를 조작하는 것보다 parallel program을 쓰고 유지하는 것이 더 쉽다.

SMP 관행을 표준화하며, vectorization과 heterogeneous device programming도 지원한다.

Motivation

OpenMP 프로그래머는 1) sequential 버전으로 시작한 다음, 2) OpenMP 지시문을 추가한다. 그러면 대부분의 kernel 생성, memory allocation, data 전송을 OpenMP compiler에게 맡기게 된다.

한편, OpenMP 코드는 pragma를 무시하고 non-OpenMP 컴파일러에서 컴파일할 수 있다.

Tradeoff

장점으로는 low-level detail을 알 필요 없이 sequential program에서 parallel version으로 빠르게 변환할 수 있다.

단점은 OpenMP 프로그램의 성능은 컴파일러의 성능에 크게 의존한다. 몇몇 OpenMP pragma는 컴파일러에게 hint일 수 있지만, 그렇지 않을 수도 있다. 때문에 컴파일러가 pragma에 따라 동작하지 않는 이유를 찾기 어렵다. 이러한 불확실성은 CUDA나 OpenCL 프로그램에 비하면 훨씬 덜하다.

OpenMP common core

OpenMP pragma, function, clause	개념
#pragma omp parallel	병렬 영역, thread team, structured block, thread 간 교차 실행
int omp_get_thread_num() int omp_get_num_threads()	병렬 영역에서 thread를 생성하고, thread ID를 사용해 여러 개의 thread를 식별하고 작업을 분할한다.
double omp_get_wtime()	Amdahl's law를 적용한 speedup. false sharing과 기타 성능 문제
setenv OMP_NUM_THREADS N	내부 제어 변수로, 기본 thread 개수를 설정한다.
#pragma omp barrier #pragma omp critical	synchronization과 race conditioon. 교차 실행을 revisit한다.
#pragma omp for #pragma omp parallel for	workshaing, 병렬 loop, loop carried dependency
reduction(op:list)	thread team 사이에서 값을 reduction
schedule(dynamic [,chunk]) schedule (static [, chunk])	loop 계획, loop overhead과 load balance
private(list), firstprivate(list), shared(list)	data 환경
nowait	작업 공유 구조에서 barrier 비활성화. barrier의 high cost. flush 개념
#pragma omp single	single thread로 작업 공유
#pragma omp task #pragma omp taskwait	작업에 대한 데이터 환경을 포함한 작업

OpenMP Device Model

OpenMP device model

OpenMP는 host/device model을 사용한다. host는 초기 thread가 실행을 시작하는 위치이며, 0개 이상의 device가 host에 연결된다.

하나의 host, 여러 개의 device가 존재한다. 각 device는 1개 이상의 compute unit으로 구성되며, 각 compute unit은 1개 이상의 processing element로 구성된다.

memory는 host memory와 device memory로 분할된다.

Host/Device Platform Model

target : device로 진입하기 위한 대상 구성
teams : 각 computing unit에 하나의 team thread로 이뤄진 team league를 만든다.
distribute : distribute clause로 team에게 loop iteration block을 할당한다.
parallel for : 각 loop iteration block을 processing element에서 실행한다.

예시 : Vector Add

#include <omp.h>
#include <stdio.h>
#define N 1024

int main() {
    float a[N], b[N], c[N];
    // initialize a, b and c ....
    
#pragma omp target // thread는 host에서 실행된다.

    for (int i = 0; i < N; i++)
        c[i] += a[i] + b[i];

    // Test results, report results ...
}

여기서 `#pragma omp target`을 하면 thread는 host에서 실행된다. original variable i, a, b, c는 construct 초기에 device로 복사된다. target construct는 code 영역을 device로 offload한다. 이후 계산이 끝나면 i, a, b, c는 host로 돌아온다.

`target` : device에서 실행 중인 초기 thread가 code block의 code를 실행한다. 즉, single thread가 loop를 sequential하게 실행한다.

#include <omp.h>
#include <stdio.h>
#define N 1024

int main() {
    float a[N], b[N], c[N];
    // initialize a, b and c ....
    
#pragma omp target
#pragma omp teams

    for (int i = 0; i < N; i++)
        c[i] += a[i] + b[i];

    // Test results, report results ...
}

`teams` : 같은 개수의 thread를 가진 여러 개의 thread group이 시작된다. 실행은 각 team의 master thread에 의해 계속된다. team들끼리는 synchronization이 없다.

#include <omp.h>
#include <stdio.h>
#define N 1024

int main() {
    float a[N], b[N], c[N];
    // initialize a, b and c ....
    
#pragma omp target
#pragma omp teams distribute

    for (int i = 0; i < N; i++)
        c[i] += a[i] + b[i];

    // Test results, report results ...
}

`distribute` : team의 master thread가 loop iteration을 분배한다. (static distribution) 정해진 실행 순서가 없고, thread team 내부에서 parallelism이나 work-sharing을 생성하지 않는다.

#include <omp.h>
#include <stdio.h>
#define N 1024

int main() {
    float a[N], b[N], c[N];
    // initialize a, b and c ....
    
#pragma omp target
#pragma omp teams distribute parallel for

    for (int i = 0; i < N; i++)
        c[i] += a[i] + b[i];

    // Test results, report results ...
}

`parallel for` : loop 반복을 team 내의 thread에게 분배한다. `teams`가 없는 경우 오직 하나의 team만 존재하게 된다.

Target Data Environment

target data environment

host thread에서 `#pragma`로 OpenMP를 실행시키면 다음과 같은 일이 일어난다.

host thread는 task가 끝나기를 기다린다.
A, B 등 원래 값들이 device로 복사된다.
- target 영역에서 참조된 scalar나 static allocated array는 implicitly하게 host - device에서 복사된다.
device에서 값을 parallel하게 계산한다.
device에서 계산이 끝난 A, B 등 변수 값들을 host로 돌린다.
host thread가 이어 실행한다.

Data Movemont 관리

data movement는 `map`을 사용해 explicitly 관리할 수 있다.

int i, a[N], b[N], c[N];
#pragma omp target map(to:a, b) map(toform:c)

map(to: list) : device에서 read-only data
map(from: list) : device에서 write-only data. target 영역의 끝에서 list 내의 변수들이 원래 값에 복사된다.
map(tofrom: list) : to와 from 둘 다 동작한다.
map(alloc: list) : data가 device에서 할당되고, 초기화되지 않은 상태
map(to: a[0:N]) : pointer의 경우 array notation을 사용해야 한다.

이외 자주 사용되는 Clause

Target과 자주 사용되는 Clause

#pragma omp target [clause[[,]clause]...]
structure-block

if (scalar expression) : scalar expression이 false면 target은 host에 의해 실행된다.
device (integer expression) : integer expression의 값은 device를 결정한다.
private(list) firstprivate(list) : list에 있는 변수와 동일한 변수를 device에 생성한다. firstprivate의 경우 host에서 원래 변수의 값이 device에서 생성된 private 변수로 복사된다.
map(map-type: list[0:N]) : list의 변수가 host와 device 간에 어떻게 이동하는지 정의한다.
nowait : target 작업이 연기되어 host와 target 영역이 parallel하게 실행된다.

Teams Distribute Parallel For과 사용되는 Clause

#pragma omp teams distribute parallel for [clause[[,]clause]...]
for-loop

reduction(reduction-identifier : list) : list의 변수에 대해 reduction 연산을 수행한다. reduction 변수는 map clause에도 나타나야 한다.
collapse(n) : distribute 지시어가 iteration을 team에게 분배하기 전에 loop를 합친다.
schedule(kind[, chunk_size]) : loop iteration을 team에게 분배하는 것을 제어한다.

Target Data Directive

#pragma omp target data map(to: A,B) map(from: C)
{
#pragma omp target
 // do lots of stuff with A, B, and C
//do something on the host
#pragma omp target
 // do lots of stuff with A, B, and C
}

`target data`는 target data region을 생성한다.
`map`은 explicit한 data 관리를 위해 사용한다. device data 환경에 data가 지시문의 시작과 끝에 복사한다.
`target data` 영역 내에서 여러 `target` 지시문이 하나의 data 영역과 작업할 수 있다.

Target Update Directive

#pragma omp target data map(to: A,B) map(from: C)
{
#pragma omp target
 // do lots of stuff with A, B, and C
#pragma omp target update from(A)
// do something with A on the host
#pragma omp target update to(A)
#pragma omp target
 // do lots of stuff with A, B, and C

`target update`를 사용해 target 영역 간의 data를 갱신할 수 있다.

CUDA vs OpenMP : Vadd

- CUDA의 경우

_global__ vadd(float *a, float *b, float *c) {
    int i = blockDim.x * blockIdx.x + threadIdx.x;
    c[i] += a[i] + b[i];
}

- OpenMP의 경우

#include<omp.h>
#include<stdio.h>

#define N 1024

int main() {
    float a[N], b[N], c[N];
    // initialize a, b and c ....
#pragma omp target map(to:a,b) map(tofrom:c) // device로 정보 옮김
#pragma omp teams num_teams(NCU) thread_limit(NPE) // device 묘사. NCU는 CU의 개수, NPE는 CU당 PE의 개수
#pragma omp distribute // thread block을 compute unit에게 분배
    for (ib=0; ib<N; ib+=tbsize)
#pragma omp parallel for // 바로 아래의 for문은 thread block의 개별 thread가 실행
    for(int i=ib; i<ib+tbsize; i++)
        c[i] += a[i] + b[i];
    // Test results, report results ...
}

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

[이종병렬컴퓨팅] Parallel Patterns : Sparse Computation

hyelie — Sun, 17 Dec 2023 02:29:38 +0900

이 글은 포스텍 성효진 교수님의 이종병렬컴퓨팅(CSED490C) 강의를 기반으로 재구성한 것입니다.

이 글에서는 memory bandwidth를 절감가힉 위한 parallel sparse computation에서 input data를 압축하는 방법을 살펴본다. 이를 통해 memory의 utilization을 높일 수 있고, on-chip memory로 전송되는 data 크기를 줄일 수 있다.

또한 clamping으로 variation 제한, sorting, transposition 등으로 불규칙한 데이터를 규칙적으로 만드는 방법을 살핀다.

Sparse Matrix

자연 상태의 많은 system들은 sparse하다. 보통 matrix의 80% 이상이 0이면 sparse matrix라고 한다.

Sparse Matrix-Vector Multiplication, SpMV

sparse matrix-vector multiplication

sparse matrix-vector multiplication는 많은 곳에서 사용되는데, 예를 들어 계수행렬 A, vector x, y에 대해 linear system Ax = y의 역행렬을 구해야 할 때 사용된다.

sparse linear system 해결

sparse matrix vector multiplication을 기반으로 하는 iterative conjugate gradient solver가 일반적인 방법이다.
mv(A)가 A와 matrix-vector 곱을 계산할 때 시간복잡도일 때, O(mv(A) * n)의 시간이 걸린다.
이 경우 SpMV operation에 대해 100초 이상이 걸린다.

신경쓸 것들

dense matrix multiplication과 비교했을 때 SpMV은 불규칙하고, 구조화되지 않는다. 또한 input data reuse가 거의 없고, compiler transformation tool로 이득을 얻기 힘들다.

때문에 성능을 높이기 위해서는 divergence나 load imbalance를 줄여 regularity를 최대화하거나, layout을 재배열해 DRAM burst utilization을 최대화하는 방법이 있다.

Sparse Matrix Format

sparse matrix format

왼쪽으로 갈수록 구조화된 것, 오른쪽으로 갈수록 구조가 없는 것이다. 이 글에서는 ELL, CSR, HYB, COO, JDS 정도만 살펴본다.

간단한 Parallel SpMV

간단한 parallel SpMV

각 thread가 하나의 row를 처리하면 된다. 이걸 이제부터 발전시켜 나갈 것이다.

Compressed Sparse Row Format : CSR

compressed sparse row format

위 형식은 compressed sparse row format이다. non-zero element에 대한 정보만 저장한다.

data[] : 값들을 저장한다. length는 matrix에서 non-zero element의 개수와 동일하다.
col_index[] : column index를 저장한다. length는 non-zero element의 개수와 동일하다.
row_ptr[] : 각 row에 non-zero element의 개수가 몇개인지 prefix sum 형태로 저장된다. length는 row + 1과 동일하다.

예시

CSR format example : row 0 & row 1

CSR format example : row 2 & row 3

위 예시의 경우, row 0에는 3, 1이, row 1에는 아무것도 없고, row 2에는 2, 4, 1이, row 3에는 1, 1이 있다.

row_ptr[0]은 0이고, row_ptr[1]은 row 0까지 non-zero element의 개수는 2이므로 2이다. row_ptr[2]는 row 1까지 non-zero element의 개수이므로 2이다. 같은 방식으로, row_ptr[2] = 5, row_ptr[3] = 7이다.

이후 col_index를 보면 된다. row_ptr[1]까지 element가 2개이므로, data와 col_index의 index 0과 index 1이 row 0에 대한 정보를 가지고 있다는 것을 알 수 있다. 같은 방식으로, row_ptr[1]이 2이고 row_ptr[2]의 값이 2이므로, row 1에는 non-zero 값이 없다는 것을 알 수 있다. 똑같이 row_ptr[2]가 2, row_ptr[3]이 5이므로 row 2에는 non-zero element가 3개 있다는 것을 알 수 있고, index 2, 3, 4에 해당 element들이 저장된다.

이게 CSR format이다.

Compressed Sparse Row Kernel Design

compressed sparse row kernel design

CSR format의 경우, row_ptr과 data를 사용해 어떤 row에 어떤 data가 있는지 알 수 있다. 그렇다면 vector와 이 값을 dot product하고 더해버리면 해당 위치의 결과가 나오게 된다.

Parallel SpMV/CSR kernel

__global__ void SpMV_CSR(int num_rows, float* data, int* col_index, int* row_ptr, float* x, float* y) {
    int row = blockDim.x*blockIdx.x + threadIdx.x;
 
    if (row < num_rows) {
        float dot = 0;
        int row_start = row_ptr[row];
        int row_end = row_ptr[row+1];
 
        for (int i = row_start; i < row_end; i++)
            dot += data[i] * x[col_index[i]];
        y[row] = dot;
    }
}

CSR의 단점

첫 번째는 kernel의 memory access가 coalesce되지 않았다는 것이다.

위 예시로 보자면, 첫 번째 for문에서 thread 0은 data[0], thread 1은 x, thread 2는 data[2], thread 3은 data[5]에 접근한다. 다음 for문에서 thread 0은 data[1], thread 1은 x, thread 2는 data[3], thread 4는 data[6]에 접근한다. 때문에 memory coalesce가 발생하지 않는다.

두 번째는 divergence가 발생한다는 것이다.

각 thread가 수행하는 for문의 반복 회수는 해당 thread가 접근하는 row의 non-zero element의 개수인데, 이는 row마다 달라질 수 있기 때문에 반복 회수가 thread마다 매우 달라진다. 즉 divergence가 발생하게 된다.

Regularizing SpMV with ELL(PACK) Format : ELL

ELL format

앞서 살펴본 CSR format의 divergence 문제와 memory access pattern 문제를 해결하기 위해 padding과 transpose를 적용해 해결할 수 있다.

먼저 non-zero element의 개수가 제일 많은 row를 찾는다. 이후 다른 row들은 해당 row와 크기가 동일하도록 padding(0)을 추가한다. 왼쪽 그림의 예시에서는 row 0에서는 1개, row 1에서는 3개, row 2에서는 0개, row 3에서는 1개의 padding이 추가된다. 이 때 col_index 배열 또한 같은 방식으로 padding을 적용해야 한다.

이 경우 몇몇 row만 다른 row들에 비해 훨씬 길면 padding이 비효율적으로 형성된다.

이후 이렇게 만들어진 data[]를 transpose한다. 이에 맞춰 col_index[]에 있는 값들도 mapping을 유지하기 위해 같은 방식으로 transpose한다.

그러면 row i의 시작이 위치가 data[i]로 바뀌었기 때문에 row_ptr이 필요없어진다.

ELL Kernel Design

ELL kernel design

ELL format에서 memory coalescing

Parallel SpMV/ELL Kernel

__global__ void SpMV_ELL(int num_rows, float* data, int* col_index, int num_elem, float* x, float* y) {
    int row = blockDim.x*blockIdx.x + threadIdx.x;
 
    if (row < num_rows) {
        float dot = 0;
        for (int i = 0; i < num_elem; i++)
            dot += data[row + i*num_rows] * x[col_index[row + i*num_rows]];
        y[row] += dot;
    }
}

CSR과 비교하면 입력 parameter가 조금 달라진 것을 볼 수 있다. row_ptr이 사라지고 num_elem이 추가되었는데, 여기서 `num_elem`은 원래 matrix의 모든 row 중 non-zero element가 제일 많은 row의 element 개수이다.

padding을 추가했기 때문에 모든 row의 길이가 같아진다. 때문에 모든 thread들이 for문을 같은 회수만큼 반복하면 된다. padding의 경우 값이 0이기 때문에 결과에 영향을 미치지 않는다.

또한 for문 내에서 각 thread가 `data[row + i*num_rows]`에 접근하기 때문에 memory coalescing이 일어나므로 memory bandwidth를 더 효율적으로 사용할 수 있게 된다.

ELL format의 한계

예를 들어 1000 by 1000 size의 sparse matrix에서 1%의 element가 0이 아니라고 가정하자. 평균적으로는 각 row에는 10개의 non-zero element가 존재하게 되고, CSR format의 경우에는 사용하는 저장공간의 크기는 전체의 2% 정도이다.

그러나 row 중 하나가 non-zero element가 200고, 나머지는 매우 적은 경우, 모든 row에 size 200이 되도록 padding을 만들기 때문에 저장공간 압축 효율이 떨어진다.

즉, non-zero element가 많은 특별한 한 row가 있다면, CSR의 경우에는 하나의 warp만 오래 실행하지만, ELL은 모든 warp가 오래 실행된다.

또한 conversion에 대한 overhead도 존재한다. (큰 문제는 아니다)

ELLPACK variation

ELLPACK-R

각 row에 non-zero element의 개수를 저장하는 방식이다.

Coordinate Format : COO

coordinate format

명시적으로 non-zero element에 대해 row/column index를 나열하는 방식이다.

이 경우, data[i]와 row_index[i]와 col_index[i]가 같이 움직이기만 한다면, 순서를 변경해도 정보가 유지되기 때문에 순서를 변경해도 된다.

Sequential SpMV/COO

data[i]의 element를 계산할 때는 `y[row_index[i]] += data[i] * x[col_index[i]]`만 실행해도 되고, 모든 data에 대해 이 연산을 수행하면 처리되는 순서에 상관없이 결과를 얻을 수 있다.

for (int i=0; i < num_elem; i++) {
    y[row_index[i]] += data[i] * x[col_index[i]];
}

COO Kernel Design

COO kernel design

때문에 각 thread가 data의 특정 section을 담당하고 `y[row_index[i]] += data[i] * x[col_index[i]]` 연산을 수행한다. 이후 각 thread는 row_index[i]를 사용해서 output Y에 atomic operation을 사용해서 값을 누적하면 된다.

Parallel SpMV/COO Kernel

__global__ void SpMV_COO(float* data, int* col_index, int* row_index, int num_elem, float* x, float* y) {
    int i = blockDim.x*blockIdx.x + threadIdx.x;
 
    if (i < num_elem) {
        float dot = 0.0f;
        dot = data[i] * x[col_index[i]];
        atomicAdd(&y[row_index[i]], dot);
    }
}

design과 같은 방식으로 실행하면 된다.

Hybrid Format

ELL을 typical entry에 대해, COO를 exceptional entry에 대해 처리하는 방법이다. ELL을 적용할 때 non-zero element가 매우 많은 일부 row에 대해서만 COO를 적용하고 나머지를 ELL을 적용하는 것이다. 이를 통해 padding의 개수를 많이 줄일 수 있고, 나머지는 SpMV/COO를 사용해서 계산하는 방식이다.

예시

예시 : Hybrid format

위 예시는 hybrid format의 예시를 보여준다.

[2, 3]에 해당하는 element 하나만 COO를 적용하고, 나머지를 ELL을 적용한 모습이다.

CSR Runtime

block performance는 non-zero element가 가장 많은 row에 depend한다.

Jagged Diagonal Sparse : JDS

load balancing을 위해 JDS를 구성한다.

JDS Kernel Design

JDS kernel design

각 row의 non-zero element의 개수로 내림차순 정렬한다. 여기에 output vector를 올바르게 계산하기 위해 original row index를 추가로 가지고 있어야 한다.

예시

예시 : JDS

CSR to JDS conversion

예시 : CSR to JDS

data[], col_index[]는 순서만 바뀌지만, row_ptr[]도 정렬 결과에 따라 바뀌어야 하고, original row index를 추가적으로 관리해 주어야 한다.

CSR과 같은 방식으로 해석하면 되지만, original row index를 나타내는 `jds_row_index`만 추가되었다고 보면 된다.

Parallel SpMV/JDS Kernel

__global__ void SpMV_JDS(int num_rows, float *data,
                         int *col_index, int *jds_row_ptr, int jds_row_index,
                         float *x, float *y) {
    int row = blockDim.x * blockIdx.x + threadIdx.x;
    if (row < num_rows) {
        float dot = 0;
        int row_start = jds_row_ptr[row];
        int row_end = jds_row_ptr[row + 1];
        for (int elem = row_start; elem < row_end; elem++) {
            dot += data[elem] * x[col_index[elem]];
        }
        y[jds_row_index[row]] = dot;
    }
}

CSR kernel과 대부분이 같지만, `y[jds_row_index[row]] = dot` 부분만 바뀌었다. original row index에 해당하는 위치에 값을 더해주어야 하기 때문이다.

JDS vs CSR control divergence

JDS kernel의 for문에서 thread는 여전히 iteration 회수가 다르다. 그러나 sort했기 때문에 인접한 thread들의 iteration 회수가 비슷하다. 때문에 CSR보다는 thread utilization이 좀 더 좋다.

JDS vs CSR memory divergence

그러나 여전히 memory coalesce가 발생하지 않는다는 문제가 있다.

JDS with Transposition

JDS transposoe

CSR 대신 ELL format을 적용했을 때를 생각해 보면, ELL은 transpose했기 때문에 memory coalesce를 할 수 있었다. 같은 방식으로 JDS도 transpose해서 memory coalesce를 노려볼 수 있을 것이다.

예시 : JDS transposition

예시 : JDS-transposed

transpose 이후 JDS format

transposed JDS format

transpose하기 때문에 data[]와 col_index[]를 수정하고, jds_row_ptr 대신 jds_t_col_ptr를 사용해야 한다. jds_row_index는 original row index를 나타내는 것이므로 그대로 남겨둬야 할 것이다.

JDS : memory coalescing

transposed JDS memory coalescing

transpose하면 ELL과 같은 이유로 memory coalesce가 일어나기 때문에 더 효율적이게 된다.

언제 뭘 써야 할까?

무작위한 경우 : ELL

무작위한 경우

ELL이 제일 좋을 것이다. random하기 때문에 non-zero element도 균일하게 분포할 것이기 때문에 padding으로 인한 space overhead가 적을 것이다.

row의 편차가 큰 경우 : ELL/COO

row의 편차가 큰 경우

ELL/COO hybrid 방식이 제일 효율적일 것이다.

대부분 ELL 방식이 효율적이기 때문이다. 특히 긴 row들에 대해서는 COO로 처리하고, 나머지는 ELL 방식으로 처리하면 된다.

매우 sparse한 경우 : COO

매우 sparse한 경우

COO가 제일 좋은 방식일 것이다. space overhead가 제일 적기 때문이다.

삼각형인 경우 : JDS

삼각형인 경우

JDS가 제일 좋을 것이다. sparsity structure의 장점을 가져올 수 있기 때문이다.

banded matrix : ELL

banded matrix인 경우

ELL이 제일 효율적일 것이다. 각 row의 편차가 적기 때문이다.

이외 다른 format들

Diagonal(DIA) : strictly banded/diagonal인 경우 좋다.
- dense diagonal vector의 sparse set만 저장하고, 각 diagonal에 대해 main diagonal과의 offset을 저장하는 방식이다.
Packet(PTK) : row/col 재배열로 diagonal submatrix 구성
- 인접한 row access가 인접한 element에 접근하기 때문에 cache performance가 좋다.
Dictionary of Keys(DOK) : data의 row/col mapping 저장
- sparse matrix를 만들거나 query할 때 좋다.
Compressed Sparse Column(CSC)
Blocked CSR : block-sparse matrix에 유용하다.
이외, 이것들의 조합

Appendix: 고급 알고리즘을 위한 sparse matrix

graph를 sparse adjacency matrix로 표현하기도 한다.
binning technique(압축)는 data compaction을 위해 sparse matrix로 표현하기도 한다.

결론

SpMV는 어렵다.
다른 표현 방식은 다른 storage requirement를 가진다.
storage requirement는 sparsity pattern에 따라 다르다.
regularity와 efficiency는 tradeoff가 있다.
몇몇 표현 방식은 제일 좋은 처리 방식이 있다.
높은 compute-to-communication ratio를 얻기 힘들다.

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

[이종병렬컴퓨팅] Parallel Patterns : Scan

hyelie — Sun, 17 Dec 2023 00:14:43 +0900

이 글은 포스텍 성효진 교수님의 이종병렬컴퓨팅(CSED490C) 강의를 기반으로 재구성한 것입니다.

이 글에서는 parallel scan (prefix sum)과 koggle-stone algorithm(work-inefficient)와 brent-kung(work-efficient) algorithm을 살펴본다.

Scan

Inclusive Scan

어떤 binary associative operator ⊕와 array [x$_0$, x$_1$, ... , x$_{n-1}$]에 대해, [x$_0$, x$_0$ ⊕ x$_1$, ... , (x$_0$ ⊕ x$_1$ ⊕ ... ⊕ x$_{n-1}$]을 리턴하는 것이 inclusive scan이다.

scan은 radix sort, quick sort, 등등 다양한 병렬 알고리즘에 사용되며, 그냥 prefix sum이라고 생각하면 된다.

일반적으로 parallel한 버전을 만들 때, 각 thread는 출력 값을 어디에 쓸 지 알아야 한다. scan의 경우 각 thread는 다른 thread가 쓰는 값에 의존하기 때문에 이를 고려해서 효율적인 병렬 알고리즘을 만들어야 한다.

exclusive scan

어떤 binary associative operator ⊕와 array [x$_0$, x$_1$, ... , x$_{n-1}$]에 대해, [, x$_0$, ... , (x$_0$ ⊕ x$_1$ ⊕ ... ⊕ x$_{n-2}$]을 리턴하는 것이 exclusive scan이다.

inclusive scan과 조금 다르다. inclusive scan은 i번째 결과값이 i번째 element의 연산을 포함하는데, exclusive scan은 i번째 결과값이 i번째 element와의 연산을 포함하지 않는다.

예를 들어 inclusive scan은 처음 값이 0이 아니라 arr[0]인데, exclusive scan은 0부터 시작한다. 끝 값도 조금 다르다. inclusive scan의 arr[n-1]은 모든 배열의 합인데, exclusive scan의 arr[n-1]은 모든 배열의 합 - arr[n-1]이다.

exclusive scan을 사용하는 이유는 할당된 buffer의 시작 주소를 찾을 때와 같은 상황에서 사용한다. inclusive scan이나 exclusive scan은 변환하기가 매우 쉽다!

Inclusive Sequential Scan

input [x0, x1, x2, ...]에 대해 output [y0, y1, y2, ...]를 계산한다고 했을 때,

y$_0$ = x$_0$
y$_1$ = x$_0$ + x$_1$
y$_2$ = x$_0$ + x$_1$ + x$_2$
...
즉, y$_i$ = y$_{i-1}$ + x$_i$

따라서 prefix sum의 sequential 버전은 다음과 같다. 이 경우 시간복잡도는 O(n)이다.

y[0] = x[0]
for(int i = 1; i < len; i++){
    y[i] = y[i-1] + x[i];
}

Parallel Inclusive Scan

제일 쉬운 버전은, y element 하나를 계산하기 위해 필요한 모든 x 값들을 다 더하면 된다. 성능을 신경쓰지 않는다면 병렬 구성 자체는 쉽다. 그러나 이는 O(n$^2$)의 연산이 필요하기 때문에 다른 방법을 살펴본다.

Kogge-Stone Parallel Scan Algortihm

각 output element를 이전 element의 reduction으로 계산하는 방식이다. 이 때 이전에 계산했던 reduction partial sum은 output element를 계산할 때 사용된다. kogge-stone tree를 기반으로 한 계산 방식이다.

global memory에서 size n의 배열 T를 shared memory로 load한다. 이 때 n은 2의 k승이라고 하자.
pass를 logn번 반복하며, 각 pass에서 stride를 1부터 n/2까지 증가시킨다.
- 이 때 각 pass에서는 stride부터 n-1개의 thread가 active하다.
  - 예를 들면 pass 0에서는 stride가 1이다. 1부터 n-1까지의 thread가 active하다.
- 이후 간격이 stride인 pair element를 더한다.
shared memory의 결과로부터 global memory로 값을 쓴다.

kogge-stone parallel scan algorithm

위 예시는 size 8일 때 3번의 pass를 보여준다.

pass 1에서는 stride가 1이므로 인접한 값을 더한다.
pass 2에서는 stride가 2이므로 2칸 옆에 있는 값을 더한다.
pass 3에서는 stirde가 4이므로 4칸 옆에 있는 값을 더한다.

예시를 잘 보면 알겠지만, 최종 결과물에서 i번째 값은 0 ~ i번째 값이 모두 더해지는 것을 확인할 수 있다.

CUDA kernel

__global__ void koggeStoneScan(float* X, float* Y, int n) {
    __shared__ float XY[SECTION_SIZE];
    int i = blockIdx.x*blockDim.x + threadIdx.x;
    
    XY[threadIdx.x] = (i < n) ? X[i] : 0;

    float temp = 0.f;
    for (unsigned int stride = 1; stride < blockDim.x; stride *= 2) {
        __syncthreads(); // __syncthread();
        if (threadIdx.x >= stride) {
            temp = XY[threadIdx.x] + XY[threadIdx.x - stride];
        }
        __syncthreads(); // __syncthread();
        if (threadIdx.x >= stride)
            XY[threadIdx.x] = temp;
    }
    
    if (i < n)
        Y[i] = XY[threadIdx.x];
}

이 코드에서 temp 값을 사용하는 이유는, shared memory에 바로 값을 쓰면 input 값이 바뀌기 때문이다. 때문에 temp에 값을 쓰고 이후에 다시 shared memory에 값을 쓴다.

`__syncthread()`가 2군데에 있는데, 2번째에 있는 `__syncthread()`를 삭제하면 다른 thread가 같은 위치에 대해 동시에 쓸 수 있기 때문에 필요하다.

Double Buffering

위 코드에서는 2개의 bariier를 사용했는데, 이를 해결하기 위해 double buffering을 사용한다.

T0와 T1의 사본을 사용한다.
T0을 input으로, T1을 output으로 사용한다.
이후 각 pass에서 input/output의 역할을 바꾼다. 예를 들어 iteration 0에서는 T0가 input, T1이 output, iteration 2에서는 T1이 input, T0가 output이 되는 방식이다.

일반적으로 2개의 pointer를 사용해 source와 destination을 swap()하는 방식으로 사용한다. 이를 통해 위 코드에서 2번째 barrier를 없앨 수 있다.

Double-Buffered Kogge-Stone Parallel Scan

double buffered kogge stone parallel scan

이렇게 하면 오직 하나의 barrier만 사용하고, destination에 값을 쓰면 source의 값이 바뀌지 않음을 보장할 수 있다.

효율 분석

이 scan 방식은 logn번의 iteration을 수행한다. 각 iteration은 n-1번, n-2번, n-4번, ... n-n/2번의 add 연산을 수행한다. 따라서 총 add operation의 개수는 n * logn - (n-1) = O(nlogn)이다.

따라서, 이 방식은 work-inefficient한 방식이다. sequential 방식이 O(n)임을 생각해 보면 된다.

따라서, 낮은 work efficiency로 인해 resource가 가득 찼을 때 parallel 알고리즘이 sequential보다 더 느릴 수도 있다.

Brent-Kung Algorithm

이 방식은 work-efficient이다.

balanced tree 방식의 parallel algorithm pattern을 사용해 효율을 올린다. input data에 대해 balanced binary tree를 만들고, root부터 tree를 sweeping한다.

이 때 tree는 실제 data structure가 아니라 각 pass에서 thread가 작업을 결정할 때 사용하는 개념이다.

scan의 경우, 1) leaf에서 root까지 내려가면서 tree의 internel node들의 partial sum을 구성한다. 그러면 root는 모든 leaf node들의 합을 가지게 된다. 2) 이후 root부터 leaf까지 올라가면서 계산해 둔 partial sum을 사용해 계산하지 않은 scan 값을 계산하는 방식이다.

brent kung parallel scan - reduction step

위 그림처럼 leaf부터 root까지 올라가면서 internal node들의 partial sum을 계산한다.

위 예시에서는 x7이 모든 값의 합을 가지고 있게 된다. 반면 다른 값들은 아직 완벽한 값을 가지고 있지 않다.

brent kung parallel scan - post scan step

post scan step에서는 계산된 값들의 일부를 이용해 아직 계산되지 않은 위치의 값을 쉽게 계산할 수 있다.

예를 들어 왼쪽 그림에서 x0부터 x5까지 값을 구하고 싶다면 x0부터 x3까지의 합이 들어 있는 x3과, x4부터 x5까지의 합이 들어 있는 x5를 더하면 된다.

같은 방식으로 오른쪽 그림에서 x0부터 x2까지의 합을 구하고 싶다면 x0부터 x1까지의 합이 들어 있는 x1과 x2를 더하면 된다.

brent kung parallel scan - 요약

즉 위와 같은 방식으로 1) reduction을 통해 partial sum을 구하고 2) 이 값들을 사용해 다시 prefix sum을 계산한다.

CUDA Kernel

__global__
void brentKungScan(float* X, float* Y, int n) {
    __shared__ float XY[SECTION_SIZE];
    int i = 2*blockIdx.x*blockDim.x + threadIdx.x;
    if (i < n)
        XY[threadIdx.x] = X[i];
    if (i + blockDim.x < n)
        XY[threadIdx.x + blockDim.x] = X[i + blockDim.x];
    
    // reduction phase
    for (unsigned int stride = 1; stride <= blockDim.x; stride *= 2) {
        __syncthreads();
        int index = ((threadIdx.x + 1) * stride * 2) - 1;
        if (index < SECTION_SIZE) {
            XY[index] += XY[index - stride];
        }
    }
 
    // post scan phase
    for (unsigned int stride = SECTION_SIZE/4; stride > 0; stride /= 2) {
        __syncthreads();
        int index = ((threadIdx.x + 1) * stride * 2) - 1;
        if (index + stride < SECTION_SIZE) {
            XY[index + stride] += XY[index];
        }
    }
 
    __syncthreads();
    if (i < n)
        Y[i] = XY[threadIdx.x];
    if (i + blockDim.x < n)
        Y[i + blockDim.x] = XY[threadIdx.x + blockDim.x];
}

예시를 보자. 예를 들어 input size가 8일 때, reduction step에서, stride가 1이면 threadIdx.x + 1은 1, 2, 3, 4, 5, 6, 7, 8이 된다. 그러면 index는 1, 3, 5, 7, 9, 11, 13, 15가 된다. `XY[index] += XY[index - stride]`를 하므로 reduction이 올바르게 계산된다.

한편, 이 때 post scan step에서 bank conflict가 발생할 수도 있다.

효율 분석

parallel inclusive scan은 2 * logn번의 pass를 실행한다. logn번은 reduction에서, logn번은 post scan에서 사용한다.

각 iteratioon에서는 n/2, n/4, ... , 1번, 그리고 1, 2, ... , n/4, n/2번의 add operation을 수행한다. 따라서 add operation은 총 2(n-1)번 수행하므로 O(n)이다.

parallel 버전에서 추가된 add operation의 회수는 sequential 버전의 2배 이하이다. 이 경우, parallel하게 계산하는 경우 2배로 늘어난 연산으로 인한 overhead는 쉽게 극복할 수 있다.

Kogge-Stone vs Brent-Kung

brent-kung은 kogge-stone과 비교했을 때, 절반의 thread를 사용한다. brent-kung의 경우 각 thread는 2개의 element를 shared memory로 load하기 때문이며, reduction이기 때문에 필요한 thread의 개수가 훨씬 적다.

brent-kung은 kogge-stone과 비교했을 때 pass의 개수가 2배이다.

즉, brent-kung의 경우 1/2배의 thread, 반면 2배의 pass -> n/2 * 2logn = nlogn이므로, GPU에서 효율성은 비슷하다. 그러나 pass의 개수가 더 많은데, 각 pass의 실행은 이전 pass의 결과에 dependent하기 때문에 더 많은 barrier가 필요하므로, 더 많은 synchronization overhead를 발생시킨다. 때문에 GPU의 block 내부의 parallel scan은 kogge-stone이 더 좋다.

일반화

매우 큰 input에서 hierarchical parallel scan

매우 큰 reduction에 대해, 각각을 section으로 나누고, section의 결과를 다시 reduction 했던 것처럼, scan 또한 같은 방식으로 진행한다. section의 결과를 auxiliary array에 넣고, 그 array를 다시 scan한다. 이후 최종 결과를 얻을 수 있다.

global memory content 사용하기

하나의 thread block에 속한 shared memory나 register 값은 다른 thread block에 보이지 않는다. 때문에 data를 visible하게 만들기 위해서는 data가 global memory에 쓰여야 한다.

그러나, global memory에 써진 값들은 memory fense로 인해 보이지 않는데, kernel 실행이 종료되었을 때 fense가 사라진다. 따라서 한 kernel의 실행이 끝났을 때 다른 kernel을 실행해야 한다. 그래야만 종료된 kernel이 global memory에 쓴 값이 다른 thread block에서 보인다.

임의 길이 input에 대해 작업하기

`2 * blockDim.x`개의 element를 처리할 수 있는 scan kernel을 만든다. kogge-stone의 경우, 각 section이 blockDim.x개의 element가 하나의 block에 할당되게 만든다.
각 block은 sum[blockIdx.x]에 값을 쓴다.
sum array에 대해 parallel scan을 다시 실행한다. 만약 block size보다 sum 배열의 크기가 훨씬 크다면 sum을 나눠야 할 것이다.
scan된 sum 배열의 값을 해당 section의 element에 더한다.

CUDA kernel : exclusive scan

kogge-stone kernel의 경우,

thread block 0에서 thread 0은 shared memory에 값을 올릴 때 `arr[0]`이 아니라 `0`을 올리게 한다. 다른 모든 thread들은 `X[threadIdx.x - 1]`을 `XY[threadIdx.x]`에 쓴다.

다른 모든 thread block들은 `X[(blockIdx.x * blockDim.x) + threadIdx.x - 1]`을 `XY[threadIdx.x]`에 쓴다.

brent-kung의 경우도 매우 유사하지만, 각 thread가 2개의 element를 load할 수 있어야 한다. 제일 앞의 0이 load되어야 하고, 다른 모든 element들은 단 한 칸만 shift되어야 한다.

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

[이종병렬컴퓨팅] Parallel Patterns : Reduction

hyelie — Sat, 16 Dec 2023 03:35:08 +0900

이 글은 포스텍 성효진 교수님의 이종병렬컴퓨팅(CSED490C) 강의를 기반으로 재구성한 것입니다.

이 글에서는 parallel reduction pattern을 살펴본다.

parallel reduction pattern은 제일 많이 사용되는 패턴 중 하나이다. 추가로, control divergence와 thread utilization 등의 작업 효율성, shared memory bank conflict 등의 resource 효율성을 살펴본다.

Reduction

Reduction은 input value를 하나의 값으로 요약하는 연산이다. 예를 들어 max(), min(), sum() 등등이 있다.

기본적으로 associative(결합), commutative(교환)여야 하며, 잘 정의된 identity value가 있어야 한다.

identity value는 항등원을 의미한다. sum의 경우 0, product의 경우 1, 등등이다.

Partition and Summarize

큰 input data set을 처리할 때 자주 사용되는 전략이다. 순서는 다음과 같다.

data set의 element를 처리할 때 특별한 순서가 없으므로, input data set을 작은 chunk로 분할한다.
이후 각 thread가 chunk를 담당한다.
각 chunk로부터 reduction 결과를 tree를 만들어 최종 결과를 만든다.

Reduction은 다른 기술들도 가능하게 만든다.

몇몇 연산의 경우, 병렬 변환 이후 reduction이 필요하다.

예를 들어 지난 포스팅에서 살펴봤던 histogram의 privatization의 경우, 각 thread block에서 private copy를 만들었다. 이후 private copy를 사용해 final copy를 만들 때 reduction tree를 사용한다.

Sequential Reduction

sequential reduction은 다음과 같이 실행한다.

reduction operation의 초기값을 identity value로 설정한다.
- 예를 들어 max의 경우 제일 작은 값을(INT_MIN), min의 경우 제일 큰 값을(INT_MAX), sum의 경우 0, product의 경우 1로 설정하는 것이 그것이다.
input을 순회하면서 n개의 입력에 대해 n번 reduction 연산을 수행한다.

이 경우 각 element는 오직 1번만 방문하므로 O(n) 알고리즘이다.

Parallel Reduction Tree

parallel reduction tree

반면 parallel reduction tree는 각 reduction의 결과를 tree로 만들어 합치는 방법이다.

Reduction Tree 알고리즘 분석

n개의 입력 값이 있을 때, binary reduction을 사용하는 reduction tree의 경우, 첫 번째 pass에서는 n/2번, 두 번째 pass에서는 n/4번, ... 마지막 pass에서는 1번의 연산을 수행한다. 즉 (1/2 + 1/4 + 1/8 + ... + 1/n) * n = (1 - 1/n) * n = n - 1번의 연산을 수행하게 된다.

pass는 총 logn개가 있게 된다.

따라서 평균 parallelism은 $\frac{n-1}{logn}$이다.

예를 들어 n이 1,000,000일 때 20개의 pass가 생긴다. 이 때 평균 parallelism은 50,000인 반면 첫 번째 pass에서는 500,000번의 연산이 필요하다. 이처럼 이 방식은 work-efficient한 방식이지 resource-efficient한 방식이 아니다.

GPU에서 Parallel Reduction

GPU에서 parallel reduction은 다음과 같은 과정을 거쳐 수행된다.

각 thread block에서 tree-based 알고리즘을 사용한다.
- 이 때 각 thread block에서는 shared memory를 사용해 in-place reduction을 수행한다고 가정하자. (모든 thread는 병렬로 수행되기 때문) 즉, global memory에 있는 값을 shared memory에 load하고, thread block에서 reduction을 수행한다고 가정하자는 것이다.
그러면 original data set은 global memory에 존재하게 되고, thread block의 shared memory는 일부 값만 가진다.
- 예를 들어 이 때 sum()을 실행한다고 했을 때, 각 pass에서 partial sum을 계산하고, 그 결과는 index 0에 저장될 것이다.(이 값은 최종 결과값에 반영될 것이다) 이를 통해 global memory access 회수를 줄일 수 있다.
매우 큰 값을 처리하기 위해서는 여러 개의 thread block을 사용해야 한다. 이는 GPU를 BUSY한 상태로 유지하는 것에서도 의미가 있게 되고, 각 thread block은 input data set의 일부 값을 처리하게 된다.

Reduction #1 : Interleaved Addressing

제일 기본적인 버전으로, element to thread direct mapping라고도 불린다.

interleaved addressing #1

다음과 같은 단계로 실행된다.

각 thread는 shared memory에 값을 할당한다. (모든 thread가 shared memory에 data를 올리는 과정에 참여한다.)
각 pass에서 2개의 값을 더하며, pass마다 stride를 2배로 늘린다.
- 첫 번째 iteration에서는 홀수 thread들이 자신에 해당하는 값과 인접한 값에 대해 reduction을 수행한다.
동시에 각 pass마다 thread 개수를 절반으로 감소시켜가면서 재귀적으로 반복한다.

즉, n개의 element를 처리하기 위해 logn의 pass와 n개의 thread가 필요하다.

예를 들어 pass 1에서는 0 2 4 6 ...의 thread만, pass 2에서는 0 4 8 12, ...의 thread만, pass 3에서는 0 8 16, ...의 thread만 계산에 참가한다.

CUDA Kernel

각 thread는 자신이 담당하는 부분에 대한 책임을 가진다.
각 pass가 끝나면 절반의 thread는 더 이상 필요가 없어진다.
각 pass에서, 2개의 값을 더하는데, 하나는 그 thread가 생성한 값이고, 다른 하나는 다른 thread가 처리한 값인데, 이 때 다른 하나의 입력값이 점점 더 멀리서 온다.
- pass 0에서는 바로 옆에서 오지만 pass 1에서는 2칸, pass 2에서는 4칸, pass 3에서는 8칸, ... 이렇게 입력값이 멀리서 온다.

__global__ reduction(int *input, int *results) {
    unsigned int t = threadIdx.x;
    unsigned int i = blockIdx.x * blockDim.x + threaddIdx.x;

    __shared__ float partialSum[BLOCK_SIZE]; // BLOCK_SIZE == blockDim.x
    partialSum[t] = input[i]; // 각 thread가 하나의 element를 shared memory에 load한다.

    for (unsigned int stride = 1; stride <= blockDim.x; stride *= 2) {
        __syncthreads();
        if (t % (2 * stride) == 0){
            partialSum[t] += partialSum[t + stride];
        }
    }

    // 여기에 __syncthread()를 추가하지 않는 이유?
    // thread 0이 결과를 적는다.
    if (t == 0) {
        // note that the result is per-block, not per-thread
        results[blockIdx.x] = partialSum[0];
    }
}

각 thread block는 blockDim.x개의 input element를 처리하고, 각 thread는 1개의 element를 shared memory에 올린다.
for문 내의 `__syncthread()`가 필요한 이유는 이전 pass의 partial sum이 모두 계산되어 있어야 하기 때문이다.
마지막 loop가 끝난 후 `__syncthread()`를 추가하지 않는 이유는, `if(t == 0)`으로 왔다는 것은 이미 partialSum을 모두 계산한 것이기 때문이다.

그리고 위 코드의 제일 마지막에 있는 `results[blockIdx.x] = partialSum[0]`의 경우, 모든 input에 대한 결과값이 아니라 해당 thread block의 결과이다. 최종 결과값을 얻기 위해서는 reduction이 다시 한 번 수행되어야 한다.

Observation

각 iteration에서, 각각의 warp에 대해 2개의 control flow가 순차적으로 발생한다. 하나는 for문 내의 if문에 걸려서 addition을 수행하는 thread들, 나머지는 그렇지 않은 thread들이다. 그렇지만 아무것도 하지 않는 thread들도 여전히 resource를 소모하고 있다. (idling)

첫 번째 pass가 끝나면 절반의 thread가 필요없게 된다. 즉, 모든 홀수 index를 가지는 thread는 첫 번째 pass가 끝난 이후 필요없게 된다.

예를 들어 n이 1024인 경우, 5번째 pass가 끝나면 전체 warp의 각 block은 for문 내의 if문을 실패하게 되어 resource utilization이 별로다. 몇몇 warp는 살아있을 수 있지만, 해당 warp에서 오직 하나의 thread만 if문을 성공하므로 divergence가 발생한다.

예를 들어 thread block size가 32인 경우, 5번째 pass 이후에는 active thread의 간격이 64가 되는데, 그러면 thread block 0의 첫 번째 thread는 active, thread block 1의 모든 thread는 inactive, 이후 thread block 2의 첫 번째 thread가 active, ... 이렇게 반복된다. 때문에 warp의 일부 thread block의 모든 thread는 idling하게 된다.

Reduction #2 : Interleaved Addressing 2

interleaved addressing #2

이 방식은 n개의 element에 대해 logn개의 pass를 사용하되, n/2개의 thread만 사용하는 방식이다.

각 thread block은 2 * blockDim.x개의 input element를 처리하고, 2개의 element를 shared memory에 load한다. 위 그림에는 바로 옆에 있는 값을 shared memory로 load하는 것으로 보이는데, 실제로는 thread 하나는 threadIdx.x와 threadIdx.x + BLOCK_SIZE 2개의 값을 shared memory로 load하는 방식이다. 이렇게 하면 memory coalescing을 통해 조금이나마 더 효율적으로 작동한다.

그 결과 divergence를 조금 줄일 수 있다.

CUDA Kernel

__global__ reduction(int *input, int *results) {
    __shared__ float partialSum[2 * BLOCK_SIZE]; // BLOCK_SIZE == blockDim.x
    
    // load two elements
    unsigned in t = threadIdx.x;
    unsigned int start = (2 * BLOCK_SIZE) * blockIdx.x;
    partialSum[t] = input[start + t];
    partialSum[BLOCK_SIZE + t] = input[start + BLOCK_SIZE + t];

    for (unsigned int stride = 1; stride <= blockDim.x; stride *= 2) {
        __syncthreads();
        if (t % stride == 0){
            partialSum[2 * t] += partialSum[2 * t + stride];
        }
    }

    // thread 0이 결과를 적는다.
    if (t == 0)
    {
        // note that the result is per-block, not per-thread
        results[blockIdx.x] = partialSum[0];
    }
}

#1과의 차이점은 for문 내의 if문이다.

한편 이 경우 2-way bank collision이 발생한다.

Reduction #3 : Non-Divergent Reduction

interleaved addressing 3

#1 버전과 달라진 점은 thread id가 순서대로 줄어든다는 것이다. 이를 통해 하나의 warp에 있는 thread를 계속 살릴 수 있게 되므로 divergent가 줄어든다.

CUDA Kernel

reduction #1에서 inner loop의 divergent branch를 없애고, strided index와 non-divergent branch를 사용한다.

for (unsigned int stride = 1; stride <= blockDim.x; stride *= 2) {
    __syncthreads();
    int index = t * (2 * stride);
    if (index < blockDim.x) {
        partialSum[index] += partialSum[index + stride];
    }
}

단, 이 경우에는 shared memory bank conflict가 발생한다. 첫 번째는 2-way, 두 번째는 4-way, ... 이렇게 bank conflict가 계속 늘어난다.

thread index의 사용이 문제다

divergence를 없애기 위해 index를 바꿔서 쓸 수도 있다. 물론 이 경우는 commutative나 associative여야만 한다.

#3 버전의 경우에는 active thread가 연속적이지만 접근하는 data가 멀리 있기 때문에 bank conflict가 발생한다는 점도 문제였다.

더 좋은 전략은 항상 partialSum[] 배열의 첫 번째 위치로만 partial sum을 합치는 것이다. 이를 통해 active thread를 연속적으로 유지할 수 있다.

Reduction #4 : Sequential Addressing

sequential addressing

#3까지의 구현은 stride가 점점 더 커지는 방식이었다. 그러나 sequential addressing의 경우에는 stride가 점점 더 줄어든다. 이것이 더 좋은 이유는 bank conflict가 없어지기 때문이다.

16개의 thread가 있을 때 예시

CUDA Kernel

그러면 코드는 아래와 같다. 바뀐 점은 stride의 초기값, 바뀌는 값, 그리고 partialSum의 index이다.

// before : #1 interleaved addressing
for (unsigned int stride = 1; stride <= blockDim.x; stride *= 2) {
    __syncthreads();
    if (t % (2 * stride) == 0){
        partialSum[t] += partialSum[t + stride];
    }
}

// before : #3 non-divergent reduction
for (unsigned int stride = 1; stride <= blockDim.x; stride *= 2) {
    __syncthreads();
    int index = t * (2 * stride);
    if (index < blockDim.x) {
        partialSum[index] += partialSum[index + stride];
    }
}

// after : #4 sequential addressing
for (unsigned int stride = BLOCK_SIZE / 2; stride >= 1; stride /= 2) {
    __syncthreads();
    if (t < stride){
        partialSum[t] += partialSum[t + stride];
    }
}

before의 경우에는 bank conflict가 발생하지만 after의 경우에는 그렇지 않는다. 그리고 stride가 *2에서 /2로 바뀌었다. 또한 if문의 condition이 달라진다.

분석

예를 들어 thread block size가 32일 때 1024개의 thread가 있는 thread block의 경우, 각 thread block은 1024개의 element를 shared memory에 올린다.

이 때 처음 5개 group에 대해서는 divergence가 존재하지 않는다! 512, 256, 128, 64, 32개의 연속된 32개의 thread들이 각 pass에서 계속 active하기 때문에, warp 내의 모든 thread가 active거나 모두 inactive이기 때문이다.

반면, 이후 16, 8, 4, 2, 1 5개 step에 대해서는 divergence가 발생한다.

다시 Global하게 돌아가면 : Segmented Reduction

segmented reduction

kernel 실행이 끝났을 때, 각 thread block의 오직 단 하나의 thread, thread 0만이 partialSum[0]에 있는 값을 global result의 blockIdx.x에 작성한다. 이후 이 global result에 다시 한 번 reduction을 진행해야 한다.

만약 input vector size가 매우 큰 경우, host는 반복적으로 kernel code를 실행시켜야 한다.
- global memory에 저장된 처음의 reduction 결과도 여전히 클 때, 그 reduction 결과에 대해 반복적으로 reduction을 진행한다는 말이다.
- 또는, global sum을 만들기 위해서는 atomic operation을 사용할 수도 있다. 단 이 경우에는 reduction 결과가 atomicAdd를 사용해도 될 만큼 충분히 작아야 할 것이다.
만약 input vector size가 별로 크지 않은 경우, data를 kernel로 전송하고 다시 불러오는 간단한 과정만 거쳐도 된다.

Parallel Algorithm 분석

Parallel Algorithm Overhead

parallel하게 reduction을 실행했을 때 overhead는 1) shared memory에 값을 올리는 것과 2) reduction을 실행하는 for문에 존재하는 barrier(__syncthread())에 대한 overhead가 있다.

또한, asymtotic하게 연산의 개수는 O(n)이지만, 각 연산은 주소 계산이나 중간 결과값 조작 등 복잡한 로직을 포함하고 있다.

이러한 점 때문에 만약 parallel code가 single thread hardware에서 실행된다면 sequential algorithm보다 훨씬 느릴 것이다.

Parallel Reduction Complexity

logn번의 parallel pass에 대해, 각 pass S는 $\frac{n}{2^S}$번의 독립적인 연산을 수행한다. 즉, step complexity(pass의 개수)는 O(logn)이다. 그리고 각 pass에서는 O(n)의 연산이 수행된다.

물리적으로 병렬로 동작하는 P개의 thread에 대해, time complexity는 O($\frac{n}{P}$ + logn)이다.

$\frac{n}{P}$ 부분은 전체 작업량을 processor의 개수로 나눈 부분이다.
logn 부분은 step complexity 부분이며, 해당 부분은 parallelize될 수 없으므로 logn이다.
한편, thread block에서 n = P이므로 O(logn)이다.

parallel algorithm의 cost는 processor의 개수 * time complexity이다. 즉 O(n) thread * O(logn) time complexity = O(nlogn)이다. 즉, cost-inefficient이다. (sequential의 경우 O(n)라는 것을 기억하자.)

즉, sequential한 버전보다 parallelize에 추가적인 resource가 필요해 더 많은 resource를 사용하고, 더 많은 시간이 걸린다.

Algorithm Cascading

sequential과 parallel을 결합할 수 있다.

지금까지 살폈던예시에서는 각 thread가 binary reduction을 수행하는 예시를 보았지만, 더 효율적인 병렬화를 위해 각 thread가 2개 이상의 element를 shared memory에 load하고 합칠 수 있다. 같은 방식으로 binary reduction 대신 n-way reduction을 수행한다.

이것이 cascading인데, 각 thread는 sequential하게 실행하는 element의 개수가 늘어나므로 thread 자체의 실행 시간은 더 길어지지만 pass의 개수가 줄어든다. 전체적으로 시간이 훨씬 더 많이 줄어드므로, 더 효율적이게 된다.

단계로 표현하면 다음과 같다.

각 thread는 sequential하게 O(logn)개의 element를 합친다.
그러면 O($\frac{n}{logn}$)개의 thread를 할당했을 때, O($\frac{n}{logn}$)개의 thread는 O(logn) pass에 대해 parallelize하게 실행된다.
따라서 cost = O($\frac{n}{logn}$ * logn) = O(n), 즉 cost-efficient하다.
- thread 개수가 $\frac{n}{logn}$개, 각 thread는 logn개만큼 연산을 수행하기 때문.

이 경우 parallelism과 overhead이 균형을 이루며, 실제로는 상당한 속도 향상이 이뤄진다.

추가적인 최적화 #5 : Unroll Loops

reduction은 낮은 arithmetic intensity를 가지고 있으므로, bandwidth를 포화할 수 있다.(계산에 필요한 연산량보다 I/O를 더 많이 쓴다는 뜻이다) 따라서 bottleneck은 instruction overhead일 가능성이 높다. 즉 address array arithmetic과 loop overhead이다.

그러면 loop를 없애면 된다!

reduction이 진행될 때마다 active thread의 개수가 감소한다. 특히 stride <= 32일 때는 오직 하나의 warp의 thread 중 몇 개만 active하다. 이 때 instruction은 warp 내에서 SIMD 방식으로 동기화되고, lock-step에서 실행된다. 즉, stride <= 32일 때 warp끼리 barrier를 사용할 필요가 없고, 같은 이유로 `if(t < stride)`도 필요없다.

그러면 마지막 6개의 iteration(32, 16, 8, 4, 2, 1)에 대해서는 loop를 풀면 더 효율적일 것이다.

CUDA Kernel

// for stride > 32
for (unsigned int stride = BLOCK_SIZE / 2; stride > 32; stride /= 2) {
    __syncthreads();
    if (t < stride)
        partialSum[t] += partialSum[t + stride];
}

// loop unrolling for stride <= 32
if (t < 32) {
    partialSum[t] += partialSum[t + 32];
    partialSum[t] += partialSum[t + 16];
    partialSum[t] += partialSum[t + 8];
    partialSum[t] += partialSum[t + 4];
    partialSum[t] += partialSum[t + 2];
    partialSum[t] += partialSum[t + 1];
}

이 방식은 마지막 warp 뿐만 아니라 모든 warp에서 필요 없는 작업을 없앤다. unrolling하지 않는 경우, 모든 warp에서 for loop와 if문을 반복적으로 실행한다.

실행 시간 분석

실행 결과

각 버전에 대해 실행 결과는 위와 같다.

kernel 1 : #1 버전
kernel 2 : #3 버전
kernel 3 : #4 버전
kernel 4 : 이 글에서 다루지 않음
kernel 5 : #5 버전

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

[이종병렬컴퓨팅] Parallel Patterns : Histogram

hyelie — Sat, 16 Dec 2023 00:47:23 +0900

이 글은 포스텍 성효진 교수님의 이종병렬컴퓨팅(CSED490C) 강의를 기반으로 재구성한 것입니다.

이 글에서는 다음과 같은 내용들을 살펴본다.

parallel한 histogram 계산 패턴
privatization

Histogram

histogram은 큰 data set에서 특징과 패턴을 추출하는 방법으로, 기본적으로는 dataset의 각 bin 요소에 대해 count를 증가하는 방법이다. 제일 기본적인 병렬 알고리즘은 아래와 같다.

input을 section으로 나누기
각 thread는 하나의 section을 담당한다.
각 thread는 section에서 순회한다.
각 letter에 대해 bin counter를 증가시킨다.

효율적인 memory 접근을 위한 partitioning 방법

section을 나누는 방법이 memory access 효율에 영향을 미친다.

partitining 방법 2가지

위 그림에서 각 숫자는 thread가 어떤 element에 어떤 thread가 접근하는지를 나타낸다.

왼쪽 그림은 sectioned partitioning인데, 이 경우 각 thread의 memory access가 coalesce되지 않기 때문에 효율적이지 않다. 각 thread의 첫 실행에서 thread 1은 index 0에, thread 1은 index 5에, thread 2는 index 9에, ... 이런 방식으로 접근하기 때문에 memory access가 coalesce된다.

오른쪽 그림은 interleaved partitioning인데, 이 경우 모든 thread가 연속된 section의 element에 접근하기 때문에 memory access가 coalesce되어 더 효율적이다.

예시 : sectioned partitioning

sectioned partitioning 예시

위 그림은 `PROGRAMMING MASSIVEL`이라는 글자를 5개씩 section으로 나누고, 4개의 thread가 parallel하게 histogram을 count하는 것을 보여준다.

왼쪽 / 오른쪽 그림에서 각 thread는 각 section의 첫 번째 글자에 해당하는 bin counter를 1 증가시킨다.

오른쪽 그림은 2개의 thread가 같은 bin counter에 접근할 때 발생하는 문제를 보여준다. 이 경우, 두 thread가 접근하는 bin counter 모두 정상적으로 증가해야 한다.

예시 : interleaved partitioning

interleaved partitioning 예시

위 그림은 interleaved partitioning 예시이다. sectioned partitioning과 다르게 하나의 iteration에서 모든 thread가 비슷한 memory에 있는 값을 참조하기 때문에 memory coalescing이 일어나며, 따라서 memory bandwidth를 더 효율적으로 사용할 수 있다.

마찬가지로 오른쪽 그림의 경우 2개의 thread가 같은 bin counter에 접근할 때 문제점을 보여준다. 이를 해결하기 위해 read-modify-write operation을 사용한다.

Atomic Operation (Read-Modify-Write)

동일한 memory 위치에 대해 2개 이상의 thread가 접근할 때 data race가 발생한다. 이 경우 값을 쓰는 과정이 non-deterministic하기 때문에 결과가 어떻게 될지 보장할 수 없다. 이를 막기 위해 `atomicAdd()`를 사용한다.

이를 적용한 CUDA histogram 코드는 다음과 같다. (interleaved partitioning 버전이다)

__global__ void histo_kernel(unsigned char *buffer, long size, unsigned int *histo) {
    int i = blockIdx.x * blockDim.x + threadIdx.x;
    int stride = blockDim.x; // stride는 thread의 총 개수이다.
    
    // 모든 thread는 blockDim.x * gridDim.x개의 연속적인 element를 처리한다.
    while (i < size) {
        atomicAdd(&(histo[buffer[i]]), 1);
        i += stride;
    }
}

Atomic Operation 성능

atomic operation 성능

DRAM에서 atomic operation의 경우, 각 read-modify-write 연산은 2번의 full memory access delay(read latency, write latency)를 가진다. 이는 하나의 thread가 atomic하게 특정 위치에 값을 썼을 때 다른 모든 thread들이 해당 위치의 변경된 값을 확인할 수 있어야 하기 때문이다.

또한 동일한 memory location에 대한 모든 atomic operation은 serialize된다. 하나의 thread가 atomic operation으로 하나의 memory에 접근하고 있을 때, 다른 thread는 해당 위치에 접근할 수 없다는 말이다.

Latency가 Throughput을 결정한다.

같은 DRAM 위치에 대한 atomic operation throughput은 프로그램이 atomic operation을 실행하는 속도와 동일하다. 따라서 특정 위치에 대한 atomic operation의 비율은 read-modify-write 연산의 latency에 의해 한정된다. 일반적으로 global memory의 경우 1000 cycle보다 더 크다.

즉, 많은 thread가 같은 memory location에 대해 atomic operation을 수행해 contention이 발생한다면, memory throughput은 최대 bandwidth의 1/1000배 이하로 감소한다.

Hardware Improvement

L2 cache에서 atomic operation 수행

hardware improvement : L2 cache

atomic operation을 L2 cache에서 수행하는 것이다. 이 경우 latency가 더 줄어들게 된다. 그렇지만 여전히 serialize된다.

Shared Memory에서 atomic operation 수행

hardware improvement : shared memory

atomic operation을 shared memory에서 수행하면 latency가 매우 줄어든다. 반면 각 work group에 private하게 만들어지므로 코드를 좀 더 짜야 한다는 단점이 있다.

Privatization

privatization

여러 개의 thread block이 하나의 memory에 접근하는 경우, contention과 serialization이 계속 발생한다. 이를 막기 위해 1) 각 thread block은 private copy를 가지고, 2) 이들을 통합해 final copy을 만드는 것이 privatization이다. 이를 통해 contention과 serialization을 줄일 수 있다.

장단점

overhead : privatization의 경우 추가적인 overhead는 private copy를 만드는 것, 그리고 private copy를 합쳐 final copy를 만드는 것이 overhead이다.
장점 : final copy의 접근에 대한 contention과 serialization을 훨씬 줄일 수 있기 때문에 전체적인 성능은 약 10배 이상 향상된다.

Histogram의 Shared Memory Atomic Operation

하나의 thread block에는 여러 개의 thread가 있고, shared memory는 이들 사이에서 공유되는 memory이다.

이 때 shared memory에서 atomic operation을 수행할 때 DRAM보다 100배, L2 cache보다는 약 10배 정도 더 높은 throughput을 뽑아낼 수 있다. 또한 shared memory variable에 접근할 수 있는 것은 같은 thread block의 thread뿐이기 때문 에 contention도 더 적다.

Privatization과 Shared Memory Atomic

shared memory에서 atomic operation을 적용해 privatization을 구현한 CUDA histogram 코드는 다음과 같다.

__global__ void histo_kernel(unsigned char *buffer, long size, unsigned int *histo) {
    int tid = threadIdx.x;
    __shared__ unsigned int histo_private[256]; // number of bins = 256
    if (tid < 256)
        histo_private[tid] = 0;
    __syncthreads(); // 초기화가 끝날 때까지 대기한다.

    int i = blockIdx.x * blockDim.x + threadIdx.x;
    int stride = blockDim.x; // stirde는 thread의 개수
    while (i < size) {
        atomicAdd ( &(private_histo[buffer[i]), 1); // shared memory에 접근
        i += stride;
    }
    __syncthreads(); // thread block의 모든 thread의 작업이 끝날 때까지 대기한다.

    // 이후 final copy에 추가한다.
    if (tid < 256){
        atomicAdd( &(histo[tid]), private_histo[tid] );
    }
}

Privatization에 대한 추가 정보

privatization은 병렬화하기 위해 자주 사용되는 강력한 기술이다.
이 때 privatization을 적용하기 위해, operation은 associative(결합)하고 commutative(교환) 가능해야 한다. 그래야만 private copy를 합쳐도 결과가 동일하기 때문이다.
- histogram add operation의 경우 associative & commutative하기 때문에 privatization을 적용할 수 있다. 만약 그렇지 않은 연산에 대해서는 privatization을 적용할 수 없다.
또한, shared memory의 크기는 작기 때문에 private histogram의 크기는 작아야만 한다.
- 만약 histogram이 privatize하기에 너무 크다면, output histogram을 부분적으로 privatize하고, range test를 사용해 global/shared memory로 이동하면 된다.
shared atomics는, 일반적으로 global atomics보다 2배 이상 더 빠르다.

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

[RAFT] RAFT consensus algorithm specification

hyelie — Tue, 31 Oct 2023 01:01:47 +0900

중간고사가 끝난 이후부터는 RAFT 알고리즘을 maude를 사용해 formal modeling을 진행할 것입니다. 그에 앞서 어떠한 specification을 모델링할지 결정해야 합니다.

따라서, 이 글에서는 RAFT consensus algorithm에 대해 간단히 소개하고 modeling하고자 하는 specification을 작성하고자 합니다.

RAFT consensus algorithm

RAFT consensus algorithm은 모든 node가 동일한 상태를 유지하며, tolerance를 보장하기 위해 고안된 알고리즘이다. 때문에 일부 node에 문제가 생겨도 전체 system이 잘 동작해야만 한다.

구성

state의 변화. 출처 : In Search of an Understandable Consensus Algorithm

모든 node는 아래 3가지 상태 중 한 가지를 가진다.

cluster란 여러 subsystem이 연결되어 하나의 system처럼 동작하는 것을 말한다.

leader : cluster를 대표하는 상태로, client가 cluster로 보낸 모든 메시지의 수신, 전송, 응답을 모두 맡는다. 주기적으로 모든 follower에게 heartbeat를 보낸다.
follower : leader가 존재할 경우, 모든 node는 이 상태를 가진다. Leader로부터 받은 메시지를 처리한다.
candidate : leader가 존재하지 않는 경우, 새 leader가 되기 전 상태이다. heartbeat를 받지 못한 follower가 candidate가 된다.

RAFT consensus algorithm은 cluster의 모든 node가 최신 상태로 동기화하는 방식으로 replicated state machine을 구현한다.

Flow

아래와 같은 과정을 통해 cluster 전체가 최신 상태로 동기화된다.

client가 leader에게 특정 명령을 보낸다.
- 좀 더 구체적으로는 client가 leader가 아닌 상태라면, 해당 요청을 leader로 redirect한다.
leader가 모든 메시지에 대한 log를 생성해 local에 저장한 후, 모든 follower에게 복제해 전달한다. 해당 메시지를 수신한 follower는 leader에게 응답을 보낸다.
leader가 수신한 `정상 응답 수`가 전체 노드 개수 중 과반수 이상이라면, log를 통해 cluster의 모든 node가 해당 명령을 수행할 때까지 log를 재전송하며 동시에 client에게 명령 수행 결과를 리턴한다.
- 때문에 cluster의 모든 node가 같은 명령이 수행되었음을 보장할 수 있다.
문제가 발생해 명령을 처리하지 못한 follower들은 복구된 후 cluster와 연결되었을 때 leader로부터 그간의 log를 모두 받아 다시 수행한다.

Leader Election Flow

leader는 다수결을 통해 선출된다. flow는 아래와 같다.

각 node의 election timeout 내에 heartbeat가 도착하지 않았다면 아래 단계를 진행한다.
- leader는 heartbeat를 모든 node에게 전송한다. 만약 election timeout 내에 leader로부터 heartbeat가 오지 않은 경우 leader에 문제가 생겼다고 간주하고, candidate로 상태를 바꾼다.
election timeout이 끝난 follower node들은 candidate로 바뀌고, 새로운 term `newTerm`이 시작된다. 해당 node는 자신에게 한 표를 행사한 후 다른 node들에게 `투표 요청 메시지`를 보낸다.
이 메시지를 받은 node가 `newTerm`에서 투표한 적이 없다면 해당 `투표 요청 메시지`를 보낸 candidate node에게 `투표 응답 메시지`를 보낸 후 자신의 election timeout을 초기화한다.
- 때문에 현재 투표 중인 candidate 이외에 다른 candidate의 생성을 막을 수 있다.
전체 node 중 과반수에 해당하는 `투표 응답 메시지`를 받은 node는 `newTerm`의 새로운 leader가 된다. 다른 candidate들은 follwer가 된다.

여기서 사용된 용어는 아래와 같은 의미를 가지고 있다.

term : 새로운 election이 시작된 시점부터 끝날 때 까지의 시간을 식별하는 값이다.
election timeout : follower node가 candidate node로 될 때까지 기다리는 시간이다. 이 값은 모든 node별로 다른 값이 주어진다. 또한 매 term마다 모든 node들의 election timeout은 무작위로 재조정된다.
heartbeat : leader가 모든 follower에게 주기적으로 보내는 메시지이다. leader의 상태 확인을 위해서만 사용한다.

Leader에 문제가 생긴 경우

위 flow에 따르면, heartbeat를 수신하지 못한 채 election timeout이 끝난 node들은 candidate가 된다. 이후 `투표 요청 메시지`를 모든 node에게 보낸다고 했다.

만약 leader가 해당 메시지를 수신한 경우, `투표 요청 메시지` 내에 있는 `term 번호`를 확인하고, 자신이 가지고 있는 것 보다 크다면 follower로 전환한다.

과반을 얻지 못한 경우 - 동점자가 만들어진 경우

과반을 얻지 못한 경우, 해당 term을 즉시 종료하고 새로운 term을 시작함과 동시에 재선거를 시작한다. 동점자가 나타나는 현상을 막기 위해 모든 term에서 모든 node들의 election timeout은 다르게 재조정된다.

과반을 얻지 못한 경우 - 과반을 얻을 수 없는 경우

문제가 발생한 node가 너무 많다면 어떠한 경우에도 과반수 이상의 표를 얻을 수 없다. RAFT consensus algorithm의 경우 client의 모든 명령이 leader를 통해 수신되는데, leader가 만들어질 수 없는 이 경우 cluster 전체가 마비된다.

Quorum

투표에서 leader를 선출하기 위해 과반수를, 즉 n이 cluster의 node 개수일 때 $\frac{n+1}{2}$ 개의 표를 얻어야만 한다. 이 개념은 cluster가 제대로 동작하기 위해 필요하다.

바로 앞에서 살펴 본 [과반을 얻을 수 없는 경우]가 발생하지 않기 위해서는 최대 $\frac{n-1}{2}$개의 node가 투표를 하지 않아도 된다. 만약 문제가 발생한 node가 $\frac{n-1}{2}$보다 많다면 과반수의 득표를 얻을 수 없기 때문에 cluster의 기능이 멈춘다.

Specification

RAFT의 safety rule

election safety : 한 term에서 최대 하나의 leader가 선출된다.
log matching : 두 log의 index와 term이 동일한 경우 해당 index까지의 모든 log entry는 동일하다.
leader completness : 모든 leader는 commit된 log를 가진다.
state machine safety : 과반수 이하의 node가 offline이더라도 잘 동작해야 한다.
join consensus : 새로운 node가 추가되더라도 오직 단 하나의 leader만 존재할 수 있다.

Log

log matching을 비교할 수 있어야 한다.
index, term, 변경 명령 3가지를 가지고 있다.

각 Node

state를 가진다. state는 크게 4가지, follower, leader, candidate, offline이 있다.
모든 node는 현재 term과 각자의 log를 가지고 있다.
모든 node는 현재의 leader node와 다른 모든 node들을 알고 있다.
모든 node는 offline으로 변할 수 있다.
state의 변화는 아래 diagram을 따른다.

state의 변화. 출처 : In Search of an Understandable Consensus Algorithm

Follower

leader node를 알고 있어야 한다.
RequestVote를 받은 경우 본인의 log index와 term을 바탕으로 true로 응답한다.
leader로부터 heartbeat를 받지 못한 경우 candidate로 변화한다.

Leader

다른 모든 node에게 multicast를 보낼 수 있다.
주기적으로 heartbeat 메시지를 multicast한다.

Candidate

다른 모든 node로 RequestVote 메시지를 multicast할 수 있다.
leader로부터 AppendEntry 메시지를 받은 경우 follower로 변화한다.
다른 node로부터 ResponseVote 메시지를 받을 수 있다.
- 과반수 이상의 투표를 받은 경우 leader로 변화한다. leader가 된 경우 모든 follower에게 AppendEntry 메시지를 보내며 이를 통해 log matching을 보장한다.
- 과반수 미만의 투표를 받은 경우 follower로 변화한다.

Offline

state가 offline인 node는 그 어떤 message도 보낼 수 없고, 받을 수 없다.
offline에서 online으로 바뀔 수 있다.

Message

type이 있다. logUpdaterequest, appendEntryRequest, appendEntryResponse,commit, voteRequest, voteResponse가 있다.
logUpdateRequest : leader node가 log update를 요청하는 메시지이다.
appendEntryRequest : follower node에게 보내는 메시지이다.
appendEntryResponse : follower node가 응답하는 메시지이다.
commit : log commit message
voteRequest : 투표를 요청하는 메시지
voteResponse : 투표 응답 메시지

Spring 면접대비 질문

hyelie — Sun, 29 Oct 2023 23:05:09 +0900

Spring

정의

뭐 지원하는지

IoC(bean)

AOP

등의 특징을 가지는 프레임워크

Bean

정의

spring에서 plain old java object - 그냥 객체 - 를 bean이라고 한다.

IoC Container가 관리 및 생성한다.

@Component를 사용한 class들만 bean으로 정의된다. 이 bean들은 기본적으로 singleton이다.

IoC Container가 DI해주기도 한다.

IoC

정의

제어 역전 - 프로그램 제어권이 programmer가 아니라 framework인 spring에 있는 것. 개발자는 framework의 형식에 맞춰 개발하게 된다.

AOP

정의

aspect oriented programming

공통 관심사를 분리해 모듈화하는 것. 인증/로깅 등에 사용.

어떤 로직에 대해 핵심 관점과 부가 기능으로 나누고, 부가 기능을 모듈화하는 것. 예를 들어 logging 등.

Filter vs Interceptor

filter는 dispatcher servlet에 들어가기 전에 요청을 가로챔. spring 범위의 밖임. 따라서 business logic과는 관계 없으므로 인증, xss, 인코딩 변환 등을 사용.

interceptor는 dispatcher servlet에 들어간 후의 요청을 가로챔. 때문에 로그인, 권한 체크 등을 함.

(나올 때는 반대)

DI

정의

spring IoC Container

종류 3가지

dependency injection

필요한 객체를 직접 생성하는 것이 아니라 외부에서 주입하는 것.

각 bean들의 dependency는 IoC Container가 설정해줌.

등록한 bean들끼리 dependency를 넣어준다.

각 bean의 과정 : container 생성 - bean 생성 - dependency inject - 초기화 - 사용 - 소멸 전 callback - 종료 / container가 관리.

구성 요소를 변경하더라도, 다른 부분의 코드를 변경하지 않는 것. DI를 쓰면 dependency가 있는 object를 다른 코드로 쉽게 바꿀 수 있다. 따라서 dependency가 느슨해지기에 유지보수를 쉽게 할 수 있게 된다.

dependency injection의 방법은 contructor, setter, field injection 3가지가 있다. @autowired를 넣는 위치가 constructor는 costructor에 넣는 방식, setter는 setter method를 사용하는 방식, field는 field에 넣는 방식이다.

일반적으로는 constructor injection을 사용한다고 한다.

final로 선언해 immutable 보장 가능
circular dependency 컴파일 시점에 확인 가능

field injection의 경우 실행 시점에 circular dependency 확인 가능.

Dispatcher Servlet 흐름

DispatcherServlet이 client request를 받음
HandlerMapping이 request url에 해당하는 controller 찾음
HandlerAdapter에 처리 요청을 보냄
controller가 로직을 처리하고 결과를 HandlerAdapter로 줌
DispatcherServlet은 결과를 ViewResolver로 보내고, ViewResolver는 jsp파일의 경로를 찾는다.

Persistence Context

정의

장점

entity를 저장하는 환경.

DB의 캐시 역할을 한다.

쓰기 지연 : write한 것들이 DB에 각각 들어가지 않고 모아서 넣어주기 때문에 내부적인 최적화가 이루어진다. (캐시, 쓰기 지연 등)

위와 같은 백락으로, persistence에서 DB로 commit 보내는 시점에 스냅샷과 비교해서 필요한 만큼만 sql을 보낸다.

지연 로딩 : 필요할 때 해당 data를 가져온다.

쓰기 지연 : 영속된 상태에서는 entity가 DB에 반영되었을 수도 있고 그렇지 않을 수도 있다. 내부적으로 값을 가지고 있기 때문. persistence context가 flusth하면 DB에 작업 내용을 반영함.

비영속 : 객체는 생성됨, persistent context에 속하지 않음
영속 : persistence ontext가 entity를 관리.
준영속 : persistence context에서 관리되던 것이 더이상 관리되지 않는 상태. 이 상태에서는 변경사항은 DB에 반영됨.

지연 로딩 떄문에 N+1 문제가 생길 수 있다. join한 것들을 가져올 때 N개를 N번의 쿼리로 가져오는 경우가 그렇다. 해결하기 위해 fetch join을 쓴다.

패키지 구성

종류

계층형

도메인형 : 도메인형 구조를 사용하면 코드의 응집도가 높고, 도메인 그 자체의 흐름을 이해하기 쉽습니다.

Spring Security

filter에서 처리한다.

1. filter가 요청을 가로채면 정보를 토대로 인증용 객체 Token object를 생성.

2. 이후 authentication manager의 인증 method를 호출한다. 해당 method 내부에서는 개발자가 구현한 UserDetailsService method 내부에서 검증을 진행한다.

3. UserDetailService는 UserDetail이라는 객체를 반환하고, securitycontext에 userdetail 정보가 들어간다.

그러면 내부적으로 filter에서 걸리고, 올바르지 않으면 return 올바르면 구현한 부분에서 userDetail을 securitycontext에 넣어준다.

DAO, DTO, BO, VO

dao : data access object, DB 데이터 접근/조작을 위해 사용

dto : data transfer object, layer 간에 데이터 교환을 위해 사용 (getter, setter만 사용)

vo : value object, 값을 나타내는 객체

Spring vs Spring Boot

spring 같은 경우는 설정을 많이 해 줘야 한다. bean이 어떤 package에 있고 어떤 이름을 가지는지 application.xml에 직접 등록을 해 줘야 한다. web.xml에 각 library에 대한 dependency도 직접 등록을 해 줘야 했다. 서버도 톰캣 따로 띄워 줘야 했다.

spring boot는 이러한 과정이 매우 간소화되었다. auto config 과정 (component scan 등)을 통해 bean 등록 자동화, 라이브러리도 가독성 좋게 관리, 내장 서버 등이 있다.

Spring 장점 & thread 동작

spring

- spring은 CPU 작업이 많은 경우가 좋다. 연산이 많은 경우 thread를 사용해 명시적으로 처리할 수 있기 때문에 효율적.

- type-safe하다.

- 실행에 오래 걸린다. (JVM, GC)

- 플랫폼 독립. (jvm 위에서 돌 수 있음)

- thread 생성 위해서는 개발자의 관리가 필요함.

spring은 thread pool을 사용해 thread를 관리함. 내부적으로 몇 개의 thread를 미리 생성해 둠. 이후 필요한 작업에 할당했다가 돌려 받음. (thread를 생성/삭제하는 게 OS, JVM에 로드를 많이 주고, 무한히 생성할 수도 있기 때문.)

1. 초기에 정해진 크기만큼 thread 생성함

2. 사용자 요청이 들어오면 queue에 담아두고, idle 상태(놀고 있는) thread가 있으면 queue에서 꺼내서 작업을 thread에 할당함.

- idle인 thread가 없다면 작업은 queue에서 대기, 만약 queue가 가득 차면 thread 새로 생성.

- task 완료 시 thread는 idle 상태로 돌아가고, queue가 비고 thread가 초기 개수보다 더 많다면 destroy.

=> 미리 만들어 놓고, 필요한 작업에 할당했다가 돌려받음.

JPA & Transactional & Test annotation

@transational

해당 메소드가 transation이 되게 보장해줌. 여러 DB 쿼리가 있으면 이것들을 transaction으로 묶음. 하나라도 문제 발생 시 롤백. 종료 시 commit().

여러 개의 transactional이 있는 경우, 격리 수준을 사용해서 해당 리소스에 접근. 순서는 jvm 스케쥴링에 따름.

rollbackfor option : 기본적으로 unchecked exception만 롤백하기 때문에 exception도 롤백하게 지정

readonly option:

(일반적으로) entity가 영속성에 영속될 때, 해당 entity의 상태를 snapshot으로 남긴다. snapshot과 entity 상태를 비교해 변경된 내용만 update query를 모아 DB로 날린다.(이게 dirty checking이다!) transactional이 붙은 method는 트랜잭션 commit 시 DB에 flush함.

readonly true : dirty checking 발생 X. read 한 이후 DB로 flush하지 않는다. (snapshot을 찍지 않기 때문에 변경사항 감지 X. 때문에 메모리 절약도 가능) 때문에 변경사항 반영 안 되는 것으로 알고 있다.

---

slice test : 특정 계층만 처리 가능. @springboottest : 전체, @webmvctest: controller, 등

@test

junit에서 test annotation 다 모아서 테스트 돌려줌.

@springboottest

spring에서 bean 등록한 것들 "다" 모아서 injection해줌.

테스트 코드에서 @transactional 쓰면 쿼리 날린 것 다 롤백해 줌. (안붙이면 롤백안됨)

bean 등록한거에서 가져오고 싶으면 @autowired 쓰면 됨

@webmvctest

controller 관련만 로드함. @mockbean 만들고 리턴값 정의해서 써야 함.

[이종병렬컴퓨팅] Parallel Patterns : Convolution

hyelie — Sat, 28 Oct 2023 04:42:37 +0900

이 글은 포스텍 성효진 교수님의 이종병렬컴퓨팅(CSED490C) 강의를 기반으로 재구성한 것입니다.

이 글에서는 다음과 같은 내용을 다룬다.

convolution과 tiled convolution : 1D/2D convolution과 tiled convolution (input tiling, output tiling)
2D convolution kernel을 작성하는 방법 : boundary condition 처리
tiled parallel convolution 알고리즘의 cost와 장점

Convolution

인접한 input data element의 weighted sum 연산. 이 때 weighted sum 연산에 사용하는 weight를 input mask array 또는 convolution kernel 또는 filter라고 부른다.

예시 : 1D Convolution

1D convolution 예시

위 예시는 input arrya가 N, convolution mask가 M일 때 P[2]를 계산하는 방법을 나타낸다.

convolution mask size가 5이므로, N의 P[2]를 포함해 주변의 5개 element를 가져온다.
두 vector를 내적한다.
내적한 결과의 합을 P[2]에 넣는다.

수식으로 표현하면, P[2] = N[0] * M[0] + N[1] * M[1] + N[2] * M[2] + N[3] * M[3] + N[4] * M[4]이다.

Boundary Condition

1D convolution boundary condition

그러나 위 그림처럼 input array의 끝에 가까운 경우 convolution mask의 크기와 맞지 않은 boundary condition이 생긴다. 이 경우, input array의 범위를 벗어나는 것을 ghost element라고 한다. ghost element는 applicatoin마다 처리하는 방식이 다르다. 0이 들어갈 수도 있고, boundary에 있는 값을 복사하기도 한다.

위 예시는 ghost element에 0을 넣는 경우이다.

코드 : 1D convolution

__global__ void convolution1D_basic(float* N, float* M,
                                    float* P, int Kernel_Width, int Width)
{
    int i = blockIdx.x*blockDim.x + threadIdx.x;
 
    float Pvalue = 0.f;
    int N_start_point = i - (Kernel_Width/2);
    for (int j = 0; j < Kernel_Width; j++) {
        if (N_start_point + j >= 0 && N_start_point + j < Width)
            Pvalue += N[N_start_point + j] * M[j];
    }
 
    if (i < Width)
        P[i] = Pvalue;
}

1D convolution을 수행하는 kernel code는 위와 같다.

9번줄의 if문은 boundary condition을 확인하는 부분이다.

2D Convolution

그러면 2D의 경우를 보자. 사실상 1D와 동일하다!

2D convolution 예시

위 예시는 2D convolution 예시이다. 1D와 동일한 방식으로, 특정 element를 convolution하기 위해 해당 element 주변의 element와 convolution mask를 내적하고 합계를 결과에 넣는다.

예시 : 2D Convolution Boundary Check

2D convolution boundary condition

2D의 경우 ghost cell 처리하는 방식은 1D와 동일하다.

Convolution Mask의 Access Pattern

convolution mask는 다음과 같은 특징이 있다.

크기는 일반적으로 작다.
kernel 실행 중에 바뀌지 않는다.
모든 output을 계산하기 위해 필요하며, 접근하는 순서가 동일하다.

따라서 convolution mask는 constant memory에 넣기 좋다!

CUDA memory hierarchy

각 thread는 grid별 constant memory나 texture memory에 100 cycle만에 read only할 수 있으며 cache hit인 경우 10 cycle만에 read only할 수 있다.

Constant Memory

constant memory는 `cudaMemcpyToSymbol()`을 사용해 device memory에 복사한다. device로 옮겨지는 다른 변수와 같은 방식이다. `cudaMemcpyToSymbol()`는 해당 변수가 수정되지 않으며, read only로 안전하게 caching된다는 것을 알려준다.

#define MAX_MASK_WIDTH 10

// global variable, outside any kernel/function
__constant__ float M[MAX_MASK_WIDTH];

// allocate N, P, initialize M_h and N, copy N to N_d
…
cudaMemcpyToSymbol(M, M_h, MASK_WIDTH*sizeof(float));

// Mask is not given as an argument
convolution_1D_basic_kernel<<<dimGrid, dimBlock>>> (N_d, P_d, MASK_WIDTH, Width);

Constant Cache

constant cache는 kernel 실행 중에 수정되지 않는 constant data를 위한 특별한 cache이다. `__constant__`로 선언하며, L1 cache와 비슷한 throughput으로 constant cache에 접근할 수 있다.

또한, constant cache는 read only이므로 warp 내의 같은 주소에 접근할 때 동시에 제공된다.

추가적으로 read only이므로 coherence에 대해 신경쓰지 않아도 된다.

1D Tiled Convolution

tiling

인접한 output element는 같은 input element를 공유한다. 따라서 모든 thread의 input element를 shared memory에 올려 global memory access를 줄일 수 있다.

위 예시에서 mask_width가 5일 때 N[2]는 P[0], P[1], P[2], P[3], P[4]에서 사용하는 변수를 사용한다.

각 group이 T개의 output element를 계산한다고 하자.

T개의 output element를 계산하기 위해 T + mask_width - 1개의 input element가 필요하다.
일반적으로 T는 mask_width보다 훨씬 크다.

Tiling Option

output tile에 thread block 크기를 맞추는 방법

input tile 크기에 thread block 크기를 맞추는 방법

tiling하는 방법은 크게 2가지가 있다.

output tile에 thread block 크기를 맞추는 방법
- 모든 thread가 output element 계산에 참가한다. 위 예시에서는 blockDim.x가 4이다.
- 몇몇 thread는 input element를 shared memory에 올려야 한다.
input tile에 thread block 크기를 맞추는 방법
- 몇몇 thread는 output element 계산에 참가하지 않는다. 위 예시에서는 blockDim.x가 8이다.
- 각 thread는 1개의 input element를 shared memory에 올린다.

여기서는 두 번째 방법을 살펴본다!

Input/Output Data와 Thread의 매핑

input/output data와 thread 매핑

N이 input, P가 output이다.

각 thread에서 index_input = index_output - (mask_width/2)이다.
tile_width은 tile의 output element 개수. 위 예시에서는 4.
thread block size은 tile_width + (mask_width - 1). 위 예시에서는 8.

코드

float output = 0.0f;
__shared__ float Ns[tile_width + (mask_width – 1)];
int tx = threadIdx.x;

int index_output = blockIdx.x * blockDim.x + threadIdx.x;
int index_input = index_output – (mask_width – 2);

if (index_input >= 0 && index_input < width)) {
    Ns[threadIdx.x] = N[index_input];
}
else {
    Ns[threadIdx.x] = 0.0f;
}

if (tx < tile_width) {
    output = 0.0f;
    for (int j=0 ; j < mask_width; j++) {
        output += M[j] * Ns[tx + j];
    }
    P[index_output] = output;
}

위에서 언급했듯 input tile에 thread block의 크기를 맞추는 방법이기에 각 thread는 하나의 input element를 shared memory에 올려야 한다. 위 코드의 8번줄부터 13번줄까지 shared memory에 input memory를 올리는 모습이다.

15번줄부터는 0부터 (tile_width-1)까지의 thread만 계산에 참가하는 것을 보여준다.

해석

shared memory access

thread당 shared memory access

mask_width가 5인 상황이다.

NS[0]은 thread 1에 의해 사용된다.
NS[1]은 thread 1, 2에 의해 사용된다.
NS[2]은 thread 1, 2, 3에 의해 사용된다.
NS[3]은 thread 1, 2, 3, 4에 의해 사용된다.
NS[4]은 thread 1, 2, 3, 4에 의해 사용된다.
NS[5]은 thread 1, 2, 3에 의해 사용된다.
NS[6]은 thread 1, 2에 의해 사용된다.
NS[7]은 thread 1에 의해 사용된다.

2D Convolution

Padding

padding

2D matrix를 DRAM에서 burst할 때, width가 burst의 배수가 아닌 경우 misalignment가 발생할 수 있다. 때문에 width를 burst의 배수에 맞춰 row의 시작점을 DRAM burst에 맞추는 방식이 좋다. 이는 width에 추가적인 padding을 넣는 방식이다.

만약 위 예시에서 padding이 없는 상황을 가정해 보자. 이 때 burst는 4개의 element를 가져온다고 하자.

그러면 M$_1, _0$은 burst 0에 속해 있고, M$_1, _1$과 M$_1, _2$는 burst 2에 속해 있기에 row 1을 가져오기 위해 DRAM access를 2번 해야 한다.

반면 padding이 있다면 1번만 DRAM access해도 된다.

Tiling Strategy

Tile 설계

tiling 설계

thread block을 input tile에 매핑한다. 그러면 모든 thread는 N의 tile을 shared memory에 올린다. 그러면 thread들은 N의 element를 사용해 P를 계산한다.
TILE_SIZE는 x, y축의 output tile 크기를 정의한다.
thread block size는 TILE_SIZE와 input tiling의 mask width에 의존한다.

Indexing

tile indexing

int tx = threadIdx.x;
int ty = threadIdx.y;

int row_o = blockIdx.y * TILE_SIZE + ty;
int col_o = blockIdx.x * TILE_SIZE + tx;

int row_i = row_o – MASK_WIDTH/2;
int col_i = col_o – MASK_WIDTH/2;

그러면 input/output index는 위 코드와 같다. input의 경우 ghost cell을 포함해야 하기에 output보다 더 크다.

Shared Memory에 Input Tile Load

float output = 0.0f;

if ((row_i >= 0) && (row_i < N.height) && (col_i >= 0) && (col_i < N.width)) {
    Ns[ty][tx] = N[row_i*N.width + col_i];
}
else {
    // threads that load halos outside N returns 0.0
    Ns[ty][tx] = 0.0f;
}

input tile을 shared memory에 올리는 코드는 위와 같다. 범위가 벗어나는 경우 ghost element이므로 if-else를 사용한다.

Output 계산

output 계산

float output = 0.0f;

if (ty < TILE_SIZE && tx < TILE_SIZE){
    for (i = 0; i < MASK_WIDTH; i++) {
        for (j = 0; j < MASK_WIDTH; j++) {
        	output += M[i][j] * Ns[i+ty][j+tx];
        }
    }
    if (row_o < P.height && col_o < P.width)
        P[row_o * P.width + col_o] = output;
}

3번줄의 첫 번째 if문은 TILE 안에 있는 thread만 수행하게 만든다. thread block size가 TILE_SIZE보다 크기 때문에 필요하다.

9번줄의 if문은 output이 올바른 범위 내에 있는지 확인한다.

Bandwidth Reduction 분석

1D Convolution의 경우

TILE_SIZE + MASK_WIDTH - 1개의 element가 shared memory에 올라간다.

TILE_SIZE * MASK_WIDTH번의 global memory access가 shared memory access로 바뀐다.

따라서 bandwidth reduction은 다음과 같다.

$\frac{\text{(TILE_SIZE * MASK_WIDTH)}}{\text{(TILE_SIZE + MASK_WIDTH - 1)}$

위 수식은 edge tile에 있는 ghost cell을 무시한 수식이다.

Ghost Cell을 고려한 경우

boundary tile의 예외를 처리하기 위해 TILE_SIZE + $\frac{\text{(MASK_WIDTH - 1)}}{2}$개의 element를 shared memory에 올렸다.

이 때, ghost cell들에 대해서는 global memory access를 하지 않았다. 그만큼 더 줄어든다.

일반화

일반화하면, MASK_WIDTH << TILE_WIDTH인 경우 MASK_WIDTH에 근사하게 bandwidth가 줄게 된다.

예시

1D convolution에서 bandwidth 감소율

mask_width가 5인 위 예시에서, 각 P의 element를 계산하기 위해 5개의 N element가 있어야 한다. tiling을 쓴 경우, 5개의 N element는 shared memory에 있는 것을 참조한다.

shared memory에는 12개의 element가 올라갔으며, 전체 output tile을 위해 8 * 5개의 shared memory access를 했다. 따라서 bandwidth reduction은 40/12 = 3.3으로, 3.3배 향상되었다.

boundary tile까지 고려해 보자. boundary가 아닌 element는 10개가 shared memory에 올라간다. 이 떄 ghost cell들은 global memory access를 하지 않으니, 전체 access 회수는 3 + 4 + 6*5 = 37이다. 따라서 37 / 12로, 3.7배 향상되었다.

2D Convolution의 경우

(TILE_SIZE + MASK_WIDTH - 1)$^2$개의 element가 shared memory에 올라간다.

P의 각 element를 계산하기 위해 MASK_WIDTH$^2$개의 N element에 접근해야 하므로 TILE_SIZE$^2$ * MASK_WIDTH$^2$번의 global memory access가 발생한다.

따라서 bandwidth reduction은 다음과 같다.

$\frac{\text{TILE_SIZE}^2 \times \text{MASK_WIDTH}^2}{\text{(TILE_SIZE + MASK_WIDTH - 1)} ^ 2}$

위 수식은 edge tile에 있는 ghost cell을 무시한 수식이다.

TILE_SIZE에 비례해 memory bandwidth가 급격하게 줄게 된다. 근사하면 TILE_SIZE$^2$배만큼 성능이 향상되기 때문이다.

그렇지만 TILE_WIDTH가 커질수록 필요한 shared memory size가 더 커진다는 것을 인지해야 한다.

이외의 최적화

Texture Memory 사용

input image를 shared memory 대신 texture cache에 올리기
- 코드가 더 쉽고 깔끔해지며, texture hardware path를 통해 global memory read를 할 수 있다.
- 이 경우 data read는 2D/3D spatial locality에 특별화된 texture cache에 저장된다.
CUDA array 사용
- global memory에 1D/2D/3D 형태의 data 저장을 위한 object를 만든다.
- OpenGL이나 DirectX의 표준 교환 형식이다.

host code

// global declaration of 2D float texture (visible for host and device code)
texture<float, cudaTextureType2D, cudaReadModeElementType> tex; …

// Create explicit channel description (could use an implicit as well)
cudaChannelFormatDesc channelDesc = cudaCreateChannelDesc(32, 0, 0, 0, cudaChannelFormatKindFloat);

// Allocate CUDA array in device memory
cudaArray* cuArray;
cudaMallocArray(&cuArray, &channelDesc, width, height);

// Copy some data located at address h_data in host memory into CUDA array
cudaMemcpyToArray(cuArray, 0, 0, h_data, size, cudaMemcpyHostToDevice);
…

// Bind the array to the texture reference
cudaBindTextureToArray(tex, cuArray, channelDesc);

texture data storage를 할당하고, texture를 해당 data storage에 할당한다.

device code

float value = tex2D(tex, xpos, ypos);

texture reference를 사용해 data fetch할 수 있다.

Loop Unrolling

loop를 펼쳐서 control flow overhead를 줄이는 방식. 이 방법을 사용하면 global read 성능이 향상될 수 있다.

예를 들어 숫자 1개 대신 4개의 숫자를 가져오던가(memory coalescing), float4 vector type을 쓰면 locality와 bandwidth 최적화에서 이점이 있다.

Matrix Multiplication

입력 image를 matrix로 바꾸고, matrix multiplication을 수행한다.

기본적으로 convolution은 filter와 이동하는 window에 의해 선택된 local region 사이의 내적이므로 memory에 있는 모든 window를 확장하고 matrix multiplication으로 최적화 할 수 있다.

예를 들어 input image f가 [1, 2, 3, 4]rh filter가 [-1, -2, -3]인 경우,
f = $ \begin{bmatrix} 1 & 2 & 3 \\ 2 & 3 & 4 \\ \end{bmatrix}$, g = $\begin{bmatrix} -1 \\ -2 \\ -3 \end{bmatrix}$로 설정하고 matrix multiplication하면 된다.

Computational Transformation

algorithmic strength reduction을 통해 multiplication 연산 회수를 줄일 수 있다. 예를 들어 덧셈같은 weak operation의 회수를 늘이고 곱셈같은 strong operation의 회수를 줄일 수 있다.

Winograd
Strassen Algorithm : 행렬 곱을 부분으로 나눠, 8번의 곱연산을 7번의 곱연산과 n번의 덧셈으로 나누는 기술이다.
Fast Fourier Transform

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

[이종병렬컴퓨팅] Performance Considerations

hyelie — Sat, 28 Oct 2023 02:03:13 +0900

이 글은 포스텍 성효진 교수님의 이종병렬컴퓨팅(CSED490C) 강의를 기반으로 재구성한 것입니다.

이 글에서는 GPU resource의 제약과, 이들이 성능에 미치는 영향을 알아본다.

최적화 목표
memory coalescing
shared memory bank 충돌
점유율
thread granularity

최적화 목표

Performance 고려 사항

parallel한 코드와 hardware resource의 제약, 이 두가지를 관리하는 것이 고성능의 핵심이다.

그러나 먼저, 어디서 제일 많은 시간이 걸리는지 측정해야 한다.

Amdahl의 법칙을 생각해야 한다.
coarse grained한 부분부터 측정하고, 이후에 fine grained한 부분을 측정하면 된다.

다음으로 main resource의 병목을 찾아야 한다.

application마다 bottleneck이 다르다.
하나의 resource 사용량을 다른 것과 교환해서 성능을 올릴 수 있는지 고려해야 한다.
compute-bound인지 memory-bound인지 고려해야 한다.

최적화 목표

최적화의 목표는 computing unit과 memory bandwidth를 최대로 사용하는 것이 목적이다.

computing unit을 최대로 사용하기 위해서는,

Flops가 최대 연산량에 근접하게 처리해야 한다.
각 thread에서는 latency와 control divergence를 줄여야 한다.
- DRAM bandwidth 줄이기 : shared memory나 memory hierarchy를 사용해야 한다.
- memory coalescing : memory bandwidth를 더 효율적으로 사용해야 한다.
- shared memory bank collision 회피
- control divergence 회피
thread끼리는 더 concurrent하게 만들어야 한다. 이는 occupancy이며, SM resource를 동적으로 분할하면 된다.

memory bandwidth를 최대로 사용하기 위해서는

thread granularity : 각 thread는 더 independent하게 접근해야 한다.
thread끼리는 더 concurrent하게 만들어야 한다. 이는 occupancy이다.

Memory Coalescing

DRAM Burst

DRAM burst

DRAM burst는 memory에서 data를 읽거나 쓸 떄 한 번에 연속적인 data 묶음을 사용하는 방법이다.

기본적으로 off chip memory, DRAM은 chunk로 접근한다. 만약 하나의 byte에 접근하더라도, 그 byte가 속한 chunk에 있는 모든 byte를 읽어온다. 때문에 chunk 전체를 읽지 않으면 bandwidth가 낭비된다!

Memory Coalescing

coalesced access

모든 warp에서 memory operation이 발생하고, warp 내의 32개의 thread가 memory에 접근한다.

만약 모든 thread의 memory에 접근하는 위치가 연속적이고 하나의 burst section에 있는 경우 하나의 DRAM 요청만 발생하게 되므로, 모든 access가 coalescing(통합)된다.

위 그림에서는 T0, T1, T2, T3가 memory의 같은 burst에 접근하고 있다.

un-coalesced access

반면 memory에 접근하는 위치가 1개 이상의 burst인 경우, coalescing이 실패하므로 여러 개의 DRAM 요청이 만들어진다. 이렇게 받은 memory의 일부 정보는 thread에서 사용하지만, 몇몇 정보는 thread에서 사용하지 않기 때문에 bandwidth가 낭비된다.

위 그림에서는 T0, T1, T2, T3가 2개의 DRAM burst에 접근하고, 이마저도 100% 사용하는 것이 아니기 때문에 bandwidth가 낭비된다.

Coalesced Access

만약 array index가 다음과 같은 형식인 경우, warp의 memory access는 연속적이다.

`A[X + threadIdx.x]` 또는 `A[X + (blockDim.x*blockIdx.x + threadIdx.x)]`

(여기서 X는 X 이외의 항과 독립적이다.)

예시 : Output Tiling Matrix Multiplication

지지난 포스팅에서 살펴본 output tiling matrix multiplication을 보자.

memory access pattern

각 thread는 위 그림처럼 memory에 접근한다.

memory N, M의 access pattern

왼쪽 그림은 matrix N에, 오른쪽 그림은 matrix M에 해당하는 memory에 접근하는 방식이다.

그림에서 알 수 있듯 N의 경우 memory access가 coalescing되어 있다. 접근이 연속적이기 때문이다. 반면 M은 coalescing되어 있지 않다. 연속적인 memory에 접근하지 않기 때문이다.

예시 : Input Tiling Matrix Multiplication

tiling matrix multiplication에서 memory access pattern

반면 tiling을 한 경우 memory coalescing이 일어난다. 연속된 memory를 shared memory로 읽어오기 때문이다!

예시 : strided access

__global__ void foo (int* input, float3* input2)
{
    int i = blockDim.x * blockIdx.x + threadIdx.x;
    
    // Stride 1
    int a = input[i];
    
    // Stride 2, half the bandwidth is wasted
    int b = input[2*i];
    
    // Stride 3, 2/3 of the bandwidth wasted
    float c = input2[i].x;
}

위 코드를 보자.

stride 1의 경우 access pattern이 i이다.
stride 2의 경우 access pattern이 2i이므로 bandwidth의 50%가 낭비된다.
stride 3의 경우, input2는 float3이므로 bandwidth의 2/3이 낭비된다.

예시 : Structure의 Array와 Array의 Structure

C를 공부했다면 알만한 내용이다.

struct AoS
{
    int key;
    int value;
    int flag;
};
AoS *d_AoS_data;

structure의 array

struct SoA
{
    int * keys;
    int * values;
    int * flags;
};
SoA *d_SoA_data;

array의 structure

__global__ void bar(AoS *d_AoS_data, SoA *d_SoA_data)
{
    int i = blockDim.x * blockIdx.x + threadIdx.x
    
    // AoS wastes bandwidth
    int key_aos = d_AoS_data[i].key;
    
    // SoA efficient use of bandwidth
    int key_soa = d_SoA_data->keys[i];
}

이 경우 memory bandwidth는 어떨까?

물론 코드 짜기 나름이겠지만, 위 코드의 경우 array of structure는 bandwidth의 2/3을 낭비한다. structure of array는 100% 쓰고 있다.

요약

각 warp에서 100% address coalescing을 이루면 좋다.

이를 위해서 시작 주소를 정렬해서 쓰거나(padding이 필요할 수도 있다.), warp는 연속적인 memory에 access하는 것이 이상적이다. thread 사이에 큰 stride가 있거나, access 간격이 큰 것은 별로다.

이를 위해 address access pattern을 분석하고 최적화해야 한다.

request당 memory transaction 회수 분석
array of structure 대신 structure of array 사용
read only data는 read only variable을 사용하는 것이 좋다.
가능하면 shared memory를 쓰는 것이 좋다.

Shared Memory Bank Conflict

shared memory는 thread block 내의 thread의 communication과 global memory access 회수를 줄이기 위해 사용한다.

이런 shared memory는 4byte로 이뤄진 32개의 bank로 이뤄져 있으며, 서로 다른 bank를 통해 연속적인 word에 접근할 수 있다. (bank level parallelism)

성능의 경우,

shared memory access는 warp별로 만들어진다.
각 SM의 clock당, bank의 bandwidth는 4byte이다.
serialization : N개의 thread가 하나의 bank 안에 있는 32개의 다른 word에 접근한다면, N개의 access는 순서대로 실행된다.
mutlicast : N thread는 하나의 fetch로 같은 word에 접근할 수 있다.

각 bank는 모두 independent하다.

optimal : 모든 thread가 다른 bank에 접근하는 경우 optimal하며, multicast할 수 있다.
worst : 2개 이상의 thread가 같은 bank에 접근하는 경우 bank conflict가 발생한다. 이 경우 serialization이 발생하기 때문에 효율이 떨어진다.

Bank Conflict 회피

예시 : Matrix Transpose

__global__ transpose(float in[], float out[])
{
    __shared__ float tile[TILE][TILE];
    int glob_in = xIndex + yIndex*N;
    int glob_out = xIndex + yIndex*N;
    tile[threadIndx.y][threadIndx.x] = in[global_in];
    __sync_threads();
    out[glob_out] = tile[threadIdx.x][threadIndx.y];
}

위 코드를 실행시킬 때 shared memory에 32 by 32의 array가 있다고 하자.

bank conflict 예시

read에 대해서는 stride 1이기 때문에 coalescing이 발생한다. 때문에 가운데 그림처럼 bank 0에는 0번째 column이, bank 1에는 1번째 column이, ... 들어간다. 이 경우는 괜찮다! 모든 thread가 다른 bank에 접근하고 있다.

반면 bank에 값을 쓰는 상황을 보자. thread 0은 bank 0의 0번째에 값을 쓰고, thread 1은 bank 0의 1번째에, ... thread k는 bank 0의 k번째에 값을 쓴다.

이 경우 bank conflict가 일어나며 이 요청은 serialize되기에 성능이 대폭 떨어진다.

bank conflict 회피 - padding 추가

이를 막기 위해 사용하지 않는 column 하나를 덧붙이는 trick이 있다. 기존에 column 0에 해당하는 것은 모두 bank 0에 들어갔는데, 이렇게 바꾸면 column 0에 모든 종류의 bank가 들어가게 되어 bank conflict가 줄어든다.

Occupancy

Review : Thread Scheduling

SM은 overhead가 없는 warp scheduling을 했다. SM은 언제든 준비된 warp를 실행하고, 이 때 context swtiching cost가 없었다.

만약 모든 warp가 정지되어 실행할 warp가 없는 경우, 실행할 instruction이 없어 성능이 떨어진다.

그러면 왜 멈출까? 아래와 같은 이유가 있다. 두 경우 모두 active warp로 switch해서 latency를 숨겨야 하는데, 그러지 못하는 경우다.

global memory access 대기
compute unit를 대기

Occupancy

Occupancy = $\frac{\text{SM에서 활성화된 thread의 개수}}{\text{SM의 thread 개수}}$

Occupancy, 점유율의 정의는 위와 같다.

occupancy가 높을수록 latency를 숨기는 데 도움이 된다. 당연하다! 실행할 수 있는 warp가 있기 때문에 그동안 idling하지 않는다.
달성된 occupancy vs 이론적 occupancy
- compute unit을 포화시키기 위해, 모든 SM을 채울 수 있는 충분한 thread block을 실행해야 한다.
- memory bandwidth를 포화시키기 위해 concurrent memory request를 가진 충분한 thread block을 실행해야 한다.

Occupancy와 성능

최대 성능을 위해 100% occupancy가 필요하지는 않다. 특정 occupancy에 도달하면, 더 늘려도 성능이 향상되지 않는다는 말이다.

이 [특정 occupancy]는 코드에 따라 다르다. 더 independen할수록 더 적은 occupancy가 필요하다. 일반적으로 memory에 의존하는 코드는 latency가 더 많기에 더 많은 occupancy가 필요한 경향이 있다.

Resource Limit

각 SM에서 각 thread는 register, shared memory를 공유한다. 또한 resource는 한계가 있기 때문에 hardware scheduler는 SM에 맞는 thread의 개수를 결정한다.

thread당 register : SM register는 thread에 나눠진다.
thread block당 shared memory : SM shared memory는 thrread block에 나눠진다.
SM당 thread block : thread는 thread block granularity에 따라 나눠진다.
SM당 thread

예시

resource의 한계

위 그림을 보자.

왼쪽의 경우, thread block 3개가 register와 shared memory를 나눠가진다.

반면 오른쪽의 경우 shared memory가 부족해 thread block 0, 1이 대부분의 shared memory를 점유하고 있다. 때문에 thread block 3가 활성화되지 못했다.

Thread Block Sizing

thread block sizing

위 예시에서 볼 수 있듯 thread block의 개수와 thread의 개수는 thread block size과 관련이 있다.

위 그림의 왼쪽 부분. thread block이 너무 작으면 안 된다. SM이 occupancy의 임계점에 다다르기 전에 thread block의 한도에 다다르기 때문이다.
위 그림의 오른쪽 부분. thread block이 너무 커서도 안 된다. SM이 occupancy의 임계점에 다다르기 전에 thread 한도에 다다르기 때문이다. thread에 대해서는 resource가 충분하지만 thread block에 대해서 충분하지 않을 수도 있다.

Occupancy Guideline

thread block 크기의 경우 (thread block당 thread의 개수)
- 각 thread block당 128 - 256개로 먼저 시작하고, 기능에 따라 조정하면 된다.
- warp size인 32에 배수인 것이 좋다.
- occupancy가 성능에 중요한 영향을 미치는 경우, thread block size가 register나 shared memory resource에 영향을 미치는지 확인해야 한다.
grid size (grid당 thread block 개수)
- 1000개 이상의 thread block이 있는 것이 좋다.

Thread Granularity

thread가 얼마나 많은 일을 하게 둘지에 대한 지표이다.

일반적으로 independent한 thread가 더 많을수록 occupancy를 높일 수 있고, parallel하게 처리할 수 있다. 그러나 thread간 중복된 작업이 있는 경우 compute unit에서 thread가 정지될 수 있다.

SM은 floating point, load나 branch instruction에 대해 제한된 bandwidth를 가지고 있다. 때문에 중복 작업을 없애는 것이 좋다.

예시 : Tiling Matrix Multiplication

tiling matrix multiplication

이 경우 각 M, N tile을 가져오는 데 중복이 있다. 이 경우 2개의 thread block을 하나로 합치면 global memory access를 줄 일 수 있다.

단, 이 경우 active thread의 개수가 줄어들어 SM resource에 대한 압박이 증가할 수 있고, 총 thread block의 개수가 줄어들어 parallelism에 문제가 생길 수도 있다.

요약

성능에 영향을 미치는 병목을 찾아내고 이를 해결해야 한다. 만약 병목을 찾아낸 경우, tuning을 적용해야 한다.

sequential code를 parallelize하는 방법도 고려해야 한다.

kernel launch를 조절해 occupancy 높이기
global memory access coalescing 을 사용해 memory bandwidth 효율 높이기
shared memory & shared memory bank conflict 회피를 사용해 global memory에 대한 중복 접근을 없애기
같은 warp 내에서 다른 execution path를 줄여 control divergence 없애기
stream, unified memory를 사용해 host - device data 전송 최소화 또는 숨기기

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

[이종병렬컴퓨팅] Thread Execution Efficiency

hyelie — Sat, 28 Oct 2023 00:14:03 +0900

이 글은 포스텍 성효진 교수님의 이종병렬컴퓨팅(CSED490C) 강의를 기반으로 재구성한 것입니다.

이 글에서는 다음과 같은 내용들을 살핀다.

SIMD hardware에서 GPU thread가 실행되는 방식 : warp partitioning, control divergence
control divergence가 성능에 미치는 영향을 분석하는 방법 : boundary condition checking
GPU thread execution을 겹치는 방법 : CUDA stream
GPU의 synchronization primitive 동작 : warp synchronization, atomics

SIMD hardware에서 GPU thread가 실행되는 방식

Scheduling Thread Blocks

hardware는 thread block을 가능한 processor에게 보내며, 어떤 SM이 어떤 thread block을 실행할지 결정한다.

GPU는 많은 processor(SM)들이 있다. 보통 16개 ~ 132개 정도가 있다.
각 processor는 여러 thread block을 concurrent하게 실행할 수 있다. 때문에 kernel launch가 충분한 thread block을 생성해서 busy한 상태를 유지하게 하는지 살펴야 한다. (이에는 memory latency를 숨기는 효과도 있다.)
- thread block의 개수가 SM의 개수보다 작으면 SM을 모두 사용하지 못하는 것이고, 즉슨 성능을 100% 활용하지 못하는 것이다.
hardware는 resource가 사용가능할 때 thread block을 실행한다. 때문에 thread block 간의 순서가 보장되지 않으므로 이에 알고리즘이 thread block의 실행 순서에 영향을 받지 않게 설계해야 한다.

Scheduling 단위로써 Warp

warps as scheduling units

각 thread block은 하나 이상의 warp에 mapping된다.
hardware scheduler는 각 warp를 independent하게 scheduling한다. 즉, warp가 scheduling의 단위이다.
- warp 안의 thread는 SIMD 방식으로 함께 수행된다.
- thread block의 다른 warp는 independent하게 실행된다. 예를 들어 warp size가 32인 경우, thread block 크기가 32보다 크면 thread block을 실행하는 warp는 2개 이상으로 나뉘며, 이 warp들은 independent하게 실행된다.
warp의 크기나 execution/communication model은 버전/제조사에 따라 다르다.

N차원 Thread Block에서 Warp

thread block linearlize

n-D 형태의 thread block은 row-major 순서로 1D로 linearize되며, x, y, z축 순서이다.

multi dimensional thread block 안의 warp

이렇게 나누는 이유는 thread block을 warp로 나누기 위함이다.

1D로 바뀐 thread block은 warp로 나뉘며, warp 내의 thread index는 연속적이며 증가한다.
partitioning하는 방식은 모든 기기에서 동일하므로 control flow에 사용할 수 있다. CUDA의 경우 어떤 warp에 어떤 thread를 넣을지 explicit하게 설정할 수 있다.

위 예시에서는 4 by 6 by 2의 형태인데, 여기서 warp를 할당하기 위해 1D로 펼치고 32개의 thread를 하나의 warp에 넣는다. 0부터 31까지는 warp 0에, 32부터 64까지는 warp 1에, ... 넣는다.

Warp 채우기

thread block은 warp를 가득 채울 수 있는 것이 좋다.
- 예를 들어 thread block size가 1이면 1개의 warp에 할당되지만 나머지 부분이 비어서 별로다.
- 32면 1개의 warp에 할당되지만 warp의 빈 공간이 적어서 좋다.
- 128이면 4개의 warp를 채울 수 있어서 더 좋다.
hardware가 warp를 전환할 수 있게 하려면 thread block당 충분한 thread가 존재해야 한다. thread block이 warp에 매핑되기 때문이며, warp가 여러 개 있어야 memory access latency를 숨길 수 있기 때문이다.
scratchpad memory와 같은 resource는 thread block당 thread 개수를 제한할 수도 있다. 앞선 글에서 살펴본 것처럼 한 thread block에 너무 많은 thread가 할당되면 하나의 SM에서 실행할 수 있는 thread의 개수가 낭비되기 때문이다.
thread의 개수가 thread block의 개수의 배수가 아니면 kernel 내부에 boundary test를 삽입해야 한다. 앞서 살펴본 if문과 동일하다.
- boundary test가 없는 경우 thread blodk이 array의 index 외부에 접근할 수 있기 때문이다.

Control Divergence

warp의 모든 thread는 동일한 instruction을 실행해야 한다. 때문에, 모든 thread가 같은 control flow path를 따르는 경우 제일 효율적이다.

예를 들어 모든 if-then-else는 같은 결정을 내리며, 모든 loop는 같은 회수만큼 반복된다.

만약 warp의 thread가 branch로 인해 서로 다른 작업을 수행하면 어떻게 될까? 이게 control divergence이다.

이 내용은 SIMT와 SIMD 포스팅에서 잠깐 다뤘었다.

control divergence는 서로 다른 control decision이 발생해 서로 다른 control flow path로 갈 때 발생한다.

예를 들어, if-then-else에서 몇몇은 then으로, 몇몇은 else로 가는 경우이다.
다른 예로 몇몇 thread가 loop 회수가 다를 수도 있다.

이 때, 서로 다른 path를 사용하는 경우, GPU 내부에서 serialize된다. 모든 warp의 thread는 같은 instruction을 실행해야 하기 때문이다.

warp의 thread가 선택한 control path는 더 이상 다른 path를 가진 thread가 없을 때까지 한 번에 하나의 path에 해당하는 thread를 실행한다. 돌지 않는 thread는 idling한다.
각 path를 실행하는 동안 모든 thread는 parallel하게 실행되며, 해당 path를 사용하지 않는 모든 thread는 mask된다.

예시

control divergence 예시

위와 같은 상황을 고려해 보자. 한 warp에는 32개의 thread가 들어간다.

control divergence 실행 결과

파란색 warp 1에 속한 thread들은 모두 같은 control decision을 내리기 때문에 divergence가 없다.
빨간색 warp 2에 속한 thread들의 경우 일부 thread는 threadIdx.y가 0이고, 일부 thread는 아니다. 때문에 [B에 해당하는 control decision을 내린 thread들]과 [C에 해당하는 control decision들을 내린 thread들]을 serialize해서 실행한다. 이후 D는 모든 thread가 같은 control decision을 내렸기 때문에 모두 같이 실행된 모습이다. 이 경우 divergence이다.
초록색 warp 3에 속한 thread들의 경우 thread block이 warp size를 삐져나갔다. 때문에 warp 내에 있는 thread들만 활성화된 모습을 볼 수 있다. 이 경우 divergence는 아니다.

Nested Control Divergence

nested control divergence

위 그림처럼 nested branch가 있는 경우, 모든 branch가 serialize되므로 divergence가 더 심해진다.

Divergent Iteration

__global__ void per_thread_sum(int *indices, float *data, float *sums)
{
    ...
    // number of loop iterations is data dependent
    for(int j=indices[i]; j<indices[i+1]; j++)
    {
        sum += data[j];
    }
    sums[i] = sum;
}

nested loop 이외에도 나쁜 divergent의 예시이다.

위와 같은 kernel code를 실행한다고 하자. 이 경우 실행 회수가 모두 다르기 때문에 thread 하나가 전체 warp의 실행 시간을 결정할 수도 있다.

Control Divergence가 성능에 미치는 영향

divergence는 프로그램의 정확성에 영향을 주지 않기 때문에, 프로그램을 짤 때 divergence에 대해 correctness를 고려할 필요가 없다.

control divergence가 있는 코드가 synchronization을 할 때 deadlock이 발생하기도 하지만, 매우 드물다.

그렇지만 일반적으로 divergence가 많아질수록 성능이 떨어지기 때문에, performance를 분석하고 divergence를 줄일 수 있도록 해야 한다. 1개 정도는 괜찮지만, nested branch는 지양해야 한다.

예시 : control divergence가 성능에 미치는 영향

array size가 1000이고, thread block당 256개의 thread가 있고, 각 thread block당 8개의 warp가 있다고 하자.

thread block 0, 1, 2에 해당하는 thread들은 0부터 767이며, 총 24개의 warp가 있다. 이들은 control divergence가 없다.
thread block 3에서 control divergence가 발생한다.
- warp 0 ~ 6 (thread 0 ~ 223)까지는 1000 안에 들어오므로 control divergence가 없다.
- warp 7의 992 ~ 999에 해당하는 thread들은 범위 내에 있다.
- warp 7의 1000 ~ 1023에 해당하는 thread들은 범위 밖에 있다.
이 경우 32개의 warp 중 1개의 warp에 control divergence가 발생하기 때문에 성능에 미치는 영향은 약 3%일 것이다.

이처럼 큰 input data에 대해서는 boundary test로 인한 영향이 적어야 한다. 그렇지만 기능이 올바르게 동작하는 것을 보장하기 위해서는 boundary test를 사용해야 한다.

Addressing Control Divergence Guideline

control divergence로 인해 parallel의 효율이 매우 크게 저하될 수 있다. worst case, 한 thread만이 매우 복잡한 branch를 따르고 나머지 32개의 thread는 그렇지 않다면 32배 성능 손실을 본다.
warp 내부에서 divergence를 피해야 한다. 다른 warp는 다른 code를 실행할 수 있으므로 성능에 영향을 주지 않는다.

// divergence가 발생하는 예시
// branch granularity < warp size
if (threadIdx.x > 2) {...}
else {...}

// divergence가 발생하지 않는 예시
// branch granularity is a whole multiple of warp size
if (threadIdx.x / WARP_SIZE > 2) {...}
else {...}

위 예시와 같은 방법을 쓸 수 있다.

위 코드는 무조건 divergence가 발생한다. 반면 아래 코드의 경우, 특정 warp에 대해서만 if문이 걸리기 때문에 divergence가 발생하지 않는다.

cost를 고려해서 boundary test를 해야 한다.
- 만약 boundary test cost가 낮다면 branch를 써도 된다.
- 반면 boundary test cost가 높다면 여러 개의 kernel을 사용하는 것이 좋다. 예를 들어 하나는 범위 내의 것, 하나는 범위 밖의 것으로.
kernel specialization : cost가 매우 크게 드는 일부 목록을 분리하는 방법이다.

Concurrency With Stream

Synchronicity

폰 노이만 모델은 계산 단계가 synchronous이다.
- 실제로는 false인 경우가 대부분이다. compiler나 out of order reorder나 pipelined CPU가 instruction을 중복한다. 이처럼 실제 동작은 다르다.
- 그러나 여전히 abstract level을 보는 programmer에게는 synchronous한 실행으로 보인다.
- 만약 program level에서 asynchronous하다면 프로그래머는 어떤 일이 어떤 순서로 일어나는지 면밀히 관심을 가져야 한다.
GPU의 경우 host와 kernel code의 synchronicity와, GPU stream들끼리의 synchronicity를 고려해야 한다.

GPU Kernel Code에서 Synchronicity

하나의 warp에서 코드는 synchronous하게 실행된다. 즉 모든 instruction은 이전 instruction이 끝날 때까지 기다린다.
다른 warp들은 랜덤하게 overlap된다. 이는 `__syncthreads()`를 호출해 올바른 동작을 유도할 수 있다.
다른 thread block들은 랜덤하게 overlap된다. 이들은 어떻게 synchronous하게 동작하게 유도할까? 가장 쉬운 방법은 작업이 끝나면 kernel을 종료하는 것이다.

CUDA Host Code에서 Synchronicity

모든 CUDA 호출은 host에 대해 synchronous 또는 asynchronous이다
- synchronous의 경우 : 작업을 대기열에 추가하고 끝날 때까지 기다린다.
- asynchronous의 경우 : 작업을 대기열에 추가하고 즉시 리턴한다.
Default API의 경우
- CUDA kernel launch는 CPU와 asychronous이다. (non-blocking) host에서 kernel call을 해도 kernel이 끝날 때까지 다음 instruction을 실행하는 것을 보류하지 않는다.
- 대부분의 CUDA call은 synchronous / blocking이다. 예를 들어 `cudaMemcpy()`의 경우 복사가 끝날 때까지 기다린다.
- asynchronous한 버전의 API도 존재한다. 예를 들어 `cudaMemcpyAsync()`는 CPU와 asynchronous하다.
- asynchronous한 API를 호출한 경우, `cudaDeviceSynchronize()`를 호출해 완료를 기다리거나 `cudaMemcpy()`를 호출해야 한다.

CUDA Streams

CUDA Streams는 GPU에서 만들어진 순서대로 실행되는 operation sequence. host는 작업을 queue에 넣고, device는 resource를 쓸 수 있을 때 stream에 작업을 넣는다.

stream을 사용해 여러 개의 CUDA operation을 동시에 할 수 있다. 때문에 concurrency와 pipelining을 실현하는 programming model이다.
종류는 크게 2가지, kernel launch와 data transfer이다.
또한 CPU에서 GPU로, GPU에서 CPU로 data를 옮기는 communication을 숨길 수 있다!

예시

cuda stream 성능향상 예시

stream을 사용하면 위 예시와 같이 kernel launch와 data transfer를 겹칠 수 있다.

예시 : 코드

cudaSream_t stream; // Declaring the stream variable
cudaStreamCreate(&stream); // Creating the stream

// Assigning stream to kernel launch
myKernel<<grid, shmem, stream>>(args);

// Checking if the stream has finished
if (cudaStreamQuery(stream) == cudaSuccess) cout << “Finished”;

// Waiting for finalization
cudaStreamSynchronize(stream);

// Deallocating memory
cudaStreamDestory(stream);

Stream Semantics

stream이 지정되지 않은 경우 기본값인 stream 0이 사용된다.
같은 stream에서 만들어진 두 연산은 만들어진 순서대로 실행된다. 예를 들어 operation A, operation B 순서대로 만들어졌다면 A가 끝날 때 까지 B는 실행되지 않는다.
서로 다른 stream에서 만들어진 두 연산은 순서 없이 실행된다.

`cudaMemcpyAsync()`나 kernel launch를 stream으로 사용하는 것이 일반적이다.

Default Stream (stream 0)

stream이 지정되지 않은 경우 사용되는 stream이다.
default stream은 특별한 synchronization 규칙이 있다.
- host와 device에 대해 100% synchronous하다. 다른 stream에 대해서도 synchronous하다.
- `cudaDeviceSynchronize()`가 모든 CUDA operation 전후에 삽입된 것처럼 보인다.
host에 대해서는 asynchronous하다.
- kernel은 default stream에서 실행된다. 만약 `cudaMemcpyAsync()`나 `cudaMemsetAsync()`를 호출하면 asynchronous하게 실행된다.

Concurrency의 요구사항

CUDA operation은 0이 아닌 서로 다른 stream에 있어야 한다.
`cudaMemcpyAsync()`는 host의 pinned memory와 사용되어야 한다.
- pinned memory는 page locked memory이며, page eviction이 발생하지 않는 memory에 고정된 page이다.
- `cudaMallocHost()`나 `cudaHostAlloc()`으로 할당할 수 있다.
충분한 resource를 사용할 수 있어야 한다.
- `cudaMemcpyAsync()`의 방향이 다르기 때문이다.
- 만약 SM, register, memory, block 등이 충분하지 않지 않다면 concurrency가 발생하지 않는다.

Pinned Memory

pinned memory는 GPU의 exclusive access를 위한 virtual memory page이며, CPU에 할당된다. pinned memory로 지정된 memory는 host virtual memory에서 제거되며, paging의 대상에서 벗어난다. (항상 on memory라고 생각하면 된다.)

CPU나 GPU 사이에서 asynchronous하게 memcopy하며, host와 device copy보다 빠르다.
direct memory access의 방식이기에 asynchronous하다.

사용 방법은 다음과 같다.

`cudaHostAlloc()`과 `cudaFreeHost()`
`cudaHostRegister()`과 `cudaHostUnregister()`

pinned memory

`cudaMemcpy()`와 같이 pinned memory로 할당하지 않는 data transfer는, pageable host memory에서 implicitly pinned memory로 이동한 후 device memory로 이동한다.

반면 pinned memory로 할당한 data transfer는 바로 device memory로 이동한다.

예시 : synchronous

cudaMalloc (&dev1, size);
double *host1 = (double *) malloc(&host1, size);
…
cudaMemcpy(dev, host1, size, H2D);
kernel2<<<grid, block, 0>>>(…, dev2, …);
kernel3<<<grid, block, 0>>>(…, dev3, …);
cudaMemcpy(host4, dev4, size, D2H);
...

위 코드에서 `cudaMemcpy()` 2개 사이에 있는 kernel launch는 100% synchronous이다. default stream의 모든 CUDA operation끼리는 100% synchronous이기 때문이다. kernel launch는 host와 asynchronous이지만 default stream 내에서는 synchronous이다.

예시 : asynchronous

cudaMalloc (&dev1, size)
double *host1 = (double *) malloc(&host1, size);
…
cudaMemcpy(dev, host1, size, H2D);
kernel2<<<grid, block, 0>>>(…, dev2, …);
some_CPU_method();
kernel3<<<grid, block, 0<<<(…, dev3, …);
cudaMemcpy(host4, dev4, size, D2H);
…

위 코드에서 `kernel2<<<grid, block, 0>>>()`과 `some_CPU_method()`는 겹칠 수 있다. GPU kernel launch는 host와 asynchronous이기 때문이다.

cudaStream_t stream1, stream2, stream3, stream4;
cudaStreamCreate(&stream1);
…
cudaMalloc(&dev1, size);
cudaMallocHost(&host1, size); // pinned memory required on host
…
cudaMemcpyAsync(dev1, host1, size, H2D, stream1);
Kernel2<<<grid, block, 0, stream2>>>(…, dev2, …);
Kernel3<<<grid, block, 0, stream3>>>(…, dev3, …);
cudaMemcpyAsync(host4, dev4, size, D2H, stream4);
some_CPU_method();
…

다른 예시이다. 위 코드에서 `cudaMemcpyAsync()`부터 `some_CPU_method()`는 모두 겹칠 수 있다. `cudaMemcpyAsyn()`과 kernel launch에서 stream을 썼기 때문이다. `some_CPU_method()` 또한 겹칠 수 있다.

Explicit Synchronization

모든 것을 synchronize하고 싶을 때 : `cudaDeviceSynchronize()`로 실행할 수 있고, 모든 CUDA call이 완료될 때까지 host를 block한다.
특정 stream에 대해 synchronize하고 싶을 때 : `cudaStreamSynchronize()`로 실행할 수 있고, 모든 stream CUDA call이 완료될 때까지 host를 block한다.
event를 사용해 synchronize하고 싶을 때 : stream 내부에서 event를 사용해 synchronize한다. `cudaEventRecord()`, `cudaEventSynchronize()`, `cudaStreamWaitEvent()`, `cudaEventQuery()` 등이 있다.

Implicit Synchronization

아래 작업들은 CUDA operation을 implicitly synchronize한다.
- paged locked memory allocation : `cudaMallocHost()`, `cudaHostAlloc()`
- device memory allocation : `cudaMalloc()`
- non async version of memory operation : `cudaMemcpy90`, `cudaMemset()`
- L1이나 shared memory로 변경 : `cudaDeviceSetCacheConfig()`

Stream Scheduling

GPU가 stream을 예약하는 방법. Computer Engine Queue, H2D Copy Engine Queue, D2H Copy Engine Queue 3개의 queue가 있다.

CUDA operation은 만들어진 순서대로 hardware에 전달되고, 그리고 관계 있는 queue에 배치된다. kernel launch는 computer engine queue에, memcpy는 관련된 queue에 들어가는 식이다.

engine queue들끼리 stream dependency는 유지되지만, 각각의 engine queue에서는 dependency가 유지되지 않는다.

이후, 아래 조건을 만족할 때 engine queue에서 pop된다.

같은 stream의 이전 호출이 완료되었을 때
- 하나의 stream에는 kernel launch, host2device, device2host operation이 여러 개 있을 수 있다. 예를 들어 이 stream이 kernel launch - host2device - device2host 순서로 호출을 한다고 하자. device2host가 실행되기 위해서는 host2device의 실행이 끝나야 한다! 이런 의미다.
같은 queue에 있는 호출이 전달되었을 때 : 이건 작업 queue에서 순서가 왔을 때 실행할 수 있다는 의미이므로 직관적이다.
resource를 사용할 수 있을 때

서로 다른 stream에 있는 CUDA kernel은 concurrent하게 실행될 수 있다.

주어진 kernel의 thread block은 이전 kernel에 대한 모든 thread block이 예약되었거나, 아직 사용할 수 있는 SM resource가 있을 때 schedule된다.
참고로, blocked operation은 같은 queue의 다른 모든 operation을 block한다.

예시

synchronous : `cudaMemcpy()`
같은 stream일 때 asynchronous : `cudaMemcpyAsync(..., stream1)`로 memory를 옮기고 `foo<<<..., stream1>>>()`로 kernel launch한다.
다른 stream일 때 asynchronous : `cudaMemcpyAsync(..., stream1)`로 memory를 옮기고 `foo<<<..., stream2>>>()`로 kernel launch한다.

예시 : Blocked Queue

2개의 stream이 있다고 하자. stream 1은 HDa1, HDb2, K1, DH1 순서고, stream 2는 DH2 작업이 있다고 하자.

stream 1이 먼저 만들어진 경우

stream 1이 먼저 만들어진 경우 execution은 오른쪽 그림과 같다.

queue는 dependency를 관리하지 않기에, queue의 signal이 synchronization을 만든다. 각 stream의 CUDA operation은 아래 조건을 만족할 때 실행된다.

이후, 아래 조건을 만족할 때 engine queue에서 pop된다.
- 같은 stream의 이전 호출이 완료되었을 때
- 같은 queue에 있는 호출이 전달되었을 때
- resource를 사용할 수 있을 때

때문에 stream 1이 모두 실행된 후 stream 2의 DH2가 실행된다.

stream 2가 먼저 만들어진 경우

반면 stream 2가 먼저 만들어진 경우 실행은 위와 같다.

stream 2의 DH2가 실행되고, 동시에 steam 1의 HDa1은 이전 호출이 없고, H2D queue도 비었고, 작업을 사용할 수 있으므로 HDa1을 실행한다.

때문에 stream 1의 HDa1과 stream 2의 DH2가 concurrrent하게 실행된다.

예시 : 다른 blocked kernel

만약 두 stream이 CUDA kernel을 호출하기만 한다고 하자. 그러면 stream 1은 Ka1, Kb1이고 Stream 2는 Ka2, Kb2이다.

depth vs width

이 때 kernel이 작아서 SM의 절반을 채울 수 있다고 하자. 그러면 depth부터 먼저 적용하면 runtime은 3이고, breath를 먼저 적용하면 runtime은 2가 된다.

반면 각 kernel의 크기가 다른 경우 위와 같다. depth를 우선순위로 두면 runtime은 5, breath를 우선순위로 두면 runtime은 4가 된다. 개발자가 적당히 잘 조절하면 3까지도 줄일 수 있다.

Concurrency Guideline

cost가 높은 GPU 작업을 pipelining하기 위해 CUDA stream과 asynchronous API를 사용한다.
issue order에 따라 실행 결과가 크게 달라지기 때문에 주의해야 한다.
concurrrency를 깨뜨릴 수 있는 resource와 operation에 주의해야 한다.

Thead Synchronization

Synchronizing Threads

grid level collective synchronization : global memory를 통해 서로 다른 thread block끼리 communication과 synchronization을 한다.
block level collective synchronization : shared memory를 사용해 thread block끼리 communication과 synchronization을 한다.
warp level collective synchronization : warp level primitive를 사용하면 warp 내의 thread끼리 register를 사용해서 direct communication을 할 수 있다.
fine grained synchronization :
- 만약 2개 이상의 thread가 동시에 같은 shared memory에 접근하고, 하나 이상의 thread가 write operation을 수행할 때 race condition이 발생한다.
- synchronization하지 않는다면 update가 사라지게 되므로 예측할 수 없는 동작이 발생한다.
- non-deterministic fine grained communication의 경우 kernel launch나 barrier가 동작하지 않는다.

Warp Level Synchronization

__syncwarp()

`__syncwarp()` : warp 내의 thread를 synchronize하는 데 사용하는 함수로, parameter로 넣은 mask에 해당하는 모든 wap 내의 thread가 `__syncwarp()`를 호출할 때까지 기다린다.

Atomics

필요성

제일 일반적인 문제는 shared data에 read-modify-write를 할 때 race condition이 발생한다는 것이다. 특히 transaction이나 data access에 대해! 이를 위해 data aggregation과 enumeration을 한다.

Atomic Operation

CUDA는 여러 thread에서 접근하는 shared variable에 대한 atomic function을 제공한다. 이는 다른 thread의 중단 없이 memory를 atomic하게 수정하는 방식으로 동작한다.

이를 통해 동시에 만들어진 atomic update가 수행되고, 모든 thread가 update 결과를 볼 수 있다는 것을 보장한다.

access는 serialize되어 한 번에 하나의 thread만 접근하고 나머지는 대기하는 방식이다.

CUDA에서 Atomic Operation

단일 instruction으로 변환되는 function를 호출해 쓸 수 있다. `atomicAdd()`, `atomicSub()`, ... 등등이 있다.
- 예를 들어 `atomicAdd()`의 경우 원래 global/shared memory에 있는 값을 읽고, 거이에 값을 더하고 저장한다.

Atomic의 성능 효과

atomics는 일반적인 memory load/store보다는 느리다.
- shared memory에 있는 변수에 대해서는 빠르지만 global memory에 있는 변수에 대해서는 느리다.
많은 thread가 몇몇 작은 위치에 atomic operation을 사용할 경우 성능 저하가 있을 수 있다.
더 많은 parallelism과 locality를 만들기 위해 hierarchy를 만든다.
가능할 때마다 synchronization을 피하기 위한 자료구조가 필요하다.

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

[이종병렬컴퓨팅] Memory와 Data Locality - Tiled Multiplication & Unified Memory

hyelie — Fri, 27 Oct 2023 00:38:37 +0900

이 글은 포스텍 성효진 교수님의 이종병렬컴퓨팅(CSED490C) 강의를 기반으로 재구성한 것입니다.

이 글에서는 다음과 같은 내용들을 살핀다.

CUDA memory를 효율적으로 사용하는 방법
- memory access 효율이 performance에 미치는 영향
- 다양한 memory의 수명
tiled parallel algorithm
matrix multiplication - tiled multiplication kernel
unified memory

Introduction

Matrix Multiplication

__global__ void MatrixMulKernel(float* M, float* N, float* P, int Width) {
    // Calculate the row index of the P element and M
    int Row = blockIdx.y*blockDim.y+threadIdx.y;
    
    // Calculate the column index of P and N
    int Col = blockIdx.x*blockDim.x+threadIdx.x;
    
    if ((Row < Width) && (Col < Width)) {
        float Pvalue = 0;
        // each thread computes one element of the block sub-matrix
        for (int k = 0; k < Width; ++k) {
            Pvalue += M[Row*Width+k]*N[k*Width+Col];
        }
        P[Row*Width+Col] = Pvalue;
    }
}

M, N이 given, P가 output일 때, 지난 포스팅에서 배운 내용으로 matrix multiplication을 구현하면 위와 같을 것이다. if문 검사하는 부분은 matrix size가 input size의 배수가 아닐 수 있기 때문에 하는 검사 로직이다.

곱하는 부분을 그림으로 나타내면 위와 같다.

문제점: GPU의 성능

위 코드의 경우, 모든 thread가 global memory의 `input` matrix에 접근한다.

floating point 곱셈과 덧셈 연산에서 2번의 memory access가 발생한다.
각 floating point operation Flops당 4byte의 memory bandwidth가 발생한다.

그러면 이 때 GPU가 600GB/s DRAM이고, GPU는 1.6TFlops - 초당 1.6T개의 floating point operation - 를 할 수 있다고 가정하자.

GPU가 가지는 1.6TFlops를 모두 감당하기 위해서는 4 * 1.6 = 6.4TB/s의 bandwidth가 필요하다.
가정한 memory bandwidth는 600GB/s이므로, 150GFlops밖에 하지 못한다.

즉, floating point 연산 속도에 비해 memory bandwidth가 크게 못미치는 상황이다. 따라서, 1.6TFlops에 근접하기 위해서는 memory access를 줄여야 한다.

Cuda Memory Hierarchy

CUDA memory hierarchy

CUDA memory hierarchy는 위와 같다.

각 thread는
- thread별 register에 1-2 cycle만에 read/write할 수 있다.
- thread별 local memory에 약 500 cycle만에 read/write할 수 있다.
- block별 shared memory에 10 cycle만에 read/write할 수 있다.
- grid별 global memory에 500 cycle만에 read/write할 수 있다.
- grid별 constant memory나 texture memory에 100 cycle만에 read only할 수 있다.

CUDA의 Variable Type

CUDA variable type

LocalVar는 thread의 register에 저장되고, thread가 끝나면 사라진다.
`__shared__`로 선언하는 SharedVar는 shared memory에 저장되고, thread block이 끝나면 사라진다. thread block당 하나가 생성된다.
`__device__`로 선언하는 GlobalVar는 global memory에 저장되고, grid, 즉 application이 끝나면 사라진다.
`__constant__`로 선언하는 ConstantVar는 constant memory에 저장되고, application이 끝나면 사라진다.

Variable의 선언 위치

host가 접근해야 하는지 여부에 따라 variable을 어디에 선언하는지가 달라진다.
- True면 function 밖에 선언한다. `__constant__`나 `__device__`로 선언한다.
- False면 kernel 안에 선언한다. `LocalVar`나 `__shared__`로 선언한다.

Memory Type에 따른 전략

read only : constant memory에 둔다. 이는 64KB 이하의 작은, thread가 공유하는 read only data인 경우 좋다. 빠르다.
block 내부에서 공유하고, read/write하는 경우 : local memory 또는 shared memory에 둔다. 빠르다.
각 thread에서 read/write하는 경우 : thread register에 둔다. 빠르다.
각 thread 내부에서 indexed read/write하는 경우(array인 경우) : thread-local memory에 둔다. 느리다.
- 따라서 array를 쓰는 경우 global memory에 두고 shared memory로 가져오는 편이 좋다.
input/result read/write : global memory에 둔다. 느리다.

GPU의 Shared Memory

kernel 코드에서 explicitly하게 정의되고 사용되는 특별한 memory이다. 즉 프로그래머가 직접 관리해야 하는 memory이다. L2 cache는 공개 cache이기 때문에 많은 thread가 모두 공유하는데, GPU의 경우 thread가 매우 많기 때문에 L2 cache에 caching되더라도 evict될 확률이 너무 높다. 따라서 L2 cache만을 사용해서 locality를 제공하는 것은 한계가 있다.

각 SM당 하나씩 있다.
access 및 sharing의 범위는 thread block이다.
lifetime은 thread block이다. 즉, thread block의 실행이 끝나면 내용이 사라진다.
explicitly하게 memory load/store instruction을 호출해야 한다.
scratchpad memory라고도 불린다.
직접 관리하는 cache라고 보면 된다.

Cache vs Shared Memory

cache와 shared memory

cache	shared memory
hardware과 관리한다.	software가 관리한다. (별도의 address space를 사용하므로 cache 나 global memory와 공유하지 않는다.)
tag matching으로 인해 overhead가 있다.	전력 소비량이 낮고, directly addressed이다.
implicit하게 data가 이동한다.	explicit하게 data가 이동한다.
replacement policy를 따르기 때문에 memory 낭비가 발생할 수 있다.	작고 효율적이다.

예시: Shared Memory의 필요성

// motivate shared variables with Adjacent Difference application
// compute result[i] = input[i] – input[i-1]
__global__ void adj_diff_naive(int *result, int *input) {
    // compute this thread’s global index
    unsigned int i = blockDim.x * blockIdx.x + threadIdx.x;
    
    if (i > 0) {
        // how many times does this kernel load input[i]?
        int x_i = input[i]; // once by thread i
        int x_i_minus_one = input[i-1]; // once by thread i+1

        result[i] = x_i – x_i_minus_one;
    }
}

위 코드는 인접한 index의 차이를 result에 넣는 kernel function이다.

이 경우, input[i]는 thread i에 의해 한 번, thread i+1에 의해 또 한 번 불러진다. 그러나 input은 global memory에 있기 때문에 느리다! 따라서 이러한 중복된 global memory access를 줄이는 것이 shared memory의 목표이다.

Barrier Synchronization

barrijer synchronization

`__syncthreads()` 함수를 사용해 한 thread block에 있는 모든 thread가 해당 barrier에 도착하면 모든 thread가 도착할 때까지 기다리게 할 수 있다.

Shared Memory의 사용법

static allocation과 dynamic allocation 2가지가 있는데, 둘 다 예시를 통해 살펴볼 것이다.

예시 : Shared Memory Fixed Allocation

// optimized version of adjacent difference
__global__ void adj_diff(int *result, int *input)
{
    int tx = threadIdx.x; // shorthand for threadIdx.x
    
    // allocate a __shared__ array, one element per thread
    __shared__ int s_data[BLOCK_SIZE];
    // each thread reads one element to s_data
    unsigned int i = blockDim.x * blockIdx.x + tx;
    s_data[tx] = input[i];
    
    // avoid race condition: ensure all loads
    // complete before continuing
    __syncthreads(); // thread block 내의 모든 thread의 실행이 끝난 것을 보장한다. 즉, s_data에 모든 값이 잘 들어갔음을 보장한다.
    
    if (tx > 0)
    	result[i] = s_data[tx] – s_data[tx–1];
    else if (i > 0) // tx == 0 && i > 0
    {
        // handle thread block boundary
        result[i] = s_data[tx] – input[i-1];
    }
}

이 경우 fixed size allocation으로 shared memory를 사용하는 예시이다. fixed allocation인 만큼 BLOCK_SIZE로 s_data를 할당했으며, BLOCK_SIZE는 thread block size와 동일하다. (one element per thread이므로)

shared memory 부분에는 `s_data[tx] = input[i]`로 수행되었는데, s_data의 경우 tx로 indexing하고 input의 경우 i로 indexing했다. tx는 thread index이고, i는 전체에서 실행 중인 thread의 index이다. 이렇게 한 이유는, shared memory는 thread block 내에서 공유하기 때문에 s_data를 tx로 indexing하기 때문이다.

이후에는 `__syncthread()`를 호출하는데, 다음 단계로 진행하기 전에 barrier를 만들어 s_data에 모든 data가 들어갔는지 보장하기 위해 사용한다. 만약 `__syncthread()`가 없다면 data가 아직 들어오지 않았을 수 있기 때문에 다음 코드에서 문제가 생긴다.

이후의 if문에서는 shared data에 접근해서 값을 계산한다. 이 코드에서는 `result[i] = ...`와 같이 global memory에 값을 1번 쓰고 있는데, 오직 1번의 global memory write만 하므로 괜찮다. (문제가 되는 것은 여러 번 access할 때이므로)

else if문에서는 `result[i] = s_data[tx] - input[i-1];`의 방식으로, s_data는 shared memory에 접근하고 input은 global memory에 접근하는데, tx == 0인 경우는 해당 thread block의 shared memory에 저장되지 않은 input[i-1]의 값이 필요하다. 즉, 다른 thread block의 data를 필요로 하는 경우가 있기 때문에, 이 경우만 예외적으로 처리해 준다.

예시 : Shared Memory의 Dynamic Allocation

/ when the size of the array isn’t known at compile time...
__global__ void adj_diff(int *result, int *input)
{
    // use extern to indicate a __shared__ array will be
    // allocated dynamically at kernel launch time
    extern __shared__ int s_data[];
    ...
}

// pass the size of the per-block array, in bytes, as the third
// argument to the triple chevrons
adj_diff<<<num_blocks, block_size, block_size * sizeof(int)>>>(r,i);

dynamic allocation을 하기 위해서는 아래 2가지를 지켜야 한다.

kernel의 ` __shared__` 앞에 `extern`을 붙여 써야 한다.
kernel launch를 할 때 shared memory 크기를 지정해 줘야 한다.
- shared memory는 thread block에 할당되며, SM이 하나의 thread block을 실행한다. kernel launch에서 shared memory 크기를 알려 주고, 이를 통해 scheduler가 applicatoion 전체에서 필요한 공간을 계산한다.

예시 : Shared Memory에 여러 개의 Dynamic Array

extern __shared__ int s[];
int *integerData = s; // nI ints
float *floatData = (float*)&integerData[nI]; // nF floats
char *charData = (char*)&floatData[nF]; // nC chars
...

//kernel launch from host
myKernel<<<gridSize, blockSize,
nI*sizeof(int)+nF*sizeof(float)+nC*sizeof(char)>>>(...);

만약 여러 개의 array를 사용하고 싶다면 위 코드와 같이 하나의 큰 array를 할당한 후, pointer를 사용해 나누어야 한다.

Tiling

Tiling이 없는 경우

tiling 없이 memory access pattern

앞서 살펴본 matrix multiplication은 같은 element에 중복해 접근하는 일이 많았고, 이 중복이 모두 global memory access였다. 각 thread는 M과 N을 width번 호출한다. 호출 위치가 global memory이기 때문에 상당히 느리다.

Tiling을 쓰는 경우

tiling 사용했을 때 memory access pattern

global memory를 tile을 기준으로 나누고, 각 thread 또한 tile에만 집중해서 계산하는 방식이다. 이 방법을 사용하면 global memory를 중복해 호출하는 회수를 줄일 수 있다.

이 구현은 L1 cache나 L2 cache를 사용해 caching effect를 극대화 할 수도 있고, shared memory(scratchpad)를 사용할 수도 있다.

Synchronization

synchronization

단, 이 방식은 synchronization이 필요하다.

위 경우, 같은 element에 2개의 thread가 비슷한 시간대에 접근하고 있다. 반면, 아래 경우 같은 element에 2개의 thread가 매우 다른 시간대에 접근하고 있다. 아래 경우는 cache effect를 받지 못하고, 그만큼 on chip memory에 데이터를 계속 올려둬야 하기에 좋지 않은 모델이다.

따라서, thread들이 비슷한 시간에 access할 때 좋다.

요약

global memory access는 on chip memory보다 느리기 때문에 이 global memory access 대신 shared memory access를 사용한다.

global memory content에 사용할 tile을 만든다.
global memory에서 shared memory로 tile을 가져온다.
thread는 shared memory에 access해서 계산한다.
synchronization을 위해 barrier를 사용한다.
(필요 시) shared memory에서 global memory로 계산 결과를 복사한다.
다음 tile로 이동한다.

Tiling : Matrix Multiplication

tiling의 종류에는 크게 2가지, input tiling과 output tiling이 있다.

output tiling은 output matrix를 tile 기준으로 나누고 thread block에 매핑하는 방식이다. 반면 input tiling은 input matrix를 tile 기준으로 나누는 방식이다.

Output Tiling

output tiling 예시

output tiling은 위 그림처럼 output matrix을 tile로 나누고, 이 tile을 thread block에 할당하는 방식이다. thread block을 output matrix에 매핑하는 것이다.

그러면 하나의 thread block은 하나의 output tile을 계산한다. 일반적으로 thread block을 tile과 동일한 크기로 잡으므로, thread block은 output matrix에서 하나의 element를 계산하게 된다. 그러면 각 thread는 M의 row와 tile에 해당하는 N의 column에 access한다. 위 그림에서는 Md, Nd로 표현되었다.

예제: Output Matrix를 Thread Block에 매핑

tile

TILD_WIDTH * TILD_WIDTH 크기의 thread block을 선언한다. 그러면 각 thread block에는 TILD_WIDTH$^2$개의 thread가 들어가고, thread block은 총 $\frac{\text{WIDTH}}{\text{TILE_WIDTH}}^2$개가 존재한다.

위 예시는 WIDTH가 4, TILD_WIDTH가 2인 예시이다.

Memory Layout

indexing

이전 포스팅에서 다뤘듯 모든 n-D memory는 1D array로 평면화된다. 따라서 indexing을 해야 한다.

예를 들어 위 그림에서 M$_2, _1$에 접근하기 위해서는 2 * WIDTH + 1에 접근해야 한다.

코드

__global__ void MatrixMulKernel(float* M, float* N, float* P, int Width) {
    // Calculate the row index of the P element and M
    int Row = blockIdx.y*blockDim.y+threadIdx.y;
    
    // Calculate the column index of P and N
    int Col = blockIdx.x*blockDim.x+threadIdx.x
    
    if ((Row < Width) && (Col < Width)) {
        float Pvalue = 0;
        // each thread computes one element of the block sub-matrix
        for (int k = 0; k < Width; ++k) {
            Pvalue += M[Row*Width+k]*N[k*Width+Col];
        }
        P[Row*Width+Col] = Pvalue;
    }
}

void MatrixMulOnDevice(float* M, float* N, float* P, int Width) {
    int size = Width * Width * sizeof(float);
    cl_mem Md, Nd, Pd;
    cudaMalloc((void**) &Md, size);
    cudaMalloc((void**) &Nd, size);
    cudaMalloc((void**) &Pd, size);
    
    cudaMemCpy(Md, M, size, cudaMemcpyHostToDevice);
    cudaMemCpy(Nd, N, size, cudaMemcpyHostToDevice);
    cudaMemset(Pd, 0, size);

    // kernel invocation code
    ...

    // Read P from the device
    cudaMemCpy(P, Pd, size, cudaMemcpyDeviceToHost);

    // Free device matrices
    cudaFree(Md);
    cudaFree(Nd);
    cudaFree(Pd); 
}

output tiling의 코드는 위와 같다.

`MatrixMulOnDevice`에서 `cudaMalloc()`, `cudaMemcpy()`, `cudaMemset()`을 호출해 M, N, P를 초기화한다. 이후 `cudaMemcpy()`를 호출해 Pd를 P에 복사하고 있다.
`MatrixMulKernel`은 M의 모든 row, N의 모든 column으로 output tile의 한 element에 들어갈 값들을 계산한다. 이게 한 thread에서 수행하는 일이고, TILE_WIDTH * TILE_WIDTH개의 thread... 즉 thread block이 `MatrixMulKernel`을 실행하면 하나의 output tile의 모든 element를 계산하게 된다.

Input Tiling

tiled matrix multiplication

input tiling은 input을 tile로 나누는 방법이다.

output tiling에서는 M의 모든 row, N의 모든 column으로 P의 한 element를 계산했는데 여기서는 그 방법 대신 M의 tile, N의 tile을 사용한다.

input tiling에서는 각 thread의 실행을 phase로 나눈다. 그러면 각 phase에서 thread가 접근하는 data가 M의 tile 1개, N의 tile 1개에 집중된다. 위 그림에서는 처음에는 파란색 tile의 곱을 계산하고, 이후에는 주황색 tile의 곱을 계산한다.

물론 한 번의 tile의 곱으로 완벽한 결과를 내지 못한다. 모든 tile의 연산이 끝나야 올바른 결과가 나온다.

대신, 하나의 thread가 하나의 element의 결과를 연산하는 것이 아니라, shared memory에 올린 모든 data, 그러니까 tile에 해당하는 모든 data에 대해 연산한다. 따라서, 각 tile을 shared memory에 올리고 - 이것은 thread block의 모든 thread가 공유한다 - 각 thread는 shared memory를 참조하면서 결과를 계산한다는 것이 input tiling의 기본 골자이다.

예시

phase 0 : block load

M의 tile 1개와 N의 tile 1개를 각각 shared memory에 넣는다. 그러면 각 thread block은 자신만의 tile을 가지게 된다.

phase 0 : block (0, 0)을 계산

loading이 끝나면 shared memory에 로딩된 block (0, 0)을 사용해 계산한다. 여기서 계산의 결과값은 최종값이 아니다.

왼쪽 그림은 iteration 0으로 M의 column 0과 N의 row 0 - M$_0, _0$과 M$_1, _0$, N$_0, _0$과 N$_0, _1$ - 을 사용한다.
오른쪽 그림은 iteration 1로, M의 column 1과 N의 row 1 - M$_0, _1$과 M$_1, _1$, N$_1, _0$과 N$_1, _1$ - 을 사용한다.
그냥 단순히 matrix multiplication이다! (각 iteration은 ijk matrix multiplication에서 k를 의미한다고 생각하면 된다.)

phase 1 : block load

block (0, 0)은 아직 계산이 덜 되었다. 이전에 계산한 tile 말고, 다른 M의 tile 1개와 N의 tile 1개를 shared memory에 넣는다.

phase 1 : block (0, 0)을 계산

shared memory에 있는 값으로 block (0, 0)을 계산한다. 세부 내용은 위와 동일하다.

Indexing

input tiling index

2D의 경우
- M[row][m*TILE_WIDTH + tx]
- N[m*TILE_WIDTH+ty][col]
1D로 바꾸면
- M[row*WIDTH + m*TILE_WIDTH + tx]
- N[(m*TILE_WIDTH+ty)*WIDTH + col]
참고로 row = `blockIdx.y * blockDim.y + threadIdx.y`, `col = blockIdx.x * blockDim.x + threadIdx.x`이다.

여기서 m = for loop의 iteration index.

Boundary Check

boundary check

1D에서 처리했던 것과 마찬가지로 WIDTH가 TILE_WIDTH의 배수가 아닐 수 있기 때문에 이에 관한 예외 처리를 해야 한다. 만약 하지 않는다면, 값을 넣지 않은 공간을 계산하기 때문에 결과가 달라질 수 있다.

이를 수행하는 방법은 아래와 같다.

index를 계산하고, valid한지 검사한다. 구체적으로는, M의 row, column에 대해 / N의 row, column가 모두 Width보다 작은지 검사한다.
범위를 벗어나는 것에 대해서는 0을 둔다. 이는 결과에 영향을 미치지 않기 때문이다.

// Loop over the M and N tiles required to compute the P element
for (int p = 0; p < ((Width-1)/TILE_WIDTH)+1; ++p) {
    __shared__ float ds_M[TILE_WIDTH][TILE_WIDTH];
    __shared__ float ds_N[TILE_WIDTH][TILE_WIDTH];

    int bx = blockIdx.x;
    int by = blockIdx.y;
    int tx = threadIdx.x;
    int ty = threadIdx.y;
    int Row = by * blockDim.y + ty;
    int Col = bx * blockDim.x + tx;
    float Pvalue = 0;
    
    // Loop over the M and N tiles required to compute the P element.
    for (int p = 0; p < ((Width-1)/TILE_WIDTH)+1; ++p) { // phase
        // Collaborative loading of M and N tiles into shared memory
        if (Row<Width && p*TILE_WIDTH+tx < Width) {
            ds_M[ty][tx] = M[Row*Width + p*TILE_WIDTH+tx];
        } else {
            ds_M[ty][tx] = 0.0;
        }

        if (p*TILE_WIDTH+ty < Width && Col<Width) {
            ds_N[ty][tx] = N[(p*TILE_WIDTH+ty)*Width + Col];
        } else {
            ds_N[ty][tx] = 0.0;
        }
    }
    
    __syncthreads(); // 모든 data가 shared memory에 저장된 것을 보장
    
    if (Row < Width && Col < Width) {
        for (int i = 0; i < TILE_WIDTH; ++i)
            Pvalue += ds_M[ty][i] * ds_N[i][tx];
        }
    }
    __synchthreads(); // 모든 data가 계산된 것을 보장
    
    if (Row < Width && Col < Width)
    	P[Row*Width+Col] = Pvalue;
}

그러면 코드는 위와 같다.

`__syncthread()`를 사용하는 이유는 위와 같이, 모든 data가 shared memory에 저장된 것을 보장하고, 모든 data가 계산된 것을 보장하기 위해 사용한다.

첫 번째 `__syncthread()`는 thread의 실행 속도가 다르기 때문에 모든 data가 shared memory에 저장된 것을 보장한다.
두 번째 `__syncthread()`는 모든 data가 계산된 것을 보장한다. 만약 이것이 없다면 다음 phase에서 다른 값을 집어넣고, pvalue를 계산할 수 있기 때문에 꼭 필요하다.

for문에서 `p < (Width-1) / TILE_WIDTH + 1`는 phase의 ceil을 취한 것이다.

Tile Size 결정

tiling multiplication을 하면 TILE_WIDTH만큼의 global memory access 회수를 줄일 수 있다. 원래 구현이 N$^3$이라면, tiling multiplication에서는 2N$^2$ * $\frac{\text{N}}{\text{TILE_WIDTH}}$이다.

각 thread block은 TILE_WIDTH * TILE_WIDTH개의 thread를 가진다. 예를 들어 TILE_WIDTH가 16이면 16$^2$ = 256개의 thread를 가진다.

이 때, 각 thread block이 실행하는 연산 회수는 다음과 같다.

M에 대해 1번, N에 대해 1번, 총 2 * [thread 개수]만큼의 float load
for문에서 TILE_WIDTH * [thread 개수] 만큼의 multiply, TILE_WIDTH * [thread 개수]만큼 add operation, 총 2 * TILE_WIDTH * [thread 개수]만큼의 mul/add
그러면 1번의 load에 대해 TILE_WIDTH만큼의 연산을 할 수 있다.

그러나 무작정 TILE_WIDTH를 늘린다고 좋은 것은 아니다. shared memory size가 한정되어 있기 때문이다.

예를 들어 SM당 shared memory가 16KB라고 하자.

만약 TILE_WIDTH가 16이면 각 thread block은 2 * 16 * 16 * 4byte = 2KB의 shared memory를 사용하게 된다. 즉, 한 번에 8개의 thread block만 사용할 수 있다. 그러면 8 * 2 * [thread 개수]만큼의 pending load가 발생한다.
반면 TILE_WIDTH가 32면 각 thread block은 2 * 32 * 32 * 4byte = 8KB의 shared memory를 사용하게 된다. 즉, 한 번에 2개의 thread block을 사용할 수 있다. 그러나 GPU의 SM당 thread는 1536개로 제한되어 있으므로 SM당 block 수가 1개로 줄어든다. 한계는 1536인데 실제로 사용하는 것은 1024개로, thread의 낭비가 발생한다!

이처럼 shared memory size가 active thread의 개수를 한정하므로, 일반적으로는 thread block이 많은 것이 더 좋을 것이다. 그렇지만 thread block의 크기가 커지면 global memory access 회수가 줄어들므로 중간지점을 잘 잡아야 한다.

Unified Memory

unifired memory

높은 programmability를 위해 성능을 조금 향상한 것. GPU와 CPU 둘 다에서 사용할 수 있는 통합용 메모리이다. 잘못 사용하는 경우 성능이 급격하게 떨어지기 때문에 잘 사용해야 한다.

특히 tree나 graph traversal과 같은 몇몇 알고리즘은 GPU에서 돌리기 어려운데, unified memory는 이를 가능하게 한다.

이외에도 아래와 같은 특징들이 있다.

더 큰 memory를 제공한다 : GPU memory size보다 더 큰 data를 가져올 수 있다. paging mechanism을 사용해 GPU memory에 올리는 방식이다.
data access가 더 쉽다 : CPU/GPU data coherence가 보장된다.
unified memory는 programmability를 위한 것이기 때문에 user API가 많다. 예를 들어 cudaMemAdvise()는 어떤 memory에 접근하는지 hint를 제공하며 이를 바탕으로 성능을 향상시킨다. prefetching이라 생각하면 된다.

예시 : Unified Memory를 사용하지 않은 경우

unified memory를 사용하지 않은 경우

`cudaMalloc()`을 사용해 GPU memory를 할당하고, `cudaMemcpy()`로 data를 복사하고, CUDA kernal launch 한다. 이후 `cudaMemcpy()`를 사용해 결과값을 CPU memory로 다시 가져오고, `cudaFree()`로 GPU memory를 해제해야 한다.

예시 : Unified Memory를 사용한 경우

unified memory를 사용하는 경우

코드가 훨씬 줄어든다. `cudaMallocManaged()`를 사용해 unified memory를 사용한다는 것을 알린다. 이 때 pointer는 CPU와 GPU 둘 다에서 사용할 수 있다. 이후 같은 pointer를 사용해 kernel launch한다. 이후 `cudaDeviceSynchronize()`로 data 처리 결과값을 받아온다. 마지막으로 `cudaFree()`한다.

cudaMemcpy()는 synchronous이므로 추가적인 synchronize method가 필요없다. 반면 unified memory를 사용하는 경우 barrier를 사용한 synchronize가 필요하다.

작동 방식

위 코드 예시에서 볼 수 있듯 `cudaMallocManaged()`로 호출하며, demand paging 방식으로 작동한다.

`cudaMallocManaged()`을 호출하면 GPU에 memory를 할당하고, CPU memory에 할당된 data를 GPU memory로 내부적으로 알아서 옮겨준다. 이 때, CPU에서 값을 수정한 후 GPU에서 접근하면 알아서 값을 옮겨준다. 그 반대도 마찬가지다.

한편 page fault는 overhead가 크기 때문에 unified memory는 느릴 수 밖에 없다.

요약

memory와 data locality... 즉 memory hierarchy가 GPU의 성능을 결정한다. 일반적으로 GPU의 계산 속도는 빠르지만 memory bandwidth가 훨씬 작기 때문에 memory bandwidth를 덜 사용하는 것으로 throughput을 높일 수 있다.

이를 위해 `__shared__` - shared memory를 사용해 중복 global memory access를 줄이며, 이를 통해 memory bottleneck을 해소해 throughput을 높인다.

또한, architectural trend는 portability를 높이고 programming에 대한 부담을 줄이는 쪽으로 발전하고 있다. 때문에 unified memory 등 방법이 고안되었다.

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

[이종병렬컴퓨팅] CUDA Basics

hyelie — Thu, 26 Oct 2023 19:31:00 +0900

이 글은 포스텍 성효진 교수님의 이종병렬컴퓨팅(CSED490C) 강의를 기반으로 재구성한 것입니다.

이 글에서는 CUDA programming language를 사용하는 방법을 알아본다.

CUDA

CUDA는 NVIDIA GPU 전용 software이다. 기본적으로는 C/C++이며 여기에 몇몇 library를 추가해서 쓸 수 있다.

CUDA kernel을 사용하고 실행하는 방법
GPU memory를 관리하는 방법
communication과 synchronization을 관리하는 방법

Host와 Device

host memory : CPU의 memory
device memory : GPU의 memory

heterogeneous computing은 serialize한 부분과 parallel한 부분이 나뉜다. serialize한 부분은 CPU가, parallel한 부분은 GPU가 실행한다.

Heterogeneous Computing의 단계

heterogenous computing 단계

실행되는 방법은 크게 아래와 같다.

CPU memory에 있는 data를 GPU로 옮긴다.
kernel(GPU program)을 실행한다. 그러면 GPU는 안에 있는 cache에 값을 쓴다.
필요 시 GPU memory에 있는 결과를 CPU로 옮긴다.

CUDA Programming

Hello World!

__global__ void mykernel(void) {
}

int main(void) {
    mykernel<<<1,1>>>();
    printf("Hello World!\n");
    return 0;
}

위 코드에서 `__global__`로 선언한 함수가 GPU에서 실행된다. 이를 호출하기 위해서는 기본적인 function call과 동일하지만 `<<<>>>`를 추가해야 한다. 여기에 들어가는 숫자는 grid의 크기, thread block의 크기이며 작업을 어떤 단위로 나눌지에 대한 숫자인데, 후술하겠다.

이 코드가 컴파일되면 `__global__`이 붙은 부분은 nvcc가 컴파일하며, GPU에서 실행시키기 위해 한 binary executable file로 바뀐다. 나머지 부분은 gcc가 컴파일하며, CPU에서 실행시키기 위해 또다른 binary executable file로 바뀐다.

`mykernel<<<1,1>>>()` 이 부분을 kernel launch라고 하며, 이 코드가 GPU에서 실행된다.

Vector Addition

__global__ void add(int *a, int *b, int *c) {
    *c = *a + *b;
}

vector addition을 위해서는 위와 같이 코드를 쓴다.

이 때 a, b, c는 GPU에서 실행되기 때문에 device memory에 올라가 있어야 한다. 따라서 GPU에 미리 값을 올려 두어야 한다.

Memory Management

host memory와 device memory는 별개이다.

즉, host memory에 있는 값들은 device로 전달되거나 받아올 수 있지만 device에서 dereference되지 않는다. 같은 이유로 device memory에 있는 값들은 host로 전달되거나 받아올 수 있지만 host에서 deference되지 않는다.

이를 위해 `cudaMalloc()`, `cudaFree()`, `cudaMemcpy()`를 사용해 device memory를 할당하고, 해제하고, 복사한다. C의 malloc(), free(), memcpy()와 동일하다.

cudaMalloc ( void** devPtr, size_t size ) : device의 global memory에 memory를 할당한다.
cudaFree ( void* devPtr ) : device의 global memory에서 memory를 할당 해제한다.
cudaMemcpy ( void* dst, const void* src, size_t count, cudaMemcpyKind kind ) : host memory와 device memory에서 정보를 옮긴다. asynchronous하다!
- cudaMemcpyKind는 `cudaMemcpyDeviceToHost`와 `cudaMemcpyHostToDevice`, `cudaMemcpyDeviceToDevice`가 있다.

기본적인 틀

__global__ void add(int *a, int *b, int *c) {
	*c = *a + *b;
}

int main(void) {
	// 1.
    int a, b, c; // host copies of a, b, c
    int *d_a, *d_b, *d_c; // device copies of a, b, c
    int size = sizeof(int);
    
    // 2. Allocate space for device copies of a, b, c
    cudaMalloc((void **)&d_a, size);
    cudaMalloc((void **)&d_b, size);
    cudaMalloc((void **)&d_c, size);
    
    // 3. Setup input values
    a = 2;
    b = 7;
    
    // 4. Copy inputs to device
    cudaMemcpy(d_a, &a, size, cudaMemcpyHostToDevice);
    cudaMemcpy(d_b, &b, size, cudaMemcpyHostToDevice);
    
    // 5. Launch add() kernel on GPU
    add<<<1,1>>>(d_a, d_b, d_c);
    
    // 6. Copy result back to host
    cudaMemcpy(&c, d_c, size, cudaMemcpyDeviceToHost);
    
    // 7. Cleanup
    cudaFree(d_a); cudaFree(d_b); cudaFree(d_c);
    
    return 0;
}

위 코드와 같으며, 글로 표현하면 다음과 같다. 각 method의 사용 방법은 공식 문서를 찾아보는 것이 좋다.

host에 할당될 변수, device에 할당될 변수를 선언한다.
cudaMalloc을 사용해 device에 memory를 할당한다.
host에 값을 쓴다. (필요 시 host에 memory를 할당하고 값을 써야 할 수도 있다.)
cudaMemcpy()를 사용해 host에서 device로 값을 복사한다.
kernel을 호출한다.
kernel의 실행 결과는 device에 있으므로, 이 값을 host로 옮겨온다.
cudaFree()를 사용해 device에 할당한 memory를 해제한다.

Parallel하게 실행하는 방법

Block

__global__ void add(int *a, int *b, int *c) {
	c[blockIdx.x] = a[blockIdx.x] + b[blockIdx.x];
}

add<<<N, 1>>>();

위 코드처럼 `add<<<1, 1>>>()` 대신 `add<<<N, 1>>>()`로 호출하면 add()를 N번 병렬로 실행한다.

이 때 add() 함수의 parallel한 호출을 block이라고 하며, block의 집합을 grid라고 한다. 여기서 N은 block 개수를 의미한다.

이 때 각 호출에서 `blockIdx.x`를 사용해 thread index를 잡을 수 있다.

add<<<4, 1>>>()의 실행 분석

Thread

각 block은 thread로 구성되고, block 내의 thread 또한 parallel하게 동작한다.

__global__ void add(int *a, int *b, int *c) {
	c[threadIdx.x] = a[threadIdx.x] + b[threadIdx.x];
}

add<<<1, N>>>();

위 코드처럼 `add<<<1, N>>>()`로 호출해도 add()는 N번 병렬로 실행한다.

단, 위의 경우는 block-parallel이었지만 여기서는 thread-parallel이다. 때문에 위에서 `blockIdx.x`를 사용한 대신 여기서는 `threadIdx.x`를 사용한다.

Block과 Thread 합치기

그 전에 앞에서 살폈던 개념을 합쳐보자.

thread : sequential한 실행 단위. 따라서 thread는 parallel하게 동작하며, 같은 sequential program을 실행한다.
thread block : thread들의 그룹이다. 하나의 SM - streaming multiprocessor - 에서 실행되며, block 내의 thread는 synchronize할 수 있고, shared memory를 사용해 communication할 수 있기에 synchronization과 data 교환이 빠르다.
grid : thread block의 집합.
- grid의 thread block은 여러 개의 SM에서 실행된다.
- thread block끼리는 synchronization이 일어나지 않는다.
- thread block끼리 communication cost는 매우 높다.

execution model과 hardware

thread는 core에 매핑된다. - core에서 실행된다.
thread block은 SM에 매핑된다 - SM에서 실행된다.
grid는 device에 매핑된다. - device에서 실행된다.

Block끼리는 independent

block끼리는 indepdent여야 한다. synchronization과 communication cost가 매우 높기 때문에 dependency가 없어야 한다. dependency가 없는 경우 순서 없이, parallel하게 실행할 수 있기 때문이다.

ID와 Dimension

thread는 1D, 2D, 3D ID를 가질 수 있으며, block 내부에서 고유하다.

block도 동일하게 1D, 2D, 3D ID를 가질 수 있으며 grid 내부에서 고유하다.

이 dimension은 kernel을 시작할 때 결정한다.

아래와 같은 내장 변수들이 있으며, 이를 사용해서 n차원에 대한 memory addressing을 단순화한다.

threadIdx : `threadIdx.x`, `threadIdx.y`, `threadIdx.z`로 표기하며, 각각 block 내부의 thread index를 의미한다.
blockIdx : `blockIdx.x`, ` blockIdx.y`, ` blockIdx.z`로 표기하며, 각각 grid 내부의 block index를 의미한다.
blockDim : `blockDim.x`, ` blockDim.y`, ` blockDim.z`로 표기하며, block에 있는 thread의 개수를 의미한다.
gridDim : `gridDim.x`, ` gridDim.y`, ` gridDim.z`로 표기하며, grid에 있는 block의 개수를 의미한다.

`dim3` type을 가진 변수들은 dimension을 초기화하기 위해 사용한다. 값을 넣지 않은 것들은 1로 초기화된다. 예를 들어 dim3 `gridDim(256)`이라고 했으면 gridDim.x는 256, gridDim.y와 gridDim.z는 1이다.

예시

grid, block, thread index

위 예시에서 grid 1에는 총 6개의 block이 있다.

gridDim : gridDim.x는 3, gridDim.y는 2, gridDim.z는 1
blockDim : blockDim.x는 5, blockDim.y는 3, blockDim.z는 1
blockIdx와 threadIdx는 그림에 적혀 있다.

Kernel Launch에서 ID

그럼 `func<<<gridDim, blockDim>>>();`를 살펴보자.

gridDim은 grid에 있는 block의 개수를 정의한다.
blockDim은 block에 있는 thread의 개수를 정의한다.

예시

dim3 threadPerBlock(16, 16);
dim3 numBlocks(N/threadsPerBlock.x, N/threadsPerBlock.y);
MatAdd<<<numBlocks, threadsPerBlock>>>(A, B, C);

예를 살펴보자. input은 N by N의 matrix이다.

threadPerBlock, 즉 blockDim은 각 block에 thread를 16 by 16으로 정의하겠다는 것이고,

numBlocks, 즉 gridDim은 grid에 block을 N/blockDim.x by N/blockDim.y로 정의하겠다는 것이다. - 이거는 input을 이렇게 나누어야 모든 input을 처리할 수 있기에 이렇게 두는 것이다.

Dimension 결정

grid와 block의 크기를 설정하기 위해서는 다음과 같은 기준을 따라야 한다.
- 전체 입력을 처리하고, GPU를 busy한 상태로 처리하기 위해서는 충분한 양의 thread가 필요하다.
- block size의 선택은 warp 점유율과 관련한 최적화 단계이다.
무작정 크게 둔다고 좋은 것이 아니라, 한계도 있다.
- grid의 경우 (x, y, z)가 (2$^{31}$ - 1, 65535, 65535)
- thread block의 경우 (x, y, z)가 (1024, 1024, 64)
- block당 thread의 최대 개수는 1024개이다.

Indexing

자. 지금까지 block과 thread에 대해 살펴봤다. indexing을 해 보자.

indexing 예시

위 예시는 block당 8개의 thread를 사용하고 block은 4개를 사용하는 상황이다. 즉 blockDim.x는 8이라는 말!

여기서 thread index를 원하는 위치에 잡는 방법은 `blockIdx.x * blockDim.x + threadIdx.x`이다. 아래 내용을 복기하면서, 왜 이렇게 나오나 생각해보자.

threadIdx : block 내부의 thread index를 의미
blockIdx : grid 내부의 block index를 의미
blockDim : block에 있는 thread의 개수를 의미
gridDim : grid에 있는 block의 개수를 의미

최종 형태

__global__ void add(int *a, int *b, int *c, int n) {
     int index = threadIdx.x + blockIdx.x * blockDim.x;
     if (index < n)
         c[index] = a[index] + b[index];
}

add<<<(N + M-1) / M,M>>>(d_a, d_b, d_c, N);

그러면 최종적으로 위와 같은 형태가 나온다. index를 검사하는 이유는, input이 blockDim의 배수가 아닌 경우가 많기 때문에 이에 대한 예외를 처리하기 위해서이다.

kernal launch는 `(N+M-1)/M, M`으로 되었는데, M은 block에 있는 thread의 개수이고, `(N+M-1)/M`은 N/M의 결과를 올림하기 위한 연산이다.

Managing Device

kernal launch는 asynchronous하다. 때문에 kernal launch 이후 control이 CPU로 바로 돌아온다.

따라서 결과를 사용하기 전에 synchonize를 무조건 해 주어야 한다.

cudaMemcpy() : copy가 끝날 때까지 CPU 실행을 block한다. CUDA call이 끝나야 copy를 시작한다.
cudaMemcpyAsync() : asynchronous하며, CPU를 block하지 않는다.
cudaDeviceSynchronize() : CUDA call이 끝날 때 까지 CPU를 block한다.

기본적으로 host(CPU)가 device(GPU) memory를 관리한다.

Unified Memory Support

unified memory는 system의 모든 processor에서 접근할 수 있는 single address space이다. CPU와 GPU 둘 모두에서 해당 memory에 읽고 쓸 수 있다.

malloc()에 대한 호출을 cudaMallocManaged()로 호출한다.

__global__ void add(int n, float *x, float *y){
    int index = blockIdx.x * blockDim.x + threadIdx.x;
    int stride = blockDim.x * gridDim.x;
    for (int i = index; i < n; i += stride)
    y[i] = x[i] + y[i];
}

int main(void)
    int N = 1<<20;
    float *x, *y,
    cudaMallocManaged(&x, N*sizeof(float));
    cudaMallocManaged(&y, N*sizeof(float));
    … // initialization
    add<<<numBlocks, blockSize>>>(N, x, y);
    …
}

예시 코드는 위와 같다.

CUDA Device Memory Space Overview

CUDA device memory space overview

각 thread들은
- thread별 register에 read/write할 수 있다.
- thread별 local memory에 read/write할 수 있다.
- block별 shared memory에 read/write할 수 있다.
- grid별 global memory에 read/write할 수 있다.
- grid별 constant memory나 texture memory에 read only이다.
host는 global, constant, texture memory에 read/write할 수 있다.

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

[이종병렬컴퓨팅] GPU architectures - NVIDIA

hyelie — Wed, 25 Oct 2023 23:26:14 +0900

이 글은 포스텍 성효진 교수님의 이종병렬컴퓨팅(CSED490C) 강의를 기반으로 재구성한 것입니다.

이 글에서는 다음과 같은 내용들을 살핀다.

GPU architecture의 예시 - NVIDIA

NVIDIA GPU Architecture

용어 정리

NVIDIA	AMD	뜻
kernel	kernel	GPU의 multiple thread에 의해 동작하는 함수. CPU와 parallel하게 동작할 수 있다.
thread block	work group	다른 data에 대해 같은 kernel을 실행하는 thread의 그룹. 단일 SM/CU에서 warp의 그룹으로 실행된다. 내부의 thread끼리는 communicate할 수 있는데 이는 hardward에 의해 지원된다.
thread	work item / thread	warp의 개별 실행 단위
streaming multiprocessor (SM)	compute unit (CU)	parallel ALU를 포함하는 GPU의 parallel vector processor 중 하나.
warp	wavefront	lock step에서 실행되고, 동일한 instruction을 실행하며, 같은 control flow path를 공유하는 작업 단위, mask될 수 있으며, hardward thread에 의해 vectorize된다.

thread block의 크기에 따라, 즉

thread block의 크기가 너무 작은 경우(thread block에 thread 1개) : thread block의 개수가 streaming multiprocessor보다 더 많아져서 scheduling overhead가 너무 커진다.
thread block의 크기가 너무 큰 경우(thread block에 thread 개수가 data size와 동일) : 1개의 thread block, data size개의 thread가 있는 경우 그러면 100개의 streaming multiprocessor가 있더라도 1개밖에 사용하지 못하기 때문에 비효율적이다. 때문에 적당히 나눠야 하며, 나눈 thread block들은 streaming multiprocessor에 적당히 할당되어 실행된다.

NVIDIA Memory Hierarchy

thread, thread block, grid

thread : kernel의 instance로, thread만이 접근할 수 있는 private memory가 있다. thread block 내의 thread ID, PC, register, input/output 결과들이 이 memory에 저장된다.
thread block : 동시에 실행되는 thread의 집합. block별 shared memory가 있으며, barrirer나 shared memory를 통해 communicate한다. thread block을 식별하기 위한 block ID가 있다.
grid : 동일한 kernel을 실행하는 thread block의 array. 즉 grid는 전체 kernel이므로 global memory에 읽고 쓰며, 이를 통해 global synchronization을 한다. 단 thread block의 barrier나 shared memory를 쓰는 것이 훨씬 빠르다.

NVIDIA Fermi

16개의 SM, 총 512개의 core가 있다.

NVIDIA Fermi SM

각 SM은 위 그림과 같이 생겼다. warp scheduler는 2개, 각 warp에는 32개의 thread가 있다. SM에는 2개의 exeuction unit, 32개의 core가 있다.

여기서 core 내부에 register가 있는 것이 아니라 외부에 register가 있기 때문에 각 core는 연산을 하기 위해 register에서 값을 가져오고, register에 값을 쓰는 연산을 했다. core 내부에는 floating point unit과 integer unit 2개가 같이 있었다.

또 shared memory외 L1 cache의 역할을 둘 다 하는 memory가 하나 있다. 현대의 GPU들은 L1 cache용 memory와 shared memory용 memory가 따로 있지만, 그 당시에는 이렇게 사용했다.

Fermi의 Thread Scheduler

chip level : thread block을 SM에 할당한다. (thread block scheduler)
sm level : warp와 warp의 exeuction unit에 대해 작동한다. (warp scheduler)

warp scheduler는 한 cycle에 warp에서 하나의 instruction을 가져온다. 이 방식은 매 cycle마다 다른 warp에서 instruction을 가져오기에 fine grained multithreading이다. 이 방식을 사용하면 thread instruction 간의 dependency를 신경쓰지 않아도 된다는 장점이 있다.

Fermi Memory Hierarchy

fermi memory hierarchy

host memory는 CPU의 memory이며, host memory는 device memory와 연결되어 있다. 따라서 CPU에서 사용한 값을 GPU에서 사용하기 위해서는 host memory에서 device memory로 옮기는 과정이 필수적이다.
L2 cache는 모든 thread에 의해 공유되며, 모든 SM이 이 memory에 있는 값을 볼 수 있다. synchornization variable이 L2 cache에 있으면 더 빨리 쓸 수 있기 때문에 필요하다.
모든 SM에는 L1 cache가 있다. 앞서 언급했듯 이 시대의 L1 cache와 shared memory는 하나로 합쳐져 작동했다.
- 여기서 shared memory는 user-managed cache이며, 사용자가 값을 caching할 memory이다. 특정 값을 저장하기 위해 programmer가 explicit하게 값을 저장하는 공간이다.
Register는 위 그림에서는 분리되어 있는 것처럼 보이지만 실제로는 매우 큰 register가 SM별로 할당되어 있는 것이다.
한 SM에 대해 active한 warp의 수를 신경써야 한다. GPU의 경우 register에 context switching을 위한 정보를 넣는데, 한 SM당 너무 많은 warp를 사용하면 이 register가 부족해지기 때문이다.

Kepler (2014)

double precision floating point 연산 속도를 향상시켰다.

4개의 warp scheduler, dual instruction dispatch unit이 있다. ILP한 방식으로 indepdendent한 warp를 가져와서 2개의 independent instruction을 실행시킨다. 만약 못 찾으면 그냥 하나만 실행한다. - 즉, ILP, TLP를 모두 실행하는 방법이다.

Pascal (2016)

NVLink를 사용한다. NVIDIA GPU 전용으로 구성된 link이며 속도가 매우 빠르다. 여러 개의 GPU를 사용할 때를 고려한 기술이다.

unified memory를 지원한다. pascal 이전의 unified memory는 software가 사용하는 방식이었으며, CPU memory와 GPU memory 사이에 데이터를 옮길 필요 없이 사용하는 통합된 memory였다. 때문에 CPU와 GPU 둘 다에서 모두 사용할 수 있었다. 이 memory는 unified virtual memory space를 제공했다.

Volta (2017)

tensor core를 사용한다는 점이 제일 큰 차이점이다. 때문에 더 유연한 thread scheduling을 할 수 있게 되었다. 이 때부터는 각 thread의 execution state가 저장되므로 각각의 PC와 call stack을 저장한다. 이 방식을 사용한다고 SIMT가 아닌 것은 아니다. 실제 실행은 같은 PC를 가진 thread만 실행하기 때문이다.

이전에는 barrier가 thread block level로 작동했는데, 여기부터는 sub-block과 multiblock에서도 작동하게 되었다.

Tensor Core

tensor core

tensor core는 행렬 계산을 위한 특별한 연산 단위이다. 각 tensor cores는 cycle 하나에 4 by 4 행렬의 곱셈과 덧셈 연산을 수행한다.

tensor core의 사용

각 warp가 16 by 16의 결과를 계산한다고 하자. tensor core는 4 by 4 크기이기에, 4개의 4 by 4 size로 입력을 나눈다. 그러면 각각의 4 by 4 행렬은 하나의 cycle에서 tensor core가 실행하고 결과를 만들 수 있다.

이 block을 어떻게 thread block으로 나누는지는 이후에 다룬다. input이 shared memory에 저장된 경우, 하나의 thread block당 여러 개의 tile을 계산할 수 있다. 이 방법도 나중에 다룬다.

기존 방식의 경우, 행렬 연산을 위해서는 warp 내에 있는 32개의 thread가 병렬로 작동하고, 이후에 barrier가 작동하고 연산 결과를 tensor core가 작동하면서 취합하는 방식이었다.

Hopper (2023)

여기서부터는 tensor core gpu라고 부른다. tensor core를 위해 fetch 속도를 더 빠르게 했다.

thread block과 thread block hierarchy에 대해 새로운 수준의 parallelism을 도입했다. (thread - thread block - thread block cluster - grid 순서) 이를 통해 SM끼리 data를 더 쉽게 공유할 수 있게 되었다.

기술적 진화

interconnect와 memory bandwidth 확장으로 인해 CPU-GPU, GPU-GPU 간 병목을 줄였다. 이외에도 NVLink(point to point)나 NVSwitch(bus)가 도입되었다.
tensor core, RT cores를 사용해 heterogeneity가 증가했다.
더 flexible해졌다. thread끼리 더 fine-grained synchronization해졌고, thread block끼리 synchronization이 되고, 이를 지원하는 scheduler가 있다.
unified memory와 hardware coherence를 지원해서 host-device data communication이 더 쉬워졌다.
GPU virtual machine을 위한 보안 기능도 추가되었다.

기술적 트렌드

transistor가 점점 더 작아지고 있고, 면적당 계산력이 늘어나기 때문에 core가 더 늘어날 것이다.
성능을 위해서 Tensor Core 등의 기능이, Programmability를 위해서 cooperative group이나 indepedent thread scheduling, threadd block cluster 등이 추가되고, security를 위해 VM support 등이 추가될 것이다.
deep learning을 위해 더 큰 cluster로 scale out되고 있다. NVLink나 shared memory, NVSwitch 등의 기능이 생기고 있고, CPU와 GPU, DPU들끼리 integration이 일어나고 있다.
한계점은 GPU core가 더 빨라짐에 따라 memory bandwidth가 한계점으로 맞은 상황이다.

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

[이종병렬컴퓨팅] GPU architectures - SIMT와 SIMD

hyelie — Wed, 25 Oct 2023 23:25:27 +0900

이 글은 포스텍 성효진 교수님의 이종병렬컴퓨팅(CSED490C) 강의를 기반으로 재구성한 것입니다.

이 글에서는 다음과 같은 내용들을 살핀다.

GPU의 실행 모델인 SIMT와 SIMD

Heterogeneous Computing

heterogeneous computing

순서가 있는 instruction은 CPU에, parallel하게 돌릴 수 있는 instruction은 GPU에 할당해서 돌리는 것이 heterogeneous computing이다.

GPU Architecture의 개요

CPU vs GPU

CPU는 하나의 thread에서 발생하는 latency를 최소화하는 데 목적이 있으며, 때문에 cache가 매우 크다. 따라서 일반적으로 core의 개수가 적으며, 여러 종류의 instruction을 수행할 수 있는 general한 목적이다.

GPU는 모든 thread의 throughput을 최대화하는 것이 목적이며, multithreading으로 인해 latency를 숨길 수 있다. 따라서 또한 core가 수행하는 연산이 더 간단하기 때문에 core의 개수가 매우 많으며, cache의 크기가 작다.

CPU는 훨씬 복잡하고, latency가 훨씬 적다. 반면 GPU는 훨씬 작고 간단하지만 훨씬 많은 core가 있다.

GPU는 어떻게 높은 성능을 내는가?

GPU는 graphics processing unit인 만큼, 동일한 작업을 계속 수행하므로 parallel하게 구성한다.

CPU의 control

GPU의 control

CPU와 비교했을 때 나타나는 이러한 GPU의 효율성은 control overhead를 최소화하는 데서 나온다.

여기서 control overhead란 flow of control에서 발생하는 overhead이다. 기본적으로 instruction을 fetch하고 어떤 instruction을 실행할지 결정하는 것이 flow of control이다.

CPU는 모든 context에 별개의 program counter가 있으며, 하나의 core에서도 context가 여러 개 있기도 하다. 반면 GPU는 여러 개의 core를 그룹화하기 때문에 core 각각의 program counter가 없다. 한 group은 program counter 나 call stack 등의 정보를 공유하는 방식을 통해 각 group을 한 번에 관리한다.

GPU의 모든 core는 여러 개의 thread를 independent하게 실행해야 하므로 자체적인 control logic이 필요한데, 여기서 GPU는 core들끼리 이 control logic을 공유하는 방식을 택한다. (때문에 모든 thread가 program counter 나 stack pointer를 공유한다.) 이것이 GPU의 핵심 실행 모델이며, 본질적으로는 hardward가 실행하는 SIMD 방식이다. 이러한 방식으로 control overhead를 최소화한다.

이렇게 하나의 그룹으로 묶인 thread set을 warp라고 한다. warp의 모든 thread set은 동일한 instruction을 실행하고, SIMD 작업이지만 GPU scheduler가 수행한다.

SIMD, Single Instruction Multiple Data

SIMD

여러 개의 data, 일반적으로 vector에 대해 하나의 instruction을 수행하는 것을 말한다. 오직 하나의 instruction으로 여러 개의 data를 처리할 수 있다. 이 경우, programming model과 execution model 모두 SIMD로 작동한다.

SIMD를 사용하기 위해서는 SIMD가 작동할 때 한 번에 몇 개의 data를 처리할지에 대한 지표인 width를 알고 있어야 한다.

예를 들어 width를 512로 설정하면, instruction 하나로 512개의 data를 처리할 수 있는 것이 vector instruction - SIMD이다.

기본적으로 GPU 내부는 SIMD로 구현되어 있다. program counter를 공유하는 같은 core에 대해 같은 instruction이 실행하기 때문에, SIMD처럼 작동해야만 한다. 그렇지만 programming model이 SIMD가 아니기 때문에 프로그램에서 vector instruction을 볼 수 없고, 일반적은 parallel program처럼 thread로 작성한다. - 즉, GPU의 프로그래밍 모델(software)과 실행 모델(hardware)이 분리되어 있다.

Programming Model vs Hardware Execution Model

programming model : 프로그래머가 코드를 작성하는 방식이다. 예를 들어 sequential, data parallel, dataflow, multi thread 등이 있다.
execution model : hardward가 실제로 코드를 실행하는 방식이다. out of order execution, vector processor, multiprocessor 등이 있다.
이 둘은 다른 것이기 때문에, 둘이 지향하는 패러다임에서 매우 큰 차이가 날 수 있다. 예를 들어 programming model은 sequential이지만 execution model이 out or order일 수도 있다.

GPU : SPMD 프로그래밍 모델과 SIMD 실행 모델

SPMD, Single Program Multiple Data

때문에, GPU는 GPMD programming model과 SIMD execution model이라 불리기도 한다.

SPMD의 작명에서 알 수 있듯 하나의 프로그램이 여러 개의 data를 돌리는 방식이다. SPMD는 programming model이며, MIMD의 subclass로 좀 더 제약이 걸린 버전이다.

각 thread는 같은 kernel을 수행하지만, data의 다른 부분을 실행한다. 각 thread는 각각의 context가 있으며, 때문에 독립적으로 동작한다. 각 program은 서로 다른 control flow path를 가질 수 있다. 이러한 동작은 불필요한 overhead를 없애기 때문에 더 빨리 동작한다.

SIMT, Single Instruction Multiple Thread

코드를 작성하는 단계에서는 single instruction을 사용하지만 실제로 실행되는 방식은 mulitple thread인 형식이다. 이 때 instruction은 vector instruction이 아니라, scalar instruction이다! 한편 thread들은 warp라는, 동적으로 형성된 group으로 묶이며, 각 thread는 scalar instruction을 사용한다. hardware가 warp를 그룹화하며, 각 warp는 동일한 instruction을 실행한다.

warp의 크기는 하드코드된 값을 사용한다. 예를 들어 32라고 설정하면 총 32개의 thread를 하나의 warp에 넣고, 64라고 설정하면 64개의 thread를 하나의 warp에 넣는다.

만약 너무 작은 숫자를 사용한다면 SIMD exeuction engine을 사용하는 이점이 사라진다. 반면 너무 큰 숫자를 사용하면 해당 warp를 채우기 힘들뿐더러 가장자리 부분에 cache miss가 날 수 있다. 따라서 이러한 경우를 모두 고려해 memory를 효율적으로 사용할 수 있는 숫자를 사용해야만 한다. 지금은 일반적으로 32를 쓴다.

SIMD vs SIMT

SIMD : 하나의 instruction이 여러 개의 data를 처리하는 방식이다. 예를 들어 VLD, VLD, VADD, VST, VLEN 등이 있다. vector length를 알고 있어야 한다.
SIMT : scalar instruction의 multiple instruction stream이다. 같은 명령어를 동시에 실행하는 여러 개의 thread가 hardward에 의해 warp로 묶인 것이다. 예를 들어 LD, LD, ADD, ST, NumThreads 등이 있다.
- SIMD의 경우 single thread이다.

SIMT는 크게 2가지 장점이 있는데,

SIMT는 multi thread이므로 thread를 개별적으로 처리할 수 있다. 즉, 각 thread가 독립적으로 실행할 수 있기 때문에 MIMD processing을 할 수 있다.
thread를 동적으로 warp로 묶을 수 있다. 즉, 동일한 instruction을 실행해야 하는 thread를 warp로 묶어 SIMD processing의 이점을 최대화할 수 있다.

Warp와 Warp-Level FGMT

warp

warp의 각 thread는 program counter , call stack을 공유하고, register만 다른 값을 가진다. 따라서 같은 프로그램이더라도 다른 warp는 다른 program counter 를 가질 수 있다.

일반적으로 GPU는 매우 큰 register를 가지며, 이를 적당히 나눠 각 thread에게 제공한다.

위 그림의 오른쪽은 SIMD pipeline을 의미하는데, 여기에는 실행할 준비가 끝난 warp들이 들어가며 여기서 실행하기로 한 warp가 SIMD pipeline에 들어간다.

High Level View of GPU

GPU 구조 개요

sharder core는 앞에서 설명한 core라 받아들이면 된다.
- 각 core에는 scalar pipeline이 있으며, SIMD execution이 일어나는 곳이다.
- PC, mask는 warp의 실행 정보가 담기는 부분이다. PC는 program counter이고, warp가 같은 program counter를 공유하므로 필요하다. mask의 경우 warp의 thread가 분기로 인해 다른 warp로 바뀔 때 적용하는 값이다. mask를 사용해 다른 program counter를 실행하는 warp를 묶는다.
아래쪽의 GDDR3는 GPU memory를 의미하는데, NVIDIA나 AMD GPU는 GPU 내부의 memory, GPU memory 또는 device memory가 있다. ARM GPU의 경우 CPU와 RAM을 공유하기도 한다.

Latency Hiding with Warp Level FGMT

제일 윗부분은 hardware scheduler가 있는 부분이다. 실행할 준비가 된 warp들이 들어간다.
이후 SIMD pipeline에서는 하나의 warp를 실행한다.
- SIMD pipeline을 보면 fetch, decode는 하나만 있고, ALU만 여러 개가 있다. - 즉 하나의 instruction을 thread끼리 공유한다는 뜻이다. (SIMD)
- cache miss가 있는 경우 memory를 확인해야 하는데, 값을 가져오기 위해 context switch를 한다. 이 context switch의 경우 CPU와는 조금 다르다. CPU의 경우 PC, register, stack pointer 등을 저장하고 context switch를 한다. 반면 GPU의 경우 모든 thread가 크기가 큰 개인용 register를 가지기 때문에 여기다가 PC, register, stack pointer 등을 저장하므로 값을 저장하고 꺼내오는 데에 대한 overhead가 매우 적고, 따라서 warp의 실행을 잠시 보류하기만 한다.

fine-grained multithreading을 사용하기 때문에 매 cycle마다 hardward scheduler가 서로 다른 warp로부터 instruction을 수행한다. 이 과정은 interlocking이 없이, pipeline에 있는 thread마다 하나의 instruction을 실행한다는 것이다. context switch를 할 때, 모든 thread의 register 값들은 register file에 저장되며, context switching overhead가 매우 낮기 때문에 I/O를 기다리는 warp를 hardware scheduler가 scheduling하기만 하면 되는 이 효과로 인해 latency가 숨겨진다. 따라서 FGMT는 긴 latency를 허용한다.

Warp Instruction Level Parallelism

여러 개의 instruction을 겹칠 수 있다.

위 그림은 warp당 32개의 thread가 있고, 8개의 core이 있는 상황이다. 이 경우 각 core는 한 cycle에 8개의 thread만 처리할 수 있으므로, 각 warp가 처리되기 위해서는 4 cycle이 필요하다.

위 예시에서는 load, multiply, add unit 3가지로 나뉘어 있는데, 때문에 동시에 3개의 unit을 처리할 수 있다. 즉 cycle당 24개의 operation을 수행할 수 있게 된다.

Control Flow Problem in GPU

같은 warp에 있는 모든 thread는 같은 program counter를 실행한다. 그러나 branch를 만나 조건이 다르면 다른 program counter를 가지게 된다. 때문에 branch divergence - 다른 실행 경로를 가지는 문제가 발생한다.

branch divergence problem

이를 해결하기 위해 mask를 사용하며, mask를 사용해 다른 branch로 들어간 thread들을 묶을 수 있다.

위 예시에서 branch를 기준으로 실행하는 thread가 달라진 모습이다. 몇몇 thread는 path A로, 몇몇 thread는 path B로 간다. path A로 간 thread들은 1로 mask하고, path B로 간 thread들은 0으로 mask한다. 이후 branch가 끝난 후 converge하는 방식으로 branch divergence 문제를 해결한다.

이러한 방식으로 같은 instruction을 실행하는 thread를 동적으로 warp로 묶으며, 이를 통해 낭비되는 cycle을 줄여 SIMD process의 이점을 최대화한다.

정리

중요한 점: 각 thread는 independent이다!

SIMT는 2가지 장점이 있다.

각 thread를 독립적으로 처리할 수 있다.
thread를 warp로 유동적으로 묶을 수 있다.

만약 thread가 매우 많다면

같은 program counter를 가진 독립적인 thread를 찾고,
이 thread를 warp로 묶는다.

이 과정은 divergence를 없애주기 때문에 SIMD utilization을 향상시킨다. 단, nested if문이 있는 경우에는 divergence가 발생하기 때문에 cycle이 낭비된다. if문이 하나일 때는 cycle 하나이지만 중첩될수록 많은 cycle이 낭비된다.

최신 기술은, 이러한 nested if를 허용하기 위해 각 thread별로 PC를 가진다. 앞서 warp의 모든 thread가 같은 PC를 가진다고 했는데 조금 모순되지 않나?라 생각할 수도 있다. 각 thread는 각각의 PC를 가지되, 같은 PC를 가진 thread만 한 번에 실행하는 형식이다. - 그래서 SIMT를 유지한다.
이를 통해 divergence로 인해 생기는 cycle 낭비를 조금이나마 막을 수 있다.

Warp Based SIMD vs Tranditional SIMD

traditional SIMD의 경우 single thread이다.

sequential instruction execution이기 때문에 SIMD instruction에서 lock이 필요하다.
programming model도 SIMD이다. 따라서 software가 vector 길이를 알아야 한다.
ISA는 vector instruction이 SIMD instruction을 포함하고 있어야 한다.

반면 warp based SIMD의 경우, SIMD 방식으로 실행되는 여러 개의 scalar thread들로 구성되어 있다. (모든 thread가 같은 instruction을 실행한다)

따라서 lock이 필요없다.
각 thread는 독립적으로 취급받는다. 즉, programming model은 SIMD가 아니다. 때문에 software는 vector 길이를 몰라도 되며, dynamic하게 thread를 grouping할 수 있다.
ISA는 scalar이므로 dynamic하게 구성될 수 있다.
근본적으로 SPMD programming model이 SIMD hardware에 구현된 것이다.

요약

GPU는 SPMD를 parallelism을 사용하고, 이에 최적화된 hardware를 설계한다. portability와 programmability를 위해 SPMD programming model을 유지하며, 복잡한 contol logic은 SIMD hardware로 대체한다.

GPU execution model은 ILP, DLP, TLP 3가지를 모두 지원한다.

DLP의 경우 여러 개의 data를 처리하는 것이고, TLP는 find-grained multithreading으로 여러 개의 thread를 실행하며, ILP는 모든 warp더라도 모든 instruction이 별개로 + 동시에 돌아가기 때문이다.

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

[이종병렬컴퓨팅] Parallel Computing Basics

hyelie — Wed, 25 Oct 2023 03:15:48 +0900

이 글은 포스텍 성효진 교수님의 이종병렬컴퓨팅(CSED490C) 강의를 기반으로 재구성한 것입니다.

이 글에서는 다음과 같은 내용을 살핀다.

parallel computing의 기본적인 개념
- parallelism의 종류
- parallel architecture 분류
parallel program을 어떻게 작성하고 어떤 기준으로 평가하는지

Parallelism의 종류

크게 3가지의 parallelism이 있다.

ILP, Instruction Level Parallelism
- instruction들끼리 independent하다.
- hardware는 instruction window size 내내에서 implicit하게 찾을 수 있다.
- complier들은 window 내에 있는 명령어들이 independent할 수 있도록 찾아서 순서를 바꾼다. independent한 순서로 재배열 한 후 실행하는 방식이다.
TLP, Thread Level Parallelism
- complier와 programmer가 program을 명시적으로 나눈다.
DLP, Data Level Parallelism
- TLP의 variation 중 하나로, 같은 instruction을 실행하는 여러 개의 thread가 다른 data에 대해 동작하는 방식이다.

예시

parallelism의 종류

위쪽 부분은 programmer view를, 아래쪽 부분은 실제 작동 방식을 나타낸다.

ILP의 경우 independent한 instruction을 적당히 동시에 실행시킨다. hardware가 수행하기에 programmer는 이에 대해 알 수 없다.
TLP의 경우 programmer가 instruction을 나누어 배치했기 때문에 해당 instruction들끼리는 parallel하게 실행되는 모습이다. programmer가 instruction을 나누었기 떄문에 이를 인지하고 있다.
DLP의 경우 같은 종류의 data는 같은 instruction이 실행되는 모습이다. TLP의 variation인 만큼 programmer도 이를 인지하고 있다.

Flynn's Taxonomy

flynn's taxonomy

single instruction stream은 single thread를, multiple instruction stream은 multiple thread를 의미한다.

multiple data streams & single instruction stream - (1, 0)에 있는 것 - 은 DLP를, multiple data streams & multiple instruction streams - (1, 1)에 있는 것 - 은 TLP를 의미한다.

Hardware가 parallelism을 달성하는 방법

ILP
- Superscalar : single thread에서 여러 개의 instruction을 실행하는 방식이다. instruction dependency가 없는 instruction만 하나의 cycle에 동시에 실행되기 때문에 dependency에 크게 영향을 받는다.
TLP
- Find Grain Multithreading : thread 간 context switching이 빠르다. 매 cycle마다 다른 thread를 교체해서 실행하는 방식이다. (single core)
- SMT, Simultaneous MultiThreading : 같은 cycle에 여러 개의 thread의 instruction을 실행하는 방식이다. (multi core)
- CMP, Chip Multi Processors : 하나의 chip에 여러 개의 core를 탑재하고 각 thread를 다른 core에서 실행하는 방식이다.
DLP
- Vector Processors : data의 여러 부분에 작동하는 single instruction을 실행하는 방식이다.

Parallel vs Concurrency

Parallel은 여러 개의 resource(CPU나 core 등)을 사용해 single prcessor에서보다 더 빨리 푸는 방식이다. 예를 들어 merge-sort의 경우 각 thread가 data의 각 부분을 정렬하고, 합치는 parallel을 생각할 수 있다.

Concurrency는 여러 개의 execution flow를 동시에 실행하는 것처럼 보이는 방식이다.

Parallel Algorithm Design

concurrency를 달성하기 위해서는 programmer가 concurrency를 인지하고 아래 3가지를 잘 다뤄야 한다.

dependency를 올바르게 관리
concurrency 관리로 발생하는 overhead 최소화
balanced한 방식으로 work를 나누기

때문에 parallel program을 설계하는 방식은 크게 아래와 같다.

parallel하게 수행할 수 있는 작업 식별
task, data 분할
data access, communication, synchronization 관리

이를 통해 program을 parallel하게 실행해서 성능을 향상시키는 것이 목적이다.

Speedup(P processors) = $\frac{\text{Time(1 processor)}}{\text{Time(P processors)}}$

parallel program 설계 단계

이 단계를 그림으로 표현하면 위와 같다.

decomposition은 work를 subwork로 나누는 것, assignment는 core에 work를 할당하는 것, orchestration은 communication을 하는 부분을 말한다. mapping은 hardward에 mapping하는 과정으로, 이 과정은 보통 OS가 수행한다.

Parallel Algorithm의 목표

제일 좋은 방식은 아래 3가지를 모두 달성하는 것이다.

Maximize parallelism
Minimize communication
Minimize load imbalance

그러나 실제로는 이런 3가지를 모두 달성하기는 매우 어렵다. 아래와 같은 conflict에서 적당한 위치를 찾아야 한다.

parallelism vs communication : 이 둘은 tradeoff이다.
load imbalance vs communication : 이 둘은 tradeoff이다.
architectural contraints의 한계

Parallel Algorithm의 구성 요소

parallel algorithm은 위 그림에서 언급되었듯 크게 3가지로 나뉜다.

Task Decomposition: 문제를 동시에 실행할 수 있는 작업으로 나누는 것
Mapping & Scheduling : task를 여러 computing unit에 할당하고 input/output/중간 data를 배포하는 과정
Communication & Synchronization : parallel execution의 다양한 지점에서 task를 동기화

Task Decomposition

task를 개별적인 작업으로 나누어 사용하는 방법. execution unit이 최대한 busy하게 두면서 dependency를 최소화하는 방법이 기본적인 골자이다. 이 때, task를 지나치게 잘게 쪼개면 thread의 생성/관리에 필요한 overhead가 더 커지기 떄문에 적당히 작은 크기로 쪼개는 것이 좋다.

나누는 방법은 다음과 같은 방법들이 있다.

어떻게 나누는지
- domain decomposition : operation을 나누는 것이 아니라 data만 나누어서 같은 연산을 수행하는 방식이다.
- functional decomposition : 문제의 분류에 따라 나누는 방식이다. 다른 작업으로 나뉘기에 다른 연산을 수행한다.
언제 나누는지
- static decomposition : 계산하기 전에 decomposition을 결정하는 방식이다.
- dynamic decomposition : 입력에 따라 decomposition을 결정하는 방식으로, 나눌 때 발생하는 overhead가 있다. 예시로 sparse matrix multiplication이 있다.
어떠한 크기로 나누는지
- coarse-grained task : 크게크게 나누는 방법. communication overhead가 적지만 load imbalance가 발생한다.
- fine-grained task : 세밀하게 나누는 방법. communication overhead가 크지만 load balance하다.

parallel execution overhead는 `communication/synchronization cost + idling + excess work`의 3가지로 표현된다.

이 때, 너무 세밀하게 나누면 overhead가 너무 커지고, 너무 크게 나누면 load imbalance가 너무 커지기 때문에 overhead와 load imbalance가 균형을 이루는 지점을 잘 잡아 task decomposition해야 한다.

Mapping and Scheduling

이 단계는 decompose한 task를 어떤 processing unit에게 할당하고(mapping), 언제 실행할지(scheduling) 결정하는 단계이다.

static mapping and scheduling
- task가 실행 전에 processing unit에 할당되는 방식이다.
- 때문에 task size가 고정된 경우에 쓸 수 있다.
- overhead가 적다.
dynamic mapping and scheduling
- task가 실행 중에 동적으로 processing unit에 할당되는 방식이다. scheduler가 다음에 실행할 작업을 결정하고 core에 할당한다. 때문에 task queue 등 자료구조가 필요하다.
- task 크기를 모르는 경우에 써야 한다.
- overhead가 높지만, load imbalance를 줄일 수 있다.

예시

mapping and scheduling 예시 - locality가 나쁜 경우

이러한 예시가 있다고 하자. Tn은 n번째 row를 처리한다고 하자. 위 경우, static decomposition, static mapping을 사용했다. 이 경우 locality가 나쁘다! T1, T5, T9가 하나의 processing unit에서 사용되는데, 서로 다른 cache를 보기 때문이다.

mapping and scheduling 예시 - locality를 보완한 경우

locality를 개선하면 위 그림과 같다. T1, T2, T3가 같은 processing unit에 속하므로 cache를 좀 더 효율적으로 쓸 수 있다.

mapping and scheduling 예시 - 딱 나눠떨어지지 않는 경우

이 상태에서 위와 같은 상황이 되면 어떨까? processing unit 1에 추가적인 load가 생기기 때문에 load imbalance가 생긴다. 때문에 T13을 끝낼 때 까지 cycle을 낭비하게 된다.

mapping and scheduling 예시 - fine grained task

이를 해결하는 방법 중 하나가 fine-grained task이다. task를 좀 더 쪼개면 cycle 낭비가 있더라도 그 낭비를 더 줄일 수 있다.

mapping and scheduling 예시 - dynamic mapping

다른 한 가지 해결 방법은 dynamic mapping이다. task를 dynamic하게 나눠서 다른 processing unit이 task를 끝낼 때 쯤 다른 task를 할당하는 방식이다. 이 방법은 앞에서 설명했듯 granularity를 설정하기 위한 scheduling overhead가 발생한다.

Overhead 최소화 방법

overhead를 최소화하는 방법은 아래와 같은 방법들이 있다.

independent task를 다른 core에 할당 : 만약 depedent task를 다른 core에 할당하는 경우 core끼리 통신하기 위해 barrier나 log가 필요하다. 때문에 independent task를 다른 core에 쓰는 것이 좋다.
- parallelism을 최대화한다.
critical path를 최대한 빨리 할당 : 다른 작업들보다 오래 걸리는 작업은 먼저 수행하는 것이 좋다. 이 작업을 나중에 수행하면 다른 core들이 idling하기 떄문이다.
- load imbalance를 최소화한다.
communication 최소화 : 첫 번째 것과 관련이 있는 내용으로, communication을 최소화하면 최대한 independent task를 다른 core에 할당해야 한다.
- overhead를 최소화한다.

이러한 기준들은 서로 충돌할 수 있다. 예를 들어 indepedent task의 개수를 찾을 수 없을 수도 있고, 다른 core에 dependent task를 할당해야 할 수도 있다. 때문에 balance를 잘 맞춰야 한다.

Communication and Synchronization

parallel task 사이에서 data를 공유하는 부분을 의미하며, thread끼리의 communication, synchronization에 관한 것이기 때문에 그 자체로 race condition을 만든다. 따라서 parallel thread로 동작하는 경우, communication cost는 sequential program에 동작하지 않는 순수한 overhead이다. lock contention의 경우 network를 사용한다는 문제점도 있다.

communication은 문제에 따라 필요할 수도 있고, 그렇지 않을 수도 있다. 문제가 communication이 거의 없는 경우 그냥 바로 하면 된다. 앞서 matrix add 예시가 그것이다.

이를 사용하는 방법은 크게 2가지가 있다.

message passing model : communication이 explicit한 방식이다.
- 더 많은 programming을 해야 하고, flexible하지 않지만 이해하기 쉽다.
shared memory model : communication이 implicit한 방식이다. coherence protocol 등 software나 hardward의 communication support가 있어야 한다.
- 프로그래밍 자체는 쉽지만 어디서 버그가 났는지 찾기 어렵다.

Communication의 종류

크게 collective, point-to-point가 있다.

Barrier Synchronization (collective)

먼저 collective이다.

1 to all, all to all을 수행하는 broadcast(multicsat)와 all to one을 수행하는 reduction이 있다. 별개로 scatter/gatter로 하기도 한다.

collective synchronization

위 그림과 같이 parallel program은 barrir로 의해 단계가 나눠진다.

제일 처음에는 broadcast / scatter로 parallel하게 나눠진다.
각 단계에서는 parallel하게 실행되고, barrier에서는 communicate가 실행된다.
마지막에는 reduction / gather가 실행된다.

barrier를 사용하는 경우 depedency를 사용하는, coarse-grained한 방식이다. 각 단계의 연산은 이전 단계의 연산(이전 단계의 barrier에서 완료된)에 의존한다.

Point to Point Synchronization

point to point synchronization

다음으로 point to point로, lock을 사용하는 방식이다. 때문에 하나의 thread만 critical section에 진입할 수 있다.

이 경우 fine grained이기 때문에 더 빠르며, lock이 필요한 각각의 thread가 1대1로 통신하기 때문에 통신에 대한 overhead도 더 적다.

Communication Overhead

task를 하나의 iteration로 나눈 경우

위 그림과 같은 경우 communication overhead = synchronization time + data communication time이다.

task를 n/4 iteration으로 나눈 경우

task를 위 그림과 같이 n/4 iteration으로 나눈 경우, distributed reduction이다. 이 경우 communication overhead = reduction time + data communication time이다.

위 경우에서는 distributed reduction을 한 경우가 좋은데, 항상 그런 것은 아니다. 예를 들어 core가 1개, 또는 2개인 경우 task를 reduction하고 합치는 시간이 더 많이 들어가기 때문에 전자의 방식이 더 좋다. 일반적으로는 core가 4개 이상일 때 distributed reduction을 하는 것이 좋다고 한다.

현대로 올수록 computation 속도가 매우 빨라졌기 때문에 communication cost보다 communication cost가 훨씬 더 크다.

data locality 최대화
data exchange 최소화
communication 최소화
contention 최소화
computation과 communication 겹치기 (non-blocking communication의 경우)

Performance Modeling

실행 시간 $T_p$ : p개의 processor가 문제를 해결하는 데 걸린 시간
전체 overhead $T_0 = pT_{p} - T_s$
speedup $S_p = \frac{T_s}{T_p}$ : sequential 실행 시간 / parallel 실행 시간
효율 E = $\frac{S_p}{p} = \frac{T_s}{p \times T_p}$
- parallel execution으로 얼마나 더 많은 task를 했는지에 대한 지표.
- 만약 E가 1보다 큰 경우 superlinear라 한다.

Amdahl's Law

변경으로 인해 f 부분이 K배 향상된 경우, 기존 실행 시간이 T = (1-f)T + fT일 때, 향상된 시간은 $T_K$ = (1-f)T + $\frac{f}{K}$T이다.

parallel programming에서 f는 parallel하게 실행되는 부분이다. 즉슨, (1-f) 부분은 sequential한 부분이라는 뜻이다.

그러면 speedup은 아래와 같다.

speedup S = $\frac{T}{T_K} = \frac{1}{(1-f) + \frac{f}{K}}$

이 수식 아래서 최대한 값을 키우는 것이 목적이므로 아래 2가지 방법을 모두 사용한다.

f를 크게 만들어야 한다: parallel한 부분의 비중을 높여야 한다.
- f가 0.5인 경우 2배의 speedup이지만, 0.95인 경우는 20배의 speedup이다.
K를 크게 만들어야 한다: core 개수를 늘려야 한다.
- data parallel computation의 경우 K를 키우기만 하면 된다. (core 개수만 늘이면 된다.)
- task parallel computation의 경우, parallel task는 고정되어 있기 때문에 K를 늘이기 쉽지 않다.

Scalability

$E_p$가 problem size가 변해도 계속 유지된다면 scalable하다고 한다. 일반적으로 p가 늘어나면 synchronization cost가 증가하기 때문에, core를 늘이더라도 동일한 효율을 얻을 수 없는 경우가 생긴다. $E_p$에 영향을 미치는 것은 communication과 synchronization이 대부분이다.

strong scaling : problem size를 고정한 채로 K만 늘이는 방법. 예를 들어 n size의 문제를 1개, 2개, 4개, ...의 core로 해결할 때 speedup을 보는 방식이다.
weak scaling : core가 담당하는 problem size를 고정한 상태로 problem size를 늘이는 방법. 일반적으로 이야기하는 scalability이다.

Parallelization Techniques

따라서, parallel한 프로그램을 짜고 싶다면 다음과 같은 단계를 거쳐야 한다.

Parallel Algorithm 설계

parallel하게 해결하고 싶은 문제를 식별하고, parallel하게 풀 수 있는지 확인한다.
병목을 식별하고, 해당 부분을 parallelism을 적용한다. 이 때 overhead와 load imbalance를 최소화해야 한다.

Computation

dependence graph를 사용해 task/data dependence를 분석한다.
critical path를 최소화한다. 이는 load imbalance를 줄이는 효과도 있다.
data dependency를 최소화한다. dependency가 있는 부분은 parallel의 효과가 떨어지기 때문이다. 특히 loop를 사용하는 부분을 잘 보아야 한다.

Synchronization and Load Imbalance

centralized 대신 distributed 방식을 사용해서 공유 정도를 줄인다.
lock-free와 synchronization-free 알고리즘을 사용한다.
coarse-grained task decomposition을 지양한다.
critical path에 더 높은 priority를 부여한다.

Communication

data locality를 신경써야 한다.
communication과 computation을 최대한 겹쳐야 한다.
몇몇 경우, communicate보다 다시 계산하는 것이 더 빠를 수도 있다.

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

[Maude] Token Ring 검증

hyelie — Mon, 23 Oct 2023 22:26:17 +0900

이 글에서는 Designing Reliables Distributes Systems, 225p에 있는 Token Ring을 maude를 사용해 formal modeling하고 원하는 검증을 진행합니다. 원 프로젝트는 RAFT consensus algorithm을 모델링하는 것이지만, 그 전에 손풀기 느낌으로 좀 더 쉬운 token ring을 모델링합니다.

Token Ring

In the “token ring” mutual exclusion algorithm, the nodes logically form a “ring” structure, as shown in Figure 13.1 where a node only knows the next node in this ring.

The algorithm works as follows: there is one “token,” and only the node that holds the token may enter its critical section. The node then holds on to the token during its execution in the critical section, and passes the token to the next node in the ring when it exits its critical section. If a node that is not waiting to enter its critical section receives the token, it just passes the token to the next node.

코드

--- module in textbook
mod MESSAGE-CONTENT is
    sort MsgContent . --- message content, application-specific
endm

omod MESSAGE-WRAPPER is
    including MESSAGE-CONTENT .
    op msg_from_to_ : MsgContent Oid Oid -> Msg [ctor] .
endom
---

omod OBJECT-TOKEN-RING is
    including MESSAGE-WRAPPER . --- object들 간의 message 처리

    class Node | state : MutexState, next : Oid . --- 각 Node : state와 next를 가짐.

    sort MutexState .
    ops normal waiting acquire : -> MutexState [ctor] . --- state 정의

    --- prev, current, next
    vars P C N : Oid .

    op token : -> MsgContent [ctor] .

    --- current node가 normal이면 waiting으로 변경
    rl [AccessRequest] :
            < C : Node | state : normal >
        =>  < C : Node | state : waiting > .

    --- message를 받았을 때 current node가 normal이면 다른 state로 바뀌지 않고, next node에게 전달
    rl [SkipToken] :
            (msg token from P to C)     < C : Node | state : normal, next : N >   
        =>  (msg token from C to N)     < N : Node | > .

    --- message를 받았을 때 current node가 waiting이면 acquire로 변경 (critical section에 진입)
    rl [Access] :
            (msg token from P to C)     < C : Node | state : waiting >   
        =>                              < C : Node | state : acquire > .

    --- critical section에서 나감
    --- current node state가 acquire에서 normal로 변경, next node로 message 전달
    rl [Release] :
            < C : Node | state : acquire, next : N >
        =>  < C : Node | state : normal >    (msg token from C to N) .
endom

omod OBJECT-TOKEN-INIT is
    including OBJECT-TOKEN-RING .

    ops a b c d : -> Oid [ctor] .
    op init : -> Configuration .
    
    eq init = (msg token from d to a) --- token이 전달된 상황
    < a : Node | state : normal, next : b >
    < b : Node | state : normal, next : c >
    < c : Node | state : normal, next : d >
    < d : Node | state : normal, next : a > .
endom

***(
    load ./object-token-ring.maude
    set trace on .
)

실행

아래 명령어로 실행할 수 있습니다.

load ./object-token-ring.maude
set trace on .

검증

Normal State 검증

아래 명령어는 특정 2개의 node의 state가 normal인 상태를 찾는 명령어입니다.

search [1] init =>* C:Configuration
    < O1:Oid : Node | state : normal, next : O1N:Oid >
    < O2:Oid : Node | state : normal, next : O2N:Oid > .

실행 결과, Solution이 나옵니다. 즉, 2개의 node가 normal인 state가 존재함을 알 수 있습니다.

Solution 1 (state 10)
states: 11  rewrites: 11 in 0ms cpu (1ms real) (~ rewrites/second)
C:Configuration --> < c : Node | state : normal, next : d > < d : Node | state : normal, next : a >
O1:Oid --> b
O1N:Oid --> c
O2:Oid --> a
O2N:Oid --> b

Mutual Exclusion

아래 명령어는 2개의 node가 acquire인 상태를 찾는 명령어입니다.

search [1] init =>* C:Configuration < C:Oid : Node | state : acquire > < C:Oid : Node | state : acquire > .

실행 결과, No Solution이 나옵니다. 한 번에 2개 이상의 node가 acquire하는 state가 존재하지 않음을 알 수 있습니다.

No solution.
states: 432  rewrites: 865 in 120ms cpu (168ms real) (7208 rewrites/second)

Critical Section 진입

아래 명령어는 특정 node의 state가 acquire이 되는 상태를 찾는 명령어입니다.

search [1] init =>* C:Configuration < C:Oid : Node | state : acquire, next : N:Oid > .
search [1] init =>* C:Configuration < a : Node | state : acquire, next : b > .
search [1] init =>* C:Configuration < b : Node | state : acquire, next : c > .
search [1] init =>* C:Configuration < c : Node | state : acquire, next : d > .
search [1] init =>* C:Configuration < d : Node | state : acquire, next : a > .

실행 결과, solution이 나옵니다. 즉, node가 token을 acquire하는 state가 존재함을 알 수 있습니다.

Solution 1 (state 10)
states: 11  rewrites: 11 in 0ms cpu (1ms real) (~ rewrites/second)
C:Configuration --> < b : Node | state : normal, next : c > < c : Node | state : normal, next : d > < d : Node | state : normal, next : a >
C:Oid --> a
N:Oid --> b

[Model Checking] Designing Reliable Distributed Systems

hyelie — Mon, 9 Oct 2023 21:41:47 +0900

TODO

Ch. 2 : 자연수, 정수, list, binary tree, multiset 등 data type 정의

Ch. 3 : equational specification이 만족하는지 확인

Ch. 8 : rewrite logic을 사용해서 concurrent behavior 작성 방법을 설명

Ch. 9 : rewriting logic을 사용해서 system의 동작 하나를 분석하는 방법

FREE

Ch. 10 : concurrent

Ch. 11 : communication

Ch. 12 : TCP와 같은 transport protocol 모델링

Ch. 13 : distributed DB 모델링

Ch. 2 Data Types

Module

fmod MODULE_NAME is
    MODULE_BODY
endfm

op : 연산자 정의

protecting은 다른 module 가져오는 것
sort는 새로운 data type 정의

ctor : 생성자

var : 변수 선언

eq : 등식

data type import (sort)
op 정의하기 : 생성자와 해당 연산
var 정의하기 : 변수 정의하기
eq 정의하기 : 어떤 연산의 결과가 어떤 것인지 정의하기

Ch. 3 Equational Specification

equational specificaion은 specification이 실행될 수 있는 방법을 설명한다.

Ch. 8 Modeling Distributed System in Rewriting Logic

state가 바뀌는, dynamic system을 modeling하고 analysis하는 방법을 살핀다.

한 예시로, 변화는 잘 안바뀐다!

distributed system은 shared variable에 읽고 쓰거나, 서로 messaage를 주고받는 등 여러 개의 component로 이루어져 있다.

distributed system은 대부분 non-deterministic하다!

Interleaving

interleaving system은 한 번에 하나의 component만 실행할 수 있는 system에 적합하다.

Rewriting Logic

state t에서 t'로 0번 이상의 rewriting logic을 사용해 t'로 변경할 수 있다. 이것들은 nondeterministic하게 이뤄진다!

crl : 조건이 있는 rewriting logic

rl : 조건 없는 rewriting logic

Concurrency

rl로 적으면 된다.

Ch. 9 Executing Rewriting Logic Specifications in Maude

equational specification은 더 이상 적용할 수 없을 때까지 해당 specification을 실행한다.

반면 rewriting logic은 dynamic system의 모든 가능한 behavior를 정의하며, 종료되지 않을 수 있다.

rewriting logic과 equational이 같은 변수에 의해 적용될 경우, equational을 먼저 rewriting logiㅊ 형태로 바꾼다. 이를 위해서는 rewriting logic의 좌항에는 생성자가 와야 한다.

set trace on .

으로 규칙 적용과 rewriting 과정을 기록한다.

rew, frew

rew나 frew를 사용해 rewriting을 할 수 있다. rew는 leftmost에만 적용, frew는 가능한 것들에 적용.

search

search t arrow pattern .
search t arraw pattern such that cond .

search 명령어를 사용해 모델 검증을 할 수 있다. 그 결과로 특정 속성을 만족하는지, 다음 state를 검증할 때 쓸 수 있다.

=>1 : t에서 한 step으로 도달할 수 있는 state
=>* : t에서 0개 이상의 step으로 도달할 수 있는 state
=>+ : t에서 1개 이상의 step으로 도달할 수 있는 state
=>! : 더 이상 rewrite될 수 없는 state

show path

특정 state의 path를 출력한다. 만약 =>!가 무한루프라면 상한을 걸어서 둘 수 있다.

Ch. 10 Concurrent Objects in Maude

distributed system의 각 component를 object로 모델링하고, 각 component는 message를 주고받아서 communicate할 수 있다. 여기서는 rewriting logic을 사용해 concurrent logic을 모델링하는 방법을 살펴본다.

Ch. 11 Modeling Comunications in Maude

ch. 10에서는 concurrent system이 concurrent object들의 multiset으로 표현하는 방법을 살펴봤었다. 이를 위해서는 model을 abstraction해야 한다.

communication은 sync일 수도 이쏙, async일 수도 있다.

rewriting은 communication primitive에 대한 뭔가를 제공하지 않기 때문에 통신 그 자체를 rewriting logic을 사용해 모델링해야만 한다.

일단 비동기식을 쓸 때는, 메시지를 보내고, 받은 사람이 해당 메시지를 받지 않고 자신의 action을 취한 이후 받은 메시지를 처리하는 경우에, 문제가 발생하기 때문에 이 경우를 처리할 수 있는 로직을 작성해야 한다.

Ch. 13 Distributed Algorithm

ch. 12는 생략했다. TCP를 굳이 쓸 필요는 없을 것 같아서.

2-phase commit, mutual exclusion, leader election, concencus algorithm을 살핀다.

이제 직접 해 보자!

기타 면접대비 질문

hyelie — Wed, 4 Oct 2023 10:36:18 +0900

간단한 자기소개
지원동기
장단점
나의 비전 : 사람들에게 긍정적인 영향을 줄 수 있는 사람이 되는 것.
프로젝트 하면서 어려움 극복 : bizkicks 얘기?
회사에 대해 궁금한 점
- 협업 방식
각 프로젝트
인성

개발지식

객체지향

정의

class vs instance

특징 4가지

장단점

객체들의 상호작용으로 프로그램을 구현하는 방법.

객체는 어떤 개념을 추상화하고 모델링한 요소. state와 behavior를 가짐.

- 추상화란 불필요한 정보는 숨기고 중요한 정보만을 보여주는 것(컴퓨터 과학)

class : 설계도, instance : class로 만들어진 메모리에 올라간 실체.

특징

abstraction : OOP에서 abstraction은 불필요한 정보는 private으로 숨기고 중요한 정보를 public으로 노출하고, 공통된 부분을 상위 class로 추출하는 것.

encapsulation : information hiding

inheritance : 공통 부분을 추출

polymorphism : static (overloading) - 이름만 같은 함수로 사용하는 방법, dynamic (overriding) - 부모 class method를 자식 class에서 재정의

장단점

코드 재사용률이 높아짐

단점으로는 객체들이 상호작용하기 때문에 느리다.

SOLID

5가지 + 각각의 예시

single responsibility principle

모든 class가 하나의 책임을 가짐, 변경의 이유가 하나뿐.

지키지 않으면 한 책임의 변경에 의해 다른 책임이 변경될 수 있음.

open closed principle

확장에는 열려 있고 수정에는 닫혀 있음. 코드 변화를 적게 하면서 기능 변화/확장할 수 있게.

확장 시 변경으로 인한 영향을 최소화하는 것이 목적.

예시로 분기문 : polymorphism이나 map을 사용해 적용 가능.

liskov substitution principle

subtype이 supertype으로 치환할 수 있음. supertype 자리에 subtype 넣어도 수행에는 변화가 없어야 한다.

parent class method의 동작 의도를 크게 수정하면 안되는 것이 목적.

예시 : 직사각형/정사각형. - 명확한 관계가 있을 때만 상속을 써야 함.

interface segregation principle

object는 자신이 사용하지 않는 method를 포함한 interface에 의존하면 안 된다.

사용하지 않는 method를 가진 interface에 의존하는 경우, 사용하지 않는 method가 변경되어도 재컴파일되어야 하기 때문.

dependency inversion principle

dependency를 가지는 경우, 구현체가 아니라 추상화에 의존해야 한다.

inversion인 이유는, 기존에는 상위 모듈이 하위 모듈에 의존하고 있었다. 그러나 interface를 사용하면서 하위 모듈이 상위 모듈(abstraction)에 의존하게 되었다. 때문에 inversion.

지키지 않는 경우, 요구사항 하나의 변화로 인해 dependency가 걸린 모든 것들을 다 바꾸어야 한다.

예시 : dependency injection (upcasting), abstract factory

디자인패턴

정의, 예시

template

strategy

abstract factory

factory

singleton

adapter

proxy

composite pattern

decorator pattern

facade

observer

소프트웨어 설계 시 많이 사용하는 구조들을 모아놓은 패턴.

내가 사용한 것들

template

customize한 부분과 invariant한 부분을 구분하는 방법. invariant는 abstract class에서 정의, customize는 concrete class 에서 정의. 객체에서 abstraction이고, 공통 부분만 빼내는 방식.

strategy

한 알고리즘의 여러 변형본이 필요할 때 사용하는 방법. 같은 것을 인자로 받는 if-else문을 분리하기 좋다.

예시로 내가 사용한 if-else를 변경한 것.

abstract factory

concrete class 없이 연관된 객체를 생성하는 방법

단점으로는 새로운 것을 넣기 힘들다는 것.

내가 사용한 부분은 auth client와, converter에서 authclient가 필요했다. 그러나 이를 explicit하게 생성하면 의존성이 드러난다. 때문에 이를 숨기고, auth client와 converter를 같이 생성하게 했다.

factory

class 생성자를 subclass에 맡김.

예시로는 attribute 값 할당을 subclass에서 해 줘야 할 때 사용.

singleton

단 하나의 instance만 사용하게 하는 방법. 메모리 낭비 방지.

private 생성자 + static 변수를 사용한다.

DB connection pool 등이 있다.

adapter

서로 호환되지 않는 interface를 작동시키는 패턴. target의 행동에 추가적인 로직을 처리해 기존 interface가 동작하게 하는 방식. 예시로는 n2t에서 네이버 형식을 티스토리 형식으로 바꾸기 위해 중간 자료구조를 하나 두고, 이를 사용한 방식이다. 직접적으로 class는 아니지만 . . .

proxy

실 연산을 다른 객체로 위임하는 패턴.

예시로실 객체를 생성하기 전 caching을 하거나 호출 시점에 만들 수 있다.

composite pattern

전체-부분 관계를 가질 때 object 관계를 정의. 내가 사용한 부분은 n2t scrapper에서 모든 type을 처리하기 위해 if-else를 변형한 strategy를 사용했는데, 이렇게 쓰니 sectionparser가 test module parsing + section parsing 2가지 역할을 가지게 되었다. 그러나 이런 tree 구조의 경우 composite pattern을 사용했으면 더 좋지 않았을까 싶다.

decorator pattern

composite와 유사. object를 dynamic하게 확장할 때 사용.

카페 음료수 예시

facade

복잡한 subsystem에 대한 interface를 만드는 방법

observer

하나의 object가 다른 여러 개의 object에게 영향을 끼칠 때 object끼리의 direct coupling 만드는 대신 observer를 두고, observer가 해당 object들에게 대신 전달하는 방식. 이를 통해 coupling 줄일 수 있음. ex) front에서 listener

Docker

개념 (container)

virtualize vs containerize

image

어떤 프로그램의 실행에 필요한 모든 파일을 포함한 패키지를 image라고 한다.

이 image를 실행한 것이 container.

vm은 운영체제까지 띄우는 방식

container는 코드, 실행 환경을 포함해 띄우는 방식.

가상화의 정도가 다름. vm은 hw까지 가상화하지만 container는 sw만 가상화함. 즉, container는 os를 공유.

vm은 host os 위에 hypervisor(os의 resource 관리해주는 도구)를 올리고, hypervisor가 각각의 os를 올림. hw를 가상화하기 때문에 각 os는 완전히 independent하지만 무겁다.

container는 host os 위에 docker engine이 올라가고, docker engine이 각각의 container를 관리함. host는 os는 공유하되, process들의 격리 환경을 만듬.

Kubernetes

개념

container application들의 deploy, scaling 등을 제공하는 관리 툴.

scaling은 CPU나 memory같은 자원 등등의 metric에 따라서 scaling한다. scaling은 pod 개수나 resource 할당량 등을 조절할 수 있다.

Git 전략

Git Flow

master, develop, feature, release, hotfix

master에서 develop 분기, develop에서 feature 분기.

develop에서 feature가 다 merge되었다면 qa를 위해 release 분기. 이후 버그 수정

최후에는 release를 develop과 main으로 merge.

hotfix는 main에서 나옴.

bizkicks의 경우 develop과 release를 하나로 합쳐 사용했다.

Github Flow

main은 항상 배포가 가능한 상태로 유지 / 최신 / stable을 유지해야 한다. 이외 feature가 있다.

merge 전에 테스트를 해야 한다.

gitlab

배포만을 담당하는 production branch를 하나 두고, pre-production (배포 전 테스트) branch를 하나 둔다.

정리

git flow와 github flow를 쓰면서 느낀 차이점은, develop branch가 있냐 없냐이다. git flow는 develop branch를 하나 두고 github flow는 그게 없다. git flow의 경우 develop branch에 변경사항이 생겼을 때 문제가 생기더라도 부담감이 덜하다. main이 아니기 때문에.. 그리고 release를 위해 별개의 branch를 생성하기 때문에 각 branch의 역할 분담이 확실하고, 오류가 났을 때도 대처가 편한 것 같다. 그러나 복잡도가 높아 PR이 많이 생성된다는 단점이 있다.

반면 github flow에서 merge를 할 때 충분한 테스트를 하지 않으면 main이 망가질 수 있다는 위험?부담이 좀 있는 것 같다. 그렇지만 훨씬 간단하기 때문에 작은 프로젝트에서 진행하기 좋을 것 같다.

MySQL, MariaDB

왜 사용했는지

어떤 특징이 있는지

왜 사용했는지

어떤 특징이 있는지

RDB에 대한 선택 이유 : 데이터가 정형화되어 있기 때문에 이해하기 쉽다. 비정형화되어 있는 NoSQL보다 이해하기가 더 쉽고, NoSQL을 사용할 만큼 트래픽이 많지 않을 거라 생각했기 때문에 RDB를 선택했다.

RDB에는 MySQL, PostgreSQL, Oracle 정도가 있다고 생각한다.

oracle은 과금을 해야 해서 선택지에서 아웃.

데이터를 자주 읽는 경우 mysql, 자주 쓰는 경우 postgres

mysql : write lock을 사용해 concurrency 구현. 때문에 쓸 때 느림. 러닝커브가 낮음
PostgreSQL : 객체 저장 가능(배열 등). write lock을 걸지 않고 mvcc를 사용함.

MariaDB는 MySQL에서 fork되어 나온 것. mariadb 사용한 이유는 mysql은 영리 목적으로 하면 라이센스 비용을 내야 하는 것으로 알고 있어서 해커톤 했을 때는 이거 나중에 채팅앱으로 만들자~ 해서 mariadb 사용하기로 했다. 어차피 둘 다 거의 유사한 db라서 그렇게 사용하기로 함.

격리 수준

mysql : repeatable read
oracle : read commited
postgresql : read commited

MVC

model-controller-view

model : 데이터 저장

controller : model, view 변경

view : 사용자에게 보이는 부분

spring의 경우, model은 repository(db), controller는 controller, service, view는 jsp가 처리.

mvc1의 경우 jsp가 controller, view 둘 모두를 수행하고 있었다. 때문에 현대 spring은 mvc 2 model을 사용한다.

Async / Sync / Block / Non-Block

각각의 정의

sync 여부 : 작업이 동기화 되었는지 여부

sync : 작업이 동기화 된 방식. A가 B를 call했을 때 B의 결과가 A로 바로 들어가면 sync.

async : 작업이 동기화되지 않은 방식. A가 B를 call했을 때 A가 B의 결과를 요청해야 하면 async. async의 경우 대기 시간이 필요한 작업을 효율적으로 다룬다.

blocking 여부 : 제어권을 넘기는지 여부. 작업이 blocking되는지 여부라고 보면 된다

blocking : A가 B를 call했을 때 B가 자신의 작업이 끝나기 전까지 제어권을 넘겨주지 않는 방식. A의 작업이 block된다.

non-blocking : A가 B를 call했을 때 B가 제어권을 바로 넘겨주는 방식. A의 작업이 block되지 않는다.

Blockchain

블록체인은 안전하게 데이터를 저장하고, 운영할 수 있게 하는 P2P 네트워킹 기술이다. 누군가가 블록체인에 트랜잭션을 추가하려고 하면 이 요청은 네트워크에 전송되며, 공개 트랜잭션이 승인된 후에만 블록체인에 추가할 수 있다. 이를 통해 중앙 시스템 없이 모든 거래에 대해 모든 사용자들이 알 수 있는 P2P 네트워크가 구축된다.

1. 네트워크에 전파

2. 트랜잭션 검증 (잔고 충분한지, 서명 유효한지, 중복되지 않았는지)

3. 채굴 : 블록의 해시값이 해당 블록체인의 기준에 맞는 결과가 나올 때까지 해시값을 반복적으로 계산해 해당 조건이 만족하는 블록을 블록체인 끝에 추가하고 네트워크로 전송. (만약 2개 이상의 노드가 다른 결과값을 블록체인 결과가 분기되는데, 네트워크 과정에서 더 긴 체인을 사용함.)

- 채굴 : 해시값을 계산하기 위해 많은 시도가 필요하며, 때문에 공격자가 네트워크를 공격하기 위해 거대한 리소스를 사용해야 한다. 또한 채굴은 누구나 할 수 있기 때문에 탈중앙화를 꾀할 수도 있음. + 보상 시스템으로 유통도 처리함.

- 한편 해싱 결과를 찾기 때문에, 찾는 것은 어렵지만 검증은 매우 빠름.

체인 : 각 트랜잭션이 체인 형태로 엮여 있음. 좀 더 자세하게는, 이전 블록의 해시값을 현재 블록에 넣어 사용함. 때문에 이전 블록을 조작하는 경우 현재 블록의 해시값이 크게 바뀌게 됨.

아키텍처

아키텍처 간단히(pipelined CPU 동작 간단히) + 베릴로그 언어
HW가 lock을 어떻게 처리하는지

RISC-V

R(arithmetic), I(load), S(store), B(branch), J(jump)

1) IF : instruction fetch

2) ID : instruction decode and operand fetch

3) EX : ALU/execute

4) MEM : memory access

5) WB : write-back

single-cycle CPU는 비효율성 때문에 사용하지 않는다. 모든 insturction이 가장 느린 instruction만큼 걸리기 때문이다.

structure hazard : resource가 busy인 것. 여기서는 memory에 값을 쓸 때 + 읽을 때가 동시에 오는 경우 발생함. 이를 해결하기 위해 clock을 절반으로 나눠, 앞쪽 절반에서는 read, 뒤쪽 절반에서는 write 하는 식으로 함.

data hazard : 이전 instruction 실행 결과를 기다려야 하는 것. stall(실행 멈춤)하거나 forwarding(실행 결과를 앞단에 넣어줌)한다.

control hazard : 이전 instruction 실행 결과에 따라 다음 instruction이 결정되는 것. 예측을 통해 해결. +4(다음 instruction)을 수행하다가, 분기 결과에 따라 해당 instruction을 멈출지 결정.

hw의 lock 처리 방법

atomic instruction의 경우 hw가 중간에 다른 명령어를 실행시키지 않는 방식으로 구현함.

memory에 대한 접근이기에, memory bus에서 해당 memory address로 접근하는 요청에 대해 lock을 건다.

async 방식으로 프로그래밍을 하는 거의 첫 경험이라 개념 잡는 데도 많은 시간이 걸렸고, instruction 종류도 많아 구현하는 데 어려웠다. 이전에는 sequential programming 형식으로, 각 module의 연산 결과를 다른 module에서 바로바로 받아와 쓸 수 있었는데, 베릴로그는 모든 상태 변화가 clock 신호와 동기화되어 있기 때문에 기존 프로그래밍 패러다임과 차이가 있어서 어려웠다. 해결은 동기/비동기에 대한 개념을 명확하게 잡고, 결국 시간 많이 쓰니까 해결 되더라.

Async / Await

await는 promise에서 then을 쓰는 것과 동일하다.

즉.. promise의 값이 나올 때까지 await한다는 것.

let a = await func();을 통해 async func()의 promise 결과를 바로 받을 수 있다.

사실상 코드 이쁘게 만드는 방법. (더 직관적인 이해 가능)

오류 코드도 간편해지고 sync style이랑 코드가 비슷해짐. callback도 사용하지 않아도 됨. 여러 개의 promise도 사용할 수 있음.

javascript 동작 방식

asynchronous event loop model ?

event가 발생할 때마다 이를 처리하기 위한 함수를 등록하고, event 발생 시 해당 함수 실행하는 방식.

javascript는 single thread 기반의, event loop model.

내부적으로 call stack에다가 코드를 넣어서 동작시킨다. 만약 바로 실행할 수 없는 코드의 경우(timeout, event listener 등등), browser web API 내에 해당 코드들을 넣어 둔다. (일종의 대기실, 새로운 thread가 생성되어 작업을 함) 내부적으로 동작 과정에서 async하게 background thread를 사용한다.

- 즉, async 작업이 발생하면 해당 작업을 background thread pool로 보내 새로운 thread를 생성해 사용한다.

browser web API에서 작업이 끝나면 바로 call stack으로 들어가서 코드가 실행되는 게 아니라, callback queue로 들어간 이후에 하나씩 call stack으로 올려보낸다. (단, call stack이 빌 때만 올려준다. - 때문에 I/O가 많은 작업에 유리하며 CPU 작업이 많은 서버인 경우 불리하다.)

Node.js vs Spring

node.js

- asynchronous event loop model을 사용하므로, I/O 작업을 비동기로 처리하기 때문에 I/O가 많은 작업에 유리함

- CPU 작업이 많은 경우에는 callback queue에 있는 것이 실행되지 않기 때문에 좋지 않다.

- 가볍다.

spring

- spring은 CPU 작업이 많은 경우가 좋다. 연산이 많은 경우 thread를 사용해 명시적으로 처리할 수 있기 때문에 효율적.

- type-safe하다.

- 실행에 오래 걸린다. (JVM, GC)

- 플랫폼 독립. (jvm 위에서 돌 수 있음)

- thread 생성 위해서는 개발자의 관리가 필요함.

성능상 큰 차이는 없을 것 같다. spring에서 thread 생성해서 오래 걸리는 작업을 multi thread로 돌리면 되는 것 아닌지?

1. 초기에 정해진 크기만큼 thread 생성함

2. 사용자 요청이 들어오면 queue에 담아두고, idle 상태(놀고 있는) thread가 있으면 queue에서 꺼내서 작업을 thread에 할당함.

- idle인 thread가 없다면 작업은 queue에서 대기, 만약 queue가 가득 차면 thread 새로 생성.

- task 완료 시 thread는 idle 상태로 돌아가고, queue가 비고 thread가 초기 개수보다 더 많다면 destroy.

=> 미리 만들어 놓고, 필요한 작업에 할당했다가 돌려받음.

JPA & Transactional & Test annotation

@transational

해당 메소드가 transation이 되게 보장해줌. 여러 DB 쿼리가 있으면 이것들을 transaction으로 묶음. 하나라도 문제 발생 시 롤백. 종료 시 commit().

여러 개의 transactional이 있는 경우, 격리 수준을 사용해서 해당 리소스에 접근. 순서는 jvm 스케쥴링에 따름.

rollbackfor option : 기본적으로 unchecked exception만 롤백하기 때문에 exception도 롤백하게 지정

readonly option:

---

slice test : 특정 계층만 처리 가능. @springboottest : 전체, @webmvctest: controller, 등

@test

junit에서 test annotation 다 모아서 테스트 돌려줌.

@springboottest

spring에서 bean 등록한 것들 "다" 모아서 injection해줌.

테스트 코드에서 @transactional 쓰면 쿼리 날린 것 다 롤백해 줌. (안붙이면 롤백안됨)

bean 등록한거에서 가져오고 싶으면 @autowired 쓰면 됨

@webmvctest

controller 관련만 로드함. @mockbean 만들고 리턴값 정의해서 써야 함.

플젝

SW개발병

육군본부 운영지원과에서 내부 WAS를 유지보수하는 일을 했다. 주로 추가 요구사항 구현, 버그 픽스, 보안 취약점 수정 등을 진행함.

어떤 일을 했는지, 내부 구성은 어땠는지, 어떤 일이 제일 기억에 남았는지

- 내가 어떤 과에서 뭘 유지보수했고, 어떤 걸 유지보수했으며, 어떤 이슈가 있었고, 어떻게 고쳤는지.

육군본부 내부에서 사용하는 웹 서버를 유지보수 했습니다. 서버 자체는 내부에서 띄워주고, 어떤 방식으로 띄우는지는 알 수 없었다. 주로 추가 요구사항 구현, 버그 픽스, 등등 업무를 진행했다.

내부 코드는 전자정부프레임워크 3.2를 사용한다. 2014년도에 나왔네..

직접적으로 티켓같은 걸 맡지는 않고 파견 형식이라 처리하는 방식.

로컬 환경 구성은 조금 어지러운데, 내부 규칙으로 인해서 java 파일을 올리지 못한다. 그래서 컴파일된 .class 파일들만 다 올라가 있는데, 그것들을 디컴파일해서 오류 수정하고 처리했다.

젤 힘들었던 것 : 로컬 구성 + 인수인계 + git 없음

+ 소마는 왜 했는지 - SW개발병 가려고 했다고 했다.

쿼리 최적화는 어떤 거 했는지 : 쿼리 최적화 포스트

타이밍 + 권한이 없어서 추가 분석 못한 게 아쉬움.

MVC 구조는 뭐고, 어떻게 수정했는지, 얼만큼 수정했는지 기존 코드는 controller에 모든 코드가 다 있어서 service repository로 분리했다고 했더니, 굳이 나눌 필요가 있나요? 라는 질문이 들어왔다. 유지보수하기 편하게 하려고 그렇게 했다고 답했다. 하나에 다 몰아두면 뭐가 뭔지 구분하기 힘드니까.

보안

XSS, SQL Injection, path traversal, web shell

XSS는 동적 웹 페이지의 입력 폼에 javascript 명령어를 넣는 등의 방식을 통해 해당 페이지에 접근하는 사용자의 브라우저에서 악의적인 스크립트를 실행시키는 공격 방법이다.

가장 쉬운 해결방법은 모든 입력값에 대해 <, >, ", '와 같은 script에서 사용하는 특수문자를 HTML character entity refernce로 바꾸는 방법으로 바꾸는 것이다. < → < > → > " → " ' → ' 이 경우, 모든 사용자 입력값에 대해 검증해야 하기 때문에 코드가 난잡해질 수 있으며 사용자가 html을 입력할 수 없다는 단점이 있다. 그러나 난잡한 코드는 servlet filter로 대체할 수 있고, 사용자가 직접 html을 입력하게 하는 대신 개발자가 설정한 특정 태그만 white-list로 열어두던지, 아니면 정해진 format으로만 출력되게 하는 방법이 있을 것이다.

SQL Injection은 사용자가 입력한 값이 필터링이나 이스케이핑 없이 DB로 들어가는 경우에 할 수 있는 공격 방법이다. 변수가 바로 SQL문에 들어가는 경우 주석처리나 OR 등의 연산자를 통해 원하는 SQL을 실행할 수 있게 된다.

가장 쉬운 해결방법은 prepared statement를 사용하는 것이다. prepared statement가 무엇인지 설명하려면 그것만으로도 포스팅 하나가 나오니, 간단하게만 설명하자면 "SQL 캐싱을 통해 사용자 입력을 순수 문자열로만 치환해서 SQL을 날리는 방법"입니다. SQL Injection을 막아줄 뿐만 아니라 캐싱해두기 때문에 같은 SQL을 실행시킬 때 시간이 단축된다는 장점도 있다.

Path Traversal은 파일 다운로드 시 파일 이름을 이용한다는 것에 착안하여 window의 경우 ../이나, unix의 경우 ..\와 같이 상위 폴더로 움직여 시스템의 중요한 정보를 탈취할 수 있는 공격 기법이다.

가장 쉬운 해결방법은 사용자 입력에 ../, ./, .|, ..|, ..\, .\, ||와 같은 특수문자가 있으면 지워버리거나 접근을 차단하는 방법이다. 단순히 ../를 공백으로 치환해버린다면 ....//와 같이 여러 번 중첩해서 사용할 경우 뚫릴 위험이 있기 때문이다.

Upload Attack은 첨부파일과 같이 사용자가 파일을 서버로 업로드하는 기능을 악용해 서버에서 실행되는 .jsp나 .php와 같은 스크립트를 업로드하고, 해당 스크립트를 통해 서버측의 권한을 탈취할 수 있다. 여러 방어를 우회하기 위해 a.jsp.jpg와 같이 확장자를 2개 붙이기도 하고, a.jSp와 같이 대소문자를 바꿔넣기도 하고, a.jsp%00.jpg와 같이 null 문자열을 중간에 넣기도 한다.

가장 쉬운 해결방법은 업로드한 파일 이름의 뒤에서부터 검사하고, white-list 방식을 사용하는 것이다. 다른 방법은 파일 이름을 저장할 때 내부 저장값으로 인코딩/디코딩 하는 것이다.

쿼리 최적화

어떤 쿼리를 최적화했으며, 어떻게 바꿨고, 왜 그렇게 바꿨고, 왜 그렇게 생각했는지.

쿼리 최적화 포스팅에 있는 내용대로 말했다. 일단 실행계획 봤더니 nested loop으로 도는 것 확인해서 nested for loop 3중이라서 오래 걸렸고, 때문에 join으로 바꿨다고 말했다.

왜 join을 선택했냐는 질문에는 일단 nested loop를 없애야 한다고 생각했고, join 이후 필터링한 값을 사용하면 불필요한 반복문이 생기지 않고, + table size가 작아 join overhead가 크지 않을 것이라 생각했다.

시간복잡도는 제껴두고, nested for loop의 경우 A join B면 A + AB이고, hash join같은 경우는 A + B로 처리된다. 3중이니까 A join B join C면 A + A(B+BC)니까 A + AB + ABC인데, join이면 A+B+C로 처리된다. 이런 page 개념으로 시간복잡도를 설명.

쿼리 옵티마이저가 어떤 방식으로 동작하는지도 물어봤다.

DB 정규화

접수번호	주민번호	종류	상해등급	민원등급
1	****-*****	민원	null	3급
2	****-*****	의무조사	1급	null
3	****-*****	민원	null	4급

DB 정규화 & 리팩토링

요구사항 : 보통전공상심사관리체계 - 기존 현역/공익 타입으로 입력을 받고 있었는데, 입력 페이지가 1개였다. 현역인 경우 상해등급에 값이 있고, 민원등급인 경우 민원등급에 값이 있다. 그러나 입력 페이지가 1개여서, 현역인 경우에는 민원등급에 값을 비워 쓰고, 민원등급인 경우 현역등급에 값을 비워 쓰고 있었다. 이게 불편하다는 요구사항이 있었다.
정규화 한 이유 : 종류가 상해등급/민원등급의 null을 결정. 또한 DB 컬럼이 매우 많고, 자주 사용하는 것들만 사용하기 때문에 overhead가 너무 클 것이라 생각. 실제로 로딩에 오래 걸리기도 하고.

기존 테이블 - 접수번호가 다른 것 모든 것을 결정.

이 테이블은 0NF. null 값이 존재하기 때문. 그것만 없으면 모든 값이 원자값이고, key가 접수번호이기 떄문에 부분적 함수 종속이 없다. 그러나 이행적 함수 종속 (pk id -> 접수번호 -> 나머지) 가 있기 때문에 1NF.

물론 null값이면 1NF를 만족하는지 여부는 논쟁 중이긴 하지만, 나는 그렇게 생각한다. 여기서는 반면 접수번호로 종류, 종류로 상해등급의 null 여부를 알 수 있다. 반면 종류가 민원이냐, 의무조사에 따라 식별하지는 못하지만 null값이 되는 column이 있기 때문에 이를 고쳐야 한다고 생각했다.

때문에 [접수번호, 종류, 주민번호]와 같이 공통된 부분을 묶고, 나머지를 따로 떼서 다른 테이블을 만들었다. vertical partitioning의 방법을 사용해 anomaly를 없앤 것이라 보면 될 것 같다.

id를 long으로 두는 이유는, 비즈니스 정보를 id로 두는 경우 해당 정보가 수정될 수 있는 상황이 올 수도 있기 때문. 또한 long으로 두면 auto_increment로 관리하기 쉽고, id는 숫자이기 때문에 문자보다 비교 속도도 더 빠르기 때문.

리팩토링

정규화와 이어지는 부분. DB가 바뀌었기에 repository 역할 하는 XML도 변경, XML 사용하는 service도 변경. controller에서는 기존 페이지 구조를 같게 해야 한다는 요구사항이 있어 controller는 하나로 둠.

하나의 URL로 두 종류의 값을 받아야 하는 것이 기본 요구사항.

1. controller에서는 super DTO를 사용해 두 종류의 값을 모두 받는다. 아래와 같은 느낌이다. 여기서 if-else문을 strategy pattern으로 해결했다. return url도 같은 방식으로 map에 넣어서 해결. 내부 들어가는 것에 대한 처리는 service 내부에서 해 줬다.

2. service는, 공통 양식 로직을 처리하는 DutyService, 이를 상속하는 ActiveDutyService와 ReserveDutyService 2개로 나누어, 세부 구현을 맡겼다. template method pattern이다. 변하지 않는 공통 부분은 묶고, 변하는(type에 따라 다른) 부분만 위임해서 해당 repository를 호출하는 식으로.

3. template method는 abstract class와 inheritance와 override를 사용하는 방식, strategy는 interface와 polymorphism을 사용하는 방식이다. strategy pattern은 동적으로 type을 선택하기 위함, template method는 공통 부분을 사용하기 위함. 여기서는 abstract class를 사용하긴 했지만, polymorphism을 썼다.

공통 부분을 가져오는 로직이 있는데, interface를 쓰면 이 부분이 중복되기 때문에 abstract class를 썼고 - 따라서 template method가 적용된 것이고, 각 type별로 넣는 부분이 있는데, 이 부분은 type별로 따로 써야 하니까 processDuty()를 override하는 방식으로 - 따라서 template method가 적용된 것이다.

strategy pattern은 type을 동적으로 가져오기 위해 사용했다. - controller에서 쓰인 것. controller가 service를 호출하는 것이 역할이라고 생각해서 service 내부에서 service 호출하지 않고, controller에서 service 호출하게 함.

@PostMapping("/processPerson")
public ResponseEntity<String> processPerson(@RequestBody PersonDTO personDTO) {
    if ("ActiveDuty".equals(personDTO.getType())) {
        activeDutyService.processDuty((ActiveDutyDTO) personDTO);
    } else if ("ReserveDuty".equals(personDTO.getType())) {
        reserveDutyService.processDuty((ReserveDutyDTO) personDTO);
    }
    return ResponseEntity.ok("Input processed successfully");
}

@RestController
public class YourController {
    private final Map<String, DutyProcessingService> dutyProcessingMap;
 
    public YourController() {
        dutyProcessingMap = new HashMap<>();
        dutyProcessingMap.put("ActiveDuty", new ActiveDutyProcessingService());
        dutyProcessingMap.put("ReserveDuty", new ReserveDutyProcessingService());
    }
 
    @PostMapping("/processPerson")
    public ModelAndView processPerson(@RequestBody PersonDTO personDTO) {
        DutyProcessingService dutyProcessingService = dutyProcessingMap.get(personDTO.getType());
        if (dutyProcessingService != null) {
            PersonDTO resultPersonDTO = dutyProcessingService.processDuty(personDTO);
            ModelAndView modelAndView = new ModelAndView();
            modelAndView.setViewName("/.../" + dutyProcessingService.getViewName());
            modelAndView.addObject("person", resultPersonDTO);
            return modelAndView;
        } else {
            // 유효한 유형이 아닌 경우 처리
            return new ModelAndView("error"); // 에러 페이지로 리다이렉트 또는 에러 처리를 할 수 있습니다.
        }
    }
}

위 코드는 접은글 1번의 코드.

소마

프로젝트 : 법인의 임직원들이 복지 용도로 사용할 수 있는 통합 공유킥보드 플랫폼

무슨 프로젝트를 했고 어떤 과정이 있었는지, 어떤 기술을 썼는지, 쓰면서 힘든 점은 없었는지, 팀 빌딩은 어떻게 했고 주제는 어떻게 골랐는지 : 소마 회고록에 있는 내용 거의 다 말했던 것 같다.

CRUD 말고 API 몇개 정도 만들었는지 : 통계 3개, 계약, 사용 CRUD정도 말했다.

기술 선택은 어떻게 했고 jenkins pipeline은 어떻게 구성했는지, 막힌 점은 없었는지, yaml 파일 쓰면서 어려운 건 없었는지 : hook 따오고 gradle build, gradle test, sonarqube 분석, gcr image push, clean까지 했었다고 답변했다. CI를 하지 않은 이유는, push를 한 시점 == 배포 시점이 되면 안될 것 같아서 배포를 위해서는 저장한 image를 GKE에서 명령어 쳐서 배포하는 방식으로 했다.

왜 GCP 썼는지 : 익숙해서 사용했다고 했다. 학교 딥러닝 프로젝트 하면서 그래픽카드가 필요했는데, 2019년도즘? GCP에서 GPU 포함 30만원 정도 크레딧을 줬다. (작년까지도 준 것으로 안다) 그래서 그때부터 잘 사용했다.

redis는 왜 썼는지 - login token을 jwt로 구현했는데, logout 검증하려고 사용했다. 토큰 기반 인증 사용한 이유는 pod 여러 개 두려고 사용했다고 했다.

추가 질문 - redis 날아가면 어떻게 처리할 건지 물어봤다. 고민해보지 못한 점. 원했던 건 분산처리나 백업이었던 것 같다. replica 만들던가, dual로 동작시키던가 하는 백업 방안을 원했던 것 같다. 그리고 나는 access token, refresh token 모두 redis에 뒀는데 refresh는 DB에 둬야할 것 같다.

k8s 사용하면서 어땠는지 - 배포 알아서 해주고 로드밸런싱 해주니까 좋았다고 답변했다.

사실상 새로운 기술을 사용하면서 느낀 점은 많이 편하다...가 거의 대부분이었는데, 더 질문이 들어와서 좀 어려웠다.

Bizkicks에서 JWT/redis

bizkicks에서는 access token + refresh token을 사용했다. redis를 사용한 이유는 scale out을 위해서인데 해당 부분은 구현하지 않았다. refresh token만 redis에 넣는다.

login 요청이 오면 access token + refresh token을 돌려준다.
access token + refresh token으로 reissue한다.
모든 접근에는 access token만 사용한다. 만약 만료될 경우 refresh token을 보내서 reissue한다. 만약 틀리다면 작동 안되는 식이다.
refresh token은 redis에 들어가 있다. refresh token을 받아서 reissue하는 방식이기 때문에 자주 불릴 것이라 예측했고, 따라서 빠른 in memory DB인 redis에 넣었다. 또 만료 시간을 DB가 관리해 준다는 장점도 있었다. (DB의 부하 감소)
refresh token이 없다는 것은 로그아웃된 상태임을 시사한다.

meerkat에서는 access token만 사용했다. token 인증 방식이다.

redis의 사용 이유는

in memory DB라 속도가 빠르며, 사용자 token이라는 간단한 정보만 넣기 때문에 key-value store가 적당하다. 그리고 시간도 알아서 관리해 준다.
정보가 많다.
이후 확장할 때 pub/sub 구조 등을 활용해서 jwt 처리하기가 다른 DB보다 쉽다.

단점

in memory DB이기 때문에 날아갈 수 있다. 그러면 reissue 로직에서 redis에 있는 값을 보는데, 없기 떄문에 로그아웃 처리가 된 것으로 했다. 따라서 access token의 만료 시간인 15분에 한 번씩 로그인해 주어야 한다는 단점이 있다. memory DB이기 때문에 불안정하다는 단점은 replica를 만들던가, dual로 동작시키던가 하는 방법이 있을 것이다.

추가적으로 refresh token 관리

기존 코드에서 redis에 access token, refresh token 둘 다 넣었는데 redis가 날아가는 상황을 고려하지 않았다. 좀 더 안정적인 서비스를 위해서는 refresh token을 DB에 넣는 것이 더 좋을 것 같다. 어차피 refresh token은 access token이 만료되는 상황에서만 불러지니까 그렇게 load도 심하지 않을 것이다.

탈취

access token 탈취 시 해킹에 의한 피해를 줄이기 위해 지소시간이 짧은 access token을 사용한다. 그러나 refresh token이 탈취당하는 경우에는 access token을 재발급할 수 있으므로 피해가 커질 것이다.

이를 해결하기 위해 refresh token rotation 기법을 사용하는데, access token이 만료되어 refresh받을 때 refresh token도 재발급하는 방법이다. 그러나 이 방법의 경우 해커가 먼저 refresh를 하는 경우에 문제가 발생한다. 때문에 DB에 저장할 때 user id : refresh token 이런 식으로 저장해서 refresh token이 단 하나만 존재할 수 있게 한다. 이후, refresh 요청을 보냈을 때 refresh token이 저장된 것과 다르다면 해킹 시도로 간주하고 로그아웃시키는 방법이 있다.

- 이 경우 해커가 refresh token을 탈취했을 때, 사용자보다 늦게 로그인하면 로그아웃 처리가 되고, 사용자보다 빨리 로그인하면 사용자가 로그인했을 때 로그아웃 처리가 된다.

- 그러나 사용자가 로그인하지 않는 경우에는 해커는 사용자 정보로 계속 활동할 수 있게 된다. 그러나 이는 토큰 방식의 필연적인 한계라 생각한다. 해결 방법으로는 refresh token의 유효기간을 두는 것. (로그인 시 7일 이후에는 새로 로그인해야 하는 등)

미어캣

미어캣 : E2EE를 적용한 안전한 실시간 채팅 앱

누구랑 어떤 프로젝트 했는지, 왜 만들었는지, 기술 선택 이유는 무엇인지 - mariadb 쓴 이유는 뭔지, orm은 왜 썼는지, 어디까지 구현했는지, 채팅 어떻게 구현되었는지

ORM 얘기. 이거 좀 많이 했다.

ORM을 왜 쓰는지 ? 확장성이나 유지보수성 + DB가 바뀌었을 때 쉽게 대처할 수 있다고 했다. 답변으로는 실서버에서는 DB를 바꾸는 일이 극히 드물다. 그래서 사실 DB를 바꿀 수 있어서에서 오는 장점은 거의 없고, 읽기 쉽고, 테이블이 단순해지고, query를 직접 안 쓰니까 코드 레벨에만 더 집중할 수 있다가 맞는 대답인 것 같다. 혹시나 DB를 바꾸는 상황이 되었을 때도 의존성을 줄일 수 있을 것이다.
ORM을 왜 적용했는지 : 나는 시간 없어서 안쓰는 게 맞다고 했는데 다른 팀원들이 꼭 써야 한다고 해서 수긍했다고 했다.

git 전략: rebase

docker 사용하면서 어땠는지 - 편하다고 했다. 살짝 마음에 안 든 것 같긴 하다. 추가로 이후로 모든 db나 환경 docker에 올렸다고 대답했더니 db도 올려 쓴거냐고 물어봐서 서비스당 각 db에 해당하는 걸로 올려썼다고 했다.

백만 했냐고 물어봤다 : 시간이 없어서 react로 친구 페이지, 채팅방 목록 부분을 내가 만들었다고 했다.

인증은 어떻게 했는지 : token으로 관리한다고 했다. + 모든 socket에 token을 넣어서 관리하는 식으로 했다.

E2EE?

비대칭키 암호화 : 공개키로 암호화 한 것은 개인키로만 복호화 가능. 그 역도 마찬가지. 내부적으로는 소인수분해 사용하는 RSA 쓰는 것으로 알고 있다.

암호를 만들 때 두 소수의 곱으로 만드는데, 이 때 사용한 두 소수를 찾기 힘들다. 숫자가 n일 때 n 아래의 소수를 찾는 데 nloglogn, 이는 모두 있다고 해도 O(n)이 걸림.

암호화

RSA 원리
디피헬만 간단히

salt

소인수분해 문제 : RSA

이산대수 문제 : 디피헬만

RSA
큰 정수의 소인수분해가 어렵다는 점을 활용. 비대칭키 방식. 공개키를 사용해 암호화/개인키를 사용해 복호화 또는 개인키를 사용해 암호화/공개키를 사용해 복호화 가능

개인키로 서명해서 송신자가 인증한 것을 알 수 있음

공개키 암호화 공격 시나리오

1. A, B가 메시지를 교환할 때, 해커가 B의 공개키를 탈취해 A에게 C의 공개키를 보냄.

2. A는 C의 공개키로 평문을 암호화해 B에게 보냄

3. C는 C의 개인키로 복호화하면 A의 평문을 습득할 수 있고, 이를 B의 공개키로 암호화해 B에게 보냄

4. B는 평문을 얻지만, 이미 탈취당함

디피헬만

대칭키 교환 시 사용. 키 값을 전달하는 것이 아니라 키 값을 만드는 방법을 전달함.

일방향

MD5

SHA256 : 충돌 걱정을 안 해도 괜찮은 해싱 방법

salt

비밀번호 암호화 시 평문을 그대로 저장하거나, 복호화할 수 있는 방법을 사용하지 않고 해싱으로 복호화 불가능하게 저장. 이 때 salt를 추가로 평문에 붙여서 해시 결과를 알 수 없게 하는 것.

실시간 채팅

채팅 구현 내용 : 채팅방에 속해있는 사람들은 어떻게 구현했는지, 실시간 채팅인지, socket 썼는지. 있는 그대로 얘기했다. 자료

클라이언트에 2개의 socket 연결을 이용하는데, 하나는 실시간 메시징을 위해서이고 나머지 하나는 메시지 수신에 대한 알림을 위해서. 지금 생각하기로는 채팅방 목록에서 알림 오는 거는 클라가 요청을 보내지 않고, 응답을 받기만 하면 되므로 SSE 같은 걸 쓰면 좋았을 것 같다.

모든 사람이 자신이 속해있는 모든 socket room에 join하고, 메시지 보내거나 받는 event 발생 시 read event를 발생해 최신의 읽은 메시지를 갱신하고, DB에는 모든 사람이 어떤 방에 속했는지, 각 방에서 채팅내역을 모두 보낸다.

그래서 실시간이고, E2EE 적용한 내용을 말했다.

그러면 사람마다 안 읽은 메시지 개수가 다를 수도 있지 않나? 음.. 그런 경우가 있나요? DB에서 메시지 관리하고, socket도 관리하는데, dual로 관리하는데 그런 일은 안 생길 것 같다고 답했다. 서버가 터지지 않는 이상!

SSE

polling : 클라가 서버로 일정 시간마다 데이터 요청을 보내는 방식.

long polling : 클라가 요청을 보내고, 서버에 event 발생 시 클라에게 응답하는 방식. connection이 유지되어 있어야 한다.

websocket : 실시간 연결, event 방식

websocket과 유사, client가 server로부터 데이터를 받을 수만 있음.

N2T

naver to tistory 이사 프로그램

왜 구현했는지 : 왜 구현했는지, 어떻게 구현했는지, 왜 java 썼는지에 대해 질문받았다. 있는 그대로 답했다. 필요해서 만들었고, java 공부하고자 썼다고 대답했고, 왜 CLI 썼냐는 질문에는 front 잘 못해서 그냥 cli로 깔끔하게 처리하는 게 좋을 것 같아서 그랬다고 했다.

추가 질문으로는 text만 긁어서 올린거냐고 물어봤는데, style 등 전부 다 파싱해서 올렸다고 했다.

비공개 포스트는 어떻게? 이거 하려면 사용자에게 id/pw 요구해야 하는데, 너무 사짜같아서 비공개는 배제했다. 티스토리에 올리는 건 token만 있으면 되기 때문에 이건 괜찮을 거라 생각했다.

필요없는 주석들이 너무 많았다.
try-catch문을 너무 많이 사용해 가독성이 떨어진다는 느낌을 받았다.
concrete class에 의존한다. 때문에 확장성이 없다시피 했으며 유지보수도 힘들었다.
if-else문으로 대부분의 로직을 처리한다.
테스트 코드가 없다. 때문에 소스코드를 수정한 후 검증하는 과정이 오래 걸린다.

주석 삭제. 의도를 설명한 주석, 유지보수 시 참고가 될 만한 주석만 남기고 모두 삭제. JavaDoc은 필요한 public 함수에만 남기고자 했다.
예외처리를 간소하게. 곳곳에 퍼져 있는 try-catch문을 응집시키고자 했다.
최대한 의존성을 줄이고 확장성 있게 코드를 작성하고자 했다
테스트 코드 작성

N2T 리팩토링

추후에 리팩토링했다는 이야기도 했다. 처음에는 if-else문이 너무 많게 구현했는데, 공부하다가 확장성 이슈를 크게 느껴서 implement로 구현했다고 했다. 그래서 기능 추가나, 목적지 블로그 추가해도 전체 구조는 동일하게 된다고 어필했다.

N2T 리팩토링

EME

intellij 마크다운 wysiwyg editor. 편집할 때 실제 렌더링된 결과를 보여줌. (like obsidian)

easy markdown editor

해당 프로젝트 : agile을 배우는 게 주 목적이어서 주간 회의, story point 할당, 배분, 구현 같은 것을 했다.

intellij에서 마크다운 에디터를 구현하는 것이 목적. 기존 default로는 미리보기를 위해서는 화면이 반반 나뉘며 공간을 많이 차지한다. 기존에 플러그인은 있지만, 문제점이 많았다. 탭 전환할 때 무한루프에 걸리는 건지 모르겠는데, 전환이 안 되었다. 컴퓨터 성능 모니터링 결과 성능을 크게 잡아먹는 것 같지는 않았지만, 몇몇 컴퓨터에서 이러한 문제가 발생했고 사용할 수 없는 문제가 있어 이를 해결하고자 했다.

주제 냈음, 초기 컨벤션 잡고, 전체적인 클래스 구성도 및 구현 방식 디자인, 로직 설계/작성, 테스트코드 작성, 등등 모든 부분에 관여함. 그런데 나만 이렇게 한 건 아니고 모든 팀원이 다 적극적으로 참여했다.

사용한 패턴 : observer pattern, template pattern

설명할 수 있을 정도로 준비

전체 구조도. 각 block들이 blockmanager에 notify하면 blockmanager 내부에서 markdownEditor의 updateUI()를 호출하는 식으로 구현. 내부적으로는 각 block에서 마우스 클릭 이벤트 / 키보드 클릭 이벤트를 listen하고 있음.

클래스 구조도. block은 abstract이고, 한 줄짜리로 처리 가능한 heading/horizontal line 같은 것을 처리하는 게 single line block. quote/codeblock/ul/ol 등을 처리하는 게 multiline block.

이렇게 마크다운을 여러 개의 block으로 나누고, focus된 block들만 markdown raw text로, 나머지는 html 렌더링. focus된 block에서 뭔가 이벤트가 발생한 경우, 각 케이스에 대해 처리를 했다.

- 다른 block이 클릭되는 경우 outfocus_click 이벤트를 날려 focus block을 변경

- 제일 상단에서 키보드 위 화살표나 제일 하단에서 키보드 아래 화살표가 눌리는 경우 outfocus_up, outfocus_down 이벤트를 날려 focus block 변경.

- 제일 뒤에서 엔터를 누르는 경우 new_block 이벤트를 날려 새 블록 생성 후 포커스 변경

- 제일 앞에서 delete를 누르는 경우 해당 블럭을 이전 block과 merge

- 중간에서 엔터를 누르는 경우 내용을 판단해 transform_multi나 transform_single 이벤트를 날려 적당한 block으로 변환

GUI 빼고 line coverage 90% 달성. 학점도 A+ 받음.

인성면접

개발자 선택 동기 : 대학원(AI, 시스템, 이론), 개발 시도하면서 개발동아리 하나 했는데, 하면서 적성에 잘 맞았다. 처음에는 주어진 API를 짜는 것 자체에서 재미를 느꼈는데, 하면 할수록 잘 만드는 것(요구사항을 잘 분리하고, 구조를 잘 짜고, 하는 것들)이 적성에 맞다고 느꼈다. 이후 소마, SW개발병 하면서 확신 들어서 결정.
어떤 게 좋은 코드일까? :
- 함수는 - 잘 읽히고, 수정하기 좋은 코드. 보편적인 가독성 좋은 코드란? 너무 길지도, 너무 함축적이지 않은 변수명을 사용하면서 + 함수에 parameter도 너무 많지 않으면서 (많은 경우에는 객체 하나 써서 wrapping + 적절한 이름으로 네이밍) + 하나의 로직 내에 너무 깊은 depth가 없으면서, (많은 분기문&try-catch가 없으면서, 있더라도 depth 1칸, 최대 2칸 정도) + 다른 method를 호출할 때 method 이름도 너무 길지도, 너무 함축적이지 않은 이름을 사용하는 함수 + 너무 가로로 길지도, 너무 세로로 길지도 않으면서 + 각 문단이 잘 구분되어있는 함수가 좋은 코드라 생각함.
- 전체적인 구조로는 - 전체적인 depth가 너무 깊지 않으면서 + 공통 모듈을 제외하고는 하나의 메소드가 너무 다양한 도메인에서 불리지 않으면서 (유지보수하기 힘듬) + 레이어의 구분이 잘 되어 있는? 구조가 좋은 코드라고 생각한다.
  - 레이어 : 도메인형 구조는 도메인 하나에서 사용하는 각각의 controller, service, repo, entity, dto 구분. 그러나 도메인이 섞이는 경우 복잡. (join 등) layered는 layer별로 구분. 그러나 파일 많아지는 경우에 복잡.
가장 어려웠던 경험(벽 느낀 경험) : 현실적으로는 비즈킥스 프로젝트 진행하면서. 코드 짜면서는 아키텍처.
기억나는 수업 : OR, 객체지향, 자료구조, 아키, DB, 알고리즘
자신의 장단점 :
- 집념? 목표 달성에 있어 집념있는 편. 어떤 일을 진행할 때, 해당 일의 큰 데드라인 + 자잘하게 일을 나눠서 목표를 설정한다. 목표 자체에 2일 정도의 여유 기간을 두긴 하지만 목표 자체를 달성하는 데 집념이 있다. 예를 들어 제일 힘들었던 과제인 pipelined CPU 구현 같은 경우, pair programming 했는데, 정말 잠만 자고 코딩만 했다. pair 끝나고 나서도 혼자서 추가로 구현하기도 했다. 여러 일들을 겪으면서 최근에는 목표를 타이트하게 설정하고 스트레스 받아가면서 작업하니 남는 시간에 반동으로 더 휴식을 추구하게 되었다. 그래서 조금의 여유를 두고 지속할 수 있을 정도의 부담감만 느끼는 수준으로 목표를 설정하는 쪽으로 유연하게 변경 중이다. 한편, 이 집념이 내가 맡은 어떤 일과 목표의 완수, 즉 성장과 향상심에 대한 집념이지, 의사소통에 있어 고집이 세다 이런 쪽의 집념은 아니다. 오히려 이러한 의사소통이나 충돌 같은 것에 있어서는 정말 아니다로 생각하는 것을 제외하고는 대부분 접고 들어가는 편. 대표적으로 프로젝트 기술 스택 정했을 때 팀메이트는 orm 써야 한다였는데, 나는 아니었다고 한 것. 정말 아니다라 생각하는 것 중 하나는 컨벤션. 컨벤션이라는 게 결국 팀메이트들과의 약속인데, 이를 어긴다는 건 결국 사회적 약속을 깨는 거라 생각한다. 혼자 형식 안 맞는 것도 좀 그렇고. 다른 하나는 마무리 제대로 안 하는 것? 플젝 끝냈거나 어느 정도 완성되었다면 나머지 디테일을 챙겨야 한다고 생각한다. readme나 문서, 주석 정리 등등. 이런 것들은 오히려 좋아.. 내 맘대로 할 수 있어서
- 단 : 몰입할 때는 100% 집중하는 것 같은데, 듀데이트 등 심리적 방해요소가 있으면 잘 못한다. - 때문에 항상 시간관리를 열심히 한다. + 잠이 많다. - 8-9시간은 자야 한다고 생각하는 사람인데, 때문에 깨어있는 시간과 계획 관리를 철저하게 한다.
의견 충돌 시 어떻게 해결할 건지 : 결국 의견 충돌이 나는 이유는, 현재 상황과, 특정 해결책의 장단점가지고 논쟁인데, 평행선을 이루는 이유는 확실한 근거가 부족해서라고 생각한다. 이런 상황에서는 진짜 논쟁을 하면서, 각자가 생각하고 있는 edge case에 대한 각각의 해결책들의 handling이 충분한지를 논의해보면서 더 좋은 방안을 채용할 것 같다. 만약, 그래도 해결되지 않는다면 다른 case들을 좀 더 고민해 보고, 최후의 최후에는 팀 내에서 다수결을 해야 할 것 같다. 그러나 다 잘하는 사람들끼리 모인 만큼 다들 비슷한 의견을 낼 것 같아서 그럴 일은 없을 것 같다. 그리고 최근에는 수긍을 많이 해서...
어떤 개발자가 되고 싶은지
회사에 대해 궁금한 점 : 테스트코드 쓰는 문화가 어떻게 되어 있는지, 코드리뷰 문화는 어떤지, 실제로 출근하는 분들이 많은지?
스트레스 관리법 : 잔다. 물론 낮시간이거나, 너무 급박한 일이라면 그렇지 못하겠지만, 어떻게든 충분한 수면 시간은 마련할 것 같다.
취미(여가) : 운동하거나 웹소설. 시간 좀 많이 남으면 게임하고. 유튜브 좀 본다. 쇼츠같은 건 아니고, 게임 영상이나 개발 영상 위주로 본다.
갈등관리 경험 (치어로, 포카풀) : 포카풀 일정관리 경험
회사에 들어와서 어떻게 성장하고 싶은지 : 최종적으로는 팀을 편하게 할 수 있는 만능 6각형 개발자로 성장하고 싶다. 일단은 각 능력치들을 조금씩 키우기 위해서 기존 코드가 어떻게 돌아가고 - 특히 트래픽 같은 것을 어떻게 처리하는지 공부를 하면서 작은 걸로 팀에 기여하고, 차근차근 기여할 수 있는 부분을 늘일 것.
원하지 않는 업무를 맡으면 어떻게 할지 : 백엔드가 아니라 아예 다른 작업을 시킨다면 고민을 많이 해보겠지만, 백엔드 메인 + 다른 일을 해야 하는 상황(어드민툴, 인프라 파이프라인 등)이라면 할 것 같다. 이런 일들은 원치 않는 업무라기보다는 해야 하는 일이라고 생각하기 때문. 나의 희망은 사용자와 가까운 도메인이지만, 처음부터 이런 부서에 배치를 받으면 나의 희망사항이어서 좋고, 사용자와 먼 도메인의 경우 오히려 이런저런 새로운 시도를 많이 해 볼 수 있을 것 같아서 오히려 좋다. 사용자와 가까울수록 코드 수정이 보수적으로 될 수 밖에 없다고 생각하기 때문.
나를 왜 뽑아야 하는지 : 팀에 기여할 수 있기 때문. 작게는 업무 프로세스 개선에서 - 크게는 코드 작성까지, 부족한 부분을 채우고
집념? : 원하는 거 있으면 목표를 달성할 때까지 하나만 판다. 그 과정이 조금 힘들더라도? ex) 과제할 때 2주동안 그거만 한다던가, 미어캣 프로젝트 때 프로젝트 완결 & 수상이라는 목표를 위해서 원래 맡기로 했던 역할을 넘어 팀에 기여하는 방향을 선택한다던가. (나 개인의 목표. 팀의 목표는 언제나 변할 수 있다고 생각한다.)
마감일 vs 퀄리티 : 퀄리티가 먼저라고 생각함. 일반적으로 마감일이라는 게 급박하게 주어지는 게 아니고, 결국 나도 처음에 동의한 내용이기 때문에 마감일을 맞추지 못하는 경우에는 삽질 등에 의해 지체되는 경우가 대부분일 것. 이 경우에, 중간중간 이러한 이유로 지체되고 있다는 것을 알리는 것이 먼저라고 생각. 프로젝트를 런칭했을 때 버그가 터져 사용자들이 불편함을 겪어 이탈하는 것과, 지연되어서 이탈하는 것을 비교하면 후자가 훨씬 나을 거라 생각. (물론 지연도 너무 많이 되면 안되겠지만)
일하고 싶은 도메인 : 가능하다면 트래픽을 많이 다루고, 시니어들에게 많은 것을 배울 수 있는 부서. 도메인은 음.. 이번에 네이버/네이버 클라우드/네이버랩스/네이버페이 이렇게 있는 걸로 아는데. 사용자와 가까운 도메인에 있고 싶다. 네이버나 네이버페이쪽?
같이 일하고 싶은 / 일하기 싫은 스타일 : 편하게 질문할 수 있는 사람. 어려움을 공유하고, 같이 고민하는 과정에서 더 빨리 문제를 해결할 수 있을 것이다. 일하기 싫은 스타일은 너무 퉁명한 경우.
평상시에 어떻게 공부하는지 : 기술에 대한 agenda는 유튜브 알고리즘에 뜨는 신규 기술들이나, 또는 간혹 기술 채널들에 나오는 것들을 본다. 아니면 프로그래머스 같은 데서 나오는 개발자들의 기술 통계 같은 것을 보고. 그 중에서 재밌어 보이는 것 - 내가 느꼈던 어려움을 해결할 수 있는 기술들에 대해 흥미를 가지고 공부한다. 최근에는 blue green 봤고, 이전에는 spring 이외에도 node.js, nestjs 등등 공부하기도 함.
꿈 : 사람들에게 긍정적인 영향을 주는 사람. 그것이 개발 내적이던, 개발 외적이던, 내가 만든 서비스를 사용하는 사람들이던 간에 나로 인해서 다른 사람들이 성장하거나, 정서적으로 편안함을 느낀다던가 등 긍정적인 영향을 주었으면 좋겠다.
마지막 한마디

자료구조 면접대비 질문

hyelie — Wed, 4 Oct 2023 10:05:58 +0900

Hash Table

정의

collision 해결 방식

hash function

어떤 key가 주어졌을 때 hash function으로 매핑하고, 거기에 값을 저장하는 key-value store.

메모리에 쓰는 경우, 값이 유한하기 때문에 collision이 발생한다.

separate chaining : 해당 bucket에 linked list 추가하는 방식. 쏠릴 수 있어 worst O(n)
open addressing : 해당 위치가 아니라 빈 공간을 사용하는 방식. 예외가 많아 어렵다.

hash function은 임의의 길이 data를 고정 길이 data로 매핑하는 함수.

Quick Sort

pivot 기준으로 왼쪽에는 작은 수, 오른쪽에는 큰 수 둔다. pivot은 적당한 값을 고른다.

in-memory sort라서 평균적 O(nlogn)

Array, Stack, Queue, Tree, Heap, Linked List, Graph, Set

특징

array

메모리에 연속적으로 저장됨. index를 사용해 O(1)로 접근 가능.

연속적으로 할당되기 때문에, 앞/뒤에 넣는 경우에는 새로운 위치를 찾아야 하고, 중간에 들어가는 경우는 모든 요소를 미뤄야 하므로 O(n).

stack

last in first out

queue

first in first out

heap

complete binary tree + parent가 child보다 항상 작음. (min heap 기준)

tree

graph의 일종으로, edge 개수가 vertex 개수보다 1개 적은 것. connected & acycle & undirected graph

linked list

각 element가 이전/이후에 오는 element를 알고 있다.

삽입/삭제에 O(1).

검색하는 데는 앞에서부터 순회해야 하므로 O(n)

memory cache를 사용하지 못하기 때문에 느리다.

graph

vertex, edge로 이루어진 자료구조. edge는 vertex를 잇는다.

- adjacent matrix : O(n * n), 판별에는 O(1)

- adjacent list : O(V+E), 판별에는 O(deg(v))

set

중복 허용 X

binary tree 종류

binary search tree

complete binary tree

balanced binary tree

perfect binary tree

binary search tree

검색 위해 사용, binary tree인데, 정렬된 것. parent보다 작은 것들이 왼쪽, 큰 것이 오른쪽에 온다.

worst case O(n)이라서, balanced binary search tree 등으로 O(logn)을 유지할 수 있다.

complete binary tree

마지막 level 제외하고는 모든 level이 완전히 채워짐.

- min heap의 경우 parent가 child보다 항상 작다. 삽입 시 제일 끝에 넣고 swap, 삭제 시 root로 올리고 비교하며 내림.

balanced binary tree

left child와 right child의 height 차이가 최대 1. avl이나 rb tree.

- avl에서 삽입/삭제 시 회전한다.

- rb tree에서 색을 사용해 균형 유지. avl보다 조금 빠르다.

perfect binary tree

leaf node 제외, 모두 2개의 child 가짐

Trie

정의

문자열에서 검색 빠르게 도와줌.

문자열을 tree로 만든 것.

네트워크 면접대비 질문

hyelie — Wed, 4 Oct 2023 09:29:30 +0900

URL vs URI

URL : uniform resource locator, resource의 위치

URI : uniform resource identifier, resource의 식별자

HTTP

정의

특징

http request message / response message에 들어가는 것들

hypertext transfer protocol의 약자

client-server model, TCP 사용, stateless(상태 저장 x) 등의 특징이 있다.

stateless를 해결하기 위해 cookie나 session을 사용한다.

HTTP request message에는 request, header, body가 있다.

method는 GET, POST, PUT, PATCH, DELETE 등이 있다.

GET의 경우 http body가 없고 url에 모든 정보를 담아 보낸다.
POST는 http body에 값을 담아 보내는 방식이다.

HTTP response message에는 status line, header line, response body가 있다.

status code는 응답 상태를 의미한다.

200번대는 성공, 300번대는 redirect, 400번대는 client 오류, 500번대는 서버 오류

DNS

정의

사용 이유

DNS hierarchy

name resolution

DNS는 domain name system의 약자로, host name과 ip address mapping을 저장하는 distributed, hierarchical DB이다.

domain의 사용 이유 : IP address는 외우기 힘들기 때문.

모든 domain의 최상위에는 root domain이 있다. DNS server는 hierarchy가 있다. 각 DNS server는 자신이 가지고 있는 domain의 바로 아래에 있는 DNS server의 IP address를 가지고 있다.

name resolution : domain으로 IP address를 얻어오는 과정. iteration query, recursive query 2가지 방식이 있다. 여기선 iteration query 방식.

local DNS server에 request를 날린다.
local DNS server는 root DNS server에 request를 날린다.
root DNS server는 하위 domain에 해당하는 DNS server의 IP address를 가지고 있으며, 이를 response한다.
local DNS server는 하위 domain에 해당하는 DNS server의 IP address를 얻게 되는데, 여기에 request를 날린다.
... 이를 반복해 local DNS server가 목적지 DNS server IP address를 얻게 된다. local DNS server가 해당 IP address를 response한다.

DNS server

IP address

32bit로 표현하며 network 번호와 host 번호 2가지로 나뉜다. netmask로 network 번호, host 번호를 구분한다.

TCP

정의, 특징

동작 3가지

transmission control protocol.

reliable data transfer, flow control, congestion control 등 기능 지원.

TCP는 3단계가 있다. 접속, 송/수신, 끊기가 그 3가지이다.

접속 동작 - 3 way handshake

client가 server에게 SYN bit, sequence 초기값, client window 3가지 값을 server에게 보낸다.
server는 client에게 SYN bit, sequence 초기값, server window, ACK bit 4가지 값을 client에게 보낸다.
client는 server에게 ACK bit를 server에게 보낸다.

여기서 SYN, ACK는 연결 동작에서 사용하는 bit이며, SYN은 연결 요청, ACK는 수신 응답이다. 이를 통해 session이 생성된다.

또한 sequence는 난수로 설정하는데 이전 연결에 사용한 sequence값과 혼동되지 않기 위함이다.

송/수신 동작

sender가 sequence 번호 + data를 보낸다.
receiver는 ACK 번호 + server window를 보낸다.

reliable data transfer : 한 번에 보낼 수 있는 packet size가 한정되어 있기 때문에 packet을 분할해야 한다. 때문에 sequence가 필요하다. 필요 시 data를 분할하고, sequence 값을 사용해 해당 data가 어디부터 시작되는지 분할한다. 이를 통해 data가 사라졌는지 검증할 수 있다.

여기서 ACK 번호는 어디까지 받았는지에 대한 정보이다. 여러 개를 받은 경우, 최적화를 위해 제일 최신의 ACK 번호만 응답한다. (3 duplicated ACK)

flow control : window는 buffer overflow를 막기 위해 사용하는 값이며 receiver가 몇 byte까지 받을 수 있는지에 대한 정보이다.

congestion control

AIMD : window를 1씩 늘이고 문제 발생 시 절반으로 줄임
slow start : 매 전송마다 window를 2배로 늘이고 문제 발생 시 1로 내림.

연결 끊기 동작 - 4 way handshake

client가 server에게 FIN bit를 보낸다.
server가 client에게 ACK bit를 보낸다.
server가 client에게 FIN bit를 보낸다.
client가 server에게 ACK bit를 보낸다.
- 이 과정에서 바로 socket을 삭제하면 문제가 발생할 수 있기 때문에 조금 기다렸다가 삭제한다. 예를 들어 server가 ACK bit를 못 받은 경우 재전송하라고 FIN bit를 보내는 경우나, client는 전송이 끝났지만 server는 보낼 것이 남아있는 경우.

UDP

정의

특징

user datagram protocol

UDP는 TCP에 비해 간단하다. 그냥 보내기만 한다.

TCP vs UDP

TCP는 연결형이기 때문에 연결이 성공해야 통신할 수 있다. UDP는 비연결형이기 때문에 연결 없어도 통신할 수 있다.

TCP는 전송 순서를 보장하지만 UDP는 그렇지 않다.

TCP는 수신 여부를 확인하지만 UDP는 그렇지 않다.

TCP는 1:1 통신이지만 UDP는 n:m이 가능하다.

TCP는 문제 발생 시 재전송해서 신뢰성이 높지만 UDP는 그렇지 않다.

TCP는 느리지만 UDP는 빠르다.

ARP

정의

과정

MAC address를 조사하는 과정. subnet에 IP address에 해당하는 기기의 MAC address를 받아오는 과정.

router가 연결된 모든 router에게 arp query를 날린다.
LAN의 모든 router가 해당 frame을 수신하고, 만약 자신에게 온 것이 있다면 응답하고, 그렇지 않다면 버린다.

ethernet

packet 운반은 hub, router가 한다.

NAT

정의

이유

작동 방식

subnet 전체가 하나의 IP address를 사용하는 방식이다.

초기 IP addess는 고유한 값이어야 하지만 IP 사용자가 너무 많아지면서 수가 부족해졌고, 때문에 독립망과 같이 완전히 독립된 네트워크인 경우 같은 IP가 있어도 상관없어졌다. 때문에 주소 변환을 하며, router가 이 기능을 수행한다.

내부 - 외부

TCP packet에 있는 sender IP address와 port를 보고 적당한 값으로 변경한다.
이후 인터넷으로 송출하면 회신 packet이 돌아온다. 그 packet은 변경한 값으로 설정되어 있다.
변경된 값을 원 값으로 복구해 router가 독립망에 해당 packet을 보낸다.

외부 - 내부

내부에서 외부로 먼저 보내지 않는 한 외부에서 내부로 보낼 수 없다.

Proxy

cache server IP address를 DNS server에 등록한다. 그러면 client는 cache server에 요청을 보내게 된다.

cache miss의 경우 cache server가 web server에게 request를 날린다.
cache hit의 경우 바로 응답한다.

이게 기본 골자이고, 아래와 같은 것들이 있다.

client에 cache server를 두는 forward proxy
server에 cache server를 두는 reverse proxy

OSI

internet protocol

application layer : network applicatoin 지원, user message 생성
- presentation layer : encryption, compression 등을 해제해서 application이 data를 읽을 수 있게 한다.
- session layer : synchronization, checkpointing, data 복구 등을 담당한다.
transport layer : source process에서 destination process까지 data 전송. segment 사용. TCP/UDP.
network layer : routing을 통해 host to host delivery 수행. packet 사용. ARP, IP.
link layer : 하나의 edge를 건너가기 위해 bit를 전달. frame 사용.
physical layer : bit를 wire에 전송. bit 사용.

Socket

application layer와 transport layer의 interface

IP address를 사용해 host를 식별하고, port를 사용해 socket을 식별한다.

multiplexing : 여러 socket으로 부터 온 message를 통합/분류해 network layer에게 보내는 transport layer의 기능

demultiplexing : network layer가 수신한 packet header를 떼서 desination socket에게 분배하는 transport layer의 기능

Domain에 뭔가 입력하면 생기는 일

DHCP

ARP

DNS

TCP

HTTP

DHCP : dynamic host configuration protocol의 약자

network에 연결할 때 IP address를 할당받는다. IP address의 초기값, first hop router address, local DNS server IP address 등을 받는다.

ARP : domain을 찾기 위해 DNS server에 query를 날려야 한다. 이 때 first hop router address만 알고 있지 MAC address는 모른다. 이를 알기 위해 ARP를 수행한다.

name resolution : first hop router의 MAC address를 알게 되었다. DNS name resolution을 실행한다. 이를 통해 destination의 IP address를 알게 되었다. 이 과정에서는 UDP를 사용한다.

TCP handshake : HTTP이므로, TCP session을 생성한다.

client - server : SYN bit, sequence 초기값, client window를 보낸다.
server - client : SYN bit, ACK bit, sequence 초기값, server window를 보낸다.
client - server : ACT bit를 보낸다.

HTTP request, response : TCP session이 생성되었으면 TCP 송/수신 동작을 통해 data를 주고받는다. web browser가 HTTP request message를 생성하고, server는 해당 message를 받아 응답하고, web browser가 response를 렌더링한다.

각 router들끼리는 routing algorithm (bellman ford, dijkstra를 수행한 결과)의 결과로 routing table을 가지고 있고, routing table 내부에 어떤 IP를 어떤 router에게 보내야 하는지 정보가 있다. 이후 ARP를 통해 link layer에서 보낸다.

Cookie vs Session

cookie는 client에 저장되는 값. server가 client에게 cookie를 주면 client는 이를 저장하고 있다가 다음 요청 때 server에게 cookie와 request를 같이 보낸다.

보안에 약하다.

종료되어도 보관하고 있다.

session은 server에 저장되는 값.

보안이 좋다.

종료되면 바로 삭제한다.

HTTP vs HTTPS

HTTPS는 HTTP에 SSL을 씌운 것. 더 안전하다. 암호화하기 때문에 더 안전하다.

최초 1회에 대칭키를 교환하기 위해 비대칭키 암호화 사용, 이후부터는 대칭키 암호화 사용.

1. 최초 연결 시도 -> 서버는 공개키 넘김.

2. 클라이언트는 인증서 유효성을 검사한 후 대칭키 발급, 공개키로 암호화해 서버로 전송

3. 서버는 개인키로 복호화해 대칭키 얻음

4. 대칭키를 사용해 암호화/복호화

세션 기반 인증 vs 토큰 기반 인증

authentication vs authorization

session의 경우 작동 방식

token의 경우 작동 방식

차이점

401 Unauthorized : 인증 X, 403 Forbidden : 권한 X

authentication : login

authorization : 사용자에 대한 resource 접근 확인

session

사용자가 로그인 시 session ID가 server에 저장된다. 이후 이 값을 client에게 준다.
이후 모든 요청 시 session ID와 함께 request를 보낸다.
정보가 서버의 DB에 저장된다

token

로그인 시 인증 정보를 만들어 client에게 준다.
이후 모든 요청 시 token과 함께 request를 보내면 server는 해당 값을 decode해서 사용자를 검증한다.

session은 안전하지만, token은 암호화되지 않는다. 그렇지만 확장성이 좋기 때문에 - 확장성을 쓰면 scale out을 쓰는데, session을 사용하는 경우 해당 session은 한 server에만 저장되기 때문에 정합성 문제가 생긴다.

쿠키와의 차이점: 쿠키는 서명이 안 되어 있으므로 조작이 쉽다. 때문에 인증용으로는 사용하지 않는다. 토큰은 서명되어 있으므로 조작이 힘들다. 쿠키는 브라우저에 자동으로 저장되고 전송해 줌.

JWT

정의

작동 방식

json web token의 약자.

사용자가 로그인 시 access token을 server에 저장하고 client에게 준다.
client는 access token을 cookie에 저장하고 모든 요청에 해당 cookie값을 전송한다.
server가 모든 요청을 받으면 해당 값을 검증한다.

header, payload, signature를 .으로 구분한다.

header : type, 암호화 알고리즘에 관한 정보가 있음.
payload : 담고자 하는 정보를 json 형식으로 담음. 이 경우 복호화하면 바로 정보가 나오기 때문에 중요한 정보는 넣으면 안 된다.
signature : encoding / 유효성 검증 시 사용하는 암호화 코드

암호화, 비대칭키, 대칭키

비대칭키는 암/복호화에 다른 key 사용. public key로 암호화하고 private key로 복호화한다.

대칭키는 암/복호화에 같은 key 사용

HTTP 멱등성

정의

어떤 게 멱등성이 있는지

요청을 여러번 해도 서버 state가 동일한 경우 method를 멱등성 method라 부른다.

GET, put, delete는 멱등성, post는 아님. patch는 맞을수도 아닐수도.

필요한 이유는, network에 문제가 발생했을 떄 여러 번 가도 문제가 없어야 하기 때문.

따라서 POST 요청을 보냈는데 응답이 없는 경우, GET을 보내서 요청이 처리가 되었는지 안 되었는지 확인한 후 안 된 경우에만 다시 POST를 보내야 함.

REST

정의

rest : http uri를 통해 resource를 명시하고, HTTP method를 통해 resource에 CRUD를 적용하는 아키텍처

restful : REST를 잘 따르는 시스템

WS vs WAS

ws : 항상 동일한 data를 줌. static

was : dynamic content 제공

CORS

cross origin resource sharing

서로 다른 도메인 간에 resource를 공유하는 것. 기본적으로 차단이라 허용해야 함. 한 출처에서 실행중인 web app이 다른 출처의 자원에 접근할 수 있는 권한 부여

OS 면접대비 질문

hyelie — Mon, 2 Oct 2023 05:55:23 +0900

Floating Point

어떻게 표현하는지

case 3개

변환방식

rounding

2진수를 유효숫자 형태로 표현한 것

(-1)$^s$M2$^E$

s : sign bit. signed integer와 동일하게 0이면 양수, 1이면 음수이다.
M : significand(유효숫자). 일반적으로 [1.0, 2.0)의 범위를 가진다.
E : exponent(승수). 2의 승수를 나타낸다.

Floating Point to Number

수를 정해진 형식에 따라 sign bit, exp bit, frac bit로 분류한다.
exp bit, frac bit을 이용해 normalized / denormalized / special 분류를 한다.
exp bit로 E값을, frac bit로 M값을 구한다.
(-1)$^s$M2$^E$에 값을 넣어 수를 구한다.

Number to Floating Point

수를 2진수의 급수 형태로 표현한다.
(-1)$^s$M2$^E$ 형식으로 변환한다.
정해진 bit의 개수에 따라 bias를 구하고, E와 bias를 이용해 exp bit를 구한다. 이 때 rounding을 하며, overflow 발생 시 exp값을 조정한다.
M값으로 frac bit를 구한다.

Byte Ordering

종류 2가지

byte ordering이란 컴퓨터가 메모리에 값을 저장하는 방식

Big Endian : LSB가 high address에 저장되는 방식

Little Endian : LSB가 low address에 저장되는 방식

Calling Convention

procedure P가 Q를 호출했을 때 일어나는 일

control, data, local data

caller-saved register의 값들을 caller stack frame에 저장한다. (push)
return address를 caller stack frame에 저장한다. (push)
%rbp, %rsp register의 값이 변경되었으므로 callee procedure로 제어권이 넘어간다.
1. callee saved register의 값들을 callee stack frame에 저장한다. (push)
2. callee procedure를 실행한다.
3. ...
4. callee procedure 종료 시, callee saved register를 callee stack frame에서 가져온다. (pop)
5. return value를 %rax에 저장한다.
caller stack frame에서 %rbp를 복구한다. (pop)
caller procedure로 복귀한다.

Buffer Overflow

언제 발생하는지

왜 문제가 되는지

어떻게 막는지

데이터의 크기가 할당된 범위보다 더 클 때 원래 입력되어 있던 값들이 오염되는 현상을 buffer overflow라 한다.

return address가 다른 값으로 변경될 수 있다. return address가 위치해 있는 assembly는 무조건 실행되기 때문에 segmentation fault가 나거나, 또는 사용자가 원하는 instruction을 실행시킬 수도 있다.

stack canari 사용 : 특정 data를 return address 다음 stack에 집어넣어 이 값이 바뀌지 않았을 때만 코드를 계속 실행하는 방법.
safe function 사용 : string 입력 시 길이 제한을 두는 방법. gets() 대신 fgets()를 쓰면 된다.
non-executable code segment ; 각 memory section에 control bit를 추가해 data section code를 readonly로 바꾸어 코드를 실행 불가능하게 만드는 방법.
randomized stack offset : stack의 시작 주소를 randomized해 return address를 바꾸지 못하게 하는 방법.

Cache

locality 2종류

memory hierarchy와 cache의 개념

cache miss 3종류, cache

cache 구조 : set, line, tag, block

cache 접근 방식

set index가 가운데 있는 경우

종류 3가지

locality는 프로그램이 최근에 참조한 주소와 그 근처의 주소에 반복적으로 참조하는 경향이다.

temporal locality : 최근에 참조된 주소를 반복적으로 참조하는 것을 의미한다.
spatial locality : 최근에 참조한 주소 근처의 주소를 참조하는 것을 의미한다.

cache는 level k의 memory를 level k+1 memory의 임시 저장소처럼 작동시켜 데이터에 더 빨리 접근할 수 있는 기법이며, locality와 memory hierarchy 때문에 작동한다.

miss 종류

cold miss : cache가 비어있는 경우. 첫 번째 참조일 때 발생한다.
capacity miss : d가 cache의 크기보다 더 큰 경우.
conflict miss : cache의 크기는 충분한데도 eviction이 계속 발생해 miss가 계속 발생하는 경우

cache 구조

address가 M(=2$^m$)개의 bit로 이루어진다고 가정하자.

cache는 총 S(=2$^s$)개의 set으로 이뤄지며, 각 set은 E(=2$^e$)개의 line으로 이루어져 있다. 하나의 line은 v bit + tag bit + B(=2$^b$)개의 block으로 구성되어 있으며, 하나의 block은 1 byte의 정보를 담는다. 이 때 v는 해당 cache가 valid한지 여부이며, tag는 cache line의 식별자이다. 따라서 total cache size = S * E * B = 2$^{s+e+b}$이다.

접근 방식

address를 tag / set index / block offset으로 크게 3부분으로 나누며 이를 통해 cache에 접근한다.

set index bit를 이용해 cache set에 접근한다.
set에 있는 모든 line에 대해 tag bit를 비교한다.
- 모든 line에 대해 tag bit가 일치하는 line이 없는 경우 cache miss이다.
- 있는 경우 valid bit가 1인지 살펴본다.
  - not valid라면 cache miss이다.
  - valid라면 cache hit이다. block offset을 이용해 line에 있는 block에 접근한다.

set index가 가운데인 이유 : 인접해 있는 memory block들이 같은 set에 들어가게 된다.

종류

fully associative : 단 1개의 set만 존재
E-way set associative : 각 set당 E개의 line이 존재
direct mapped : 각 set당 1개의 line만 존재

Exception의 종류

async - interrupt, signal

interrupt : process 외부에서 발생하는 exception (time interrupt)

signal : event call과 비슷한 개념.

sync - trap, fault, trap

trap : instruction 실행 중 의도적으로 발생하는 exception (system call)

fault : 의도적이지 않은 복구 가능한 에러에 의한 exception (page fault)

abort : 의도적이지 않은 복구 불가능한 에러에 의한 exception

Dynamic Memory Allocation

정의

fragmentation 2종류

fit 종류 3가지

segmentation vs paging

memory에 프로그램을 올리기 위해 memory를 관리하는 기술

Fragmentation

internal fragmentation : 할당된 block이 data보다 클 때를 의미한다. 보통 자주 발생하며, alignment로 인한 padding 등 다양한 원인으로 인해 발생하며 측정하기 쉽다.
external fragmentation : heap memory에는 충분한 공간이 있지만 큰 하나의 free block이 없어 메모리를 할당할 수 없는 상황을 의미한다.

Fit

first fit : free block list를 처음부터 검색해서 할당할 block size보다 크기가 큰 첫 번째 free block에 할당한다.
next fit : first fit과 유사하지만 free block list를 처음부터 찾는 대신 이전에 검색이 종료된 지점부터 검색을 시작한다.
best fit : 모든 free block을 검사해 할당할 block size보다 크기가 큰 block 중 제일 작은 free block에 할당한다.

segmentation : address space 단위로 구분하는 방식. external fragmentation 비중 높아진다.

paging : page 단위로 관리하는 방식. internal fragmentation 비중 높아진다.

Garbage Collection - Mark & Sweep

뭔지, 어떻게 작동하는지

application이 직접 free하지 않고 사용하지 않는 dynamic allocated space를 자동적으로 free해주는 기법

memory와 pointer를 하나의 graph로 보아 root로부터 reachable한 것은 아직 사용중인 allocated block이고, unreachable한 것은 더 이상 사용하지 않는 garbage로 보아 이러한 block들을 free하는 방식

Process

정의

process의 address space 4가지 + 각각에 어떤 것들이 올라가는지

PCB

concurrent

process state : ready / running / block

정의 : program의 instance이다.

address space

stack - local variable, argument, return address 등이 올라간다.
heap - 동적할당한 것들이 올라간다.
global data/code - 초기화된 global variable이 올라간다.
code - instruction들이 올라간다.

PCB : process context를 저장하기 위한 자료구조. PID, state, PC, register 등 정보를 가진다.

state

running : 현재 실행 중인 process
ready : CPU의 실행을 기다리고 있는 상태
block : I/O나 resource 대기 등의 이유로 event를 기다리고 있는 상태

Process Context Switching

정의

작동 방식

언제 쓰는지

cost 종류

정의 : processor가 실행하고 있는 process를 바꾸는 것

process P0에서 P1으로 switch하기 위해서는 P0의 모든 정보를 PCB0에 저장하고, PCB1의 모든 정보를 꺼내 와 실행해야 한다.

context switching overhead는 매우 크기 때문에, I/O를 기다리는 상황 등 process를 실행하지 않는 상황에서 다른 process로 제어권을 넘긴다.

cost는 크게 2가지, direct cost(save/restore)와 opportunity cost(cache miss cost)가 있다.

Fragmentation

internal fragmentation : 할당한 block이 data보다 클 때

external fragmentation : 하나의 큰 free block이 없어 할당하지 못하는 상황

Process Scheduling

process state transition을 관리하는 것.

job, ready, wait 3가지의 queue가 있다.

Thread

정의

어떤 address space 가지는지

장점

TCB

thread state

정의 : process 내의 실행 단위

thread의 address space의 경우, stack만 고유하게 가지며, code, data, heap은 공유한다.

process에 비해 고유하게 가지는 memory가 적기 때문에 더 가볍고, 공유하고 있는 자원이 많기 때문에 context switch가 더 빠르다.

TCB : thread context를 저장하기 위한 자료구조

thread state : init, ready, running, waiting, exit 5종류가 있다.

Concurrency

동시에 실행되는 것처럼 보이는 기술.

Synchronization

정의

race condition

critical section

mutex lock

condition variable

semaphore

synchronization의 구현

synchronization : multi thread로 인해 발생하는 race condition을 막는 것.

race condition : shared data에 접근할 때 순서에 따라 다른 결과가 나올 수 있는 상태

critical section : 오직 하나의 thread만 실행되는 것이 보장되는 영역

lock의 특징

safe & mutual exclusion : 해당 thread만 실행하는 것이 보장됨
progress : 아무도 lock을 가지고 있지 않다면 바로 lock을 얻을 수 있다.
bounded wait : 언젠가는 lock을 얻는다.

mutex lock

acquire() : lock이 free될 때까지 기다리며, free가 되면 lock을 가져온다.
release() : lock을 release하고 lock을 기다리는 thread를 깨운다.

condition variable : lock을 가진 도중 sleep할 수 없는 문제를 해결하기 위해 만들어진 것. lock의 보조 도구 느낌으로 쓴다.

wait() : [lock release + sleep]한 후, 누군가가 깨우면 lock을 얻는다.
signal() : waiting thread가 있다면 깨운다.
broadcast() : 모든 waiting thread를 깨운다.

semaphore : 일반화된 lock으로 여러 thread가 critical section에 접근할 수 있게 해 준다.

P() : 값이 양수가 될 때까지 기다리며, 양수가 되면 1을 뺀다. wait()와 유사.
V() : 값에 1을 더하고 P()를 호출한 thread가 있다면 깨운다. signal()과 유사.
만약 값을 1로 초기화하면 mutex처럼 쓸 수 있고, 0으로 초기화하면 coordination을 위해 쓸 수 있다. (scheduling constraints)

synchronization 구현은, uniprocessor에서는 interrupt로 쓰면 좋다. 그러나 multiprocessor인 경우 ready-modify-write instruction(memory에서 값을 읽고 수정하고 다시 쓰는 instruction)인 atomic function을 사용해 이를 구현한다.

test-and-set : lock을 BUSY로 바꾸고 기존 lock 값을 가져오는 방법. 이 자체가 atomic instruction이고 HW에서 보장한다. 기존 lock이 FREE면 acquire하는 식이다.
- test-test-and-set : lock을 얻기 위해 lock의 값을 확인하는 단계를 거친다. 때문에 성능상 실행 시간이 더 줄고, test-and-set은 cache를 계속 갱신하므로 overhead가 크다. test-test-and-set은 얻을 수 있을 때만 test-and-set을 하므로 그 간극을 줄일 수 있다.

java monitor는 하나의 lock과 0개 이상의 condition variable을 사용해 shared data에 대산 concurrent한 접근 관리를 위한, 높은 추상화를 가진 도구이다. shared object와 유사하지만 명시적으로 lock을 사용할 필요가 없어 더 쉽게 synchronization을 처리할 수 있다. lock은 mutual exclusion을 위해, condition variable은 scheduling을 위해 사용한다.

lock에 대한 방법 : queueing lock으로 구현하는 것이 효율적.

process lifecycle

thread lifecycle

Multiprocessor Synchronization

lock contention

cache ping

cache coherence

mutliprocessor에서 test-and-set의 문제점과 해결방법

lock contention : 한 번에 하나의 thread만 lock을 가질 수 있기 때문에 경쟁이 더 심해진다.

cache ping : context switch가 일어나며 shared variable의 cache가 여러 번 갱신되고, cache coherence를 유지하기 위해 해당 cache를 invalidate하기 때문에 cache 효율이 떨어진다.

cache coherence : 각 processor의 cache가 일관성있게 유지되어야 하는 것을 의미한다.

multiprocessor에서 test-and-set의 문제점

test-and-set은 shared variable의 값을 계속 cache에 값을 쓰기 때문에, 다른 processor들이 참조하고 있는 cache를 invalidate한다. 따라서 test-test-and-set을 쓰면 효율이 좀 더 좋아진다.
lock의 starvation이 일어날 수 있다.

이를 해결하기 위해 ticket lock이나 MCS lock 등 해결 방법을 사용한다.

ticket lock은 이름처럼 ticket을 뽑고, 자신의 차례가 올 때까지 기다리는 방식이다.
MCS lock은 cache coherence 문제를 해결하는 방식으로, compare-and-swap과 queue로 lock을 관리하는 방식이다. lock 획득 시 이전 thread가 쓴 데이터를 읽고, 때문에 cache miss가 나도 오직 1개의 process에서만 나게 된다.

Deadlock

정의

조건 4가지

처리 방식 3가지

정의 : 2개 이상의 작업이 resource를 할당받기 위해 circular waiting을 하고 있는 상태. resource는 CPU, disk 공간, memory, lock 등.

조건

mutual exclusion : 한 번에 하나의 thread/process만 resource에 접근할 수 있다.
non preemption : 다른 process의 resource를 뺏을 수 없다.
hold and wait : resource를 가진 채로 다른 resource를 기다린다.
circular wait : resource를 기다리는 것들이 circular해야 한다.

처리 방식

prevent : 발생 자체를 막는 방식
avoid : deadlock이 발생할 수 있지만 순서를 조절하는 방식
- banker algorithm : 현재 사용할 수 있는 resource, 각 process가 필요한 resource에 대한 정보들을 모아둔 후각 process에세 필요한 resource를 줘 보고 safe한지 검사하는 방식으로, simluation을 돌려보는 방식.
detect & cover : 발생하면 감지하고 복구하는 방식

Process Scheduling

목표와 몇 가지 scheduling 방법

목표 : throughput 최대화, fairness

FIFO
SJF : optimal but unfair
RR : time quantum만큼 실행한 후 queue의 맨 뒤로 넣는 방식. 같은 길이 task 여러개면 오래 걸린다.
MFQ : 여러 개의 RR queue를 두는 방식. 각 RR queue의 time quantum이 다르다.

Virtual Memory

정의

segmentation

demand paging

replacement policy

thrashing

address space : OS가 제공하는 physical memory의 abstraction. 각 process는 같은 address space를 바라보는 것 처럼 보이지만, OS 내부에서 다른 physical memory를 가리키게 처리해 준다. (address translation)

physical memory address를 사용하는 것이 아니라 virtual memory address를 사용해 유한한 크기의 memory를 무한하게 보이게 만드는 방법. 따라서 virtual address를 physical address로 바꾸는 address translation 과정이 필요하다. 여기서 cache 효율을 높이기 위해 TLB를 쓰기도 한다.

segmentation : base and bound를 사용해서 virtual memory의 address space를 segment로 나누고 translate하는 방식. + 권한 체크도

보통 demand paging을 쓴다. demand paging은 page가 필요할 때만 disk에서 꺼내와 memory에 올리는 방식이다.

process에서 특정 page가 필요하면, memory에 있는 page table을 본다. page table은 virtual page와 physical page를 매핑하는 자료구조.
- page hit라면 해당 page를 요청하고 받는다.
- page fault가 나면 page fault handler가 victim page를 선택해 교체한다.(필요 시 write back) 이후 disk에서 page를 memory에 올리고 page table을 갱신한다.

교체 알고리즘

FIFO
LRU : 제일 오래된 것 요체, optimal에 근사
LFU : 제일 적게 사용된 것 교체
Clock Algorithm : 2nd change - 2번 걸리면 교체하는 방식
Nth change Algorithm : n번 걸리면 교체

Thrashing : demand paging에서 page fault가 계속 발생해 I/O cost만 계속 사용하는 것. process가 너무 많거나, memory 크기보다 필요한 page 개수 크기가 더 많거나 등의 이유가 있다.

OS란?

HW와 SW 사이의 interface.

HW를 abstract해서 SW가 사용하기 쉽게 만들어준다. CPU를 process/thread로, memory는 address space로, disk는 file로.
resource를 관리한다.

kernel?

Process vs Thread

정의

공유 여부

cost

격리 여부

정의

process는 program의 instance

thread는 instruction flow

공유 여부

process는 process context를 저장하는 PCB, 4가지 address space를 가진다.

thread는 stack만 별개의 것을 가지며 heap code data는 thread끼리 공유한다.

때문에 process끼리 통신하기 위해서는 resource를 많이 써야 하는 반면 thread끼리는 resource를 적게 써도 된다. 때문에 process는 parallel하게, thread는 concurrent하게 쓰는 것이 일반적이다.

cost

stack의 경우 크기가 작으므로 context switching cost가 적고, 생성 cost가 더 적다.

격리 여부

process끼리는 완전히 격리되어 있어 하나의 process에서 문제가 생겨도 괜찮다. 반면 thread는 그렇지 않기 때문에 하나의 thread에서 오류가 생기면 다른 thread에 영향을 줄 수도 있다. (heap에 이상한 값 쓴다던가 등)

Concurrent vs Parallel

정의

parallel은 실제로 작업이 동시에 실행되는 것을 말한다. 예를 들어 process가 2개의 processor(CPU core)에서 동시에 돌아가면 parellel이다.

concurrent는 작업이 동시에 실행되지 않지만, 그렇게 보이는 것을 말한다. 실제로는 context switching이 일어나면서 동작한다.

일반적으로 thread가 concurrent를 구현하고, process가 parallel을 쓴다.

Zombie Process

정의

언제 생기는지

어떻게 해결해야 하는지

parnet process가 fork()를 call 하면 child process가 생긴다.

이 때 parent process가 wait()를 call하면 child process의 모든 자원을 정리한다. 그렇지 않고 parent process가 종료하는 경우 child process는 orphan process가 된다. 이후 init process가 종료될 때 모든 orphan process를 정리한다.

그러나, orphan process가 가지고 있는 resource는 계속 메모리에 남아 있게 되며, 이러한 process를 zombie process라고 한다. 따라서 parent process는 wait()를 explicitly 호출해야 한다.

DB 면접대비 질문

hyelie — Sun, 1 Oct 2023 04:13:29 +0900

Transaction

transaciton의 정의, 특성(ACID)

commit / rollback

state

transaction : DBMS의 상호작용 단위. transaction은 다음 4가지 성질을 가지고 있다.

Atomicity : transction은 실행되거나, 실행되지 않거나 둘 중 하나의 상태만 가진다. 중간에 끊기지 않는다.
Consistency : transaction의 실행 결과는 항상 일관성이 있다. (정해둔 규칙을 위배하지 않는다.)
Isolation : transaction 사이에 다른 trasnaction이 낄 수 없다.
Durability : DBMS가 꺼져도 수행된 transaction은 반영되어 있어야 한다.

commit은 모든 작업이 정상적으로 수행되었다는 명령이며, 실 DB에 반영하게 된다.

rollback은 crash가 난 경우, 해당 transaction의 변경을 취소하는 과정이다. 직전 commit까지만 복구한다.

이를 통해 consistency를 보장할 수 있다.

active : transaction이 실행 중인 상태

failed : transaction에 오류가 발생해 중단된 상태

partially commited : 사용자의 commit 요청이 왔을 때 도착하는 상태. 아직 반영된 상태가 아니다.

commit 되면 commited로 가고, 그렇지 않으면 failed로 간다.

commited : transaction이 성공적으로 종료된 상태

aborted : rollback을 수행하고 있는 상태

Index

종류 2가지

B tree와 B+ tree의 차이

B+ tree의 특징 3가지, 시간복잡도

hash table과의 차이점, 각각

index를 사용할 때 장단점

clustered vs non-clustered

어떤 column을 쓰면 좋은지

종류는 hash table과 B+ tree가 있다.

B tree는 tree의 모든 element에 entry가 저장됨

B+ tree는 leaf node는 data page에 대한 pointer를 가지고, non leaf node는 key와 node에 대한 pointer만 가짐, leaf node들끼리 pointer를 가짐. leaf node는 data의 pointer를 가짐.

B+ tree의 특징

m-way balanced tree (각 node에는 최대 m-1개의 element가 들어있고 각 node는 최대 m개의 child를 가질 수 있다)
- balanced tree인 만큼, child의 height 차이가 1 이상 나지 않는다.
모든 leaf node는 doubly linked list
space utilization이 50% 이상이어야 한다.
- leaf node는 $\left \lfloor \frac{n+1}{2} \right \rfloor$개의 pointer가 있어야 하고,
- non-leaf node는 $\left \lceil \frac{n+1}{2} \right \rceil$개의 pointer가 있어야 한다.

hash table은 접근, 수정, 삭제가 O(1)이지만 범위가 있는 접근을 못한다. hash 함수를 사용하기 때문에 pointer가 랜덤이기 때문. 반면 B+ tree는 접근/수정/삭제가 O(logn)이지만 tree이기 때문에 range하게 접근할 수 있다.

장점 : index에 있는 정보에 대해서는 read 속도가 빨라진다.
단점 : insert/delete/update 속도가 느려진다. 해당 tree를 수정해야 하기 때문.
자주 select되고, 덜 update되는 column에 대해 쓰는 것이 좋다. + FK나 join도.
공통적으로 사용하는 것 - index column의 순서는 cardinality가 높은 것부터 낮은 순으로 나열하는 것이 좋다. (data의 unique 개수)
- cardinality가 높은 것, selectivity가 낮은 것(적은 row가 찾아짐), 조회 많은 것, 수정 적은 것

clustered index는 B+ tree의 data page가 index 순서대로 정렬된 index이고, non-clustered index는 그렇지 않음.

Schema

schema의 정의 : DB의 구조와 제약에 대한 명세

schema의 3가지 종류

independence 2가지 종류

schema는 data의 특정 collection의 설명을 말한다. data의 관계, 구조, 표현 방법을 표시하는 구조이다.

external schema (view) : 각 user가 접근하는 table
conceptual schema (logical) : 어떤 종류의 data가 저장되는지
physical schema (physical) : data가 어떻게 저장되는지

independence

physical data independence : physical structure를 바꾸어도 logical schema는 불변하는 특징
logical data independence : logcial structure를 바꾸어도 external schema는 불변하는 특징

Join

join의 종류 3가지

theta join (conditional join) R⋈$_c$S : 조건 c를 만족하는 tuple만 가져온다.
equi join : theta join에서 조건 c가 equal로만 이뤄져 있는 theta join
natrual join R⋈S : 모든 공통 field에 대한 equi join

각 연산의 I/O cost

buffer pool?

seq scan, index scan

external sort

nested loop join, blocked nested join, sort merge join, grace hash join

DBMS는 disk에 있는 page를 memory에 frame으로 저장하는데, 이 공간을 buffer pool이라 한다. OS의 paging과 매우 유사하지만 조금은 다르다. (DB는 prefetch 예측하기 때문)

seq scan : $|R|_p$이다.
index scan
- clustered : $\left \lceil \frac{card(P)}{B} \right \rceil + 1$
- non clustered : card(P)
external sort : $2|R|_p \times (\left \lceil log_{B-1}\left \lceil \frac{|R|_p}{B} \right \rceil \right \rceil + 1)$
nested loop join : $|R|_p + |R|_p \times |S|_p$
blocked nested join : $|R|_p + \left \lceil \frac{|R|_p}{B-2} \right \rceil \times |S|_p$
sort merge join : $|R|_p + |S|_p$
grace hash join : $3|R|_p + 3|S|_p$

Query Optimizer

작동 방식

query를 logical operator들의 tree로 표현하고, logical equivalent rule을 적용해 tree를 바꾼다.
앞서 살펴본 physical operator를 적용해 physical plan으로 바꾼다.
query optimizer는 plan의 실행 시간을 유추해서 best plan을 도출한다.

Key

key의 종류 4가지

Candidate Key : tuple을 unique하게 식별할 수 있는 attribute set.
- + minimality : attribute 1개를 지우면 식별할 수 없다.
Super Key : key의 super set
Primary Key : candidate key 중 지정된 것.
Foreign Key : 다른 relation을 참조하기 위해 다른 relation의 key를 가져온 것. dangling을 알아서 처리해 준다.

Normalization

normalization이란

anomaly

각 단계가 만족하는 조건

장단점

functional dependency가 뭔지

사용하는 목적은 redundancy를 줄여 anomaly를 막기 위함이다. 단점으로는 relation이 쪼개져 join 연산이 많아진다는 것이 있다.

anomaly는 redundancy 때문에 발생하며, 다음 3가지가 있다.

insertion anomaly : insert 시 없는 정보가 있어 삽입하지 못하는 경우. 또는 null 정보를 넣어야 한다.
deletion anomaly : 삭제 시 원하지 않는 정보가 삭제되는 경우
update anomaly : 중복된 여러 값들 중 하나만 수정되는 경우

1NF : 모든 도메인이 atomic value일 때
2NF : 모든 non-key attribute가 candidate key에 fully dependent한 경우.
- (부분적 함수 종속 제거, partial functional dependency 삭제)
- candidate key의 일부분으로 식별할 수 없는 것.
3NF : 모든 functional dependency X => Y에 대해 X가 superkey이거나 Y가 prime attribute인 경우.
- (이행적 함수 종속 제거, transivity functional dependency 삭제)
- X => Y, Y => Z로 식별할 수 있는 정보가 없는 것.
BCNF : 모든 functional dependency X => Y에 대해 X가 candidate key인 경우.
- (모든 결정자 X가 후보키인 것)
4NF : 다치 종속 제거
5NF : 조인 종속 제거

어떤 relation의 모든 tuple t$_1$, t$_2$과 어떤 field X, Y에 대해 if t$_1$[X] = t$_2$[X] then t$_1$[Y] = t$_2$[Y]인 X, Y의 관계를 functional dependency라고 한다. 말로 풀어쓰면 relation의 field X로 Y를 식별할 수 있는 관계. 더 풀어 쓰면 X를 알면 Y를 알 수 있는 관계를 말한다.

Integrity Constraint

정의 : 정확성, 일관성, 유효성이 유지되는 것

Anomaly

정의

3가지 anomaly

anomaly는 redundancy 때문에 발생하며, 다음 3가지가 있다.

insertion anomaly : insert 시 없는 정보가 있어 삽입하지 못하는 경우. 또는 null 정보를 넣어야 한다.
deletion anomaly : 삭제 시 원하지 않는 정보가 삭제되는 경우
update anomaly : 중복된 여러 값들 중 하나만 수정되는 경우

CAP Theroem / PACELC Theorem

정의

Consistency, Availability, Partition Tolerance 3가지를 만족할 수 없다는 정리. 증명되었다.

consistency : 모든 request가 최신 데이터를 받는다.
availability : 모든 request는 정상적인 response를 받는다.
partition tolerance : 네트워크 오류 상황이어도 정상 작동한다.

PACELC theorem은 normal state, abnormal state를 구분해 설명하는 방식이다.

partition이 존재하는 경우 (abnormal)
- availability과 consistency는 tradeoff이다.
partition이 존재하지 않는 경우 (normal)
- latency와 consistency는 tradeoff이다.

RDB vs NoSQL

각각의 장단점과 차이

Redis

특징 몇가지만 준비

append only file : query를 저장하고, crash 시점부터 다시 만들어 두는 방식
snapshot : 특정 지점을 디스크에 백업
key-value로 이루어졌다.
single thread

빠르지만 날아갈 수 있어서 사용 시 백업에 대한 준비를 해야 한다.

빠르기 때문에 자주 조회/수정되는 leaderboard, session 등을 저장하기 좋다.

2 Phase Locking

사용 목적

lock의 종류 2가지

phase 종류 2가지

transaction에 lock을 걸어서 serialization을 보장하는 concurreny 처리 방법. lcok은 resource에 대한 mutual exclusion을 위해 사용한다.

Shared Lock : 해당 resource에 대해 read 연산만 가능한 lock. 따라서 한 resource에 여러 개의 shared lock이 걸릴 수 있다.
Exclusive Lock : 해당 resource에 대해 read 연산과 write 연산 둘 다 가능한 lock. 따라서 한 resource에 하나의 exclusive lock만 걸릴 수 있다.

lock만으로는 deadlock이 발생할 수도 있기 때문에 strict 2 phase lock을 사용한다. locking phase와 unlocking phase 2단계로 나뉜다.

locking phase : lock 연산만 수행할 수 있는 단계
unlocking phase : unlock 연산만 수행할 수 있는 단계. unlock은 transaction이 완전히 끝난 후에 실행한다.

SQL 종류

3가지 - DML, DDL, DCL

Delete vs Truncate vs Drop

delete는 rollback 가능, data 삭제하는 명령어

truncate는 table을 제외한 전체 data를 삭제하는 명령어, rollback 불가능

drop은 table을 삭제하는 명령어, rollback 불가능

Prepared Statement

원리

RDB vs NoSQL

RDB는 정해진 schema에 따라 data를 저장하고, relation을 사용해 data를 분산시킨다. 때문에 redundancy를 줄일 수 있고, anomaly를 막을 수 있다. - 즉, consistent하다.

NoSQL은 정해진 구조가 없다.

RDB의 경우 consistent하지만 수정하기 어렵고, join이 많아질 경우 cost가 매우 커진다. 또한 확장도 어렵다.

NoSQL의 경우 유연하고, 확장이 쉽다. 반면 redundancy를 계속 확인해야 한다.

ORM

object와 relation을 매핑하는 것. 코드 레벨에서 DB에 접근하기 때문에 유지보수하기 좋다.

SQL 실행 순서

FROM, ON, JOIN

WHERE, GROUP BY, HAVING

SELECT

DISTINT

ORDER BY

LIMIT

Recovery

ARIES recovery의 가정 2가지

force ? no force ? steal ? no steal ?

write ahead logging의 방식 2가지

aries recovery algorithm의 동작 3가지

transaction의 state 5가지

ARIES recovery의 가정 : strict 2 phase locking, WAL (write ahead logging)

Force: transaction commit 후 바로 disk에 쓰는 방식
No Force : transaction commit 후 바로 disk에 쓰지 않는 방식
Steal: transaction 완료 여부에 상관없이 data를 disk에 기록하는 방식
No Steal: transaction uncommit 상태에서 data를 disk에 기록하지 않는 방식

ARIES recovery의 경우 Force + No Steal 방식으로, 어렵지만 빠르다.

WAL

disk에 update하기 전에 log를 작성한다. undo를 위해 사용하며, disk에 update한 후 crash가 나면 undo할 수 없기 때문이다.
transaciton이 commit되기 전에 모든 작업 내용을 log에 기록해야 한다. redo를 위해 사용하며, 해당 transaction이 commit되었음을 보장한다.

recovery algorithm

analysis : REDO 시작위치 결정 (checkpoint : transaction이 모두 disk에 쓰인 시점), crash 위치 결정
redo : analysis에서 결정한 위치부터 crash 직전까지 redo 수행.
undo : log를 역순으로 읽으면서 uncommit transaction까지 undo. (최근 commit까지)

transaction state

active : transaction이 실행 중인 상태
failed : transaction에 오류가 발생해 중단된 상태
partially commited : 사용자의 commit 요청이 왔을 때 도착하는 상태. 아직 반영된 상태가 아니다. commit 되면 commited로 가고, 그렇지 않으면 failed로 간다.
commited : transaction이 성공적으로 종료된 상태
aborted : rollback을 수행하고 있는 상태

Transaction Isloation Level

4가지 level

각각이 뭔지, 어떤 문제가 발생할 수 있는지

non consistent data를 허용하는 수준.

Level 1 (Read Uncommited) : 아직 commit되지 않은 record나, transaction이 처리중인 record을 다른 transaction에서 접근할 수 있음. 이 경우 consistent하지 않다.
- commit되지 않은 data를 보는 dirty read가 발생할 수 있다.
Level 2 (Read Commited) : commit된 transaction의 결과만 조회할 수 있다.
- 하나의 transaction에 같은 query가 2개 이상 있을 때, 다른 결과가 나오는 non repeatable read가 발생할 수 있다. query 실행 시점 사이에 다른 transaction이 2개 실행되면 이런 현상이 생긴다.
Level 3 (Repeatable Read) : 하나의 transaction에서 조회한 record가 같음을 보장한다. 하나의 transaction이 읽은 record를 다른 transaction이 변경하지 못하게 한다.
- 같은 transaction을 2번 실행했을 때 결과가 다른 phantom read가 발생할 수 있다. (select - insert - select의 경우)
Level 4 (Serializable) : 한 transaction이 사용하는 record를 다른 transaction에서 접근할 수 없다.

Clustering vs Replication

정의, 장단점

clustering : 같은 저장소를 사용하되 여러 개의 DBMS를 사용하는 것. 동기 방식을 사용하기 때문에 일관성 있고, DB서버에 대한 부하 분산 가능. 그러나 저장소가 같기 때문에 lock으로 인한 병목 발생 가능.

replication : 저장소를 비동기 방식으로 사용하는 것. 일반적으로 DB는 select가 많기 때문에 insert할 수 있는 master와, master의 정보를 비동기로 저장하는 read replica를 두는 방식.

DB 기초 - 2

hyelie — Sun, 1 Oct 2023 04:11:49 +0900

이 글은 포스텍 한욱신 교수님의 데이터베이스시스템(CSED421) 강의를 기반으로 재구성한 것입니다.

Key

다음 4종류가 있다.

Candidate Key : tuple을 unique하게 식별할 수 있는 attribute set.
- + minimality : attribute 1개를 지우면 식별할 수 없다.
Super Key : key의 super set
Primary Key : candidate key 중 지정된 것.
Foreign Key : 다른 relation을 참조하기 위해 다른 relation의 key를 가져온 것. dangling을 알아서 처리해 준다.

Normal Form / Normalization

[1NF - 2NF - 3NF - BCNF - 4NF - 5NF] 순서로 더 higher하다. 사용하는 목적은 redundancy를 줄여 anomaly를 막기 위함이다. 단점으로는 relation이 쪼개져 join 연산이 많아진다는 것이 있다.

1NF : 모든 도메인이 atomic value일 때
2NF : 모든 non-key attribute가 candidate key에 fully dependent한 경우.
- (부분적 함수 종속 제거, partial functional dependency 삭제)
- candidate key의 일부분으로 식별할 수 없는 것.
3NF : 모든 functional dependency X => Y에 대해 X가 superkey이거나 Y가 prime attribute인 경우.
- (이행적 함수 종속 제거, transivity functional dependency 삭제)
- X => Y, Y => Z로 식별할 수 있는 정보가 없는 것.
BCNF : 모든 functional dependency X => Y에 대해 X가 candidate key인 경우.
- (모든 결정자 X가 후보키인 것)
4NF : 다치 종속 제거
5NF : 조인 종속 제거

Functional Dependency

이를 사용해 redundancy를 formal한 방식으로 알아낼 수 있는데, functional dependency X => Y가 있는 경우, X가 중복되면 Y도 중복됨을 알 수 있기 때문이다.

한편, key는 모든 attribute를 functionally determine한다.

Anomaly

anomaly는 redundancy 때문에 발생하며, 다음 3가지가 있다.

insertion anomaly : insert 시 없는 정보가 있어 삽입하지 못하는 경우. 또는 null 정보를 넣어야 한다.
deletion anomaly : 삭제 시 원하지 않는 정보가 삭제되는 경우
update anomaly : 중복된 여러 값들 중 하나만 수정되는 경우

Prepared Statement

일반적인 SQL의 경우 parse 과정을 거치는데, prepared statement는 해당 SQL의 문법을 검사한 후 DB에 caching한다. 때문에 성능이 향상되고, SQL이 이미 caching된 상태이므로 parameter에 들어가는 값을 SQL로 인식하지 않고 parameter로 인식하므로 injection을 막을 수 있다.

CAP Theorem / PACELC Theorem

Consistency, Availability, Partition Tolerance 3가지를 만족할 수 없다는 정리. 증명되었다.

consistency : 모든 request가 최신 데이터를 받는다.
availability : 모든 request는 정상적인 response를 받는다.
partition tolerance : 네트워크 오류 상황이어도 정상 작동한다.

PACELC theorem은 normal state, abnormal state를 구분해 설명하는 방식이다.

partition이 존재하는 경우 (abnormal)
- availability과 consistency는 tradeoff이다.
partition이 존재하지 않는 경우 (normal)
- latency와 consistency는 tradeoff이다.

Redis

append only file : query를 저장하고, crash 시점부터 다시 만들어 두는 방식
snapshot : 특정 지점을 디스크에 백업
key-value로 이루어졌다.

2 Phase Locking

transaction에 lock을 걸어서 serialization을 보장하는 concurreny 처리 방법. lcok은 resource에 대한 mutual exclusion을 위해 사용한다. lock 종류는 다음과 같다.

Shared Lock : 해당 resource에 대해 read 연산만 가능한 lock. 따라서 한 resource에 여러 개의 shared lock이 걸릴 수 있다.
Exclusive Lock : 해당 resource에 대해 read 연산과 write 연산 둘 다 가능한 lock. 따라서 한 resource에 하나의 exclusive lock만 걸릴 수 있다.

2 phase locking

lock만으로는 deadlock이 발생할 수도 있기 때문에 strict 2 phase lock을 사용한다. locking phase와 unlocking phase 2단계로 나뉜다.

locking phase : lock 연산만 수행할 수 있는 단계
unlocking phase : unlock 연산만 수행할 수 있는 단계. unlock은 transaction이 완전히 끝난 후에 실행한다.

Isolation Level

non consistent data를 허용하는 수준.

Level 1 (Read Uncommited) : 아직 commit되지 않은 record나, transaction이 처리중인 record을 다른 transaction에서 접근할 수 있음. 이 경우 consistent하지 않다.
- commit되지 않은 data를 보는 dirty read가 발생할 수 있다.
Level 2 (Read Commited) : commit된 transaction의 결과만 조회할 수 있다.
- 하나의 transaction에 같은 query가 2개 이상 있을 때, 다른 결과가 나오는 non repeatable read가 발생할 수 있다. query 실행 시점 사이에 다른 transaction이 2개 실행되면 이런 현상이 생긴다. (insert - update - insert의 경우)
Level 3 (Repeatable Read) : 하나의 transaction에서 조회한 record가 같음을 보장한다. 하나의 transaction이 읽은 record를 다른 transaction이 변경하지 못하게 한다.
- MVCC를 사용해 transaction에서 사용하는 record들의 version을 관리한다. 때문에 select transaction 실행 중 다른 transaction이 update를 하더라도 MVCC가 저장하고 있는 record를 넘겨주며, 이 때문에 읽는 값은 같다.
- 그러나 MVCC는 update는 versioning을 하지 않기 때문에, 같은 transaction을 2번 실행했을 때 결과가 다른 phantom read가 발생할 수 있다. (select - insert - select의 경우)
Level 4 (Serializable) : 한 transaction이 사용하는 record를 다른 transaction에서 접근할 수 없다.

ARIES Recovery

ARIES recovery의 가정 : strict 2 phase locking, WAL (write ahead logging)

DB에 접근하기 전 lock, transaction 끝난 후 unlock하는 것을 말한다.

Force / Steal

Force: transaction commit 후 바로 disk에 쓰는 방식
No Force : transaction commit 후 바로 disk에 쓰지 않는 방식
Steal: transaction 완료 여부에 상관없이 data를 disk에 기록하는 방식
No Steal: transaction uncommit 상태에서 data를 disk에 기록하지 않는 방식

ARIES recovery의 경우 Force + No Steal 방식으로, 어렵지만 빠르다.

Commit, Rollback

commit은 모든 작업이 정상적으로 수행되었다는 명령이며, 실 DB에 반영하게 된다.

rollback은 crash가 난 경우, 해당 transaction의 변경을 취소하는 과정이다. 직전 commit까지만 복구한다.

이를 통해 consistency를 보장할 수 있다.

WAL

disk에 update하기 전에 log를 작성한다. undo를 위해 사용하며, disk에 update한 후 crash가 나면 undo할 수 없기 때문이다.
transaciton이 commit되기 전에 모든 작업 내용을 log에 기록해야 한다. redo를 위해 사용하며, 해당 transaction이 commit되었음을 보장한다.

ARIES recovery algorithm

strict 2 phase lock을 사용하고 있기 때문에 data에 대한 접근은 걱정하지 않아도 된다.

analysis : REDO 시작위치 결정 (checkpoint : transaction이 모두 disk에 쓰인 시점), crash 위치 결정
redo : analysis에서 결정한 위치부터 crash 직전까지 redo 수행.
undo : log를 역순으로 읽으면서 uncommit transaction까지 undo. (최근 commit까지)

Transaction State

크게 5가지 종류가 있다.

active : transaction이 실행 중인 상태
failed : transaction에 오류가 발생해 중단된 상태
partially commited : 사용자의 commit 요청이 왔을 때 도착하는 상태. 아직 반영된 상태가 아니다. commit 되면 commited로 가고, 그렇지 않으면 failed로 간다.
commited : transaction이 성공적으로 종료된 상태
aborted : rollback을 수행하고 있는 상태

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

DB 기초 - 1

hyelie — Sat, 30 Sep 2023 01:40:45 +0900

이 글은 포스텍 한욱신 교수님의 데이터베이스시스템(CSED421) 강의를 기반으로 재구성한 것입니다.

DBMS의 정의

DBMS란 database를 관리/유지시켜주는 소프트웨어이다. 사용 이유는 data independency와 효율적 접근, 보안, 동시 접근을 위해서이다. file system에 비해서 cost는 크지만 redundancy가 없고, constraint를 유지할 수 있다는 장점이 있다.

Transction & ACID

transaction : DBMS의 상호작용 단위. transaction은 다음 4가지 성질을 가지고 있다.

Atomicity : transction은 실행되거나, 실행되지 않거나 둘 중 하나의 상태만 가진다. 중간에 끊기지 않는다.
Consistency : transaction의 실행 결과는 항상 일관성이 있다. (정해둔 규칙을 위배하지 않는다.)
Isolation : transaction 사이에 다른 trasnaction이 낄 수 없다.
Durability : DBMS가 꺼져도 수행된 transaction은 반영되어 있어야 한다.

Data Model & Schema

data model은 data를 묘사하기 위한 개념의 collection.

schema는 data의 특정 collection의 설명을 말한다. data의 관계, 구조, 표현 방법을 표시하는 구조이다.

schema는 크게 3가지 구조가 있다.

external schema (view) : 각 user가 접근하는 table
conceptual schema (logical) : 어떤 종류의 data가 저장되는지
physical schema (physical) : data가 어떻게 저장되는지

Data Independence

physical data independence : physical structure를 바꾸어도 logical schema는 불변하는 특징
logical data independence : logcial structure를 바꾸어도 external schema는 불변하는 특징

Buffer Pool

OS에서 file을 byte sequence로 봤던 것처럼, DB는 file - record(tuple) - page 3개의 structure로 분리해 본다.

Index - B+ tree

m-way balanced tree (각 node에는 최대 m-1개의 element가 들어있고 각 node는 최대 m개의 child를 가질 수 있다)
- balanced tree인 만큼, child의 height 차이가 1 이상 나지 않는다.
모든 leaf node는 doubly linked list
space utilization이 50% 이상이어야 한다.
- leaf node는 $\left \lfloor \frac{n+1}{2} \right \rfloor$개의 pointer가 있어야 하고,
- non-leaf node는 $\left \lceil \frac{n+1}{2} \right \rceil$개의 pointer가 있어야 한다.

B+ tree 노드 구조

삽입

simple case : 해당하는 key의 leaft node에 그냥 넣음
leaf overflow가 발생하는 경우 : 반 쪼개어 parent에 push한다.
non-leaf overflow가 발생하는 경우 : 쪼갬
root overflow가 발생하는 경우 : 쪼갬

삭제

simple case : 해당하는 key를 삭제해도 utilization이 50% 이상인 경우, 그냥 삭제
coalesce with sibiling : sibiling과 합치는 방법. 이전 leat node의 largest key를 가져오거나 이후 leaf node의 smallest key를 가져온다.
redistribute key : key를 재조정해 utilization을 맞추는 방법. sibling과 parent 사이에서 key를 재조정한다.
non-leaf에서 coalesce나 redistribute : 같은 방법을 취한다.

Index 쓸 때 장/단점

장점 : index에 있는 정보에 대해서는 read 속도가 빨라진다.
단점 : insert/delete/update 속도가 느려진다. 해당 tree를 수정해야 하기 때문.
자주 select되고, 덜 update되는 column에 대해 쓰는 것이 좋다. + FK나 join도.
공통적으로 사용하는 것 - index column의 순서는 cardinality가 높은 것부터 낮은 순으로 나열하는 것이 좋다. (data의 unique 개수)

Hash Table과의 차이점

hash table은 하나의 entry에 대해서는 O(1)이지만, range search를 하면 전체를 탐색해야 하기 때문에 O(n)이라는 단점이 있다.

Relational Algebra - JOIN

projection, selection 등 여러 가지 표기법이 있지만, 여기서는 join만 살펴보고자 한다. 제일 헷갈리니까.

theta join (conditional join) R⋈$_c$S : 조건 c를 만족하는 tuple만 가져온다.
equi join : theta join에서 조건 c가 equal로만 이뤄져 있는 theta join
natrual join R⋈S : 모든 공통 field에 대한 equi join

Relational Operator Implement

SQL은 logical plan인데, 이것은 physical operator로 구현된다. 크게 selection, join만 신경쓰면 된다.

cost는 CPU cost, I/O cost 2종류로 나뉘는데 CPU cost는 제하고, I/O cost만 본다.

|R|$_p$를 relation R에 해당하는 page 개수라고 정의하자. 그러면 I/O cost는 |R|$_p$로 나타낼 수 있다.

Selection - Sequential Scan

for each page P in R:
    for each tuple t in P:
        if theta(t) return

pseudo code는 위와 같다. 어떤 relation R의 모든 page에 대해 조건을 만족하는 tuple만 return한다. 따라서 cost는 $|R|_p$이다.

Selection - Index Scan

B+ tree로 구성된 index가 있고, 해당 index의 key로 검색할 수 있다면 index scan을 할 수 있다. key로 index를 탐색한 후, 그 결과에서 조건을 만족하는 tuple만 return하므로, cost는 log|R|$_p$ + fetch cost이다. log항은 B+ tree로 구성된 index 탐색에 걸리는 시간, fetch cost는 index 탐색 결과 table의 크기이다. 이 때 fetch cost는 clustered 여부에 따라 다르다.

Clustered vs Non-Clustered Index

clustered index는 B+ tree의 leaf node가 가리키는 data page가 index 순서대로 정렬된 index이고, non-clustered index는 그렇지 않은 index. (data page가 index 순서대로 정렬되어 있지 않음)

Index Scan I/O Cost

한 page에 b개 tuple이 있고, predicate의 실행 개수 cardinality를 card(P)로 두자.

clustered : fetch time은 leaf node access time + card(P)개에 접근하는 시간인데, 이 때 card(P)개의 tuple은 index의 leaf node이기 때문에 연속적이다. 따라서 fetch cost는 $\left \lceil \frac{card(P)}{B} \right \rceil + 1$이다.
non-clustered : not clustered인 경우, 각 leaf node는 key에 해당하는 data가 있는 page pointer가 있다. pointer는 worst case random이므로 fetch cost는 card(P)라 상한을 둘 수 있다.

External Sort

page가 너무 커서 in-memory sort가 불가능한 경우 I/O cost가 어떻게 되는지 보자. 그냥 merge sort할 때 I/O cost가 얼마나 나오는지 생각하면 된다.

어떤 relation R의 sequence S를 size B의 buffer pool을 사용해 정렬한다고 하자. 메모리가 부족하지 떄문에 아래와 같은 단계를 거쳐야 한다.

buffer pool에 올릴 수 있는 만큼 S를 올린다.
S를 정렬한다.
S를 disk에 쓴다.

merge sort를 생각하며 이해해 보자. 한 번의 pass는 아래와 같은 알고리즘으로 수행된다.

R을 page에 담고, 정렬한 후 다시 disk에 넣는다. 이 I/O cost는 read/write를 수행하므로 cost는 $2|R|_p$이다. 한편 초기 run의 개수는 $\left \lceil \frac{|R|_p}{B} \right \rceil$개이다.
page를 merge한다. 이 때, buffer pool에 B-1개는 정렬되지 않은 page를, 나머지 1개는 정렬한 후 disk write할 용도로 사용한다.
- 여기서 run은 합쳐야 하는 정렬된 group의 개수라고 생각하면 되고, pass는 merge 회수라고 생각하면 된다.

그러면 한 번의 pass에서 B-1개의 run이 줄어드므로 k번째 pass에서 merge할 때는 $\left \lceil \frac{|R|_p}{B(B-1)^k} \right \rceil$개의 run이 있을 것이다.

즉, 전체 pass의 개수는 $\left \lceil log_{B-1}\left \lceil \frac{|R|_p}{B} \right \rceil \right \rceil + 1$이고, 각 pass에서 run들이 정렬될 때마다 [R을 page에 담고, 정렬한 후 다시 disk에 넣는] 연산이 수행된다.

따라서 전체 I/O cost는 $2|R|_p \times (\left \lceil log_{B-1}\left \lceil \frac{|R|_p}{B} \right \rceil \right \rceil + 1)$이다.

Join - Nested Loop Join

R join S라고 가정하자.

for tuple r in R:
    for tuple s in S:
        if r == s then add (r, s) to result

nested loop인 만큼 for문의 중첩으로 join하는 방식이다. 일단 R의 모든 page를 읽어야 하고, 이후 R의 모든 page에 대해 S의 page를 가져온다. I/O cost는 worst case로, I/O cost는 $|R|_p + |R|_p \times |S|_p$이다.

참고로 outer relation size에 의존하기 때문에 nested loop join의 경우 outer loop에 더 작은 relation을 두면 좋다.

Join - Blocked Nested Join

size B의 buffer pool을 사용해 join한다고 하자.

일단 R의 모든 page를 읽어야 한다.
이후 R의 page 중 B-2개를 먼저 buffer pool에 가져온다.
- 남는 2개의 공간 중 하나는 S의 page를, 나머지 하나는 join result를 위해 output page로 사용할 것이다.
가져온 B-2개의 page에 대해 S의 모든 page에 대해 검사를 수행한다.

따라서 I/O cost는 $|R|_p + \left \lceil \frac{|R|_p}{B-2} \right \rceil \times |S|_p$이다.

Join - Sort Merge Join

sort는 앞에서 다뤘으니 넘어가고, merge만 보자. (보통 정렬되어 있는 것을 sort merge join으로 많이 쓴다.)

merge sort의 merge에 해당하는 시간복잡도가 O(n)인 것처럼, 여기서 R과 S는 정렬되어 있으므로 같은 방식으로 R의 모든 page와 S의 모든 page를 1번씩만 읽으면 된다. 따라서 I/O cost는 $|R|_p + |S|_p$이다.

Join - Grace Hash Join

grace hash join 이외에도 simple hash join, hybrid hash join 등이 있지만 여기서는 grace hash join만 보겠다.

partition

R과 S의 모든 page를 B-2개의 page로 hashing하고, 그 결과를 buffer pool에 쓴다. 읽고 쓰기 때문에 partition cost는 $2|R|_p + 2|S|_p$이다.

hash join

R의 page 하나, S의 page 하나를 buffer pool에 올리고 hashing된 page B-2개와 비교한다. 이 때 $R_i ⋈ S_j$에서 i != j면 empty이다. hash(k1) != hash(k2)면 k1 != k2이기 때문이다.

이렇게 R의 모든 page, S의 모든 page를 buffer pool에 쓰므로 이 과정의 cost는 $|R|_p + |S|_p$이다.

총계 $3|R|_p + 3|S|_p$이다.

Query Optimization

query optimizer는 SQL을 효율적으로 실행할 수 있는 plan을 세운다. 여기서 plan은 다음과 같은 과정을 거쳐 실행될 plan으로 바뀐다.

query를 logical operator들의 tree로 표현하고, logical equivalent rule을 적용해 tree를 바꾼다.
앞서 살펴본 physical operator를 적용해 physical plan으로 바꾼다.
query optimizer는 plan의 실행 시간을 유추해서 best plan을 도출한다.

logical join에 대해 physical로 바꾸면 nested loop join, sort merge join, hash join로 표기될 수 있다.
logical selection에 대해 physical로 바꾸면 seq scan이나 index scan으로 표기될 수 있다.

실행 순서에 따라 실행 시간이 꽤 많이 바뀌는데, 실행 시간을 유추할 때는 CPU cost와 I/O cost 2가지를 보며, cardinality 예측과 통계 활용 등의 방식을 사용한다. 물론 cardinality 예측이 틀렸거나 통계가 잘못된 경우 등 여러 경우의 수에 의해 좋지 않은 plan이 결정될 수도 있다. query optimizer는 이를 개선하기 위해 query optimizer는 query executor로부터 실행 결과를 feedback받아 cost 추정과 통계를 갱신한다.

잘못된 내용이나 오탈자에 대한 지적, 질문 등은 언제나 환영합니다.

23.09.25. 풀었던 문제들

hyelie — Mon, 25 Sep 2023 16:01:12 +0900

Programmers Lv. 3 입국심사, 8분

parametric search.

typedef long long ll;

vector<int> times;

// t시간동안 심사할 수 있는 인원 수
ll calculateNumPass(ll t){
    ll num_pass = 0;
    for(int time : times){
        num_pass += ((ll) t / time);
    }
    return num_pass;
}

long long solution(int n, vector<int> t) {
    ll start = 0, end = 1e18;
    times = t;

    while(start < end){
        ll mid = (start + end) / 2;
        ll num_pass = calculateNumPass(mid);
        if(num_pass >= n){ // 시간을 더 줄일 수 있을 때
            end = mid;
        }
        else{ // 시간을 늘려야 할 때
            start = mid + 1;
        }
    }

    return start;
}

시간복잡도

O(nlogn)

23.09.24. 풀었던 문제들

hyelie — Mon, 25 Sep 2023 13:23:18 +0900

Programmers Lv. 3 보석 쇼핑, 19분

two-pointer를 활용하면 되는 문제. 유의할 점은 start와 end 사이에 있는 보석 개수를 세야 하는데, map으로 숫자를 세면 count에 O(보석 개수)만큼의 시간이 걸리고, multiset을 쓰면 identical한 보석 개수를 셀 수 없기 때문에 map과 set을 같이 썼다.

set<string> cur_gems;
int num;
map<string, int> cur_gem_count;

bool isContainAll(){
    return cur_gems.size() == num;
}

void insert(string gem){
    cur_gem_count[gem]++;
    cur_gems.insert(gem);
}

void erase(string gem){
    cur_gem_count[gem]--;
    if(cur_gem_count[gem] == 0) cur_gems.erase(gem);
}

vector<int> solution(vector<string> gems) {
    set<string> s;
    for(string gem : gems){
        s.insert(gem);
        cur_gem_count[gem] = 0;
    }
    num = s.size();

    int start = 0, end = 0;
    insert(gems[start]);
    vector<int> answer = {-1, 100001};
    while(start < gems.size() && end < gems.size()){
        if(start > end){
            end = start;
            continue;
        }

        if(isContainAll()){
            if(answer[1] - answer[0] + 1 > end - start + 1){
                answer[1] = end + 1;
                answer[0] = start + 1;
            }
            erase(gems[start]);
            start++;
        }
        else{
            end++;
            if(end < gems.size()) insert(gems[end]);
        }


    }


    return answer;
}

시간복잡도

set/map에 insert/pop 시 O(logn)이고, two-pointer가 순회하는 데 걸리는 시간은 O(n)이므로, O(nlogn)이다.

Programmers Lv. 3 가장 먼 노드, 8분

weight가 1보다 크다면 dijkstra를 써야 하지만, 모든 edge weight를 1로 두기 때문에 BFS를 쓰면 되는 문제. 뭐.. 별 것 없다.

typedef pair<int, int> pii; // .first : to, .second : dist

queue<pii> q;
vector<vector<int>> edges;

int solution(int n, vector<vector<int>> edge) {
    vector<int> visited(n+1, -1);
    edges.resize(n+1);
    for(vector<int> e : edge){
        int from = e[0], to = e[1];
        edges[from].push_back(to);
        edges[to].push_back(from);
    }

    q.push({1, 0});
    visited[1] = 0;

    int max_value = -1;
    while(!q.empty()){
        pii front = q.front(); q.pop();

        for(int next : edges[front.first]){
            if(visited[next] != -1) continue;

            visited[next] = front.second + 1;
            q.push({next, front.second + 1});
            max_value = max(max_value, visited[next]);
        }
    }

    int answer = 0;
    for(int v : visited) if(v == max_value) answer++;
    return answer;
}

시간복잡도

BFS는 O(V+E)

Programmers Lv. 3 섬 연결하기, 7분 30초

MST를 구성하는 문제. 예전에 포스팅도 했었다. union-find를 쓰는 kruskal과 pq를 쓰는 prim 2가지 방법이 있는데,

typedef pair<int, int> pii;

struct cmp{
    bool operator()(pii &a, pii &b){
        if(a.second == b.second) return a.first > b.first;
        return a.second > b.second;
    }
};

priority_queue<pii, vector<pii>, cmp> pq;
vector<vector<pii>> edges;
vector<int> visited;

int solution(int n, vector<vector<int>> costs) {
    edges.resize(n);
    visited.resize(n);
    fill(visited.begin(), visited.end(), false);
    for(vector<int> cost : costs){
        int from = cost[0], to = cost[1], weight = cost[2];
        edges[from].push_back({to, weight});
        edges[to].push_back({from, weight});
    }

    // prim
    visited[0] = true;
    for(pii e : edges[0]) pq.push(e);

    int answer = 0;
    while(!pq.empty()){
        pii front = pq.top(); pq.pop();
        if(visited[front.first]) continue;

        visited[front.first] = true;
        answer += front.second;
        for(pii e : edges[front.first]) pq.push(e);
    }

    return answer;
}

시간복잡도

prim의 경우 O(ElogV)이지만 이 코드는 O(ElogE)이다. 기존 prim은 set을 사용해서 visited를 판별하기 때문에 O(ElogV)이다. 반면 여기서는 모든 edge에 대해 edge를 뽑는 for문이 1번씩 수행되므로 O(E), 그리고 pq에 모든 edge가 들어가므로 O(ElogE)이다.

23.09.23. 풀었던 문제들

hyelie — Mon, 25 Sep 2023 03:02:36 +0900

Programmers Lv. 3 불량 사용자, 28분

문제 자체는 주어진 것만 풀면 되는 문제. input size가 8이므로 최대 8!의 시간 복잡도이며, 따라서 backtrack(순열)로 풀면 된다.

단, 유의할 점은 `제재 아이디 목록을 구했을 때 아이디들이 나열된 순서와 상관없이 아이디 목록의 내용이 동일하면 같은 것으로 처리한다`이기 때문에, 이를 잘 처리해야 한다.

모든 banned_id에 대해 가능한 user_id의 후보군들을 나열하고,
permutation/backtrack으로 가능한 모든 조합을 나열하고,
해당 조합에서 겹치는 것을 빼면 되겠네.

위 3가지 flow로 쉽게 처리할 수 있다.

// banned_id와 user_id가 일치하는지
bool isBanned(string banned_id, string user_id){
    if(banned_id.length() != user_id.length()) return false;
    
    int len = banned_id.length();
    for(int i = 0; i<len; i++){
        if(banned_id[i] == user_id[i] || banned_id[i] == '*') continue;
        // 실수 1. banned_id[i] == '*'로 했어야 했는데 user_id[i] == '*'로 했다.
        else return false;
    }
    return true;
}

set<string> answer;
unordered_map<string, bool> visited; // visited[i] : user_id[i]를 사용했는지 여부. true then used
vector<vector<int>> candidates; // candidites[i] : banned_id[i]가 적용될 수 있는 user_id index vector
vector<string> user_ids, banned_ids;

void backtrack(int cur_depth, int max_depth, string result){
    if(cur_depth == max_depth){
        sort(result.begin(), result.end());
        answer.insert(result);
        return;
    }
    
    for(int i = 0; i<candidates[cur_depth].size(); i++){
        int user_idx = candidates[cur_depth][i]; // 실수 4. user_idx를 i로 넣었다.
        string s = user_ids[user_idx];
        if(!visited[s]){ // 실수 2. visited 로직을 뺐다.
            visited[s] = true;
            backtrack(cur_depth + 1, max_depth, result + to_string(user_idx)); // 실수 5. user_idx가 아니라 i로 넣었다.
            visited[s] = false;
        }
        
    }
    return;
}

int solution(vector<string> uids, vector<string> bids) {
    // init
    user_ids = uids;
    int user_size = user_ids.size();
    for(string user_id : user_ids){
        visited[user_id] = false;
    }
    
    banned_ids = bids; // 실수 3. uid로 넣었다.
    int banned_size = banned_ids.size();
    candidates.resize(banned_size);
    
    // init candidates
    for(int i = 0; i<banned_size; i++){
        for(int j = 0; j<user_size; j++){
            if(isBanned(banned_ids[i], user_ids[j])){
                candidates[i].push_back(j);
            }
        }
    }
    
    backtrack(0, banned_size, "");
    
    return answer.size();
}

시간복잡도

O(8!)

후기

오랜만에 풀어서? 그런가, 너무 급하게 풀려 해서 그런가, 실수가 너무 많았다.

23.09.20. 취준계획 - 끝!

hyelie — Wed, 20 Sep 2023 00:49:30 +0900

진짜 너무너무 바쁘다. 수업 과제는 뭐... 받자마자 하루컷 낸다 쳐도, 나머지가 끊임없이 이어진다.

일단 쓰고 싶은 데는 다 쓰는 게 맞는 것 같다.어차피 막학기 아니니까 여유 가져도 되긴 하는데, 미리 한 번 겪어보고 싶다.

근데 말도 안되게 바쁜게, 졸업과제 ← 얘가 진짜 너무 트롤이다. 1학점짜리가 아니라 한 5-6 되는 듯. 지금, 자소서도 써야하고 코테공부도 해야하고 면접공부도 해야 하는데... 근데 과제연구를 주에 적어도 6시간은 써야 한다. SD 과제도 있고... 병렬컴퓨팅 과제도 있고.. 시험기간이 되면 교양 레포트도 나오고... 크아아아악. 끔찍하다.

취준 계획 - 코테

일단 내가 쓴 곳들 중 코테를 보는 곳이 [~~LG CNS~~完, ~~넥토리얼~~, ~~베이글코드~~完] 이렇게 3군데이다. - 다 끝났다. 이제 코테 공부는 다음 이직 때....

코테 공부랑 면접 공부랑 병행하는 건 가능하지만, [수업을 들으면서 + 과제를 하면서 + 코테 공부를 하면서 + 면접 공부를 하는] 건 물리적으로 불가능하기 때문에, 일단은 [수업을 들으면서 + 과제를 하면서 + 코테 공부를 하면서] 일단은 코테를 보는 곳들에 당장 지원을 해서 코테를 보는 기업들이 끝날 때까지 주구장창 코테 공부만 일단 해 보자. 프로그래머스 Lv. 3가 한 60문제 남았으니, 하루에 4문제씩 푼다 치면 얼추 코테 치는 기간이랑 겹칠 것 같다.

취준 계획 - 면접공부

그렇게, 어떻게 어떻게 코테를 패스하면 면접이 다가온다. 면접... 시험... 일단 [코테를 패스한 곳들 + 면접을 봐야하는 곳들]을 위주로 면접 준비를 해야 한다.

CS

OOP, 알고리즘, OS, 네트워크는 블로그에 있는 것들만 복습하면 되고,

DB는 추가로 정리해야 한다. 어.. 이게 거의 7일쯤 걸리지 않을까? 중요한 개념인 B+ tree, relational operation, ERD, recovery 정도만 해도 한 5일이니까... 흠. - 이거는 끝났다!

자료구조 hash랑 tree쪽 단골이니까 한 번 봐 보자.

java를 사용하는 곳이라면 java, spring 정도 더 채워야 한다.

프로젝트

내가 했던 경험 + 프로젝트 깔끔하게 설명할 수 있을 정도로 준비해 가야 할 것이다.

SW개발병 + 미어캣
소마 + 비즈킥스
Naver2Tistory

그래.. 이렇게 면접 준비를 한다 치자. 중요한 건, 시험 기간이랑 면접 기간이랑 겹친다. 크아아악 다행히 시험 보는 과목은 SD랑 병렬컴퓨팅만 보면 되니까 그건 다행이다. ㅠ-ㅠ 진짜 너무너무 할게 많다. 파이팅하자,,,,

23.09.19. 풀었던 문제들

hyelie — Tue, 19 Sep 2023 22:35:38 +0900

Programmers Lv. 3 여행경로, 17분

그냥 DFS 돌리면 되는 문제. 단 각각의 vertex가 string으로 표현되는 점과 [사용한 표]를 어떻게 표기할지에 대해 유의해야 한다. 뭐.. 정석 DFS처럼 각 ticket의 index를 visit했는지 안했는지를 표기할 수 있긴 한데. 결국 alphabet 순서로 DFS + edges를 만들어야 하기 때문에 map을 사용해야 할 것 같다.

처음에는 multiset을 썼었는데, DFS를 위해 multiset에서 element를 빼고 넣는 과정에서 계속 같은 위치를 참조하는 것 같았다. (무한루프) 그래서 map of map을 썼다. edges[i]는 i에 인접한 공항들의 map 목록이고, 이것은 [도착지 이름, 같은 표가 몇 개인지]를 나타낸다.

나머지는 뭐.. 코드 보면 이해하기 쉬울 것 같다.

int max_depth;
map<string, map<string, int>> edges; // edges[i] : i에 인접한 공항들
vector<string> result;

bool DFS(int cur_depth, string cur_airport){
    if(cur_depth == max_depth){
        return true;
    }
    
    for(auto &[name, count] : edges[cur_airport]){
        if(count == 0) continue;
        edges[cur_airport][name]--;
        result[cur_depth + 1] = name;
        
        bool hasAnswer = DFS(cur_depth+1, name);
        if(hasAnswer) return true;
        
        edges[cur_airport][name]++;
    }
    return false;
}

vector<string> solution(vector<vector<string>> tickets) {
    max_depth = (int) tickets.size();
    for(vector<string> ticket : tickets){
        string src = ticket[0], dest = ticket[1];
        edges[src][dest]++; 
    }
    
    
    
    result.resize(max_depth + 1);
    result[0] = "ICN";
    
    DFS(0, "ICN");
    
    return result;
}

시간복잡도

ticket size를 n이라 하면, edge에 넣는 데 O(loglogn), 꺼내는 데도 O(loglogn)이다. 어떤 출발지로부터 도착지 목록을 가져오는 데는 O(logn)이 걸리고, 이를 순회하는 데 O(nlogn)이 걸린다.

DFS 자체는, vertex가 O(n)이므로 O(n)이다. 따라서 O(nlogn).

후기

참고로 예전에 풀었던 코드는 다음과 같다. 각 DFS에서 모든 ticket을 보기 때문에 시간이 너무 오래 걸릴 것이다! input이 작아 해결되지만 input이 큰 경우는 해결되지 않을 것. 그리고 코드 자체도 훨씬 간단하다.

vector<string> answer;

bool cmp(vector<string> &a, vector<string>&b){
    for(int i = 0; i<a.size(); i++){
        if(a[i] < b[i]) return true;
        else if(a[i] > b[i]) return false;
        else continue;
    }
}

void DFS(int depth, int max_depth, string dep, vector<bool>& visited, vector<vector<string>>& tickets, vector<string>& result){
    if(depth == max_depth){
        if(answer.empty()) answer = result;
        answer = cmp(answer, result)? answer : result;
        return;
    }
    
    for(int i = 0; i<max_depth; i++){
        if(tickets[i][0] == dep && !visited[i]){
            visited[i] = true;
            result[depth + 1] = tickets[i][1];  
            DFS(depth+1, max_depth, tickets[i][1], visited, tickets, result);
            visited[i] = false;
        }
    }
}

vector<string> solution(vector<vector<string>> tickets) {
    int size = tickets.size();
    vector<string> result(size + 1); result[0] = "ICN";
    vector<bool> visited(size, false);
    DFS(0, tickets.size(), "ICN", visited, tickets, result);
    return answer;
}

[Model Checking] 과제연구 주제 정리

hyelie — Tue, 19 Sep 2023 21:51:47 +0900

지도교수님과 여러 가지 이야기를 나눴고, [특정 모델 체킹 언어를 사용해, 특정 시스템의 모델 체킹을 해 보기]를 주제로 과제연구를 진행하기로 했다. 대충 flow는 아래와 같다.

특정한 model checking 언어를 공부한다.
어떤 system을 체킹할 지 확인하기
- distributed key-value store (cloud DB)
- RAFT consensus algorithm
- 위 2개를 추천받았는데, 모델링하기 위해서는 해당 system의 동작 방식을 알아야 한다. 일단 백엔드로 갈 거니까 분산 DB를 공부하는 게 좋아보인다.
safety, fairness 등 어떤 property를 모델링할지 결정하기

Model Checking 언어 공부

model checking tool은 몇 가지가 있는데, SV 랩에서 현재 사용하고 있는 maude를 공부하기로 했다.

Maude의 사용 방법은 Designing Reliable Distributed Systems를 추천받았고, 해당 글을 읽고 정리할 예정이다.

2장, 3장, 8장, 9장을 일단 보면 된다.
4장, 5장, 6장, 7장은 skip할 예정이다.
이후 concurrent를 다루는 10장, communication을 다루는 11장, transport protocol(통신)을 다루는 12장, distributed algorithm을 다루는 13장 중 원하는 system에 해당하는 것을 보면 된다.

어떤 system을 체킹할 지 결정하기

구글에 `model checking distributed key value store`나 `model checking consensus algorithm`

어떤 property를 모델링할지 결정하기

이건 system을 결정하면 따라오는 것이다.

참고

https://www.youtube.com/watch?v=nH4qjmP2KEE

[Model Checking] Linear Time Properties

hyelie — Tue, 19 Sep 2023 00:57:03 +0900

이 글은 RWTH AACHEN 대학교 Joost-Pieter Katoen 교수님의 2018년 1학기 Introduction to Model Checking 강의와 Principles of Model Checking을 기반으로 재구성한 것입니다.

model checking의 주된 알고리즘은 transition system과 requirement를 model checker에 넣어, 해당 transition system이 requirement를 만족하는지 여부를 확인하는 방법이다. 그래서 지금까지 transition system을 모델링하는 방법을 살펴봤었고, 지금부터는 requirement를 모델링하는 방법을 살펴볼 것이다.

이 포스트에서는 크게 4가지를 살핀다.

state-based and linear time view
definition of linear time properties
invariants and safety
liveness and fairness

State Graph

transition system TS는 (S, Act, → I, AP, L)의 tuple로 표기한다. 여기서 Act는 interaction, communication을 modeling하고 fairness를 설명할 때 쓴다. 반면 AP와 L은 properties를 정의할 때 쓴다. 따라서 일단 properties를 다룰 때는 labeling과 state만 일단 신경쓴다.

Definition. State Graph

state graph G$_{T}$를 정의하자. transition system TS가 (S, Act, → I, AP, L)일 때, G$_{T}$의 node는 S와 동일하고, edge는 action label이 없는 transition이다.

Definition. Path Fragment

이전 포스팅에서 execution fragment, initial execution fragment, maximal execution fragment에 대해 살펴봤었다. path fragment는 이와 유사한 개념으로 graph에서 정의되는 execution fragment라 생각하면 된다. TS를 G$_{T}$로 바꿨던 것처럼 execution fragment는 $\pi$=$s_0s_1s_2$...such that s$_{i+1}$ ∈ Post(s$_i$) for all i in |$\pi$|로 정의한다.

initial path fragment는 s$_0$ ∈S$_0$인 경우를 말한다. (initial state에서 시작한다는 뜻이다.)
maximal path fragment는 infinite거나 terminal state에서 끝나는 path fragment를 말한다.

transition system execution이 initial & maximal execution fragment였던 것처럼, 동일하게 transition system path는 initial & maximal path fragment이다.

추가로, 편의를 위해 어떤 state s의 path를 s에서 시작하는 maximal path fragment라 정의하자. 또한 Paths(T)는 transition system의 가능한 모든 path의 집합을, Paths(s)는 state s에서 시작하는 모든 maximal path fragment들의 집합이라 정의하자. Paths$_{\text{fin}}$(s)는 s에서 시작하는 모든 finite path fragment $\hat{\pi}$들의 집합이라 정의하자.

Linear Time View vs Branching Time View

바로 위에서 transition system T를 state graph와 state에 대한 labeling으로 나누었다.

linear time view는 path-based이다. state sequence만 보면 모든 것을 알 수 있다는 뜻이다. branching의 경우, 각 branching의 결과를 state sequence로 볼 수 있기 때문에 branching과 관련이 없다. action을 abstract하고 AP에 투영한다. 이를 trace라 한다.

branching time view는 nondeterministic branch에 대해 설명하므로 state와 branch를 abstraction한다. 이를 computation tree라 한다.

Trace

path는 $\pi$=$s_0s_1s_2$였는데, 이 path의 각 state에 대한 atomic proposition을 적용한 L(s$_0$)L(s$_1$)L(s$_2$)를 trace라 한다. trace는 labeling의 sequence이므로 ($2^{\text{AP}}$)$^{\omega}$ ∪ ($2^{\text{AP}}$)$^{+}$에 속한다.

개선: Terminal State 삭제

이러한 표현은 식이 너무 더럽기 때문에 TS에 terminal state가 없다고 가정하기도 한다. terminal state가 없다면 모든 경우에서 finite에 대한 계산을 없앨 수 있다. (모든 경우가 infinite)

기존 terminal state에서 자기 자신으로 가는 edge 하나를 추가하는 방식으로 terminal state를 없앤다.

예를 들어, 프로그램이 의도했던 종료 상태 s로 가는 transition system을 생각해 보자. 모든 reachable terminal state s에 대해 특별한 stop state로 edge를 추가해 기존 s를 terminal state가 아니게 하고, stop state는 자기 자신으로 edge를 추가하면 terminal state가 없어졌으므로 path가 infinite하게 된다.
다른 경우는 system fault로 인한 부분이다. 이 경우는 terminal이 되기를 원하지 않지만 system fault나 deadlock에 의해 멈추는 경우는 프로그램의 설계가 잘못되었으므로 이를 수정해야 한다.

Traces(T)를 transition system T의 모든 path $\pi$들의 trace의 합집합이라고 하자. 수식으로 정의하면 Traces(T) := {traces($\pi$) : $\pi$ ∈ Paths(T)}이고, 이 때 $\phi$는 initial & maximal path fragment이다. Traces(T) ⊆ ($2^{\text{AP}}$)$^{\omega}$이다.

같은 방법으로 Traces$_\text{fin}$(T) := {traces($\hat{\pi}$) : $\hat{\pi}$ ∈ Paths$_\text{fin}$(T)}라고 정의하자. 이 때 $\hat{\pi}$는 initial & finite path fragment이다. Traces$_\text{fin}$(T) ⊆ ($2^{\text{AP}}$)$^{*}$이다.

만약 terminal state를 삭제한 경우에는 무조건 infinite가 된다는 점을 유의하자.

Linear Time Property

앞서 model checker는 transition system T와 requirement를 구체화한 spec으로 T가 spec을 만족하는지 여부를 확인하는 기계라고 했다. 여기서 spec중 하나가 linear time property이다!

atomic propisition의 집합 AP에 대한 linear time property는 ($2^{\text{AP}}$)$^{\omega}$의 부분집합이다. 즉, state의 labeling의 infinite word의 부분집합이라는 뜻이다.

Definition. Satisfaction Relation for Linear Time Property

transition system이 언제 linear time property를 만족하는지 알 수 있어야 한다.

어떤 transition system TS와, TS의 atomic proposition AP, AP의 linear proposition E에 대해 Traces(T) ⊆ E iff TS $\models$ E이다. transition system의 모든 path의 trace가 E에 속할 때, transition system TS가 E를 만족하고 그 역도 성립한다는 것을 의미한다.

state에 대해서도 이를 정의하는데, s가 TS의 state일 때 Traces(s) ⊆ E iff s $\models$ E이다.

Definition. Trace Inclusion and Linear Time Properties

T$_1$과 T$_2$가 AP에 대한 transition system이고, AP에 대한 linear time property가 E에 대해 Traces(T$_1$) ⊆ Traces(T$_2$) iff T$_2$ $\models$ E then T$_1$ $\models$ E이다.

trace inclusion은 아래 3가지 영역에서 나타난다.

implementation / refinement relation : 예를 들어 어떤 transition system T$_i$가 LT property E를 만족한다고 했을 때, T$_i$를 조금 수정한 T$_{i+1}$이 있다고 하자. 이 때 T$_{i+1}$ ⊆ T$_i$라면 T$_{i+1}$도 E를 만족한다는 것을 보일 수 있다.
resolving nodeterminisim : 예를 들어 어떤 scheduling policy에서 nondeterministic한 선택을 하는 T에서 deterministic 한 선택을 하는 T'을 만들었다고 하자. 이 때 Traces(T') ⊆ Traces(T)이므로 T가 E를 만족하면 T'도 E를 만족하는 것을 보일 수 있다.
data abstraction : 원래 transition system T의 data를 추상화해 transition system T'를 만들었다고 하자. T'가 더 상위의 개념이므로 T의 모든 data들은 T'를 만족한다. Traces(T) ⊆ Traces(T')이므로, T'가 E를 만족하면 T도 E를 만족한다.

Definition. Trace Equivalance

같은 atomic proposition AP에 대한 transition system T$_1$, T$_2$가 있을 때 Traces(T$_1$) = Traces(T$_2$) iff trace equivalance이다.

앞선 Trace Inclusion and LT Properties에 의해 transition system이 trace equivalent하면 동일한 linear time property를 만족한다. T$_1$과 T$_2$가 AP에 대한 transition system이고, AP에 대한 linear time property가 E에 대해 Traces(T$_1$) = Traces(T$_2$) iff 모든 LT property E에 대해 T$_2$ $\models$ E then T$_1$ $\models$ E이다.

Safety Properties and Invariants

그럼 이제 linear time property를 분류하자.

safety properties는 `나쁜 상태가 일어나지 않는 것`을, liveness properties는 `좋은 상태가 일어나는 것`을 의미한다.

safety properties 예시 : deadlock이 일어나지 않는 것. critical section에 한 번에 2개 이상의 process가 접근하지 않는 것. 신호등의 red는 yellow가 선행한다. 등등.
liveness properties 예시 : wait 상태에 들어간 process는 언젠가 critical section에 진입하는 것.

이 때 safety properties 중 special case가 invariants이며, 어떤 나쁜 state에 도달하지 않는 것을 의미한다.

Invariant

AP에 대한 LT property E가 다음 조건을 만족하는 propositional fomula $\phi$가 존재할 때 E를 invariant라 한다.

E = {A$_0$A$_1$A$_2$... ∈ ($2^{\text{AP}}$)$^{\omega}$ : $\forall$ i ≥ 0. A$_i$ $\models$ $\phi$}

이 때 $\phi$를 E의 invariant condition이라 한다.

이 수식이 의미하는 것은 모든 trace의 모든 node가 $\phi$를 만족할 때, 이다.

이 때, invariant E에 대해 T $\models$ E와 다음 3가지는 동치이다.

iff trace($\phi$) ∈ E for all path $\phi$ ∈ Paths(T)
iff s $\models$ $\phi$ for all states s on a path of T
iff s $\models$ $\phi$ for all states s ∈ Reach(T)

의미하는 것은 다음과 같다.

transition system T가 invariant LT property E를 만족한다면 transition system의 어떤 path를 고르더라도 trace($\phi$)가 E를 만족하는 것을 의미한다.
T의 path의 모든 state s가 $\phi$를 만족하는 것을 의미한다.
T의 모든 reachable state s가 $\phi$를 만족하는 것을 의미한다.

Invariant Model Checking

자. 그럼 invariant를 쓸 때 model checker의 알고리즘을 얘기해 보자. model checker는 transition system T와 invariant LT property E를 받는다. model checker는 T가 E를 만족하는지 살핀다. 만약 만족한다면 true를, 그렇지 않다면 error를 나타낸다. 이 방법은 graph에서 DFS/BFS를 돌려 Reach(T)의 모든 state에 대해 s가 $\phi$를 만족하는지 살핀다. 만약 만족하면 true, 아닌 경우 error이다. pseudo code로 표현하면 다음과 같다.

FOR ALL s$_0$ ∈ S$_0$ DO
IF DFS(s$_0$, $\phi$) THEN
return "no"
FI
OD
return "yes"

DFS(s$_0$, $\phi$는 s$_0$에서 DFS를 했을 때 $\phi$를 만족하면 true를, 아닌 경우 false를 리턴하는 함수이다. 이 pseudo code를 수정해 어떤 path의 어떤 state에서 error가 났는지도 쉽게 찾을 수 있을 것이다.

IF s $\notin$ U THEN
IF s $\not\models$ $\phi$ THEN return "true" FI
IF s $\models$ $phi$ THEN
insert s in U
FOR ALL s' ∈ Post(s) DO
IF DFS(s', $\phi$) THEN
return "true"
FI
OD
FI
FI
return "false"

Safety Property

safety properties는 nothing bad will happen - 원치 않는 상태로 가지 않는 것을 보장한다.

invariant는 bad state에 도달하지 않는 것을 의미하고 invariant가 아닌 safety properties는 bad prefix가 없는 것을 의미한다. 사실상 invariant는 safety properties의 special case라는 것을 생각하자.

수식으로 정의해 보자. E가 AP에 대한 LT property라고 하자. 즉, E ⊆ ($2^{\text{AP}}$)$^{\omega}$일 때, $\sigma$ = A$_0$A$_1$A$_2$... ∈ ($2^{\text{AP}}$)$^{\omega}$ \ E에 대해 A$_0$A$_1$...A$_n$B$_{n+1}$B$_{n+2}$... 중 어떤 것도 E에 속하지 않도록 하는 $\sigma$의 finite prefix A$_0$A$_1$...A$_{n}$이 존재할 때, 이 조건을 만족하는 E를 safety property라고 한다.

해석하자면 E에 없는 prefix를 어떻게 확장하더라도 E에 속하지 않는 property가 safety property이다. 즉... A$_0$A$_1$...A$_n$로 시작하는 word가 safety property에 속해야 한다는 것이라 보면 된다.

수식으로 표현하면 E( = P$_\text{safe}$) ∩ {$\sigma$\ ∈ ($2^{\text{AP}}$)$^{\omega}$ | $\hat{\sigma}$는 $\sigma$'의 finite prefix} = $\phi$, 이 때 $\hat{\sigma}$는 bad prefix이며 bad prefix로 시작하는 word와 E의 합집합이 공집합이어야 한다는 뜻으로 의미는 같다.

BadPref

bad prefix의 집합을 BadPref라고 한다.

minimal bad prefix는 word의 bad prefix 중 제일 짧은 bad prefix를 의미한다.

Definition. Satisfaction Relation for Linear Time Property

앞서 Satisfaction Relation for Linear Time Property에서 어떤 transition system TS와, TS의 atomic proposition AP, AP의 linear proposition E에 대해 Traces(T) ⊆ E iff TS $\models$ E라는 것을 살폈다. 여기에 추가로 붙는 iff 명제들이 있다.

TS $\models$ E

iff TS $\models$ E
iff Traces$_\text{fin}$(T) ∩ BadPref = $\phi$
iff Traces$_\text{fin}$(T) ∩ MinBadPref = $\phi$
- T의 finite trace 중 BadPref가 없다는 뜻이다.

Corollary

모든 invariant는 safety property이다. invariant는 safety property의 special case이다. 앞서 invariant는 bad state가 없는 것을, safety property는 bad prefix가 없는 것을 의미한다고 했다. bad state 또한 bad prefix로 표현할 수 있으므로, 부분집합이다.
$\phi$는 safety property이다.
($2^{\text{AP}}$)$^{\omega}$는 safety property이다.

Prefix Closure

infinite word $\sigma$를 A$_0$A$_1$...라고 뒀을 때, pref($\sigma$)를 $\sigma$의 finite prefix의 집합으로, LT property pref(E)를 $\bigcup_{\sigma in E}^{}$pref($\sigma$)라고 정의하자. 이 때 closure(E)를 {$\sigma$ ∈ ($2^{\text{AP}}$)$^{\omega}$ pref($\sigma$) ⊆ pref(E)}라고 정의한다.

해석하자면 모든 prefix pref($\sigma$)가 pref(E)에 속하는 모든 $\sigma$를 말하는 것이다.

Corollary

E가 safety property iff closure(E) = E이다.

E가 closed이므로 closure를 적용해도 같다.

증명은 생략.

Finite Trace Equivalence

앞서 Trace Inclusion and Linear Time Properties에서 T$_1$과 T $_{2}$ 가 AP에 대한 transition system이고, AP에 대한 linear time property가 E에 대해 Traces(T $_{1}$ ) ⊆ Traces(T$_2$) iff T$_2$ $\models$ E then T$_1$ $\models$ E이다.라고 했었다. 이는 finite trace에도 똑같이 적용된다.

Traces$_{\text{fin}}$(T $_{1}$ ) ⊆ Traces$_{\text{fin}}$(T$_2$) iff T$_2$ $\models$ E then T$_1$ $\models$ E이다.

한편, Traces$_{\text{fin}}$(T)는 Traces(T)의 nonempty prefix의 집합, 즉 pref(Traces(T))이다!

Corollary

Traces(T) ⊆ Traces(T') then Traces$_{\text{fin}}$(T) ⊆ Traces$_{\text{fin}}$(T')이다.

Q.

trace equivalence iff finite trace equivalence인가? no.

Traces(T) ⊆ Traces(T') then Traces$_{\text{fin}}(T) ⊆ Traces$_{\text{fin}}(T')이다.

반면 그 역은 성립하지 않는데,

단, T가 terminal state가 없고(모든 path가 infinite), T'가 finite한 경우에는 성립한다.

즉, T가 terminal state가 없고 T'가 finite하고 Traces$_{\text{fin}}(T) ⊆ Traces$_{\text{fin}}(T')인 경우 Traces(T) ⊆ Traces(T')이다. 이러한 조건이 걸렸을 때만 finite trace equivalence가 trace equivalence를 의미한다.

Liveness Property

safety property는 원치 않는 상태로 전이하지 않는 것을 보장하고, liveness property는 원하는 상태에 도달하는 것을 보장한다.

구분하는 방법은.. safety property의 경우 finite bad prefix가 존재하지만 liveness property는 그런 것이 없기 때문에, 이것으로 safety와 liveness를 구분할 수 있다. 즉, finite bad prefix로 해당 property를 반증할 수 있다면 safety, 그렇지 않다면 liveness이다. 정의에 따라 liveness는 모든 finite word를 infinite로 확장할 수 있는데, 따라서 finite word로 반증할 수 없기 때문이다.

수식으로 정의하면 다음과 같다.

E가 AP에 대한 LT property라고 하자. 즉, E ⊆ ($2^{\text{AP}}$)$^{\omega}$일 때, AP의 finite word가 E에 속하는 infinite word로 확장할 수 있을 때 E를 liveness property라고 한다. 즉, pref(E) = ($2^{\text{AP}}$)$^{+}$라는 것이다.

Decomposition Theorem

모든 linear time property E는 safety property와 liveness property 2개로 나뉘고, 이 둘의 intersecion은 다시 E가 된다.

즉, 모든 linear time property를 safety property와 liveness property의 conjunction으로 표현할 수 있다는 것이다.

둘 다를 갖춘 property가 있을까? 있긴 한데, ($2^{\text{AP}}$)$^{\omega}$만 그렇다. 나머지는 없다.

Fairness

LT property는 다음 4가지로 나뉜다.

safety property + invariant
liveness property
safety property와 liveness property 둘 다를 만족하는 단 하나
나머지의 모든 property p는 safety property와 liveness property의 교집합이다.

즉, fairness assumption은 LT property가 아니다!

예를 들어 [모든 process가 critical section에 들어간야 한다]는 liveness property를 생각해보자. 이를 만족하지 않는 path가 존재한다. 이처럼 liveness property는 종종 violated된다. 이는 path가 fair하지 않기 때문이다.

이를 해결하기 위해 때문에 not fair한 몇몇 move를 없애 liveness property를 만족하게 만들 것이다.

process fairness는 interleaving과 contention으로 인한 non-determinism의 적당한 해결책이 있다는 것을 가정한다. 이 중 대표적인 것은 아래 3가지가 있다. 유의점은, fairness property는 not fair한 action을 배제하는 것이기 때문에 어떤 것이 not fair한지 정의하는 것이 중요하다.

unconditional fairness : 모든 process가 infinitely often하게 자신의 차례를 가져오는 것을 말한다.
strong fairness : enabled infinitely often한 모든 process가 infinitely often하게 자신의 차례를 가져오는 것을 말한다.
weak fairness : 특정 시간부터 continuously enable한 모든 process가 infinitely often하게 자신의 차례를 가져오는 것을 말한다.
- enabled infinitely often : 해당 action이 수행될 수 있는 finite한 구간이 있다는 것 + process가 실행되지 않는 finite 구간이 있을 수도 있음.
- continuously enable : 특정 구간에 해당 action이가 실행되는 구간이 연속적으로 있다는 것. 해당 process가 수행되지 않는 구간이 finitely often하게 존재한다는 뜻이다.
- 대충 이 둘의 차이는, 구간 내에 action을 수행할 수 있는 곳이 continuous하냐, 아니면 sparse하냐로 받아들이면 될 것 같다.

수식으로 정의하면 다음과 같다.

transition system T의 action set Act에 대해 A ⊆ Act이고 $\rho$ = s$_0$ $\overrightarrow{\alpha_0}$ s$_1$ $\overrightarrow{\alpha_1}$ s$_2$ $\overrightarrow{\alpha_2}$ ... 인 infinite execution fragment $\rho$를 보자. 이 때 fairness는 action에 의해 parameterized된다.

fairness의 정의

$\rho$는 unconditional A fairness : A에 속하는 action이 infinitely many하게 존재한다는 뜻이다.
$\rho$는 strongly A fairness : s$_j$에서 수행할 수 있는 action이 infinetly many하게 A에 존재할 경우, 그러한 action $\alpha_i$ ∈ A가 infinetly many하게 존재한다는 뜻이다.
$\rho$는 weak A fairness : 어떤 s$_j$에서 수행할 수 있는 action이 A에 존재할 경우, 그러한 action $\alpha_i$ ∈ A가 infinetly many하게 존재한다는 뜻이다.

사용된 notation은 다음과 같다. Act(s$_i$)를 s$_i$에서 택할 수 있는 모든 action set이라고 하자. 각각의 의미는 다음과 같다.

$\overset{∞}{\exists}$가 `infinitely many하게 존재함`
$\overset{∞}{\forall}$를 `거의 모든 for all`

if unconditionally A-fair then strongly A-fair이고, unconditionally A-fair then weakly A-fair이다.

Hierarchy

fairness assumption의 목적은 unfair execution을 삭제하는 것이 목적이다. 이 때 T의 모든 unconditional A-fair execution action ⊆ T의 모든 strong A-fair execution action ⊆ T의 모든 weakly A-fair execution action ⊆ T의 모든 가능한 execution와 같이 계층구조가 이루어져 있다.

F-fair

fairness assumption A에 여러 개의 action을 넣는다고 해서 그 action들에 대해 fair해지는 것이 아니다. fairness의 정의는 A의 어떤 action을 infinitely often하게 수행하는 것이기 때문이다. 따라서 Fairness Assumption F는 (F$_\text{ucond}$, F$_\text{strong}$, F$_\text{weak}$)로 정의한다.

F$_\text{ucond}$, F$_\text{strong}$, F$_\text{weak}$ ⊆ 2$^{\text{Act}}$이다.

F$_\text{ucond}$ ⊆ F$_\text{strong}$ ⊆ F$_\text{weak}$이기 때문에 계층적으로 나눠 fairness assumption을 정의할 수 있다.

그러면 F-fair를 정의하자. execution $\rho$는 F-fair iff

모든 A ∈ F$_\text{ucond}$일 때 unconditionally A-fair
모든 A ∈ F$_\text{strong}$일 때 strongly A-fair
모든 A ∈ F$_\text{weak}$일 때 weakly A-fair

FairTrace

FairTraces$_F$(T)를 {$\rho$가 T의 F-fair execution일 때 trace($\rho$)}로 정의한다.

Fairness와 Safety는 irrelevant

transition system T와, AP에 대한 LT property E가 있을 때 T $\models_F$ E $\Leftrightarrow$ FairTraces$_F$(T) ⊆ E. 즉, fairness는 safety의 역할을 할 수 없다.

위 수식이 의미하는 것은 fairness assumption F와 LT property E를 만족하는 것과, T의 FairTraces가 E에 속한다는 것은 동치라는 뜻이다.

Fairness 만들기

fairness assumption은 가능한 한 weak해야 한다. 처음에는 weak로 잡고, 안 되면 strong으로, 안 되면 uncondition으로 fairness assumption을 옮겨야 한다.

Fairness와 Safety의 관계

fairness assumption은 safety property에 영향을 주지 않는다. 단 이를 위해서는 몇 가지 스킬을 써야 한다.

realizability는 각각의 initial finite path fragment가 F-fair path로 확장되어야 한다는 것을 요구한다.

realizable의 정의는 fairness assumption는 T의 reachable한 state s에 대해, s에서 시작하는 F-fair path가 존재하는 경우 transition system T에서 realizable하다고 한다.

이 때 realizable fairness assumption은 safety property와 관계없다. 만약 transition system T와 safety property E에 대해 fairness assumption F가 realizable 하다면 T $\models$ E iff T $\models_F$ E이다.

위 명제는 non-realizable fairness assumption에 대해서는 성립하지 않는다.

23.09.17. 풀었던 문제들

hyelie — Mon, 18 Sep 2023 00:57:12 +0900

Programmers Lv. 3 베스트앨범, 15분

그냥 풀면 되는 구현 문제.

장르별 재생회수의 순서
장르 내부에서 재생회수의 순서

위 2가지에 대해 정렬되어 있어야 하기 때문에 map을 2개 써야 한다. 그냥 뭐.. map에 genre를 key로 넣어 재생회수 합계와 해당 genre에 속한 노래들의 {재생회수, index}를 저장하면 된다.

int len;

struct Info{
    int play, index;
};

struct cmp{
    // 조건 1. play가 큰 것.
    // 조건 2. index가 작은 것.
    bool operator()(Info &a, Info &b){
        if(a.play == b.play) return a.index > b.index;
        return a.play < b.play;
    }
};

typedef pair<string, int> psi;

bool cmpMap(psi &a, psi &b){
    if(a.second == b.second) return a.first < a.first;
    return a.second > b.second;
}

vector<int> solution(vector<string> genres, vector<int> plays) {
    len = plays.size();
    
    // 1. 장르별 재생회수
    map<string, int> genrePlay; // genrePlay[i] : genre i의 재생 회수
    // 2. 장르 내부에서 재생회수 
    map<string, priority_queue<Info, vector<Info>, cmp>> genrePlayMap; // genrePlayMap[i] : genre i의 plays pa
    for(int i = 0; i<len; i++){
        string genre = genres[i];
        int play = plays[i];
        
        genrePlay[genre] += play;
        
        Info info; info.index = i; info.play = play;
        genrePlayMap[genre].push(info);
    }
    
    // map value로 정렬
    vector<psi> genrePlays(genrePlay.begin(), genrePlay.end());
    sort(genrePlays.begin(), genrePlays.end(), cmpMap);
    
    vector<int> answer;
    for(psi data : genrePlays){
        string genre = data.first;
        
        priority_queue<Info, vector<Info>, cmp> &pq = genrePlayMap[genre];
        answer.push_back(pq.top().index); pq.pop();
        if(!pq.empty()) answer.push_back(pq.top().index);
    }
    
    return answer;
}

시간복잡도

for문이 O(n). map size는 worst case O(n)이므로 insert/pop에 O(nlogn)이 걸린다. 정렬에는 O(nlogn). 총 합계 O(nlogn)이다.

후기

굳이 pq로 안하고 vector로 넣은 다음에 한 번에 정렬했어도 됐을 것 같다.

Programmers Lv. 3, 스티커 모으기(2), 18분

전형적인 DP 문제.

문제를 딱 보면 dp[i]를 i번째 스티커까지 봤을 때 최댓값으로 둘 지, i번째까지 보고 i번째 스티커를 떼었을 때 최댓값이라고 정의할지 고민이 조금 된다. 그러나 후자로 선택하면 뗀다는 정보가 추가적으로 필요하기에 복잡해진다. 전자로 선택하면 된다.

그러면 점화식은 dp[i] = max(dp[i-1], dp[i-2] + sticker[i])가 된다. 후항은 dp[i-2]에서 sticker를 떼든 말든 상관없이 i번째 스티커를 뗄 수 있기 때문이고, 전항은 i-1번째 스티커를 떼었는지 여부는 모르기 때문이다.

또 하나, 유의해야 할 것이 있는데 이 문제는 선형이 아니라 환형이기 때문에 0번째 스티커를 떼는 경우와 0번째 스티커를 떼지 않는 경우를 고려해야 한다. 전자의 경우에는 마지막 스티커를 뗄 수 없고, 후자의 경우는 마지막 스티커를 뗄 수 있으므로 dp 연산을 어디까지 할지 지정만 잘 해주면 된다.

int len;

int solution(vector<int> sticker)
{
    len = sticker.size();
    if(len <= 2) return *max_element(sticker.begin(), sticker.end());
    
    vector<int> dp(len, 0);
    
    // case 1. 0번째 것 뜯는 경우
    dp[0] = sticker[0];
    dp[1] = dp[0];
    for(int i = 2; i<len-1; i++){
        dp[i] = max(dp[i-1], sticker[i] + dp[i-2]);
    }
    int answer = *max_element(dp.begin(), dp.end());
    
    // case 2. 0번째 것 뜯지 않는 경우
    fill(dp.begin(), dp.end(), 0);
    dp[0] = 0;
    dp[1] = sticker[1];
    for(int i = 2; i<len; i++){
        dp[i] = max(dp[i-1], sticker[i] + dp[i-2]);
    }
    answer = max(answer, *max_element(dp.begin(), dp.end()));

    return answer;
}

시간복잡도

O(n) 순회를 2번 하므로 O(n)

23.09.14. 풀었던 문제들

hyelie — Thu, 14 Sep 2023 22:54:42 +0900

프로그래머스 Lv. 2 최댓값과 최솟값, 4분 30초

c++에서 delimiter를 사용해 string을 파싱할 줄 알면 바로 풀리는 문제. iss 쓰고 while getline으로 풀면 된다!

string solution(string s) {
    int min_v = INT_MAX;
    int max_v = INT_MIN;
    
    istringstream iss(s);
    string buffer;
    while(getline(iss, buffer, ' ')){
        int v;
        if(buffer[0] == '-'){
            v = stoi(buffer.substr(1));
            v *= -1;
        }
        else{
            v = stoi(buffer);
        }
        
        min_v = min(min_v, v);
        max_v = max(max_v, v);
    }
    
    return to_string(min_v) + " " + to_string(max_v);
}

시간복잡도

s를 파싱하고 최대/최소값을 갱신하는 데 O(n)이 걸린다.

프로그래머스 Lv. 2 최솟값 만들기, 1분 40초

수학 규칙을 알면 되는 문제. A는 오름차순, B는 내림차순으로 정렬한 후 곱한 것을 더한 것이 답이다.

int solution(vector<int> A, vector<int> B)
{
    sort(A.begin(), A.end(), less<int>());
    sort(B.begin(), B.end(), greater<int>());
    
    int answer = 0, len = A.size();
    for(int i = 0; i<len; i++){
        answer += A[i] * B[i];
    }

    return answer;
}

시간복잡도

정렬에 O(nlogn), 순회에 O(n)

프로그래머스 Lv. 2 올바른 괄호, 2분

stack 쓰면 매우 쉽게 풀리는 문제. 사실상 예제문제다. 이런 건 1레벨로 낮춰줬으면.

bool solution(string s)
{
    stack<char> stk;
    for(char c : s){
        if(c == ')'){
            if(stk.empty() || stk.top() != '(') return false;
            stk.pop();
        }
        else if(c == '('){
            stk.push('(');
        }
    }
    
    return stk.empty();
}

시간복잡도

순회에 O(n)

프로그래머스 Lv. 2 이진 변환 반복하기, 6분 40초

주어진 대로 변환하면 되는 문제. 뭐.. 10진수를 n진수로 변환할 때 % 이후 /를 한다는 것만 기억하면 된다.

#include <string>
#include <vector>
#include <algorithm>

using namespace std;

int num_removed_zeros = 0;
int num_binary_translation = 0;

string removeZero(string x){
    int total = (int) x.length();
    string result = "";
    for(char c : x){
        if(c == '1') result += "1";
    }
    int num_ones = result.length();
    num_removed_zeros += total - num_ones;
    return result;
}

string decimalToBinary(int x){
    num_binary_translation++;
    
    string result = "";
    while(x){
        result += to_string(x % 2);
        x /= 2;
    }
    reverse(result.begin(), result.end());
    return result;
}

vector<int> solution(string s) {
    while(s != "1"){
        int len = (int) removeZero(s).length();
        s = decimalToBinary(len);
    }
    return {num_binary_translation, num_removed_zeros};
}

프로그래머스 Lv. 3 숫자의 표현, 13분

첫 접근

아래 느낌으로 nested loop로 돌렸다. n이 1만이니.. 그러나 당연히 TLE. 다른 방법이 필요했다.

vector<int> dp(10001, 0); // dp[i] : 연속된 자연수로 i를 표현하는 방법의 개수
int INF = 10001;

int solution(int n) {
    for(int i = 1; i<=n; i++){
        for(int len = 1;)
        for(int j = i; j<=5000; j++){
            int sum = (j - i + 1) * (i + j) / 2;
            if(sum >= INF) continue;
            dp[sum]++;
        }
    }
    
    return dp[n];
}

두 번째 접근

sliding window가 딱 생각이 났다. sum을 계산하고, 작으면 e를 늘이고, 크면 s를 늘이는 방식으로.

int getSum(int s, int e){
    return (e - s + 1) * (s + e) / 2;
}

int solution(int n) {
    // dp 실패했으니 sliding window로 해 볼까? two pointer로.
    int s = 1, e = 1, answer = 0;
    while(s <= n){
        if(s > e){
            e = s;
            continue;
        }
        
        int sum = getSum(s, e);
        if(sum == n){
            answer++;
            s++;
            continue;
        }
        if(sum < n) e++;
        else if(sum > n) s++;
    }
    return answer;
}

시간복잡도

s의 sliding에 O(n)이, e의 sliding에 O(n)이 걸린다.

프로그래머스 Lv. 3 숫자 게임, 17분 40초

greedy 문제이다. 일단, 기본 전제: 이길 수 있으면 이기되 최대한 작은 수로 이기고, 지는 경우에는 최대한 작은 수로 져야 한다.

첫 접근

최대한 작은 수로 이긴다 -> binary search, 특히 upper bound로 풀었다. 처음에 놓친 점은, multiset을 하지 않은 것.

int solution(vector<int> A, vector<int> B) {
    multiset<int> s(B.begin(), B.end());
    int answer = 0;
    set<int>::iterator iter;
    for(int point : A){
        
        iter = upper_bound(s.begin(), s.end(), point);
        if(iter == s.end()){ // point보다 큰 것이 없는 경우
            s.erase(s.begin());
        }
        else{ // 존재 : point보다 큰 것중 제일 작은 것
            s.erase(iter);
            answer++;
        }
    }
    
    return answer;
}

그러나 TLE가 난다! input size가 10만이고, set의 연산은 O(logn)이므로 O(nlogn)으로 풀릴 줄 알았는데, set 연산이 생각보다 느린갑다.

두 번째 접근

그래서 A는 내림차순으로, B는 오름차순으로 정렬한 후 B가 이기지 못하는 경우라면 B의 제일 작은 점수를 희생시키고, 이길 수 있으면 이기는 방식으로 선택했다.

int solution(vector<int> A, vector<int> B) {
    sort(A.begin(), A.end(), greater<int>());
    sort(B.begin(), B.end(), less<int>()); // 오름차
    int start = 0, end = B.size()-1;
    int answer = 0;
    for(int point : A){
        if(point >= B[end]){ // B가 못이기는 경우
            start++;
        }
        else{
            end--;
            answer++;
        }
    }
    
    return answer;
}

시간복잡도

정렬에 O(nlogg), 순회에 O(n)이므로 O(nlogn)이다.

후기

왜 set으로는 안풀릴까.

프로그래머스 Lv. 3 기지국 설치, 27분

전파가 닿지 않는 부분을 알면, w의 /와 % 연산을 이용해서 쉽게 답을 낼 수 있다.

그러면 전파가 닿지 않는 부분을 알아야 하는데,

전파가 닿는 구간을 찾음
전체에서 위 구간을 뺌

위 방식으로 구현했다.

N이 작으면 bitmap 형식으로 풀어도 되는데, 2억이므로 시간 내에 풀 수 없다. 따라서 [시작 좌표, 끝 좌표]로 어떻게든 풀어야 한다.

전파가 닿는 구간 찾기
1. 겹치는 부분만 잘 처리해 주면 된다.
전파가 닿지 않는 구간 찾기
1. 전체에서 전파가 닿는 구간을 빼면 된다.

typedef pair<int, int> pii; // .first : 시작 지점, .second : 끝 지점. (included)

int solution(int n, vector<int> stations, int w)
{
    int s = stations[0] - w, e = stations[0] + w;
    s = max(s, 1); e = min(e, n);
    pii p = {s, e};
    vector<pii> overlaps(1, p);
    
    // 겹쳐 있는 구간을 찾을 것임.
    for(int station : stations){
        s = station - w, e = station + w;
        s = max(s, 1); e = min(e, n);
        int prev_e = overlaps.back().second;
        
        if(prev_e + 1 < s){ // 아예 새로운 구간이 시작되는 경우
            overlaps.push_back({s, e});
        }
        else{ // 이어지거나, 겹치는 경우
            overlaps.back().second = e;
        }
    }
    overlaps.push_back({n+1, n+1});
    
    
    // overlapping 결과 테스트
    // for(pii p : overlaps){
    //     cout<<p.first<<", "<<p.second<<endl;
    // }
    
    // sum of ceil(겹쳐 있지 않은 구간 / w)가 답.
    int answer = 0;
    s = 1;
    w = 2 * w + 1;
    for(pii overlap : overlaps){
        e = overlap.first - 1;
        
        answer += (e - s + 1) / w;
        answer += ((e - s + 1) % w != 0);
        
        s = overlap.second + 1;
    }
    
    return answer;
}

/*
비어있는 공간만 찾으면 됨. 구현 문제 같음.
stations들이 겹쳐 있는 구간을 찾는 문제로 바꾸면 쉬울 것 같은데?

*/

시간복잡도

overlaps를 만드는 데 O(n), 이후 overlaps를 순회할 때 O(n)이므로 O(n)이다.

후기

이 문제는 구현에서 조금 절었다. 실수한 점은, 첫 값을 넣을 때도 s와 e가 [1, n] 사이에 있게 filtering 했어야 했는데 그러지 않아서 문제가 생겼다.

[Model Checking] Modeling Concurrent System

hyelie — Wed, 13 Sep 2023 01:51:23 +0900

이 글은 RWTH AACHEN 대학교 Joost-Pieter Katoen 교수님의 2018년 1학기 Introduction to Model Checking 강의와 Principles of Model Checking을 기반으로 재구성한 것입니다.

지난 글에서는 Transition System과 Program Graph, 그리고 Program Graph를 Transition System으로 변환하는 방법을 살펴 봤다. 여기서 살폈었던 것들은 닫힌 계로써, 단 하나의 프로그램만 모델링하는 방법이었다.

이제 총 n개의 parallel system P$_1$, P$_2$, ... P$_n$ 이 있을 때를 모델링하고자 한다. 이 때 각 thread의 행동은 아래 3가지 중 하나이다.

no communication (interleaving) : system이 `independent`할 때 (서로 communication하지 않을 때)
synchronous communication (handshaking) : system들이 `shared variable`를 사용해 communication을 할 때
asynchronous communication (channel) : `queue`를 사용해 communication할 때

이 글에서는 위 3가지를 어떻게 transition system으로 표현하는지 살펴볼 것이다.

Interleaving

interleaving communication은 parallel process들의 concurrent, independent action을 의미한다. (서로 communication하지 않는다.) 때문에 interleaving(끼워넣기)라고 표현한다. 앞서 그랬듯 이 process들은 nondeterministic하게 다음 action을 결정한다. 기호로는 `|||`로 표기한다.

interleaving에서 중요한 점은 action $\alpha$와 $\beta$가 어떤 순서로 실행되든 결과가 같다는 것이다. 이를Effect($\alpha$ ||| $\beta$) = Effect($(\alpha; \beta)$ + $(\beta; \alpha)$)로 표현한다.

Definition. Transition System의 Interleaving

transition system TS$_1$이 (S$_1$, Act$_1$, →$_1$, I$_1$, AP$_1$, L$_1$), TS$_2$ (S$_2$, Act$_2$, →$_2$, I$_2$, AP$_2$, L$_2$)일 때 이 둘의 interleaving 결과 TS$_1$ ||| TS$_2$는 다음과 같이 정의한다.

interleaving communication의 정의

interleaving system의 state들은 각 transition system의 state들의 cartesian product가 될 것이다.
→는 $\frac{s_1 \overset{\alpha}{\rightarrow} s'_1}{<s_1, s_2> \overset{\alpha}{\rightarrow} <s'_1, s_2>}$ AND $\frac{s_2 \overset{\alpha}{\rightarrow} s'_2}{<s_1, s_2> \overset{\alpha}{\rightarrow} <s_1, s'_2>}$로 정의한다.
- 좌항의 분자가 의미하는 것은 $s_1$에서 $\alpha$를 통해 $s'_1$으로 이동하는 TS$_1$의 transition relation을 의미한다. 분모가 의미하는 것은 state <$s_1$, $s_2$>에 대해 $\alpha$를 통해 <$s'_1$, $s_2$>로 이동하는 transition relaction을 의미한다. 이 때 TS$_2$의 transition은 일어나지 않는다!
- 우항도 똑같은 방식으로 이해할 수 있다.
- 이전에 살펴봤듯 이 분수식이 의미하는 것은 [분자 부분이 참이면 분모 부분을 만족하는데, 이 중 제일 작은 relation]이다.
L(s$_1$, s$_2$) = L(s$_1$) ∪ L(s$_2$)로 정의한다.

interleaving의 경우 서로 영향을 주지 않기 때문에 cartesian produce와 union으로 표현된다.

Communication via Shared Variables

interleaving의 경우에는 공유하는 변수가 없어 두 subsystem의 cartesian product를 하면 되었다. 그러나 만약 어떤 variable이 shared variable인 경우에는 어떻게 될까?

예를 들어 어떤 shared variable x를 사용하는 transition system 1, transition system 2가 있다고 하자. 둘의 interleaving 결과로 <x=4, x=6>와 같은 존재할 수 없는, inconsistent state가 생성된다. 이를 해결하기 위해 shared variable을 사용하는 경우는 따로 정의해 주어야 한다.

shared variable을 사용하는 parallel program의 transition system을 바로 합치는 것은 어렵기 때문에 program graph 단계에서 interleaving을 통해 shared variable을 먼저 정의하고, 이후 합친 program graph를 transition system으로 전환해 shared variable을 사용하는 transition system을 정의한다.

Definition. Program Graph의 Interleaving

program graph PG1와 program graph PG2의 interleaving은 다음과 같다. (단순한 cartesian product이다.)

program graph의 interleaving 정의

Loc의 경우 Loc$_1$과 Loc$_2$의 cartesian product이다.
→는 위 그림과 같이 정의한다.
- program grpah의 edge에는 guard와 action이 있었다.
- 좌항의 분자 $\text{l} \overset{g:\alpha}{\rightarrow} \text{l'}$는 location l에서 g를 만족할 때 $\alpha$를 수행해 l'로 가는 transition을 의미한다.
- 좌항의 분모는 location <l$_1$, l$_2$>에서 g를 만족할 때 $\alpha$를 수행해 <l'$_1$, l$_2$>로 transition 할 수 있다는 것이다.
- 이 분수식이 의미하는 것은 [분자 부분이 참이면 분모 부분도 참인데, 이를 만족하는 relation 중 제일 작은 relation]이다.
- 우항도 같은 방식으로 이해할 수 있다.

L(s$_1$, s$_2$) = L(s$_1$) ∪ L(s$_2$)로 정의한다.
guard는 각각의 guard의 or 연산이다.
shared varibale는 Var1 ∩ Var2이고, Var1 ∪ Var2 - (Var1 ∩ Var2)가 local variable이 된다.

program graph는 shared variable을 허용하는데, program graph에서는 state에 변수의 값이 들어가지 않고 location이 들어가기 때문이다.(변수의 값을 얻기 위해서는 evaluation function을 사용해야 한다.) 이후 이를 transition system으로 변환할 때, location과 evaluation을 state로 만드는 특성 때문에 program graph의 interleaving을 transition system으로 전환하면 shared variable을 사용할 수 있게 된다.

이 때문에 다음 특성이 성립한다.

PG = PG$_1$ ||| PG$_2$, TS$_1$ = TS(PG$_1$), TS$_2$ = TS(PG$_2$)라고 정의했을 때
shared variable이 없는 경우에는 TS$_1$ ||| TS$_2$ = TS(PG)이지만
shared variable이 있는 경우에는 TS$_1$ ||| TS$_2$ ≠ TS(PG)이다.

Mutual Exclution with Semaphore

semaphore와 같이 shared variable을 사용해서 mutual exclusion을 구현하는 경우를 생각해 보자. (42p 참고) 글로 다 나와있는 내용이라 세부 내용은 생략하지만 중요한 부분만 기술하면 아래와 같다.

PG 2개를 interleaving한 후, 만들어진 location들 중에서 reachability를 따진다.
reachable한 state들만 따져서 transition system으로 바꾼다.
critical section으로 둘 다 들어갈 수 있는지 / 둘 다 wait하는 상태는 없는지 확인한다.

Perterson's Mutual Exclution Algorithm

45p 참고

Synchronous Message Passing (Handshaking)

synchronous message passing (handshaking)이란 interacting하는 transition system들이 synchronous하게 특정 action을 처리해야 한다는 것을 의미한다. 즉, 2개 이상의 transition system이 동시에 특정 action을 수행해야 한다는 것이다.

이를 위해 새로운 operator ||$_{H}$를 정의한다. 이 연산자는 independent action에 대해서는 interleaving하고, H에 있는 action들에 대해서는 synchronization action을 취하는 연산을 의미한다.

Synchronous Message Passing의 정의

S, Act, →, I, AP, L에 대해서 모두 cartesian product를 적용한다.
→는 아래와 같이 이다. 요약하자면 즉 H에 있지 않은 $\alpha$에 대해서만 기존 relation을 가져오고, H에 있는 것들은 새로 정의한다.
- $\alpha$ ∈ Act$_i$ \ H인 $\alpha$에 대해서 : $\frac{s_1 \overset{\alpha}{\rightarrow} s'_1}{<s_1, s_2> \overset{\alpha}{\rightarrow} <s'_1, s_2>}$ AND $\frac{s_2 \overset{\alpha}{\rightarrow} s'_2}{<s_1, s_2> \overset{\alpha}{\rightarrow} <s_1, s'_2>}$로 정의한다.
  - 위의 interleaving과 같다.
- $\alpha$ ∈H인 $\alpha$에 대해서 : $\frac{s_1 \overset{\alpha}{\rightarrow} s'_1 \cap s_2 \overset{\alpha}{\rightarrow} s'_2}{<s_1, s_2> \overset{\alpha}{\rightarrow} <s'_1, s'_2>}$로 정의한다.
  - 이는 s$_1$에서 $\alpha$를 수행해 s'$_1$으로 가고, s$_2$에서 $\alpha$를 수행해 s'$_2$으로 가고, 이 때 state는 <s$_1$, s$_2$>에서 <s'$_1$, s'$_2$>로 가는 relation 중 제일 작은 것을 의미한다.

Properties of Handshaking

transition system들의 handshaking은 commutative(교환 가능)하지만 not associative(결합 불가능)이다. 단, 모든 transition system이 같은 H에 대해 synchronize하는 경우에는 associative이다.

이 때 H = Act$_1$ ∩ Act$_2$일 때는 H를 생략하고 ||로 표기한다.

또한 H = $\phi$인 경우에는 interleaving operator로 표기할 수 있다. (TS$_1$ ||$_{\phi}$ TS$_2$) = TS$_1$ ||| TS$_2$)

예시

handshaking 예시

왼쪽과 같은 transition system TS$_1$, TS$_2$가 있을 때 TS$_1$ ||$_{\beta}$ TS$_2$는 오른쪽 그림과 같다. $\beta$를 수행하기 전 state까지 기다리고, 이후에 $\beta$를 수행한다.

Synchronous Message Passing using Arbiter

arbiter는 2개의 state가 있는 machine이다. 두 transition system과 arbiter가 synchronize되므로, arbiter의 action을 통해서만 lock을 얻을 수 있다는 것이 핵심이다.

만약 두 transition system 모두 wait 상태라면, arbiter는 둘 중 하나만 non-deterministic하게 request 상태로 바꿔줄 수 있다. (arbiter의 resource가 한정되어 있기 때문이다.)

이를 식으로 표현하면 TS$_{\text{Arb}}$ = (TS$_1$ ||| TS$_2$) || Arbiter이다. TS$_1$과 TS$_2$는 서로 communication하지 않기 때문에 interleaving으로, 이 둘의 interleaving 결과와 arbiter가 synchronize한다는 것을 의미한다.

Channel System

data-dependent parallel system은 아래의 3가지로 표현한다.

shared variable들로 communication
synchronous message passing (handshaking)
asynchronous message passing

한편, channel system은 FIFO 형태의 buffer인 channel로 통신하는 parallel system이다. 이 때 buffer size가 0이면 synchronous message passing, 즉 handshaking을 의미하고 buffer size가 0보다 크면 delay가 있는 asynchronous pessage passing을 의미한다.

앞서 handshaking은 살펴봤으니 여기서는 asynchronous message passing을 살펴볼 것이다.

Asynchronous Message Passing

synchronous handshaking에서는 동기화된 action들은 동시에 실행되어야 했다. 반면 asynchronous의 경우 sender가 channel에 message를 보내면, receiver는 그 message를 (여유가 있을 때) 확인한다.

이를 위해 sender, receiver 2개의 program graph, 그리고 buffer를 정의해야 한다. 참고로, channel system은 program graph를 사용해 정의한다.

Definition. Communication Action

buffer에 대한 action인 communication action 2가지를 새로 정의하자. 참고로, 이 둘의 합집합을 Comm이라고 부르기도 한다.

c!v : value v를 channel c에 넣는다.
c?x : channel c에서 message를 받아 variable x에 넣는다.

cap(c) > 0일 때 c!v와 c?x의 동작은 다음과 같다.

c!v : c의 capacity가 가득 차지 않았을 때만 가능하다. 하는 동작은 enqueue(c, v)이다.
c?x : c가 비지 않았을 때만 가능하다. 하는 동작은 <x := front(c); dequeue(c)>이다.
조건을 만족하지 않는 동작은 정의하기에 따라 다르다.

그럼 기존에는 어떤 action $\alpha$에 대해 $\text{l} \overset{g:\alpha}{\rightarrow} \text{l'}$로 정의했던 것에 communication action도 추가할 수 있다. 추가하는 action들은 다음과 같다.

$\text{l} \overset{g:c!v}{\rightarrow} \text{l'}$와 $\text{l} \overset{g:c?x}{\rightarrow} \text{l'}$

$\text{l} \overset{g:c!v}{\rightarrow} \text{l'}$는 location l에서 g가 true일 때 value v를 channel에 넣는 것을 통해 l'로 가는 것을 의미한다.
$\text{l} \overset{g:c?x}{\rightarrow} \text{l'}$는 locaiton l에서 g가 true일 때 channel에서 message를 받아 variable x에 넣는 것을 의미한다.
- 이 때 channel에서 message를 받을 때는 front()에 있는 것을 가져온다.

Definition. Channel

이전 포스트에서 typed variable x의 domain을 Dom(x)라고 했고, 모든 x에 대해 모든 Dom(x)들의 합집합을 Var로 정의했고, $\eta$를 Var과 Values를 매핑하는 evaluation function으로 정의했었다.

channel 이와 유사하게 정의할 것이다.

typed channel c를 다음과 같이 정의한다: typed channel c에 대해 capacity cap(c) ∈ {0, 자연수} ∪ {∞}이고 domain Dom(c)를 가진다.

뜻은 capacity가 0과 자연수 또는 unbounded이고, 들어갈 수 있는 값이 Dom(c)라는 뜻이다.

Definition. Channel Evaluation Function

typed channel에 대한 evaluation function $\xi$는 Chan과 Values*를 매핑하는 함수이며, $\xi$(c)는 Dom(c)에 속하고, 길이가 cap(c)보다 작거나 같아야 한다고 정의한다. 이 때 Chan은 typed channel의 합집합을, Values*는 channel 안에 담긴 finite한 값을 의미한다. 따라서

Definition. Channel System

communication action, channel, channel evaluation function을 정의했으므로 이제 channel system를 정의해 보자.

channel system은 P$_i$를 (Var, Chan)에 대한 program graph라고 두었을 때 [ P$_1$ | P$_2$ | ... | P$_n$ ]라고 정의한다.

Var는 typed variable의 set을, Chan은 typed channel의 set을 의미한다.

이 때 (Var, Chan)에 대한 program graph P$_i$는 (Loc$_i$, Act$_i$, Effect$_i$, →$_i$, Loc$_{0,i}$, g$_i$)로 표기하며, channel에 대한 정보만 추가하기 위해 →만 새로 정의한다. 나머지는 앞서 살펴봤던 program graph P$_i$의 정의 (Loc$_i$, Act$_i$, Effect$_i$, →$_i$, Loc$_{0,i}$, g$_i$)와 동일하다.

→ ⊆ Loc × Cond(Var) × (Act ∪ Comm) × Loc
기존 →는 $\text{l} \overset{g:\alpha}{\rightarrow} \text{l'}$만 있었다. 여기에 아래 2가지가 추가된다.
$\text{l} \overset{g:c!v}{\rightarrow} \text{l'}$ : location l에서 channel c에 value v를 보내 location l'로 변함
$\text{l} \overset{g:c?x}{\rightarrow} \text{l'}$ : location l에서 channel c에 있는 값을 x에 할당해 location l'로 변함
- 이 때 c는 P$_i$가 보낼 수 있는 channel이다.

Definition. Transition System으로 표현한 Channel System

바로 앞에서 program graph로 표현한 channel system을 살펴봤다. 이를 transition system으로 변환한 결과는 다음과 같다.

transition system으로 표기한 channel system의 정의

state는 <l$_1$, l$_2$, ... , l$_n$, $\eta$, $xi$>이다. l$_i$는 P$_i$의 location이고 $\eta$는 variable evaluation function, $\xi$는 channel evaluation function이다.
- 따라서 S = (Loc$_1$ × Loc$_n$) × Eval(Var) × Eval(Chan)이다.
- 각 program graph의 위치, 각 program graph의 변수 값, 각 channel의 값이 state가 된다는 뜻이다.
- $\eta$는 Var과 $\bigcup_{x \in Var}^{} Dom(x)$ with $\eta(x)$ in Dom(x)를 매핑한다.
- $\xi$는 Var과 $\bigcup_{x \in Chan}^{} Dom(c)*$ with $\xi(x)$ in Dom(c)* and $|\xi(x)| \le cap(c)*$를 매핑한다.

transition system으로 표기한 channel system의 transition relation

transition relation는 위 그림과 같다.
- independent한 경우에는 기존 interleaving과 같이 쓰면 된다. 분자는 기존 state의 전환 중 어떤 l$_i$의 전환이 $g:\alpha$를 쓴다는 것을, 분모는 오직 l$_i$의 location만 l'$_i$로 바뀐 것을 의미한다. 이를 만족하는 제일 작은 relation이라는 뜻이다.
  - 이 때 $\xi$는 변하지 않으므로 그대로 유지된다.
- asynchronous message passing은 아래와 같다. asynchronous이므로 cap(c) > 0이 전제된다.
  - receiving의 경우
    - $\xi$(c)의 length > 0이고, $\xi$(c)가 v$_1$...v$_k$일 때 분모는 l$_i$의 location만 l'$_i$로, channel에서 값을 가져왔으니 $\eta$와 $\xi$가 바뀐 것을 의미한다. $\eta$'는 기존 $\eta$에서 x값만 v$_1$으로 바뀐 것을, $\xi$'(c)는 channel c의 값만 v$_2$...v$_k$로 바뀌었다는 것이다.
    - 분자는 g를 만족하는 transition에 대해 l$_i$의 location만 l'$_i$로 바뀐 것을 의미한다.
    - channel에서 값을 꺼내오고, variable evaluation function과 channel evaluation function 2가지를 갱신하고, location을 바꾼 것이라고 이해하면 된다.
  - sending의 경우 - receiving의 경우와 같다.
    - $\xi$(c)의 length ≤ cap(c)이고(빈 공간이 있고), $\xi$(c)가 v$_1$...v$_k$일 때 분모는 l$_i$의 location만 l'$_i$로, channel에 값을 넣었으니 $\xi$만 바뀐 것을 의미한다. $\xi$'(c)는 channel c의 값만 기존 $\xi$(c)에서 v가 추가되어 v$_1$...v$_k$v로 바뀐 것으로 바뀐 것을 의미한다. 변수 값이 바뀌지 않았으므로 $\eta$는 바뀌지 않는다!
    - 분자는 g를 만족하는 transition에 대해 l$_i$의 location만 l'$_i$로 바뀐 것을 의미한다.
    - channel에 값을 넣고, channel evaulation function과 locaiton을 갱신했다고 이해하면 된다.
- synchronous message passing은 다음과 같다.
  - synchronous message passing은 2개의 location이 동시에 바뀌어야 한다는 뜻이다.
  - program graph i는 message를 receieve하고, program graph j는 message를 send한다.
  - 분자가 의미하는 것은 g$_1$과 g$_2$를 만족할 때 서로 다른 program graph가 message를 주고받는 것을 의미한다.
  - 분모는 이 transition으로 i, j의 location이 바뀌는 것, 그리고 변수 값도 달라졌으므로 $\eta$도 바뀐 것을 의미한다. $\eta$'는 $\eta$에서 x값만 v로 바뀌었다. $\xi$는 변하지 않는다!
Act, I(초기 state), AP, L는 program graph를 transition system으로 변환하는 것과 동일하며 따로 추가되는 것이 없다.

Variation

c!v의 경우, c!expr처럼 변수 하나의 값이 아니라 expression의 결과값도 보낼 수 있다.
$\text{l} \overset{c?x:\alpha}{\rightarrow} \text{l'}$처럼 communication을 condition으로 쓸 수 있다. 이 경우는 channel에서 값을 꺼내왔을 때만 $\alpha$ action을 수행하는 것을 의미한다. 값을 꺼내 오는 것은 channel에 값이 있을 때만 가능하므로 이를 조건으로 쓴 것이다.
기존에는 closed channel system을 [ P$_1$ | P$_2$ | ... | P$_n$ ]처럼 작성했는데, 외부와 통신하는 open channel system을 P$_1$ | P$_2$ | ... | P$_n$로 표기할 수 있다.

State Explosion

2개의 program graph가 있고, 각각 2개의 location이 있고, 2개의 shared variable이 있다고 하자. 이 때 두 program graph는 capacity 10짜리 channel이 2로 communication한다. (편의상 모든 변수는 boolean이라 두자.)

이 경우 state의 개수는 어떻게 될까?

Loc에 해당하는 state는 2 * 2이고, $\eta$에 해당하는 state도 2 * 2, $\xi$에 해당하는 state는 (2$^{11}$ - 1) * (2$^{11}$ - 1)개이다. 이 3가지의 곱이 전체 state의 개수이다. 너무 크다! 만약 unbounded channel인 경우에는 당연히 INF이다. 이 문제를 해결하는 방법은 추후에 알아본다.

(nano)promola

위에서 배운 수식들은 수학적 도구를 사용하기 때문에 너무 복잡하다. 때문에 더 간단한 형식으로 써야 하는데, 이 형식은 비전문가도 사용하지 않을 정도로 간단해야 하지만 의미를 정확하게 나타내야 한다. 이를 언어로 표현하는 방식 중 하나가 promela이다.

promela는 model checker 중 하나인 SPIN의 input language이다.

SPIN의 동작 방식은 다음와 같다.

사용자가 promela program을 작성한다.
- promela program은 channel system을 매핑한 것으로써, 적당한 syntax를 사용해 이를 쓸 수 있다.
SPIN은 사용자가 작성한 promela program을 channel system으로 바꾼다.
변환된 channel system을 transition system으로 바꾼다.
transition system에서 model checking을 진행한다.

nanopromela program $\overline{P}$ = [ P$_1$ | P$_2$ | ... | P$_n$ ]일 때, 각 P$_i$를 process라고 한다. process의 동작을 의미하는 statement의 syntax는 다음과 같다.

nanopromela에서 변수 선언, dynamic process 생성 등 detail 등을 사용하지 않는다.

stmt ::=

skip | x := expr | c?x | c!expr |
stmt$_1$; stmt$_2$ | atomic{assignments} |
if :: g$_1$ $\Rightarrow$ stmt$_1$ ... :: g$_n$ $\Rightarrow$ stmt$_n$ fi |
do :: g$_1$ $\Rightarrow$ stmt$_1$ ... :: g$_n$ $\Rightarrow$ stmt$_n$ od |

여기서 사용하는 syntax들은 channel system에서 사용하는 것과 동일하므로 쉽게 이해할 수 있을 것이다.

skip : atomic command를 의미한다.
x := expr : assignment
c?x, c!expr : channel에 push/pop
atomic{} : atomic operations
if : guard 조건을 만족할 때 branch
- 만약 else option이 없는 경우는 stmt를 skip으로 두면 if branch를 탈출한다.
do : guard 조건을 만족할 때 loop
- n개의 guard 중 1개 이상이 true가 될 때까지 loop를 돌린다.

유의점

1. test-and-set semantics

promela에서 선언한 [guard에 대한 evaluation + enabled guard의 선택 + 선택된 guard에 해당하는 첫 번째 atomic statement의 실행] 이 3가지 동작은 program graph에서 하나의 edge가 된다.

예를 들어 guard가 x>=0, x<=0이 있는 상황이라면 어떤 statement를 실행해야 할까? 이를 위해 test-and-set semantics를 사용한다. x의 값을 보고, enabled guard를 non-determinsitic하게 고르고, 해당 guard의 첫 번째 atomic statement를 실행한다. 이 모든 것이 한 edge가 된다.

2. blocking semantics

if문에서 guard가 만족되지 않는 경우, 빠져나가지 않고 만족될 때까지 기다린다! blocking semantics는 if문에서만 적용된다.

if x > 10 $\Rightarrow$ atomic{...}
x < 4 $\Rightarrow$ atomic{...}
fi

직관적이지 않기 때문에 nanopromela 예시를 들어 보자.

x가 7이라고 하자. 그러면 if문의 모든 guard가 false이기 때문에 if가 시작되지 직전 위치에서 기다린다. x가 shared variable이라고 하면, 다른 process에서 값을 바꿀 수 있고, 그러면 guard가 true로 되기 때문이다. 원칙적으로는 무한히 기다릴 수 있다.

정리

interleaving `|||`
- shared variable과 independent한 transition system의 경우 transition system의 interleaving TS$_1$ ||| TS$_2$로 표현한다.
- shared variable를 사용하는 경우 program graph의 interleaving P$_1$ ||| P$_2$를 transition system으로 변환한다.
synchronous message passing (handshaking) ||$_H$
- H에 속해있는 action만 synchronization이 일어날 때 TS$_1$ ||$_H$ TS$_2$로 표기한다.
channel system
- interleaving, shared variable, message passing 3가지가 모두 속해 있다.
- buffer size에 따라 synchronous message passing인지 asynchronous message passing인지가 결정된다.
- [ P$_1$ | P$_2$ | ... | P$_n$ ]로 표기하며 이 결과를 transition system으로 변환한다.

23.09.12. 풀었던 문제들

hyelie — Tue, 12 Sep 2023 21:02:14 +0900

Leetcode 1647. Minimum Deletions to Make Character Frequencies Unique, 30분

첫 접근

그냥 주는 대로 풀었다.

일단 각 char이 몇 번 나오는지 알아둬야 하니까 map같은 걸 써야 하는데, 이 문제의 경우 알파벳 소문자만 나오기 때문에 vector(26, 0)을 map처럼 쓰면 된다.

이후, 내림차순으로 정렬한다.

정렬한 후, 만약 겹치는 값이 있는 경우에는 해당 값을 1 줄이고, 해당 문을 다시 반복한다. 이 접근이 문제될 때는, 2 2 2와 같은 예시를 보자. 2 2 2에서 index 1이 2 1 2로 바뀐다. index 1에서 같은 값의 비교는 앞의 값만 보기 때문에 pass. index 2에서 앞의 값만 보기 때문에 pass한다. 문제가 생긴다!

때문에, 바로 앞의 index와 값이 같은지 + 앞의 값보다 값이 크면 1 줄이는 식으로 구현했다.

// Runtime 42 ms Beats 93.66%
// Memory 17.3 MB Beats 77.52%

class Solution {
public:
    int minDeletions(string s) {
        vector<int> f(26, 0); // f[i] : frequency of ith alphabet
        for(char c : s){
            f[c - 'a']++;
        }
        sort(f.begin(), f.end(), greater<int>());

        // f가 겹치는 것들이 있는 경우, 몇 개의 letter를 삭제해 겹치지 않게 바꿔야 함.
        // 내린 값이 겹치지 않게 설정해야 함. 그 중 제일 큰 값으로.
        int answer = 0;
        for(int i = 1; i<f.size(); i++){
            // 만약 겹치는 경우! i번째 char를 줄여야 함.
            if(f[i] == 0) continue;

            if(f[i-1] <= f[i]){
                f[i]--;
                answer++;
                i--;
            }
        }

        // print(f);

        return answer;
    }
};

시간복잡도

frequency를 세는 데 O(n)

정렬에 O(nlogn)

이후 메인 로직인 for문에서 어떻게 시간이 걸릴 지 모르겠다. 그러나 worst case는 [모든 숫자가 똑같을 때] worst case이며, 이 경우에 25 * 26 / 2만큼 실행된다. (앞의 것과 비교하고, 만약 더 크면 1을 내리기 때문)

그러나 이렇게 해도, 입력 문자가 26이기 때문에 충분히 풀린다.

두 번째 접근

for loop로 돌리니까 뭔가 직관성이 떨어진다. for loop 대신 pq를 쓰는 방법도 있다.

세 번째 로직만 조금 바뀌는데, pq의 top t를 뽑고, 이후의 pq.top()과 같은 경우는 pq.top()을 줄여야 한다. t를 1 줄이고 pq에 다시 넣는다. 만약 t와 pq.top()이 다른 경우에는 그냥 빼버리면 된다.

이 경우를 pq.size() == 1이 될 때까지 반복한다. pq.size()가 1인 경우는 무조건 identical한 값이 튀어나오기 때문이다.

// Runtime 49 ms Beats 79.99%
// Memory 17.3 MB Beats 58%

class Solution {
public:
    int minDeletions(string s) {
        vector<int> f(26, 0); // f[i] : frequency of ith alphabet
        for(char c : s){
            f[c - 'a']++;
        }

        priority_queue<int, vector<int>, less<int>> pq;

        for(int e : f){
            pq.push(e);
        }

        int answer = 0;
        while(!pq.empty()){
            int t = pq.top(); pq.pop();
            if(t == 0 || pq.size() == 0) break;
            if(t > 0 && pq.top() == t){
                answer++;
                pq.push(t-1);
            }
        }

        return answer;
    }
};

시간복잡도

pq를 써서 시간복잡도가 개선될 것 같지만, -- 연산의 회수는 동일하다. 그러나 pq의 push, pop 연산에서 logn을 추가로 소모하기 때문에 더 많은 시간이 걸린다! 아마 26log26쯤 더 걸리지 않을까 싶다.

Programmers Lv. 3 최고의 집합, 4분

중앙값을 택하는 게 곱이 제일 커진다. 뭐... 고등학교 수학을 배운 이과라면 다들 아는 내용.

vector<int> solution(int n, int s) {
    // 만들 수 없는 경우 : 
    if(n > s) return {-1};
    
    // 중앙값일 때 곱이 최대
    int q = s/n;
    vector<int> answer(n, q);
    int diff = s % n;
    // answer 배열의 뒤에서부터 diff개에 1씩 더해주면 됨
    for(int i = n-1, cnt = 1; cnt <= diff; i--, cnt++){
        answer[i]++;
    }
    
    return answer;
}

시간복잡도

n size 배열을 만들고 s%n만큼 순회한다. 배열 만들 때 O(n), 순회할 때 worst O(n)이다.

Programmers Lv. 3 야근 지수, 3분 30초

pq를 사용할 줄 안다면 바로 풀리는 문제. n이 1,000,000으로 1백만인데, O(nlogn) 알고리즘은 5백만까지 커버 가능하다!

2$^{10}$이 1000정도로 잡으면, 2$^{20}$이 1,000,000이다. 1,000,000에 20을 곱해봤자 2천만 정도로, 백만 정도는 O(nlogn)으로 풀린다!

앞 문제와 마찬가지로, 제일 큰 값을 1 줄이는 게 야근 지수를 제일 많이 줄일 수 있다. 이를 위해 제일 큰 값을 항상 뽑아와야 하는데, 그러면 pq가 생각난다!

typedef long long ll;

long long solution(int n, vector<int> works) {
    priority_queue<int, vector<int>, less<int>> pq;
    for(int work : works) pq.push(work);
    
    while(1){
        if(n == 0 || pq.empty()) break;
        int t = pq.top(); pq.pop();
        if(t != 1) pq.push(t-1);
        n--;
    }
    
    long long answer = 0;
    while(!pq.empty()){
        int t = pq.top(); pq.pop();
        answer += (ll) t * (ll) t;
    }
    return answer;
}

시간복잡도

pq의 각 연산은 works size 5만을 w로 두면 O(logw)이다. n은 operation 개수이므로, O(nlogw)이다.

Programmers Lv. 3 단어 변환, 12분 30초

`최단 거리` -> BFS를 쓰면 된다. 단, 이 문제는 일반적으로 BFS하던 board가 아니라 string으로 하기 때문에 string에 대해 visited를 처리해야 하고, string에 대해 neighbor를 얻어와야 한다. 이건 구현 문제고.. 이것만 잘 처리하면 별 것 없다.

int의 경우에는 vector로 선언해서 쉽게 풀 수 있지만 string의 경우에는 어렵다. 그렇다고 string to integer mapper를 넣기에는 모든 string을 쓰는 부분에 mapper를 call해야 하기 때문에 너무 번거롭다고 생각해 그냥 string을 쓰기로 했다. 이를 위해 map을 사용했는데, map을 쓰면 string을 key로 넣어 visited 여부와 neighbor vector를 쉽게 얻어올 수 있기 때문이었다.

이 부분만 끝내면 뭐.. 나머지는 BFS다.

int len;
map<string, bool> visited; // visited[i] : string i를 사용했는지 여부
map<string, vector<string>> nextMap; // nextMap[i] : i에서 바꿀 수 있는 string vector

struct info{
    string s;
    int dist;  
};

// string a를 b로 바꿀 수 있는지 여부
bool canTransfer(string &a, string &b){
    int cnt = 0;
    for(int i = 0; i < len; i++){
        if(a[i] != b[i]) cnt++;
        if(cnt >= 2) break;
    }
    return cnt == 1;
}

int solution(string begin, string target, vector<string> words) {
    // init
    len = begin.length();
    words.push_back(begin);
    for(string word : words){
        visited[word] = false;
    }
    int wsize = words.size();
    for(int i = 0; i<wsize; i++){
        for(int j = i+1; j<wsize; j++){
            if(canTransfer(words[i], words[j])){
                nextMap[words[i]].push_back(words[j]);
                nextMap[words[j]].push_back(words[i]);
            }
        }
    }
    
    // solve : BFS
    queue<info> q;
    info i; i.s = begin; i.dist = 0;
    q.push(i);
    visited[begin] = true;
    while(!q.empty()){
        string cur_s = q.front().s;
        int cur_d = q.front().dist;
        q.pop();
        if(cur_s == target) return cur_d;
        
        for(string next_s : nextMap[cur_s]){
            if(!visited[next_s]){
                info i; i.s = next_s; i.dist = cur_d + 1;
                q.push(i);
                visited[next_s] = true;
            }
        }
    }
    
    return 0;
}

시간복잡도

BFS 시간복잡도는 O(V+E). V = 50이고, worst case 각 vertex당 E = 50이 될 수 있다. 그래봤자 2500이므로 시간 내에 충분히 끝낼 수 있다.

Programmers Lv. 3 등굣길, 8분 30초

길찾기 DP 문제. dp[i][j] = dp[i-1][j] + dp[i][j-1]이라는 bottom-up DP로 쉽게 풀 수 있다. 단, 물웅덩이가 있는 곳은 계산하지 않아야 하므로(0으로 두어야 하므로) 이 부분은 set으로 빨리 처리했다. 물론 초기화도 해 주고.

typedef pair<int, int> pii;
int MOD = 1000000007;

int solution(int m, int n, vector<vector<int>> puddles) {
    vector<vector<int>> dp(m, vector<int>(n, 0));
    
    set<pii> puddle_set;
    for(vector<int> puddle : puddles){
        puddle_set.insert({puddle[0]-1, puddle[1]-1});
    }
    
    // init
    for(int r = 0; r<m; r++){
        if(puddle_set.find({r, 0}) != puddle_set.end()) break;
        dp[r][0] = 1;
    }
    for(int c = 0; c<n; c++){
        if(puddle_set.find({0, c}) != puddle_set.end()) break;
        dp[0][c] = 1;
    }
    
    // dp
    for(int r = 1; r<m; r++){
        for(int c = 1; c<n; c++){
            if(puddle_set.find({r, c}) != puddle_set.end()) continue;
            dp[r][c] = (dp[r-1][c] % MOD + dp[r][c-1] % MOD) % MOD;
        }
    }
    
    return dp[m-1][n-1];
}

후기

뭔가 생각과 타이핑의 속도가 엄청나게 빨라진 것 같다. 그만큼 안 덤벙거리게 잘 해야 겠다. 특히 마지막 문제도.. 로직은 다 맞았는데 % 연산을 까먹었다. 구현 자체는 안 덤벙대서 다행이다. 근데 이건 머릿속에 좌르르 흘러가는 느낌이 든다.!!! 물론 복잡한 문제도 아니고... 구현이 복잡한 문제를 30분컷 내야 하는데. 끄악

23.09.11. 풀었던 문제들

hyelie — Mon, 11 Sep 2023 22:17:22 +0900

Leetcode 1282. Group the People Given the Group Size They Belong To, 30분

문제 자체는 빨리 풀었는데, 여러 개선을 한다고 시간이 좀 걸렸다.

첫 번째 접근

최대한 생각나는 대로 구현했다.

groupMap은 특정 size를 가지고 있는 모든 group의 정보를 가지고 있다. 때문에 구현은 단순하다.

입력으로 받은 size의 group이 없는 경우 생성한다.
입력으로 받은 size의 group이 있는 경우,
1. 해당 group이 존재하지만 아직 size만큼 차지 못하는 경우 - 해당 group에 현재 인원을 넣어준다.
2. 해당 group이 있고, size만큼 찬 경우 - 새로운 group을 넣어준다.

이렇게 푸니까 runtime 22ms, beats 8.5%가 나왔다.

시간복잡도로 따지면, 입력 size를 n이라고 하면 O(nlogn)이다. 시간이 상대적으로 느리게 나온 이유는 vector를 계속 추가적으로 할당해서 그런 것 같다.

// Runtime 22 ms Beats 8.50% 
// Memory 15.3 MB Beats 5.29%

class Solution {
public:
    map<int, vector<vector<int>>> groupMap; // groupMap[i] : i명짜리 group
    // i번째 사람을 groupSize 크기의 group에 넣는 함수
    void insertIntoGroup(int i, int groupSize){
        // 아직 해당 size의 group이 없는 경우 - 생성
        if(groupMap.find(groupSize) == groupMap.end()){
            vector<int> newGroup(1, i);
            groupMap[groupSize].push_back(newGroup);
            return;
        }

        // 해당 size의 group이 있는 경우
        // 1. group이 있지만 아직 그만큼 차지 못한 경우
        // 2. 기존에 존재하는 group size가 groupSize여서 새로운 group을 만들어야 하는 경우
        vector<int> &lastGroup = groupMap[groupSize].back();
        
        // case 2
        if(lastGroup.size() == groupSize){
            vector<int> newGroup(1, i);
            groupMap[groupSize].push_back(newGroup);
        }
        // case 1
        else{
            lastGroup.push_back(i);
            // groupMap[groupSize].back().push_back(i);
        }
        
    }
    vector<vector<int>> groupThePeople(vector<int>& groupSizes) {
        int len = groupSizes.size();
        for(int i = 0; i<len; i++){
            insertIntoGroup(i, groupSizes[i]);
        }

        vector<vector<int>> answer;
        for(auto &[groupSize, groups] : groupMap){
            for(vector<int> group : groups){
                answer.push_back(group);
            }
        }
        return answer;
    }
};

두 번째 접근

첫 번째 버전을 조금 개선했다. answer vector를 미리 선언해 두고, insertIntoGroup() 함수에서 groupMap을 다루는데, 만약 group이 가득차게 되면 answer에 넣는 방식으로 구현했다. 이렇게 하니 runtime 12ms가 나왔다.

시간복잡도 자체는 동일하다! 다만 2차원 vector를 1차원으로 줄였고 같은 vector에 계속 접근해 cache쪽에서 성능이 향상된 것이 아닐까 싶다.

// Runtime 12 ms Beats50.27% 
// Memory 13.4 MB Beats 37.1%

class Solution {
public:
    map<int, vector<int>> groupMap; // groupMap[i] : i size짜리 group
    vector<vector<int>> answer;
    // i번째 사람을 groupSize 크기의 group에 넣는 함수
    void insertIntoGroup(int i, int groupSize){
        // 아직 해당 size의 group이 없는 경우 - 생성
        if(groupMap.find(groupSize) == groupMap.end()){
            vector<int> newGroup(0);
            groupMap[groupSize] = newGroup;
        }

        // 해당 size의 group이 있는 경우 - 거기다가 넣음.
        vector<int> &group = groupMap[groupSize]; // groupSize짜리 group
        group.push_back(i);

        if(groupSize == group.size()){
            answer.push_back(group);
            vector<int> newGroup(0);
            group = newGroup;
        }
    }
    vector<vector<int>> groupThePeople(vector<int>& groupSizes) {
        int len = groupSizes.size();
        for(int i = 0; i<len; i++){
            insertIntoGroup(i, groupSizes[i]);
        }
        return answer;
    }
};

세 번째 접근

두 번째 접근에서 아이디어를 얻어, 어차피 입력이 정확하다는 것은 보장되므로 groupMap에 모두 다 넣고, 해당 group의 size만큼 파싱하는 방법이다. 이 경우 3ms로 매우 실행시간이 빨라졌는데, 두 번째 접근보다 cache 접근 쪽에서 더 향상된 것이 아닐까 싶다.

// Runtime 3 ms Beats 98.93%
// Memory 13.9 MB Beats 17%

class Solution {
public:
    map<int, vector<int>> groupMap;
    vector<vector<int>> answer;
    vector<vector<int>> groupThePeople(vector<int>& groupSizes) {
        int len = groupSizes.size();
        for(int i = 0; i<len; i++){
            groupMap[groupSizes[i]].push_back(i);
        }

        for(auto &[size, group] : groupMap){
            vector<int> temp;
            int cnt = 0;
            for(int i : group){
                temp.push_back(i);
                cnt++;

                if(cnt == size){
                    answer.push_back(temp);
                    cnt = 0;
                    temp.clear();
                }
            }
        }

        return answer;
    }
};

시간복잡도

입력 size가 n일 때, for loop에 O(n)이고, insertIntoGroupMap()에서 O(logn)이 필요하므로 O(nlogn)이다. 세 번째 접근도 동일한 과정을 거치므로 O(nlogn)이다.

Programmers Lv. 2 Jadencase 문자열 만들기, 12분

코테 푸는 느낌 내려고 2시간 내에 lv2 문제 1개(1번 느낌으로) + lv3 문제 3-4개 푸려고 한다. 나중에 가면 lv3가 장난 아니게 어려워지니까 천천히 폼 올려서 감당해 보자.

첫 접근

일단 처음에는 딱 보자마자 생각난, delimiter로 string parsing 후 upper/lower 쓰는 방식을 택했다. string parsing은 해당 포스팅 참조.

단, 이렇게 풀었더니 하나가 틀렸다. 뭐지 뭐지 고민하다가 다음 문제 풀고 다시 돌아왔는데, 이렇게 풀면 맨 마지막에 있는 공백을 처리하지 못한다. 때문에 예외 케이스로 하나 추가해 줬다.

#include <string>
#include <iostream>
#include <vector>
#include <sstream>

using namespace std;

vector<string> split(string s){
    vector<string> result;
    istringstream iss(s);
    string buffer;
    
    while(getline(iss, buffer, ' ')){
        result.push_back(buffer);
    }
    
    return result;
}

string tolower(string s){
    for(char &c : s){
        if(isupper(c)) c = tolower(c);
    }
    return s;
}

string toJadenCase(string s){
    if(islower(s[0])){
        s[0] = toupper(s[0]);
    }
    return s;
}

string solution(string s) {
    vector<string> parsed_string = split(s);
    for(string &s : parsed_string){
        s = tolower(s);
        s = toJadenCase(s);
    }
    
    string answer = "";
    int len = parsed_string.size();
    for(int i = 0; i<len-1; i++){
        answer += parsed_string[i] + " ";
    }
    answer += parsed_string[len-1];
    if(s[s.length()-1] == ' ') answer += " ";
    
    return answer;
}

두 번째 접근

그러나 이렇게 풀면 맘에 안들긴 하다. 그래서 다른 풀이를 생각해 냈다.

단어의 시작은 공백 뒤에 오기 때문에, 뒤에서부터 검색한다. 만약 s[i]가 문자이고 s[i-1]이 공백이면 upper해주면 된다. 나머지는 모두 tolower() 하면 된다. 끝!

#include <string>
#include <iostream>
#include <vector>
#include <sstream>

using namespace std;

string solution(string s) {
    int len = s.length();
    for(int i = len-1; i>=1; i--){
        if(isupper(s[i])) s[i] = tolower(s[i]);
        if(s[i-1] == ' ') s[i] = toupper(s[i]);
    }
    if(islower(s[0])) s[0] = toupper(s[0]);
    return s;
}

시간복잡도

string s.length()를 n이라고 했을 때 처음부터 끝까지 순회만 하므로 O(n)

Programmers Lv. 3 정수 삼각형, 10분

간단한 DP 문제. 8분만에 풀고 넘겼고, 이후 제출 후 틀려서 다시 풀었다.

실수했던 점은, edge case는 처리 잘 했는데 일반 case를 처리할 때 for문의 제일 마지막 element가 돌지 않게 설정했음.

for(int i = 1; i<h-1; i++)로 풀었었다.
for(int i = 1; i<=h-1; i++)로 풀어야 한다.

#include <string>
#include <algorithm>
#include <vector>
#include <iostream>

using namespace std;

int solution(vector<vector<int>> triangle) {
    int n = triangle.size();
    vector<vector<int>> dp(n, vector<int>(n, 0));
    
    dp[0][0] = triangle[0][0];
    for(int h = 1; h<n; h++){ // height
        // 양쪽 끝 edge case 처리
        dp[h][0] = dp[h-1][0] + triangle[h][0];
        dp[h][h] = dp[h-1][h-1] + triangle[h][h];
        for(int i = 1; i<h; i++){ // 각 layer는 위에 2개 보고 큰 것으로 결정 가능
            dp[h][i] = max(dp[h-1][i], dp[h-1][i-1]) + triangle[h][i];
        }
    }
    
    return *max_element(dp[n-1].begin(), dp[n-1].end());
}

시간복잡도

n by n size를 모두 탐색하므로 O(n$^2$)

Programmers Lv. 3 이중우선순위큐, 12분

몇 가지를 알아둬야 한다.

일단 nlogn 알고리즘의 경우 5백만까지 커버할 수 있다.

문제 접근은, 최대/최소값 둘 다를 nlogn으로 처리해야 하기 때문에 tree 구조인 map, set을 고려했다. set의 경우 element가 중복되지 않기 때문에 multiset을 써야 한다는 것은 알았지만 STL 이름을 잊어서 map으로 풀었다.

#include <set>
#include <string>
#include <vector>
#include <map>
#include <sstream>
#include <iostream>

using namespace std;

map<int, int> m;

void insertIntoQueue(int n){
    m[n]++;
}

void removeMax(){
    int number = m.rbegin()->first, count = m.rbegin()->second;
    if(count == 1) m.erase(number);
    else m[number]--;
}

void removeMin(){
    int number = m.begin()->first, count = m.begin()->second;
    if(count == 1 || count == 0) m.erase(number);
    else m[number]--;
}
vector<int> solution(vector<string> arguments) {
    vector<int> answer;
    multiset<int> que;

    string sub;

    for(auto s : arguments) {
        sub =s.substr(0, 2);
        if(sub=="I ") que.insert(stoi(s.substr(2,s.length()-2))); 
        else if(s.substr(2,1)=="1"&&que.size()>0) { que.erase(--que.end()); }
        else if(que.size()>0) { que.erase(que.begin()); }
    }

    if(que.size()==0) { answer.push_back(0); answer.push_back(0); }
    else { 
       answer.push_back(*que.rbegin()); 
        answer.push_back(*que.begin());
    }

    return answer;
}

시간복잡도

한 operation에 O(logn)이고 operation이 n개이므로 O(nlogn)

후기

map iterator에 접근하는 방법. begin().first로 접근하는 게 아니라 begin()->first로 접근한다.
1. .first는 key, .second는 value
rbegin() - --end()라고 생각하면 된다. 제일 뒤에 있는 element.
istringstream으로 정해져 있는 input 받는 방법 - 기억해 두자.

Programmers Lv. 3 네트워크, 10분

BFS를 쓸 줄 알면 풀리는 간단한 문제. 뭐.. 딱히 설명할 것도 없다. indexing만 주의하면 된다.

#include <string>
#include <queue>
#include <vector>
#include <algorithm>

using namespace std;

int maxn;
vector<int> visited; // visited[i] : i번 computer 썼는지 여부
vector<vector<int>> connected; // connected[i][j] : i번과 j번이 연결되어 있으면 true, else false

// n번째 computer에서 BFS
void BFS(int n){
    queue<int> q;
    q.push(n);
    visited[n] = true;

    while(!q.empty()){
        int cur = q.front(); q.pop();
        visited[cur] = true;

        for(int next = 0; next<maxn; next++){
            if(!visited[next] && connected[cur][next]){
                q.push(next);
            }
        }
    }
}

int solution(int n, vector<vector<int>> computers) {
    vector<int> visited_init(n+1, false); 
    visited = visited_init;
    connected = computers;
    maxn = n;

    int answer= 0;
    for(int i =0; i<n; i++){
        if(!visited[i]){
            visited[i] = true;
            BFS(i);
            answer++;
        }
    }
    return answer;
}

시간복잡도

BFS 시간복잡도는 O(V+E)

[Model Checking] Transition System과 Program Graph

hyelie — Mon, 11 Sep 2023 03:12:33 +0900

이 글은 RWTH AACHEN 대학교 Joost-Pieter Katoen 교수님의 2018년 1학기 Introduction to Model Checking 강의와 Principles of Model Checking을 기반으로 재구성한 것입니다.

이 글에서는 model checking에서 사용하는 transition system이 대체 뭔지, 그리고 우리가 사용하는 일반적인 프로그램을 transition system으로 바꾸는 방법을 살펴본다.

Transition System

transition system은 directed graph로 나타낸다. 이 때 graph의 node는 state를, edge는 transition을 의미한다.

Definition. Transition System

transition system TS는 (S, Act, → I, AP, L)의 tuple로 표기한다.

`S`는 state의 집합
`Act`는 action의 집합
`→`는 S × Act × S의 부분집합이며, transition relation을 의미한다.
- 편의상 (s, $\alpha$, s') ∈ → 대신
- s$\overset{\alpha}{\rightarrow}$s'으로 표기한다.
  - 이 때 s ∈ S, s' ∈ S이고 $\alpha$ ∈ Act이다.
  - state s에서 action $\alpha$를 통해 s'로 transit된다고 이해하면 될 것 같다.
`S$_0$` ⊆ S이며, 초기 state를 의미한다.
- S$_0$의 원소가 하나인 경우는 거기서 시작하지만, 2개 이상인 경우에는 non-deterministic하게 시작 위치가 결정된다. 정말 간단하게 말하자면 random하게 고른다는 뜻이다.
`AP`는 Atomic Propisition들의 집합으로, state의 property를 의미한다.
`L`은 S → $2^{\text{AP}}$, labeling function을 의미한다. 모든 state을 AP의 power set에 매핑하는 것이다.
- state와 property의 매핑이라고 이해하면 된다.
- L(s) = ap라고 하면, state s의 property가 ap라는 뜻이다.

이 때 TS는 S, Act, AP가 finite면 finite이다.

Transition System 예시

이런 transition system이 있을 때, 다음과 같이 표기할 수 있다.

S = {pay, select, soda, beer}
Act = {get_soda, get_beer, insert_coin, $\tau$}
→는 위 그림의 모든 edge.
S$_0$ = {pay}
AP와 L은 property를 어떻게 설정하냐에 따라 달라진다.
- "vending machine이 코인을 넣은 후에만 음료를 준다"라는 property를 택한다고 하자.
- 그러면 AP = {pay, drink}로 설정할 수 있고, 이 경우 L(pay) = {pay}, L(soda) = L(beer) = {paid, drink}, L(select) = {paid}로 둘 수 있다.

Definition. Predecessors and Successors

직역하면 전임자와 후임자이다. s ∈ S 그리고 $\alpha$ ∈ Act일 때,

s의 $\alpha$-successors는 다음와 같이 정의한다.

successors of s

어떤 state s에서 action alpha를 통해 s'로 갈 수 있을 때, Post(s, $\alpha$) = s'들의 집합이다. Post(s)는 모든 $\alpha$에 대해 Post(s, $\alpha$)의 합집합이다.

graph식 언어로 표기하면, Post(s, $\alpha$)는 state s에서 edge $\alpha$를 통해 갈 수 있는 neighbor들은, Post(s)는 $state s의 모든 neighbor를 말하는 것이다. 이렇게 생각하면 predecessors도 바로 이해할 수 있다.

s의 $\alpha$-predecessors는 다음과 같이 정의한다.

predecessors of s

어떤 state s'에서 alpha를 통해 s로 갈 수 있을 때 Pre(s', $\alpha$) = s일 때 s'의 집합이다. Pre(s)는 모든 $\alpha$에 대해 Pre(s, $\alpha$)의 합집합이다.

Definition. Terminal State

transition system의 state s에 대해 Post(s) = $\phi$일 때 s를 terminal state이라고 한다.

graph식 언어로 표기하자면 outgoing edge가 없는 node를 terminal로 말한다는 것이다.

parallel system을 모델링할 때 terminal state는 바람직하지 않은 것으로 간주한다.

Definition. Execution Fragment

finite exeucution fragment는 다음과 같이 정의한다. 이 때 n $\ge$ 0일 때 n을 execution fragment length라고 한다.

finite execution fragment 정의

infinite execution fragment는 다음과 같이 정의한다.

infinite execution fragment 정의

infinite execution fragment의 odd-length prefix는 finite execution fragment이다. `??? 여기 잘 모르겠음`

graph식 언어로 표기하자면 path라고 생각하면 된다.

Definition. Maximal & Initial Execution Fragment

finite execution fragment가 terminal state로 종료되거나, infinite execution fragment인 경우 이들을 maximal execution fragment라고 한다.

execution fragment가 initial state에서 시작하는 경우 initial execution fragment라고 한다.

Definition. Transition System Exeuction

transition system TS의 execution은 initial & maximal execution fragment다. 즉, initial state에서 시작해야 하며, terminal state로 종료되거나 또는 infinite execution fragment여야 한다.

Definition. Reachable States

transition system TS의 execution이 있을 때, 다음과 같은 initial, finite execution fragment에 대해 아래 조건을 만족하는 s를 reachable이라고 한다.

transition system reachable 정의

앞서 설명했듯 TS의 execution은 initial & maximal execution fragment이므로 s$_0$ ∈ S$_0$이다.

graph식으로 설명하면, initial node에서 어떤 edge를 거쳐 해당 node까지 도달할 수 있다면 해당 node를 reachable이라고 한다.

Reach(TS)는 TS의 모든 reachable state를 의미한다.

여기까지 Transition System에 대해 살펴봤다. model checking에서 우리가 하고자 하는 것은 어떤 system을 modeling한 transition system TS와, requirement를 model checker에 넣어 OK인지 NO인지 얻어내는 것이다. 지금까지 TS를 살펴봤다.

HW/SW modeling

46p 참고.

HW modeling은 transition system을 modeling하는 것과 같다. state를 정의하고, initial state를 정의하고, state에 따라 next input으로 인해 다음 state가 정해지므로, 이를 기반으로 →를 얻을 수 있다. 이후 AP와 L은 어떻게 설정하느냐에 따라 달라진다.

Data Dependent System

Data Dependent System은 conditional branch에 의존하는 system을 의미한다. Data Dependent System을 transition system으로 모델링할 때는 conditional transition을 사용하며, condition으로 label을 지정하는 resulting graph를 사용한다.

단편적으로만 살펴보면, conditional branch로 나타낸 program graph는 다음과 같은 과정을 통해 transition system으로 변환할 수 있다.

이를 위해 첫째로 program counter에 대해 알아야 하고, 둘째로 관련된 모든 데이터(모든 변수들)를 알아야 한다. 이 2가지를 합쳐 transition system의 state로 표현하고, 조건에 따라 다음 state로 transit하게 만들면 된다.
program counter의 각 assignment에 해당하는 명령어를 action으로 만든다. 그러면 transition relation이 만들어진다.

일단은 Data Dependent System을 Program Graph로 나타내고, 이를 Transition System으로 변환하는 방법을 살펴보겠다. 그 전에 program graph에서 사용하는 몇 가지 개념부터 살펴보겠다.

Definition. Evaluation function

먼저 typed variable는 variable x와 x의 domain Dom(x)로 이루어진다.

boolean의 경우 Dom(x) = {0, 1}
integer의 경우 Dom(x) = N(정수)
와 같이, domain은 해당 변수가 가질 수 있는 값들의 집합이다.

Dom(x)가 0, 1인 boolean variable인 경우 Value는 0, 또는 1을 가지고 있게 된다.

이 변수를 formalize하기 위해 evaluation function $\eta$를 두어 변수를 evaluate한다.

코딩하면서 변수에 값을 넣는다는 개념이 아니라, 변수에 있는 값을 꺼내오는 함수를 만든 것이라고 생각하면 된다.

Var를 typed variable들의 집합, Values를 $\bigcup_{x \in Var}^{} Dom(x)$(Var에 있는 모든 변수들의 domain의 합집합)이라고 할 때, evaluation function $\eta$는 Var에서 Values를 매핑하는 함수이다. 이 때 $\eta$는 type consistent하기 때문에 해당 변수의 type을 유지한 채로 값을 꺼내온다. 즉, x ∈ Var인 x에 대해 $\eta$(x) ∈ Dom(x)가 된다는 것이다.

Eval(Var)는 Var의 evaluation function들의 집합이라 정의한다.

Definition. Conditions of Typed Variables - Guard

앞서 Var를 typed variable들의 집합이라고 했다. Cond(Var)는 Var에 있는 변수들의 boolean condition을 의미한다. 이를 guard라고 부르기도 한다.

¬x ∧ y < z와 같은 예시들이 있다.

Definition. Satisfaction Relation

앞에서 Var, Eval(Var), Cond(Var)를 정의했다. 이들을 사용해서 조건을 만족하는지 여부를 수식으로 표현할 수 있다.

Eval(Var)가 Cond(Var)를 만족하는 경우 Eval(Var) $\models$ Cond(Var)로 표기한다.
Eval(Var)가 Cond(Var)를 만족하지 않는 경우 Eval(Var) $\not\models$ Cond(Var)로 표기한다.

아래와 같은 예시들이 있다.
|x = 0, y = 3, z = 6| $\models$ ¬x ∧ y < z
|x = 0, y = 3, z = 6| $\not\models$ x ∨ y = z

Definition. Effect function

effect function은 다음 매핑을 의미한다: Effect : Act × Eval(Var) → Eval(Var)

앞서 설명했든 모든 변수들에 있는 값들은 변수와 값을 매핑하는 함수인 Eval()에 의해 결정된다. 즉, 위 수식이 의미하는 것은 기존 변수들의 값에 Act(실행해야 하는 코드, assignment에 해당하는 코드)으로 계산한 새로운 변수들의 값이다.

$\alpha$가 action(assignment에 해당하는 코드), $\eta$가 evaluation function일 때 표기는 Effect($\alpha$, $\eta$)와 같이 한다.

$\alpha$가 x = 2x + y;인 경우
Effect($alpha$, [x = 1, y = 3]) = [x = 5, y = 3]

$\alpha$가 x = 2x + y; y = 1-x인 경우
Effect($alpha$, [x = 1, y = 3]) = [x = 5, y = -4]

Definition. Program Graph

program graph PG는 (Loc, Act, Effect, →, Loc$_0$, g$_0$)으로 표기한다.

`Loc`은 location의 (finite) 집합. 각 program graph의 node라고 생각하면 된다.
- program의 line은 finite하기 때문이다.
`Act`는 action의 집합
`Effect`는 Act × Eval(Var) → Eval(val)이며, 현재 값으로 다음 값을 계산하는 함수이다.
`→`는 Loc × Cond(Var) × Act × Loc이며, conditional transition relation을 의미한다.
- 편의상 → 대신 $\text{l} \overset{g:\alpha}{\rightarrow} \text{l'}$으로 표기하며, l ∈ Loc, l' ∈ Loc, g ∈ Cond(Var), $\alpha$ ∈ Act이다.
- (l, g, $\alpha$, l')으로 표기하기도 한다.
- location l에서 g를 만족할 때 $\alpha$를 수행해 l'로 가는 transition을 의미한다.
`Loc$_0$` ⊆ Loc은 initial location을 의미한다.
`g$_0$` ∈ Cond(Var)는 initial condition을 의미한다.

Program Graph → Transition System으로 변환

Var을 사용하는 Program Graph의 동작은 아래와 같은 로직을 따라 Transition System Sementics로 바꿀 수 있다.

Program Graph to Transition System

state는 2가지를 포함한다: program counter(location)과 variable evaluation이 그것이다. <l, $\eta$>로 표현하며 l은 location을, $\eta$는 variable을 값으로 매핑하는 함수인 variable evaluation function을 의미한다.
- state는 location과 evaluation의 쌍으로 이뤄져 있다!
- 때문에 S = Loc × Eval(Var)이다. 이 중 도달 불가능한 state도 있겠지만 가능한 모든 경우를 취한다.
S$_0$는 {<l, $\eta$> : l ∈ Loc$_0$, $\eta \models g_0$}로 포현한다.
- 초기 location 중 가능한 모든 값과, g$_0$(초기 Cond(Var)) 중 가능한 모든 값들의 cartesian production이다.
→ (transition relation)
- 분모의 좌항은 Program Graph의 →에 해당하는 항으로 conditional transition relation을 의미한다. 여기에서 g를 만족하는 $\eta$만 이 conditional transition을 사용할 수 있기 때문에 g와 and 연산을 취한다.
  - 즉, g를 만족하는 변수값들만 해당 conditional transition relation을 탈 수 있다는 말이다.
- 분자 부분은 한 state <l, $\eta$>에서 action $\alpha$를 사용해 <l', Effect($\alpha, \eta$)>로 간다는 것을 의미한다.
- 이 분수가 의미하는 것은, [분자 부분의 조건이 만족하면 분모 부분의 조건도 만족한다]는 것이다.
- 이 때 Transition System의 transition relation은 해당 분수식, 즉 다음 식을 만족하는 제일 작은 relation이다. - if $\text{l} \overset{g:\alpha}{\rightarrow} \text{l;}$ ∧ $\eta \models$ g then <l, $\eta$> $\overset{\alpha}{\rightarrow}$ <l', Effect($\alpha, \eta$)>
AP는 Loc ∪ Cond(Var)이다.
labeling function은 location l과모든 Cond(Var)를 만족하는 현재의 evaluation $\eta$들의 합집합이다.

위 방법을 사용해 모든 Program Graph를 Transition System으로 바꿀 수 있다. 이 때 evaluation function에서 정수와 같은 무한한 집합을 사용하기 때문에 - Eval(Var)가 무한하기 때문에 state set S도 무한하다. 즉 이렇게 변환한 transition system은 infinite state를 가진다.

23.09.10. 풀었던 문제들

hyelie — Sun, 10 Sep 2023 15:45:19 +0900

오늘은 프로그래머스 데브코스 PCCP를 풀었다.

총 4문제였는데,

1번, 2번, 3번을 풀었다.

4번은 시간이 없더라. 구현이 너무 복잡했다.

4번 문제를 손을 대야 lv4를 받고, 올솔해야 lv5를 받는다... 음... lv5는 기대 안했지만, lv4는 받을 줄 알았는데. 아쉽다.

23.09.09. 풀었던 문제들

hyelie — Sat, 9 Sep 2023 22:18:07 +0900

Programmers PCCP 모의고사 #1 외톨이 알파벳, 5분

프로그래머스 짝지어 제거하기를 풀어봤다면 바로 이어져 나오는 중복 char를 쉽게 줄일 수 있다. stack을 쓰든, string의 뒤에 중복을 빼고 붙여넣든. 이 방법을 사용하면 중복을 제거할 수 있고, 그러면 map으로 count만 하면 된다. 간단한 손풀기 문제.

#include <string>
#include <vector>
#include <map>
#include <algorithm>
#include <stack>

using namespace std;

string solution(string str) {
    stack<char> stk;
    for(char c : str){
        if(!stk.empty() && stk.top() == c) continue;
        stk.push(c);
    }
    
    map<char, int> m;
    while(!stk.empty()){
        m[stk.top()]++;
        stk.pop();
    }
    
    string answer = "";
    for(auto &[key, value] : m) {
        if(value > 1) answer += key;
    }
    sort(answer.begin(), answer.end(), less<char>());
    
    return answer == "" ? "N" : answer;
}

시간복잡도

string 중복 제거에 O(n), map에 넣는 데 O(n)이 걸린다.

Programmers PCCP 모의고사 #1 체육대회, 18분

처음에는 이걸 어떻게 시간 내에 풀지..? 하고 나중에 풀었었는데. 그냥 단순한 순열 문제다! 순열은 뭐.. 예전에 포스팅했었고 별로 어렵지 않게 DFS로 코드를 짤 수 있었다.

문제 조건은 10이므로 10!, 약 3백만으로 넉넉하게 풀 수 있다.

#include <string>
#include <vector>
#include <algorithm>
#include <iostream>

using namespace std;

// stat[i][j] : i번째 학생이 종목 j의 능력치
// vertex가 
/*
DP vs graph vs BF
앞 단에서 최대값을 택한다고, 전체가 최대가 되는 게 아님. -> BF 써야 하긴 하는데.
worst 10^10
*/

// 일단 DFS
int answer = -1e9;
vector<vector<int>> stats;
vector<bool> isSelected; // isSelected[i] : i번째 학생을 골랐는지 여부
int student_num, event_num;
void DFS(int cur_d, int max_d, int result){
    if(cur_d == max_d){
        answer = max(answer, result);
        return;
    }
    
    for(int i = 0; i<student_num; i++){
        if(!isSelected[i]){
            isSelected[i] = true;
            DFS(cur_d + 1, max_d, result + stats[i][cur_d]);
            isSelected[i] = false;
        }
    }
}


int solution(vector<vector<int>> input) {
    stats = input;
    student_num = input.size();
    event_num = input[0].size();
    isSelected.resize(student_num);
    fill(isSelected.begin(), isSelected.end(), false);
    
    DFS(0, event_num, 0);
    
    return answer;
}

시간복잡도

10!의 순열이므로 O(10!), 약 3백만

후기

일단은 naive하게 되는 대로 DFS로 풀었는데, 바로 맞아서 다행이다. 역시 아무것도 안 하는 것보다는 BF로 부분점수라도 받는 마인드가 맞다.

Programmers PCCP 모의고사 #1 유전법칙, 31분

규칙 찾기 문제. 각 그룹은 무조건 1개의 parent와 4개의 child로 이루어져 있으므로 몇 번째 generation의 몇 번째 index인지만 찾으면 된다.

사실 진법 변환이랑 같은 류의 로직. 언제 끝내고 어떻게 처리할지만 잘 처리해 주면 된다. 나는 map에 vector를 넣어서 해결했다!

#include <string>
#include <vector>
#include <cmath>
#include <map>
#include <algorithm>
#include <iostream>

using namespace std;

// 4^15는 1억이 넘으므로 전부 다 계산하고 뽑는 것은 안 된다. 적당히 찾아야 한다.

// record[i] : i+1번째 generation에서 어떤 index를 가지는지
// ex) record[2] == 2 : 3번째 generation에서 index가 2
// 2번째 generation까지 계산함. 1번째 generation은 있기 때문.
vector<int> getRecords(int n, int p){
    vector<int> records; 
    records.push_back((p-1) % 4);
    while(n > 2){
        int before = ceil(((double)p)/4);
        records.push_back((before-1) % 4);
        
        p = before;
        n--;
    }
    reverse(records.begin(), records.end());
    return records;
}

// n : 세대, p : 개체
// 윗세대가 어떤 것인지 찾아야 한다.
string process(int n, int p){
    if(n == 1) return "Rr";
    
    map<string, vector<string>> m;
    m["RR"] = {"RR", "RR", "RR", "RR"};
    m["Rr"] = {"RR", "Rr", "Rr", "rr"};
    m["rr"] = {"rr", "rr", "rr", "rr"};
    
    vector<int> records = getRecords(n, p);
    
    string cur = "Rr";
    for(int record : records){
        //cout<<"cur : "<<cur<<", record : "<<record<<endl;
        cur = m[cur][record];
        
    }
    //cout<<endl;
    
    return cur;
}

vector<string> solution(vector<vector<int>> queries) {
    vector<string> answer;
    for(vector<int> query : queries){
        answer.push_back(process(query[0], query[1]));
    }
    return answer;
}

시간복잡도

n이 15이므로, getRecords() 함수의 while loop는 15번 돈다. 그러니까 O(n). map에 접근하는 것은 map size가 3이므로 사실상 O(1)로 치고. 그러면 O(n)이다.

Programmers PCCP 모의고사 #1 운영체제, 38분

많이 봤던 simulation 문제. pq를 써서 주어진 대로 풀면 된다.

실수했던 점은, future와 wait 2개의 queue에 다른 우선순위를 적용시켜줘야 했는데, 같은 우선순위를 썼었다. future의 경우에는 빨리 오는 게 먼저 와야 하고, wait queue의 경우에는 점수가 낮은 것이 먼저 와야 했다.

이것 말고는 뭐.. 딱히 실수한 것이 없었고, 잘 구현했던 것 같다. 디버깅도 빨리 해서 다행이다.

#include <string>
#include <vector>
#include <queue>
#include <iostream>

using namespace std;

typedef long long ll;

struct info{
    int point;
    int income_time;
    int running_time;
};

// 정렬 기준 : 1. 빨리 오는 것 2. 우선순위 높은 것
struct futurecmp{
    bool operator()(info &a, info &b){
        if(a.income_time == b.income_time) return a.point > b.point; // 우선순위 숫자 작은 게 top에
        return a.income_time > b.income_time; // income time 빠른 게 top에
    }
};

// 정렬 기준 : 1. 우선순위 높은 것 2. 빨리 오는 것 
struct waitcmp{
    bool operator()(info &a, info &b){
        if(a.point == b.point) return a.income_time > b.income_time; // income time 빠른 게 top에
        return a.point > b.point; // 우선순위 숫자 작은 게 top에
    }
};

// 초기화 : 시작 시간이 t보다 작은 것들을 waits에 넣음
void pushIntoWaitsLessThanT(int t, priority_queue<info, vector<info>, waitcmp> &waits, priority_queue<info, vector<info>, futurecmp> &future){
    while(1){
        if(future.empty()) break;
        if(future.top().income_time > t) break;
        if(future.top().income_time <= t){
            waits.push(future.top());
            future.pop();
        }
    }
}

vector<long long> solution(vector<vector<int>> program) {
    priority_queue<info, vector<info>, waitcmp> waits; // 실행 대기 중인 thread queue
    priority_queue<info, vector<info>, futurecmp> future; // 미래에 thread queue
    for(vector<int> p : program){
        info i;
        i.point = p[0];
        i.income_time = p[1]; 
        i.running_time = p[2];
        future.push(i);
    }
    
    // 초기화
    int time = 0;
    pushIntoWaitsLessThanT(time, waits, future);
    cout<<endl;
    
    // answer[0] : 모든 프로그램 종료 시간, answer[i] : 점수가 i인 프로그램 대기시간 합
    vector<long long> answer(11, 0);
    while(1){
        if(waits.empty()){
            // 종료조건
            if(future.empty()) break;
            
            // future가 남아있으면 그것 넣음
            waits.push(future.top()); 
            time = future.top().income_time;
            future.pop();
        }
        
        // waits 중 제일 높은 것 실행 중으로 변경
        info cur = waits.top(); 
        waits.pop();
        // cout<<"현재 시간 : "<<time<<endl;
        // cout<<"현재 실행 중 : "<<cur.point<<", "<<cur.income_time<<", "<<cur.running_time<<endl;
        
        // 해당 thread의 대기시간 추가
        int wait_time = time - cur.income_time;
        answer[cur.point] += wait_time;
        // cout<<"대기시간 : "<<wait_time<<endl;
        
        time += cur.running_time;
        // cout<<"끝난 시간 : "<<time<<endl;
        pushIntoWaitsLessThanT(time, waits, future);
        
        
        // cout<<endl;
    }
    answer[0] = time;
    
    return answer;
}

시간복잡도

n이 10만이고, pq의 각 연산이 O(logn)이므로 O(nlogn)에 얼추 풀린다.

후기

디버깅이 빨리 끝나서 다행이다. 구조화를 잘 해놔서..

Programmers PCCP 모의고사 #2 실습용 로봇, 10분

손 푸는 문제. 2D 좌표에서 이동하는 방법만 알면 된다. 실수했던 건 direction-- 이후 modular 연산을 한 것. C++에서는 음수의 modular 연산을 하면 a = bq + r에서 r = a - bq로 연산한다. 이것 때문에 한 3분? 날린 듯. 그래도 빨리 찾아서 다행이다. 디버깅도 안 찍었고.

#include <string>
#include <vector>

using namespace std;

int direction = 0; // dx, dy의 index. R이면 +1, L이면 -1
int dx[4] = {0, 1, 0, -1};
int dy[4] = {1, 0, -1, 0};

vector<int> position = {0, 0};

void rotate(char command){
    if(command == 'R'){
        direction++;
        if(direction == 4) direction = 0;
    }
    else if(command == 'L'){
        direction--;
        if(direction < 0) direction = 3;
    }
}

void move(char command){
    int d = direction;
    if(command == 'B'){
        d += 2;
        d %= 4;
    } 
    position[0] += dx[d];
    position[1] += dy[d];
}

vector<int> solution(string command) {
    for(char c : command){
        if(c == 'R' || c == 'L'){
            rotate(c);
        }
        else if(c == 'G' || c == 'B'){
            move(c);
        }
    }
    return position;
}

Programmers PCCP 모의고사 #2 신입사원 교육, 5분

문제를 딱 보면 greedy같다는 느낌이 든다. 증명해볼까?

점수가 a, b, c, ... 순서로 오름차순 정렬되어 있다고 할 때,

a와 b를 합치는 경우 a+b, a+b, c, ...가 된다.
a와 c를 합치는 경우 a+c, a+c, b, ...가 된다.
이 둘의 차이는 c-b인데, 이는 무조건 양수이다. 따라서 최소인 것을 고르지 않으면 sum이 최소가 되지 않는다는 것을 proof by contradiction으로 보일 수 있다.

그러면 min값 2개를 뽑으면 되는데, 이건 pq를 쓰면 쉽다.

#include <string>
#include <vector>
#include <queue>

using namespace std;

int solution(vector<int> ability, int n) {
    priority_queue<int, vector<int>, greater<int>> pq;
    for(int a : ability) pq.push(a);
    
    while(n--){
        int first = pq.top(); pq.pop();
        int second = pq.top(); pq.pop();
        pq.push(first + second);
        pq.push(first + second);
    }
    
    int answer = 0;
    while(!pq.empty()){
        answer += pq.top();
        pq.pop();
    }
    return answer;
}

시간복잡도

ability는 백만, n은 1만. 한 번의 연산에 O(log(1백만))이고 이 연산을 O(n)번 하므로 O(1만 * log(1백만))이다. 여기서 log(1백만)이 20 정도로, O(20만)으로 처리할 수 있다.

Programmers PCCP 모의고사 #2 실습용 로봇, 18분 풀고 이후 40분, 총 58분

처음에는 간단한 시뮬레이션 문제인 줄 알고 풀었는데.. 생각보다 까다로운 문제였다.

중요한 건 예외가 하나 있었다는 건데, 만들고 나가는 사람 + 들어오는 사람이 있으면 무조건 만들고 나가는 사람이 먼저 나간다는 것이다. 때문에 이에 대한 예외 연산을 빼놓지 않고 풀었어야 했다. 다행인 건 예제에 이 edge case를 저격하는 예외가 있었다는 것. 덕분에 쉽게 풀었다.

#include <string>
#include <vector>
#include <iostream>
#include <queue>
#include <algorithm>

using namespace std;

int solution(vector<int> menu, vector<int> order, int k) {
    int total_num = order.size();
    
    queue<int> waits; // 대기자 목록. 들어오는 것은 index
    int future_idx = 0; // 제일 근미래에 올 사람의 index
    int time = 0;
    
    int answer = -1;
    
    while(1){
        // 종료조건
        if(time >= total_num * k) break;
        
        // time보다 빨리 와서 그동안 줄을 선 손님들 waitQ에 추가
        while(1){
            if(future_idx < total_num && future_idx * k <= time){
                waits.push(future_idx);
                future_idx++;
            }
            else break;
        }
        
        // 만듬
        if(!waits.empty()){
            time += menu[order[waits.front()]];
        }
        
        // 만들 동안 와서 그동안 줄을 선 손님들 waitQ에 추가
        while(1){
            if(future_idx < total_num && future_idx * k <= time){
                waits.push(future_idx);
                future_idx++;
            }
            else break;
        }
        
        // 대기열 계산. 단, 만들고 나간 시간 == 들어온 시간이면 1을 빼 주어야 함.
        int isDuplicated = (time%k == 0 ? 1 : 0);
        answer = max(answer, (int)waits.size() - isDuplicated);
        
        // 만들었다면, 빼고, 그렇지 않다면 타임트립.
        if(!waits.empty()) waits.pop();
        else{
            time = future_idx * k;
        }
    }
    
    return answer;
}

시간복잡도

menu length는 100, order length는 1만으로, time을 1씩 늘려가면서 계산해도 1백만 정도로 시간은 여유롭다.

후기

이 문제는 진짜 아슬아슬했다.

Programmers PCCP 모의고사 #2 보물 지도, 50분

Acmicpc 벽 부수고 이동하기를 풀어봤다면 매우 쉽게 접근할 수 있는 문제. 아이템의 사용 여부도 visited 배열에 넣음으로써 쉽게 풀 수 있다.

단.. 이 문제의 경우 (x, y) 좌표로 주어지는데, 이를 (r, c) 좌표로 변환해야 했다. 이것 때문에 시간을 많이 잡아먹었다.

처음에 hole 위치를 초기화 할 때 seg fault가 나는 것을 보고 엥? 싶었는데.. 이런... 역시 문제를 잘 읽어야 한다. 항상 인지하고 문제를 읽지만 이런 "당연히 이러겠지" 싶은 것에서 항상 뒤통수를 맞는 것 같다.

#include <string>
#include <vector>
#include <queue>
#include <iostream>
using namespace std;

int INF = 1e9;
int dr[4] = {1, 0, -1, 0};
int dc[4] = {0, 1, 0, -1};

struct info{
    int r;
    int c;
    int used;
    int dist;
};

int solution(int n, int m, vector<vector<int>> holes) {
    vector<vector<int>> board(m, vector<int>(n, 0)); // 0 : 빈칸, 1 : 함정
    // (m-1, 0)부터 (0, n-1)까지 가야 함.
    for(vector<int> hole : holes){
        int r = m - hole[1];
        int c = hole[0]-1;
        // cout<<r<<", "<<c<<endl;
        board[r][c] = 1;
    }
    
    vector<vector<vector<int>>> visited(m, vector<vector<int>>(n, vector<int>(2, 0)));
    // visited[r][c][u] : (r, c) 위치를 방문했는지 여부. u가 1이면 신발 쓴 것이고, 0 신발 안 쓴 것.
    queue<info> q;
    info i; i.r = m-1; i.c = 0; i.used=0; i.dist=0;
    q.push(i);
    visited[m-1][0][0] = true;
    int answer = INF;
    while(!q.empty()){
        info cur = q.front(); q.pop();
        // cout<<"현재위치 : "<<cur.r<<", "<<cur.c<<", 사용여부 : "<<cur.used<<", dist : "<<cur.dist<<endl;
        
        // 종료조건
        if(cur.r == 0 && cur.c == n-1) answer = min(answer, cur.dist);
        
        // 안 쓰고 넘어가는 경우
        for(int d = 0; d<4; d++){
            int nr = cur.r + dr[d];
            int nc = cur.c + dc[d];
            if(0 <= nr && nr < m && 0 <= nc && nc < n && board[nr][nc] == 0 && !visited[nr][nc][cur.used]){
                // 사용 여부는 이전 상태 유지
                visited[nr][nc][cur.used] = true;
                info next; next.r = nr; next.c = nc; next.used = cur.used; next.dist = cur.dist+1;
                q.push(next);
            }
        }
        
        // 쓰고 넘어가는 경우
        if(cur.used == 1) continue;
        for(int d = 0; d<4; d++){
            int nr = cur.r + 2*dr[d];
            int nc = cur.c + 2*dc[d];
            if(0 <= nr && nr < m && 0 <= nc && nc < n && board[nr][nc] == 0 && !visited[nr][nc][1]){
                visited[nr][nc][1] = true;
                info next; next.r = nr; next.c = nc; next.used = 1; next.dist = cur.dist+1;
                q.push(next);
            }
        }

    }

    return answer == INF ? -1 : answer;
}

시간복잡도

m, n이 각각 1000 총 vertex size는 mn이고, O(1백만)이고,

각 vertex당 아이템을 사용하지 않을 때 4개 방향 + 아이템을 사용할 때 4개 방향으로 8개의 edge가 있다.

BFS의 시간복잡도는 O(V+E)이므로 O(9mn), O(mn)이다.

후기

왜 문제를 (x, y)로 냈을 까... 그냥 푸는 사람들을 괴롭히기 위해서가 아닐까?

Leetcode 377. Combination Sum IV, 30분

첫 접근 : duplicated permutation

일단은 문제를 딱 보고... [순서를 신경쓰는 + 합이 k가 되게 만드는 조합]이라길래 중복순열 딱 생각나서 중복순열로 풀었따. 그러나 문제의 input은 nums.size()가 200이기 때문에... 절대 풀 수 없다. 중복순열의 시간복잡도는 O(n$^n$)이니까. DFS 스택이 너무 많이 터져서 MLE가 떴다.

class Solution {
public:
    vector<vector<int>> answer;
    vector<int> nums;
    int target;
    void duplicatePermutation(int cur_d, vector<int> result, int sum){
        if(sum == target){
            answer.push_back(result);
            return;
        }

        for(int i = 0; i<nums.size(); i++){
            if(nums[i] + sum > target) continue;

            result.push_back(nums[i]);
            duplicatePermutation(cur_d + 1, result, sum + nums[i]);
            result.pop_back();
        }
    }
    int combinationSum4(vector<int>& i_nums, int i_target) {
        nums = i_nums;
        target = i_target;
        sort(nums.begin(), nums.end(), less<int>());

        duplicatePermutation(0, {}, 0);

        return answer.size();
    }
};

/*
중복순열 문제 같은데. + 합이 k가 되는...
*/

두 번째 접근 : DP

다른 방법이 필요하다... DFS의 tree를 보면 sum이 같을 때, 같은 연산을 반복하는 중복이 꽤나 발생하는 것을 알 수 있다. 이를 줄이기 위해서는? memoization이다. memozation? DP다!

앞선 관측에서 중복되는 부분은 [남은 값]으로 판별했다. 그러면, dp[i]를, [남은 값이 i일 때 만들 수 있는 경우의 수]로 세우면 될 것이다! 이것만 만들면 일사천리다.

점화식은 다음과 같으며, 이를 코드로 나타내면 된다. dp[0] = 1이니까 top-down이 쉬울 것 같다!

dp[0] = 1. (초기값)
dp[i] = 모든 n에 대해 dp[i-n]의 합

// Runtime 3 ms Beats 50.37%
// Memory 6.7 MB Beats 20.91%

class Solution {
public:
    vector<int> nums;
    int INF = -1;
    vector<int> dp;

    int recurse(int remain){
        if(dp[remain] != INF) return dp[remain];

        int num_cases = 0;
        for(int n : nums){
            if(n > remain) break;
            num_cases += recurse(remain - n);
        }
        dp[remain] = num_cases;
        return dp[remain];
    }
    int combinationSum4(vector<int>& i_nums, int target) {
        nums = i_nums;
        dp.resize(target + 1, INF);
        dp[0] = 1;
        sort(nums.begin(), nums.end(), less<int>());

        return recurse(target);
    }
};

시간복잡도

nums.size()가 n, target이 t일 때, recurse()를 수행하기 위해서 O(n)이 걸리고, 모든 dp 배열을 채우기 위해서 O(t)가 필요하므로 O(nt)이다.

후기

dp 으악

23.09.08. 풀었던 문제들

hyelie — Sat, 9 Sep 2023 01:31:22 +0900

Programmers 자물쇠와 열쇠, 53분

자물쇠에 열쇠를 넣어서 맞는지 보면 되는 문제. 문제 접근 자체는, N과 M이 20으로 매우 작아서 brute-force로 다 돌릴 수 있었고, 결국 구현 문제였다.

열쇠를 특정 크기로 자르는 것은 매우 귀찮고 힘들기 때문에, 그렇게 하는 것보다는 아래와 같이 for문으로 돌리는 것이 편하다.

총 N + 2M - 2 크기의 배열을 만들고, 가운데에 자물쇠를 배치한다. 자물쇠에 해당하는 좌표는 [M-1, M-1]부터 [N+M-2, N+M-2]까지다.
이후 열쇠를 모든 위치에 두고, 자물쇠를 해제할 수 있는지 본다. 열쇠는 [0, 0]부터 [N+M-1, N+M-1]까지 가능하다.
열쇠 위치를 옮겨가면서, 자물쇠에 해당하는 모든 좌표들의 숫자가 1이면 OK이다.

#include <string>
#include <vector>
#include <iostream>

using namespace std;

int N, M;

// 오른쪽으로 90도 회전
vector<vector<int>> rotate(vector<vector<int>> &key){
    vector<vector<int>> rotated_key(M, vector<int>(M, 0));
    for(int i = 0; i<M; i++){
        for(int j = 0; j<M; j++){
            rotated_key[j][M-1-i] = key[i][j];
        }
    }
    return rotated_key;
}

// total 초기화 함수
// total 중에서 lock의 시작 위치는 (M-1, M-1)부터 (M+N-2, M+N-2)까지임.
void initTotal(vector<vector<int>> &total, vector<vector<int>> &lock){
    for(int i = 0; i<N; i++){
        for(int j = 0; j<N; j++){
            total[i+M-1][j+M-1] = lock[i][j];
        }
    }
}

// lock이 가득 찼는지 확인하는 함수
// total 중에서 lock의 시작 위치는 (M-1, M-1)부터 (M+N-2, M+N-2)까지임.
bool isLockFull(vector<vector<int>> &total){
    int end = M+N-2;
    for(int i = M-1; i<=end; i++){
        for(int j = M-1; j<=end; j++){
            if(total[i][j] != 1) return false;
        }
    }
    return true;
}

// total에서 key의 시작 위치가 (r, c)일 때 key를 더하고 확인하는 함수
bool isMatch(vector<vector<int>> total, vector<vector<int>>& key, int r, int c){
    for(int i = 0; i<M; i++){
        for(int j = 0; j<M; j++){
            total[i+r][j+c] += key[i][j];
        }
    }
    return isLockFull(total);
}


bool solution(vector<vector<int>> key, vector<vector<int>> lock) {
    M = key.size(); N = lock.size();
    
    // 회전된 key들 생성
    vector<vector<vector<int>>> keys;
    keys.push_back(key);
    for(int i = 0; i<3; i++){
        key = rotate(key);
        keys.push_back(key);
    }
    
    // size 충분한 한 배열 생성. 가운데에 lock이 들어가고, key들은 위치를 옮겨가며 가득 차는지 볼 것임.
    int total_size = N+2*M-2;
    vector<vector<int>> total(total_size, vector<int>(total_size));
    initTotal(total, lock);
    
    // key의 시작 위치는 (0, 0부터) (M+N-1, M+N-1)까지 가능.
    int end = M+N-1;
    for(int i = 0; i<end; i++){
        for(int j = 0; j<end; j++){
            for(int k = 0; k<4; k++){
                if(isMatch(total, keys[k], i, j)) return true;
            }
        }
    }
    return false;
}
/*
가운데 lock 두고
상하좌우에 key만큼 size 추가함
그러면 N + 2M짜리. 
*/

시간복잡도

키가 열쇠에 맞는지 확인하는 로직이 O(N$^2$), 키를 옮길 때 O((M+N)$^2$)가 걸린다. O((M+N)$^2$)이다.

공간복잡도

추가 공간은 O((M+N)$^2$)만큼 쓴다.

후기

53분... 너무 오래 걸렸다. 일단 실수한 건, 좌표를 확실하게 생각하지 않고 시작한 것. 이게 열쇠가 들어갈 공간을 M-1 by M-1로 겹쳐 두니 계산이 조금 힘들었다.

또, 다른 실수한 것은 lock이 가득 찼는지 확인하는 함수에서 != 1로 해야 하는데 != 0으로 했던 것도 실수.

이런 문제를 35분 내에 풀어야 하는데.. 구현 문제 속도는 언제쯤 빨라질까. 그래도 모듈화를 잘 해놨어서 실수를 빨리 잡긴 했다.

Programmers GPS

문제를 처음 딱 보면 brute-force인 것 같다. bellman ford부터 접근할 생각을 하는데, 그러면 안 된다.

sweeping 느낌으로 DP를 써야 한다. 점화식은 다음과 같다.

dp[t][l] : 시간 t에서 위치가 l일 때 최소로 고치는 개수라고 두자.

그러면 점화식은, 모든 dp[t-1][l의 neighbor]에 대해 gps_log[t] == l의 neighbor이면 +0, 아니면 +1. 그 중에서 최소값을 뽑으면 된다.

점화식 자체는 간단한데, 이걸 생각하는 과정이... 모든 DP 문제가 그렇듯 점화식을 세우는 게 어렵다.

#include <vector>

using namespace std;

/*
거점 개수가 200개
도로 개수는 10000개
BF같은데
dp[t][l] : 시간 t에서 위치가 l일 때
모든 dp[t-1][l의 neighbor]에 대해서 (이전단계)
gps_log[t] == l이면 +1
아니면 +0

*/

int INF = 1e9;

// 전역 변수를 정의할 경우 함수 내에 초기화 코드를 꼭 작성해주세요.
int solution(int n, int m, vector<vector<int>> edge_list, int k, vector<int> gps_log) {
    vector<vector<int>> edges(n+1);
    for(vector<int> e : edge_list){
        edges[e[0]].push_back(e[1]);
        edges[e[1]].push_back(e[0]);
    }
    for(int i = 1; i<=n; i++){
        edges[i].push_back(i);
    }
    
    vector<vector<int>> dp(k, vector<int>(n+1, INF));
    dp[0][gps_log[0]] = 0;
    for(int t = 1; t<k; t++){
        for(int l = 1; l<=n; l++){
            int isLonT = gps_log[t] == l ? 0 : 1;
            for(int neighbor : edges[l]){
                dp[t][l] = min(dp[t-1][neighbor] + isLonT, dp[t][l]);
            }
        }
    }
    
    if(dp[k-1][gps_log[k-1]] >= INF) return -1;
    return dp[k-1][gps_log[k-1]];
}

시간복잡도

모든 DP를 채우는 데 O(k$^2$n) 만큼의 시간이 든다.

공간복잡도

추가 공간은 O(kn)과 O(n)만큼 쓰니까 O(kn).

후기

어떻게 이런 문제가 lv 3에 있는 건지 모르겠다. DP인 걸 알 수 있는 단서가 너무나도 적은데..

Programmers 다리를 지나는 트럭, 20분

문제에서 주는 대로 구현만 하면 되는 문제. queue를 사용하면 굉장히 편?리하게 풀 수 있다.

#include <string>
#include <queue>
#include <vector>

using namespace std;

typedef pair<int, int> pii;
int solution(int len, int weight, vector<int> truck_weights) {
    int cur_sum = 0; // 현재 다리 위에 있는 트럭 무게
    queue<pii> curs; //.first : 무게, .second : 들어온 시간 t
    
    // 대기열
    queue<int> waits;
    for(int wait : truck_weights) waits.push(wait);
    
    int t = 1;
    while(1){
        // 다리에서 나가는 경우
        if(!curs.empty() && t >= curs.front().second + len){
            cur_sum -= curs.front().first;
            curs.pop();
        }
        
        // 다리에 진입하는 경우
        if(curs.size() < len && !waits.empty() && cur_sum + waits.front() <= weight){
            curs.push({waits.front(), t});
            cur_sum += waits.front();
            waits.pop();
        }
        
        // 종료조건
        if(waits.size() == 0){
            return t + len;
        }
        
        t++;
    }
    return t;
}

시간복잡도

while문은 worst case 1억 정도로 돈다. 만약 최적화가 필요하면, 다리에 진입하는 트럭이 없는 경우에 curs.front()를 내보내는 시간으로 설정하면 된다.

후기

이건 왜이렇게 빨리 풀렸지?

Programmers 짝지어 제거하기, 35분

첫 번째 접근은 s.substr()을 이용해서 겹치는 부분을 삭제하고, index를 앞으로 당기는 방법이었다. 시간복잡도가 O(n)일 것이라 생각했으나... substr() 함수는 문자열을 자르고 복사하기 때문에 O(n)만큼의 시간이 걸렸다. 때문에 다른 방법을 택해야 했다.

stack을 사용하면 아주 쉽게 풀린다. 설명할 필요도 없고, 코드 보면 바로 이해가 될 것이다.

#include <iostream>
#include <iostream>
#include <stack>
#include<string>
using namespace std;

int solution(string s)
{
    stack<char> stk;
    for(char c : s){
        if(!stk.empty() && stk.top() == c){
            stk.pop();
        }
        else stk.push(c);
    }
    
    return stk.empty();
}

시간복잡도

s를 순회하므로 O(n)

공간복잡도

stack size는 worst case O(n)

후기

안 되는 풀이를 너무 오래 붙들고 있었다.

Leetcode 118, Pascal's Triancle, 10분

그냥 배열 쓸 줄 알면 풀리는 문제.

// Runtime 0 ms Beats 100%
// Memory 6.9 MB Beats 20.86%

class Solution {
public:
    vector<vector<int>> generate(int n) {
        vector<vector<int>> answer;
        answer.push_back({1});

        for(int l = 1; l<n; l++){
            vector<int> layer(l+1);
            layer[0] = layer[l] = 1;
            for(int i = 1; i<l; i++){
                layer[i] = answer[l-1][i] + answer[l-1][i-1];
            }
            answer.push_back(layer);
        }

        return answer;
    }
};

시간복잡도

2차원 배열 채우는 거니 O(n^$2$).

23.09.07. 복학 후 계획 - 끝!

hyelie — Thu, 7 Sep 2023 18:06:19 +0900

당분간 할 일들

Naver2Tistory 리팩토링 과정/선택/결과 블로그에 포스팅하기 - 23.09.05. 끝!
large query vs small 2 query 실험하기 - 23.09.06. 끝!
위 2개 끝나면 포폴 다듬기 - 전역/복학한 내용 + resume만 고치고 업로드하면 됨. - 23.09.07. 끝!
- Naver2Tistory 부분 다듬기 + 포스팅 링크도 달기 - 끝!
다 끝나면 plan에 있는 포스팅 싹 읽으면서 정리하고, 당분간 또 할 일들 정리하기. - 23.09.07. 끝!

이후에 할 일들

하반기 채용 기업들 지원서 쓰기 - 끝!
지원서 쓴 이후 코테 공부하기 (하반기 공채가 시작했으니 다시 달려보자.) - 끝!
- 아마 프로그래머스 부계정 판 거로 풀어갈 것 같다. lv2 + lv3 350문제 정도였던 것 같은데... 해보자.

메이커스페스 3D 프린터로 하우징 출력하기
과제연구 진행하기 - 끝!
DB 정리 - 코테를 패스하고, 면접을 가면 CS 공부하면서 채워봐야 할 것 같다. 최후순위로 밀린 것이라.. - 끝!

[N2T] 리팩토링 기록

hyelie — Wed, 6 Sep 2023 02:32:43 +0900

리팩토링 하게 된 계기

개발 동기

Naver2Tistory는 사실 내가 사용하기 위해 만든 프로그램이다. 2022년 10월쯤에 개발 블로그를 네이버에서 티스토리로 옮기기로 결정하면서 안에 있는 포스팅들을 다 가져오고 싶었는데, 그동안 작성했던 포스팅이 약 300개 가량 되다 보니 수작업으로 일일히 옮길 수 없었다. 이를 위해 Naver2Tistory를 당시 내가 구현할 수 있는 수준으로 만들었었다. 만들다 보니 블로그를 나만 옮기는 게 아니니까 다른 사람들도 쓸 수 있겠다 싶어 리드미도 열심히 꾸몄고 형식을 맞춰서 오픈소스로 배포도 했다.

기존 Naver2Tistory의 문제점

이후에 Clean Code, Clean Architecture 같은 개발 서적을 읽고, 객체지향의 5대 원칙을 공부하면서 내가 짰던 코드가 많이 부족함을 느꼈다. 리팩토링을 시작했을 때 코드를 읽어봤을 때 모듈화만 적당히 잘 되었지 아래와 같은 단점들이 보였다.

필요없는 주석들이 너무 많았다. 주석은 유지보수되지 않는 경우가 대부분이므로 없는 것이 더 낫다.
예외처리가 너무 난잡하다. try-catch문을 너무 많이 사용해 가독성이 떨어진다는 느낌을 받았다.
concrete class에 의존한다. 때문에 확장성이 없다시피 했으며 유지보수도 힘들었다.
if-else문으로 대부분의 로직을 처리한다.
테스트 코드가 없다. 때문에 소스코드를 수정한 후 검증하는 과정이 오래 걸린다.

기존 Naver2Tistory의 dependency tree

예시 - 너무 긴 if-else문

public class Converter {
    /**
     * Traverse childs of given parameter 'elements'.
     * While traversal, reform it's HTML element to Tistory style.
     * 
     * @param elements is which want to traverse.
     * @see Converter#convertTable(Element)
     * @see Converter#convertQUOTATION(Element)
     * @see Converter#convertTEXT(Element)
     * @see Converter#convertCODE(Element)
     * @see Converter#convertIMAGE(Element)
     * @see Converter#convertHORIZONTALLINE(Element)
     * @see Converter#convertLINK(Element)
     */
    private void dfsDOM(Elements elements) {
        for(Element element : elements){
            ContentType elementContentType = getContentType(element);

            // If section type exists, then stylize
            if(elementContentType == ContentType.TABLE){
                this.convertTable(element);
            }
            else if(elementContentType == ContentType.QUOTATION){
                this.convertQUOTATION(element);
            }
            else if(elementContentType == ContentType.TEXT){
                this.convertTEXT(element);
            }
            
            else if(elementContentType == ContentType.CODE){
                this.convertCODE(element);
            }
            
            else if(elementContentType == ContentType.IMAGE){
                this.convertIMAGE(element);
            }
            
            else if(elementContentType == ContentType.HORIZONTALLINE){
                this.convertHORIZONTALLINE(element);
            }
            
            else if(elementContentType == ContentType.LINK){
                this.convertLINK(element);
            }

            // else then traverse deeper.
            else{ // elementContentType == ContentType.NOTHING
                dfsDOM(element.children());
            }
        }
    }
    // ...
}

기존에는 table, quotation, text, code, image, horizontal line, link 정도의 스타일을 지원했다. 이 때 버전업을 하면서 새로운 스타일을 추가한다고 하자. 그러면 if문에 또 붙어야 하고, 해당하는 함수를 만들어야 한다. 숫자가 적을 때는 괜찮겠지만, 만약 모든 HTML의 스타일을 사용하게 된다면? if-else문만 엄청나게 길어질 것이다.

수정을 할 때 Converter 객체를 직접 수정해야 하기 때문에 SOLID 원칙에도 위배된다.

목표

이러한 문제들을 해결하기 위해 다음과 같은 목표를 세우고 리팩토링했다. 클린 코드에서 읽었던 [주석 최소화, 경계 처리, 테스트 코드 작성]을 적용하고자 했다.

주석 삭제. 의도를 설명한 주석, 유지보수 시 참고가 될 만한 주석만 남기고 모두 삭제. JavaDoc은 필요한 public 함수에만 남기고자 했다.
예외처리를 간소하게. 곳곳에 퍼져 있는 try-catch문을 응집시키고자 했다.
최대한 의존성을 줄이고 확장성 있게 코드를 작성하고자 했다.
- 이 프로그램은 Naver2Tistory이지만 추후에 Naver2Notion처럼 목적지 블로그를 추가할 수도 있고, Medium2Tistory처럼 출발지 블로그를 추가할 수도 있다고 가정했다.
- 현재 지원하는 스타일 이외에 다른 스타일들이 추가될 수 있다고 가정했다.
- 의존성을 줄이기 위해서 interface나 abstract class를 사용하고, if-else문을 줄이기 위해 map을 사용하는 방식을 채택했다.
테스트 코드 작성. 사용자 아이디/패스워드가 필요한 TistoryClient와 TistoryClient를 사용하는 class를 제외하고는 최대한 unit test를 진행하고자 했다.

리팩토링 결과

지금부터 어떻게 리팩토링했는지 각 module에 대해 인상깊었고, 기억해 둘 만한 변경점만 기술할 것이다.

Migrator

리팩토링 결과 Migrator의 dependency tree

기존에는 N2T class로 묶었던 것을 목적지 블로그/출발지 블로그가 추가될 수 있다고 가정했기 때문에 명칭을 더 포괄적으로 바꾸었다. 그리고 각 module들에도 변화가 생겼고, 각 module들은 VO를 사용해 통신한다.

각 module들은 exception을 던지기만 하고, Migrator class에서 이를 받아 처리한다.

먼저 각 module들을 살펴보고 다시 Migrator를 살펴볼 것이다.

UrlProcessor

기존에는 네이버 블로그만 처리할 수 있었던 URLProcessor를 UrlProcessor, BlogUrlProcessor로 나누었다. 명명도 Java naming convention에 따라 UrlProcessor로 바꾸었다.

리팩토링 결과 UrlProcessor의 dependency tree

위 그림에 적혀 있듯 UrlProcessor는 Naver2Tistory가 지원하는 블로그 형식에 맞춰 크롤링할 URL로 변환하고, 블로그 형식과 변환한 URL을 UrlVO로 래핑해 리턴한다. 만약 지원하지 않는 형식이거나 크롤링 중 오류가 발생할 경우 exception을 날린다.

분명 dependency를 줄이겠다고 했는데, UrlProcessor는 abstract class가 아니라 concrete class로 구현했다. 이렇게 구현한 이유는 UrlProcessor는 추상화 수준이 매우 높게 설계했기 때문이며, 따라서 내부 로직이 변하지 않을 것으로 예측된다. 만약 다른 종류의 블로그가 추가되면 BlogUrlProcessor의 구현체를 추가하고, UrlProcessor의 blogUrlProcessors에 추가만 하면 된다.

UrlVO는 해당 URL이 어떤 블로그의 URL인지, 그리고 URL 처리 결과 2개의 attribute가 있다.

디자인 패턴으로는 UrlProcessor는 BlogUrlProcessor를 생성하므로 Template method pattern을, 블로그 종류에 따라 다른 BlogUrlProcessor interface의 구현체를 호출해 URL을 처리하므로 Strategy pattern을 사용한다.

SOLID 원칙을 생각해 보면, UrlProcessor는 [inputUrl을 UrlVO로 변환한다]는 역할만 수행하므로 SRP를 만족하는 것 같다. UrlProcessor의 생성자만 수정하면 다른 종류의 BlogUrlProcessor를 추가할 수 있기 때문에 OCP도 만족하는 것 같다. interface에 의존하고 있기 때문에 DIP도 만족하는 것 같다. LSP는 해당 사항 없는 것 같고, BlogUrlProcessor interface의 모든 method를 사용하므로 ISP도 만족하는 것 같다.

public class UrlProcessor {
    private static final List<BlogUrlProcessor> blogUrlProcessors = new ArrayList<>();

    public UrlProcessor(){
        blogUrlProcessors.add(new NaverUrlProcessor());
        // Append other blog url processors here
    }

    public UrlVO process(String inputUrl) throws Exception {
        for(BlogUrlProcessor blogUrlProcessor : blogUrlProcessors){
            if(blogUrlProcessor.matches(inputUrl)){
                return new UrlVO(blogUrlProcessor.getUrlType(), blogUrlProcessor.process(inputUrl));
            }
        }
        throw new Exception("[Url 작업 중 오류] : 지원하지 않는 블로그의 Url입니다.");
    }
}

// Implement this interface to preprocess other types of blog URLs.
public interface BlogUrlProcessor {
    /**
     * @return blog type of each url processor
     */
    public BlogType getUrlType();

    /**
     * Return true if inputUrl matches type of blog URL format, otherwise false.
     */
    Boolean matches(String inputUrl);

    /**
     * Process inputUrl to crawlable URL and return. 
     * @throws Exception when error occurs while processing URL.
     */
    String process(String inputUrl) throws Exception;
}

코드는 위와 같으며 다음 링크에서 열어볼 수도 있다. UrlProcessor 코드, BlogUrlProcessor 코드

고민했던 점

BlogUrlProcessor를 interface로 사용할지, abstract class로 사용할지 고민했다. 둘 다 구현체/상속체에게 특정 method의 구현을 강제할 수 있으며 polymorphism을 사용할 수 있기 때문이었는데, 여기서는 BlogUrlProcessor들이 공통 기능이 필요하지 않다고 생각했기 때문에 interface를 사용했다.

Scrapper

기존에는 네이버 블로그에서 크롤링한 결과를 바로 티스토리 형식으로 바꾸었는데, 출발지/목적지 블로그가 추가될 수 있다고 가정했기 때문에 기존 Converter를 Scrapper와 Converter 2가지로 나누었다. Scrapper는 출발지 블로그에서 크롤링한 후 공통 형식으로 바꾸고, Converter는 공통 형식을 목적지 블로그로 변환하는 역할을 한다. 일단 Scrapper부터 먼저 보자.

기존에는 크롤링만 수행했기 때문에 Crawler였지만, 이제는 크롤링한 후 정보를 가공하는 부분까지 진행하기 때문에 Scrapper로 명명했으며 내부적으로 크롤링과 파싱을 진행한다.

리팩토링 결과 Scrapper의 dependency tree

Scrapper는 UrlVO를 입력으로 받아 BlogType에 해당하는 BlogScrapper abstract class의 변환 method를 호출한다. 만약 지원하지 않는 형식이거나 크롤링 중 오류가 발생할 경우 exception을 날린다.

UrlProcessor과 마찬가지로 Scrapper도 추상화 수준을 매우 높게 설계했기 때문에 내부 로직이 바뀌지 않을 것으로 예상한다. 만약 다른 종류의 블로그가 추가되면 BlogScrapper의 derived class를 추가하고, BlogScrapper의 blogScrapperMap에 추가만 하면 되기 때문이다.

BlogPost는 게시글 제목, 그리고 HTML DOM 트리를 커스텀한 ConvertedTree의 root node 2개의 attribute를 가진다.
ConvertedTreeNode는 해당 node가 어떤 스타일을 가지는지, 내용은 어떤 것인지, 그리고 child node list를 attribute로 가진다.

디자인 패턴으로는 UrlProcessor과 마찬가지로 BlogScrapper를 사용하므로 Template method pattern을 사용하고, 블로그 종류에 따라 다른 BlogScrapper abstract class의 derived class를 호출해 URL을 처리하므로 Strategy pattern을 사용한다.

SOLID 원칙을 생각해 보면, Scrapper는 [UrlVO를 입력으로 받아 크롤링/파싱한다]는 역할만 수행하므로 SRP는 만족하지 않는 것 같다. 그러나 SRP를 만족시키기 위해 크롤링 기능을 분리하는 것에는 overhead가 더 크다고 생각했는데, 그 이유는 아래의 고민했던 점에서 설명하겠다. 다른 종류의 BlogScrapper를 추가하기 위해서는 BlogScrapper를 상속해 구현하고 Scrapper의 생성자에만 추가하면 다른 종류의 BlogScrapper를 추가할 수 있기 때문에 OCP도 만족하는 것 같다. Scrapper는 abstract class인 BlogScrapper에 의존하므로 DIP도 만족하는 것 같다. LSP는 해당사항 없는 것 같고, ISP BlogScrapper의 모든 method를 사용하므로 만족하는 것 같다.

public class Scrapper {
    private static Map<BlogType, BlogScrapper> blogScrapperMap = new HashMap<>();

    public Scrapper(){
        blogScrapperMap.put(BlogType.NAVER, new NaverScrapper());
        // Append other blog scrappers here
    }

    public BlogPost scrap(UrlVO urlVO) throws Exception {
        BlogType blogType = urlVO.getUrlType();
        String url = urlVO.getUrl();

        if(blogScrapperMap.containsKey(blogType)){
            BlogScrapper blogScrapper = blogScrapperMap.get(blogType);
            return blogScrapper.scrap(url);
        }
        throw new Exception("[스크래핑 중 오류] : 지원하지 않는 블로그입니다.");
    }
}

// Inherit this abstract class to scrap other types of blogs.
public abstract class BlogScrapper {
    private static final String defaultErrorMessage = "스크래핑 중 알 수 없는 오류가 발생했습니다.";

    protected BlogScrapper(){
        initializeErrorMessages();
    }

    public BlogPost scrap(String url) throws Exception{
        Document document = crawl(url);
        return parse(document);
    }
    
    protected Document crawl(String url) throws Exception {
        try{
            Connection con = Jsoup.connect(url).timeout(5000).ignoreHttpErrors(true);
            Response response = con.execute();
            if (response.statusCode() == 200) {
                return con.get();
            }
            else{ // page not found
                throw new Exception(getErrorMessage(response.statusCode()));
            }
        } catch(IOException e) { // 이외 connection 중 발생하는 오류
            throw new Exception(getErrorMessage(500));
        }
    }
    protected abstract BlogPost parse(Document document) throws Exception ;

    protected HashMap<Integer, String> errorMessages = new HashMap<Integer, String>();
    protected abstract void initializeErrorMessages();
    protected String getErrorMessage(int statusCode){
        if(errorMessages.containsKey(statusCode)){
            return errorMessages.get(statusCode);
        }
        return defaultErrorMessage;
    }
}

코드는 위와 같으며 다음 링크에서 열어볼 수도 있다. Scrapper 코드, BlogScrapper 코드

고민했던 점

앞서 크롤링 기능 Scrapper에서 분리하는 것에는 overhead가 더 크다고 생각했는데, 그 이유를 여기에서 설명하겠다.

public class NaverScrapper extends BlogScrapper {
    @Override
    protected void initializeErrorMessages() {
        errorMessages.put(204, "[네이버 블로그 오류] : 삭제되거나, 존재하지 않거나, 비공개 글이거나, 구버전 포스팅입니다.");
        errorMessages.put(404, "[네이버 블로그 오류] : 유효하지 않은 요청입니다. 해당 블로그가 없습니다. 블로그 아이디를 확인해 주세요.");
        errorMessages.put(500, "[네이버 블로그 오류] : 예상치 못한 에러가 발생했습니다.");
        // Append other blog error code and message mapping here
    }
    
    private Elements extractPost(Document document) throws Exception {
        Elements post = document.select(".se-viewer"); // naver blog 포스트 부분
        if(post.size() == 0){
            throw new Exception(getErrorMessage(204));
        }
        return post;
    }

    private String extractTitle(Elements post) throws Exception {
        Elements head = post.select(".pcol1"); // naver blog 제목
		if(head.size() == 0){
			throw new Exception(getErrorMessage(204));
		}
        return head.text();
    }
    ...
}

위 코드는 NaverScrapper의 코드 일부분이며, 다음 링크에서 열어볼 수도 있다. NaverScrapper 코드

initializeErrorMessage()에서 네이버 블로그에서 사용하는 에러 메시지들을 초기화하고 있다. extractPost()와 extractTitle()은 크롤링 결과로부터 필요한 정보를 따 오는 것이므로 Crawler에 들어가는 것이 아니라 Parser에 들어갈 것이다.

반면, BlogScrapper의 crawl() method를 보자. 내부적으로 getErrorMessage()를 호출하는데, 여기에서 사용할 메시지들이 initializeErrorMessage()에서 초기화한 에러 메시지들이다.

만약 Crawler와 Parser 2개로 나눈다면 에러 메시지를 중복해서 적어야 한다! 중복된다면, 필연적으로 관리하기 어려워진다. 만약 에러 메시지를 공유한다고 치면, 어디서 관리할 것인가? Crawler와 Parser 2개 class만 사용하는데 Migrator에서 이를 관리할 수도 없고, Crawler에서 에러 메시지를 초기화하고 Parser에게 건네주는 방식이라면 두 클래스가 아주 강한 의존관계를 지니게 된다고 생각했다. 때문에 Scrapper를 Crawler와 Parser로 분리하는 것보다 일원화해서 관리하는 편이 더 좋다고 생각했다. Scrapping이라는 명칭의 역할도 달성할 수 있다는 부가적인 효과도 있다.

이후 따라온 고민은 BlogScrapper를 interface로 사용할지, abstract class로 사용할지였다. BlogScrapper의 parse()는 derived class에서 구현되어야 하는 것이 명확했다. 그러나 crawl() method가 애매했다. HTTP status code가 200인 경우 크롤링에 성공한 것이 99.9% 확정이기 때문에, BlogScrapper를 interface로 두면 crawl() method의 구현이 거의 중복될 것이라 예측했다. 때문에 BlogScrapper를 abstract class로 두었고, 꼭 구현해야 하는 initializeErrorMessage()와 parse()만 abstract method로 두었다.

NaverScrapper

앞서 Template method pattern과 Strategy pattern을 사용했었는데, NaverScrapper도 마찬가지이다. 예를 들어 image에 해당하는 section에서는 src를 추출해 이미지를 다운로드 해야 하고, table에 해당하는 section에서는 row/column/content를 추출해야 하는데, 이렇듯 section의 종류에 따라 공통 형식으로 변환하는 형식이 다르기 때문에 앞과 같은 방법을 사용했다.

SOLID 원칙을 생각해 보면, NaverScrapper는 Scrapper와 같은 역할을 가지므로 SRP는 조금 애매하다. 그러나 crawl() method는 Scrapper에서 처리하고, NaverScrapper는 네이버 블로그의 DOM tree를 파싱만 하므로 SRP를 만족하는 것 같다. 다른 종류의 SectionParser를 추가하기 위해서는 SectionParser의 구현체를 생성자에만 추가하면 되므로 OCP도 만족하는 것 같다. abstract class인 SectionParser에 의존하므로 DIP도 만족한다. NaverScrapper는 Scrapper의 자리에 들어가 사용될 수 있기 때문에 LSP 또한 만족한다. ISP는 해당 사항이 없다.

디자인 패턴으로는 SectionParser를 사용하므로 Template method pattern을 사용하고, 블로그 종류에 따라 다른 BlogScrapper abstract class의 derived class를 호출해 URL을 처리하므로 Strategy pattern을 사용한다.

public class NaverScrapper extends BlogScrapper {
    private static Map<String, SectionParser> parserMap = new HashMap<>();
    private static final String DEFAULT = "";

    static{
        initializeParserMap();
    }

    private static void initializeParserMap(){
        parserMap.put("table", new TableParser());
        parserMap.put("quotation", new QuotationParser());
        parserMap.put("text", new TextParser());
        parserMap.put("code", new CodeParser());
        parserMap.put("image", new ImageParser());
        parserMap.put("horizontalLine", new HorizontalLineParser());
        parserMap.put("oglink", new OglinkParser());
        parserMap.put(DEFAULT, new DefaultParser());
        // Append other [naver blog section name to StyleType mapping] here
    }

    @Override
    protected BlogPost parse(Document document) throws Exception {
        Elements post = extractPost(document);
        String title = extractTitle(post);
        Element content = extractContent(post);
        ConvertedTreeNode root = parseToTree(content);
        
        return new BlogPost(title, root);
    }
    
    private ConvertedTreeNode parseToTree(Element curElement){
        ConvertedTreeNode rootNode = ConvertedTreeNode.builder().type(StyleType.NONE).build();

        for(Element child : curElement.children()){
            Element sectionElement = child.child(0).child(0);
            if(isSection(sectionElement)){
                SectionParser sectionParser = getSectionParser(getSection(sectionElement));
                ConvertedTreeNode sectionNode = sectionParser.parseToTreeNode(sectionElement);
                rootNode.appendChild(sectionNode);
            }
        }

        return rootNode;
    }

    private static final Pattern sectionPattern = Pattern.compile("se-section se-section-([A-za-z]*)");
    private Boolean isSection(Element element){
        Matcher sectionMatcher = sectionPattern.matcher(element.className());
        if(sectionMatcher.find()) return true;
        return false;
    }

    private String getSection(Element element){
        Matcher sectionMatcher = sectionPattern.matcher(element.className());
        if(sectionMatcher.find()){
            return sectionMatcher.group(1);
        }
        return DEFAULT;
    }

    private SectionParser getSectionParser(String section){
        return parserMap.getOrDefault(section, parserMap.get(DEFAULT));
    }
    
    ...
}

코드는 위와 같으며 다음 링크에서 열어볼 수도 있다. NaverScrapper 코드

고민했던 점

// Inherit this abstract class to parse other types of naver blog sections.
public abstract class SectionParser {
    abstract public ConvertedTreeNode parseToTreeNode(Element element);

    // Regular expression filtering [se-text-paragraph se-text-paragraph-{ALIGN-TYPE}] format
    private static final Pattern paragraphPattern = Pattern.compile("se-text-paragraph se-text-paragraph-align-([A-za-z]*)");
    private static Map<String, StyleType> styleMap = new HashMap<>();
    static{
        initializeStyleMap();
    }

    private static void initializeStyleMap(){
        styleMap.put("", StyleType.PARAGRAPH_DEFAULT);
        styleMap.put("right", StyleType.PARAGRAPH_RIGHT);
        styleMap.put("justify", StyleType.PARAGRAPH_LEFT);
        styleMap.put("center", StyleType.PARAGRAPH_CENTER);
        styleMap.put("a", StyleType.LINK);
        styleMap.put("b", StyleType.BOLD);
        styleMap.put("i", StyleType.TILT);
        styleMap.put("u", StyleType.UNDERLINE);
        styleMap.put("strike", StyleType.STRIKE);
        // Append other [naver blog style to StyleType mapping] here
    }

    protected ConvertedTreeNode parseTextModule(Element textModule) { // se-module-text
        ConvertedTreeNode textNode = ConvertedTreeNode.builder().type(StyleType.TEXT).build();

        for(Element textParagraph : textModule.children()){ // se-text-paragraph
            String align = getAlignFromElement(textParagraph);
            StyleType alignType = getAlignTypeFromMap(align);
            ConvertedTreeNode paragraphNode = parseTextParagraph(textParagraph, alignType);
            textNode.appendChild(paragraphNode);
        }

        return textNode;
    }

    private ConvertedTreeNode parseTextParagraph(Element textParagraph, StyleType alignType){
        ConvertedTreeNode paragraphNode = ConvertedTreeNode.builder().type(alignType).build();
        for(Element spanElement : textParagraph.children()){
            paragraphNode.appendChild(parseSpanElementToTreeNode(spanElement));
        }
        return paragraphNode;
    }

    // span 이하 element들에 대해 DFS 이후 tagname을 style로 지정한 tree node return
    private ConvertedTreeNode parseSpanElementToTreeNode(Element element){
        StyleType styleType = getTextStyleFromMap(element.tagName());
        
        if(element.childrenSize() == 0){
            String content = element.text();
            return ConvertedTreeNode.builder().type(styleType).content(content).build();
        }
        
        ConvertedTreeNode curNode = ConvertedTreeNode.builder().type(styleType).build();
        for(Element child : element.children()){
            curNode.appendChild(parseSpanElementToTreeNode(child));
        }
        return curNode;
    }

    private String getAlignFromElement(Element textParagraph){
        Matcher paragraphMatcher = paragraphPattern.matcher(textParagraph.className());

        if(paragraphMatcher.find()){
            return paragraphMatcher.group(1);
        }
        return "";
    }

    private StyleType getAlignTypeFromMap(String align){
        return styleMap.getOrDefault(align, StyleType.PARAGRAPH_DEFAULT);
    }
    
    private StyleType getTextStyleFromMap(String style){
        return styleMap.getOrDefault(style, StyleType.CONTENT);
    }
}

위 코드는 SectionParser 코드의 일부분이며, 다음 링크에서 열어볼 수 있다. SectionParser 코드

사실상 리팩토링하면서 제일 힘들었던 부분이고, 마땅히 좋은 해결책을 찾지 못해서 조금 맘에 들지 않는다.

네이버 블로그의 HTML 구조는 다음과 같다.

- se-main-container                                                     # main text
    - se-component se-[TYPE]
        - se-component-content
            - se-section se-section-[TYPE]
                - se-module se-module-text                              # text
                  - se-text-paragraph                                       # paragraph
                - se-module se-module-code                              # source code
                  - se-code-source                                  
                      - __se_code_view
                - se-module se-module-image                             # image
                  se-module se-module-text se-caption                   # image caption
                - se-module se-module-horizontalLine                    # horizontal line
                - se-module se-module-oglink                            # auto generated shortcut 
                - se-quotation-container                                # quotation container
                    - se-module se-module-text se-quote                     # quote
                    - se-module se-module-text se-cite                      # cite
                - se-table-container                                    # table container
                    - se-table-content                                      # table body

[se-main-container - se-component se-type - se-component-content - se-section se-section-type] 이후에 module이 오는 형태인데, image module의 경우 se-section 아래에 se-module-image와 se-module-text가 같이 오기 때문에, 글의 구성요소를 section으로 판정해야만 했다. 문제는 이미지 캡션, 인용구, 표의 각 셀 등 모든 평문이 들어가는 부분은 se-module-text로 구성되어 있다는 것이다. 즉, TextParser가 TableParser나 ImageParser 내부에 들어가야 한다. SectionParser interface의 구현체에 TextParser가 들어가야 하는 것인데... 네이버 블로그 HTML의 구성상 의존성이 있는 것은 맞지만, 이것이 너무 마음에 들지 않아서 다른 방법을 생각했다.

내가 제시한 방법은 TextModule을 파싱하는 부분이 공통으로 사용되므로, SectionParser를 abstract class로 바꾸는 것이었다. 때문에 SectionParser는 각 section을 파싱하는 parseToTreeNode() method를 강제함과 동시에 text module을 파싱하는, 2가지 역할을 가지게 된 것이다.

디자인 패턴으로는 딱히 적용된 게 없다. Strategy patten이 적용된 것 같은데, 구현이 encapsulation되지 않았기 때문에 그렇다고 볼 수 없다. Template method pattern은 맞다고 볼 수 있다. SectionParser의 derived class들이 parseToTreeNode()의 동작을 다르게 구현하기 때문이다.

SOLID 원칙을 생각해 보면, SectionParser는 abstract class의 역할과 text module을 파싱하는 역할 2개를 수행하므로 SRP는 만족하지 않는 것 같다. 이를 위배한 이유는 위와 같이 설명했지만, 더 좋은 방법을 찾지 못한 것이 아쉽다. 이외에 다른 OCP, LSP, ISP, DIP는 딱히 해당사항 없는 것 같다.

AuthClient & Converter

AuthClient

앞서 [공통 형식]을 목적지 블로그에 맞는 형식으로 변환하는 역할을 Converter가 한다고 했다. Converter를 살펴보기 전에 먼저 AuthClient부터 살펴보겠다.

리팩토링 결과 AuthClient & Converter의 dependency tree

// Implement this interface to post other types of blogs.
public interface AuthClient {
    /**
     * Authorize to upload post
     */
    public void authorize() throws Exception;

    /**
     * Upload post in each blog.
     * @param title : post title
     * @param content : post content
     */
    public void post(String title, String content) throws Exception;
}

AuthClient는 authorize()와 post() 2개의 method만 가진다.

디자인 패턴으로는 딱히 적용된 것이 없다.

SOLID 원칙을 생각해 보면, AuthClient는 [목적지 블로그의 API를 사용한다]는 역할만 수행하므로 SRP를 만족하는 것 같다. AuthClient의 구현체는 AuthClient를 수정하지 않고 interface method를 구현해야 하므로 확장할 수 있기 때문에 OCP도 만족하는 것 같다. interface를 사용하므로 DIP도 만족하는 것 같다. LSP나 ISP는 해당 사항 없는 것 같다.

Converter

다음으로 Converter를 살펴보자. Converter는 BlogPost를 받아 목적지 블로그 형식으로 변환한다. 오직 하나의 함수만 있으면 되므로 interface로 이를 구현했다.

// Implement this interface to convert ConvertedTreeNode to other types of blogs.
public interface Converter {
    public String convert(BlogPost blogPost);
}

TistoryConverter는 Converter의 구현체로, 입력으로 받은 BlogPost를 Tistory 형식으로 변환한다. 일단 눈여겨 볼 점은 TistoryClient에 의존하고 있다는 것인데, 이는 조금 이따 설명하겠다.

TistoryConverter는 ConvertedTree의 root부터 특정 StyleType이 나오면 해당 TypeConverter를 호출한다.

ConvertResultVO는 변환 결과 Element와 다음으로 탐색할 ConvertedTreeNode list 2개의 attribute를 가진다.

디자인 패턴으로는 TistoryConverter는 TypeConverter를 생성하므로 Template method pattern을 사용하고, StyleType에 따라 다른 TypeConverter interface의 구현체를 호출해 URL을 처리하므로 Strategy pattern을 사용한다.

SOLID 원칙을 생각해 보면, TistoryConverter는 [BlogPost의 ConvertedTree root를 String으로 변환한다]는 역할만 수행하므로 SRP를 만족하는 것 같다. TistoryConverter의 생성자만 수정하면 다른 종류의 TypeConverter를 추가할 수 있기 때문에 OCP도 만족하는 것 같다. interface에 의존하고 있기 때문에 DIP도 만족하는 것 같다. LSP는 해당 사항 없는 것 같고, TypeConverter interface의 모든 method를 사용하므로 ISP도 만족하는 것 같다.

public class TistoryConverter implements Converter {
    private TistoryClient tistoryClient;
    private static Map<StyleType, TypeConverter> converterMap = new HashMap<>();

    public TistoryConverter(TistoryClient tistoryClient){
        this.tistoryClient = tistoryClient;
        initializeConverterMap();
    }

    private void initializeConverterMap(){
        converterMap.put(StyleType.TABLE, new TableConverter());
        converterMap.put(StyleType.ROW, new RowConverter());
        converterMap.put(StyleType.COLUMN, new ColumnConverter());

        converterMap.put(StyleType.QUOTATION, new QuotationConverter());

        converterMap.put(StyleType.PARAGRAPH_DEFAULT, new DefaultParagraphConverter());
        converterMap.put(StyleType.PARAGRAPH_LEFT, new LeftParagraphConverter());
        converterMap.put(StyleType.PARAGRAPH_RIGHT, new RightParagraphConverter());
        converterMap.put(StyleType.PARAGRAPH_CENTER, new CenterParagraphConverter());

        converterMap.put(StyleType.CONTENT, new ContentConverter());
        converterMap.put(StyleType.LINK, new LinkConverter());
        converterMap.put(StyleType.BOLD, new BoldConverter());
        converterMap.put(StyleType.TILT, new TiltConverter());
        converterMap.put(StyleType.UNDERLINE, new UnderlineConverter());
        converterMap.put(StyleType.STRIKE, new StrikeConverter());
        
        converterMap.put(StyleType.CODE, new CodeConverter());
        converterMap.put(StyleType.IMAGE, new ImageConverter(tistoryClient));
        converterMap.put(StyleType.HORIZONTALLINE, new HorizontalLineConverter());
        converterMap.put(StyleType.NONE, new DefaultConverter());
        // Append other TypeConverter implements here
    }

    @Override
    public String convert(BlogPost blogPost) {
        Element convertedElement = traverseAndConvert(blogPost.getRoot());
        
        return encodeToUTF8(convertedElement.outerHtml());
    }

    private Element traverseAndConvert(ConvertedTreeNode curNode){
        TypeConverter typeConverter = getTypeConverter(curNode.getType());

        ConvertResultVO convertResult = typeConverter.convertAndReturnNextNodes(curNode);
        Element curElement = convertResult.getResult();

        for(ConvertedTreeNode nextNode : convertResult.getNextNodes()){
            Element nextElement = traverseAndConvert(nextNode);
            curElement.appendChild(nextElement);
        }

        return curElement;
    }

    private TypeConverter getTypeConverter(StyleType supportType){
        return converterMap.getOrDefault(supportType, converterMap.get(StyleType.NONE));
    }

    private String encodeToUTF8(String origin){
        try{
            return Utils.encodeToUTF8(origin);
        }
        catch(Exception e) {
            Utils.printMessage(e.getMessage() + " 인코딩을 취소합니다.");
        }
        return origin;
    }
}

위 코드는 TistoryConverter 코드의 일부분이며, 다음 링크에서 열어볼 수 있다. TistoryConverter 코드

TypeConverter 코드는 아래와 같고, TypeConverter의 구현체들은 딱히 특이한 내용이 없으므로 생략하겠다.

// Implement this interface to convert other kind of StyleTypes.
public interface TypeConverter {
    abstract public ConvertResultVO convertAndReturnNextNodes(ConvertedTreeNode node);

    public static String convertContent(String content){
        return content.isEmpty() ? System.lineSeparator() : content;
    }
}

고민했던 점 - interface + static method

TypeConverter의 경우 static method를 사용했는데, ConvertedTreeNode를 변환할 때 content를 변환하는 로직은 모두 공통이기 때문이다. BlogScrapper나 SectionParser의 경우 이 경우와 같이 공통 로직이 있어 abstract class를 사용했다. 그러나 TypeConverter의 경우 interface를 쓰고 공통 로직에 static method를 사용했다.

Java의 경우 상속은 좋은 기능이지만 class 간 의존관계가 명확해지고, 다중상속이 허용되지 않기 때문에 class hierarchy보다는 interface를 사용하는 것이 좋다고 생각한다. 따라서 class hierarchy를 최소한으로 만들어야 했다.

그럼에도 불구하고 BlogScrapper나 SectionParser를 abstract class로 만든 이유는 공통 멤버 변수가 필요했기 때문이었다. BlogScrapper는 에러 메시지 처리를 위해 errorMessages, SectionParser는 평문의 스타일을 매핑한 styleMap을 사용했는데, 만약 interface로 사용하면 이들의 초기화 함수를 생성자에 넣는 과정을 implement할 때마다 추가해야 한다. 이는 번거로운 과정이며, 컴파일러가 경고하지 않기 때문에 초기화 함수를 구현했더라도 생성자에 넣지 않을 수 있기 때문에 초기화가 올바르게 되지 않을 가능성이 더 크다고 생각해 abstract class로 구현했다.

반면 TypeConverter의 경우 이러한 과정이 필요 없다. 단순히 input에 대해 비었는지 검사하고 없으면 System.lineSeparator()를 호출하는 함수가 필요했을 뿐이기에 interface + static method로 구현했다.

Migrator

Migrator는 사용자 입력을 받고, migration 작업을 수행하는 class이며, 각 module들을 조립한다. 제일 큰 class이며, 각 module

UrlProcessor나 Scrapper는 URL에 해당하는 BlogType에 따라 다른 구현체를 호출해야 하지만, 이 각각의 로직은 UrlProcessor와 Scrapper 내부에서 처리하므로 Migrator는 이 class들만 부르면 된다.

디자인 패턴으로는 TargetBlogConfigFactory를 사용하므로 Template method pattern을 사용하고, 목적지 블로그 종류에 따라 다른 TargetBlogConfigFactory의 구현체를 호출해 처리하므로 Strategy pattern을 사용한다.

SOLID 원칙을 생각해 보면, Migratior class는 Migrator 작업을 담당하므로 SRP를 만족한다고 볼 수 있지만, 사용자 입력과 파일 파싱, 모든 module 호출 등 여러 가지를 수행하므로 좀 애매하다. OCP는 만족하는데, 새로운 목적지 블로그가 추가되면 해당 TargetBlogConfigFactory만 구현하면 되기 때문이다. TargetBlogConfigFactory나 AuthClient, Converter를 사용하므로 ISP는 만족하고, LSP는 해당되는 부분이 없다. DIP는 반만 준수하는데, AuthClient나 Converter는 interface인 반면 UrlProcessor와 Scrapper는 concrete class이기 때문이다.

비록 DIP를 준수하지는 않지만 UrlProcessor나 Scrapper는 추상화 수준이 매우 높기 때문에 변경되지 않을 가능성이 농후하다. 때문에 유지보수에는 문제가 없을 것이라 예측된다.

public class Migrator {
    private final UrlProcessor urlProcessor = new UrlProcessor();
    private final Scrapper scrapper = new Scrapper();
    private AuthClient authClient;
    private Converter converter;

    private final List<BlogType> targetBlogTypes = new ArrayList<>();
    private final Map<BlogType, TargetBlogConfigFactory> targetBlogConfigFactoryMap = new HashMap<>();

    public Migrator(){
        targetBlogTypes.add(BlogType.NONE);
        targetBlogTypes.add(BlogType.TISTORY);
        // append other target blog types here

        targetBlogConfigFactoryMap.put(BlogType.TISTORY, new TistoryConfigFactory());
        // append other target blog factories here
    }

    public void migrate(){
        BlogType targetBlogType = getTargetBlogType();
        configureTargetBlog(targetBlogType);

        List<String> urls = loadUrlList();

        Utils.printMessage("[작업 시작] 작업을 시작합니다.");
        for(String url : urls){
            Utils.printMessage("[작업 중] : " + url);
            migratePost(url);
        }
        Utils.getInput("[작업 완료] 작업을 완료했습니다. 프로그램을 종료합니다.");
    }

    private BlogType getTargetBlogType(){
        Utils.printMessage("==============================");
        printTargetBlogTypes();
        Utils.printMessage("==============================");

        String input = Utils.getInput("업로드할 블로그를 선택하세요. 종료를 원하면 0을 입력하세요.");
        BlogType targetBlogType = parseInput(input);

        if(targetBlogType == null){
            Utils.getInput("지원하지 않는 블로그 유형입니다. 프로그램을 종료합니다.");
            System.exit(1);
        }
        if(targetBlogType == BlogType.NONE){
            Utils.getInput("사용자 입력으로 프로그램을 종료합니다.");
            System.exit(1);
        }

        return targetBlogType;
    }

    private void configureTargetBlog(BlogType targetBlogType){
        TargetBlogConfigFactory targetBlogConfigFactory = getTargetBlogConfigureFactory(targetBlogType);
        if(targetBlogConfigFactory == null){
            Utils.getInput("지원하지 않는 블로그 유형입니다. 프로그램을 종료합니다.");
            System.exit(1);
        }

        this.authClient = targetBlogConfigFactory.createAuthClient();
        this.converter = targetBlogConfigFactory.createConverter(this.authClient);
        if(this.authClient == null || this.converter == null){
            Utils.getInput("[오류 발생] 초기화 중 오류가 발생해 프로그램을 종료합니다.");
            System.exit(1);
        }
    }

    private TargetBlogConfigFactory getTargetBlogConfigureFactory(BlogType targetBlogType){
        if(targetBlogConfigFactoryMap.containsKey(targetBlogType)){
            return targetBlogConfigFactoryMap.get(targetBlogType);
        }
        return null;
    }

    private void migratePost(String url){
        try{
            BlogPost blogPost = scrapper.scrap(urlProcessor.process(url));
            String title = blogPost.getTitle();
            String convertedContent = converter.convert(blogPost);
            authClient.post(title, convertedContent);
        }
        catch(Exception e){
            Utils.printMessage(e.getMessage() + " " + url);
        }
    }

}

위 코드는 Migrator 코드의 일부분이며, 다음 링크에서 열어볼 수 있다. Migrator 코드

고민했던 점 - TistoryClient에 의존하는 TistoryConverter

티스토리의 포스트 구조를 보면 이미지는 첨부 파일의 형식으로 올린 후 해당 첨부 파일을 미리 보는 replacer라는 것을 사용해 이미지를 표시한다. 따라서 이미지를 업로드하기 위해 Tistory API를 사용하는 TistoryClient에 의존해야만 했다. 반면 Migrator에서는 Converter와 AuthClient만 호출하는 상황이고, Converter와 AuthClient는 직접적으로 의존관계가 없다. 의존관계는 TistoryConverter와 TistoryClient에만 있다.

이를 해결하기 위해 Factory method pattern을 사용했다.

Converter, AuthClient의 Factory

Abstract factory pattern을 사용한다. UrlProcessor나 Scrapper는 URL에 해당하는 BlogType에 따라 다른 구현체를 호출해야 하지만, 목적지 블로그는 하나이므로 Converter와 AuthClient는 구현체를 바로 불러오면 된다. 이 때 TistoryConverter와 TistoryClient의 명시적인 의존성을 줄이기 위해 Abstract factory pattern을 사용했다.

public interface TargetBlogConfigFactory {
    public AuthClient createAuthClient();
    public Converter createConverter(AuthClient authClient);
}

public class TistoryConfigFactory implements TargetBlogConfigFactory {
    @Override
    public AuthClient createAuthClient() {
        try{
            return new TistoryClient();
        }
        catch(Exception e){
            Utils.printMessage(e.getMessage());
        }
        return null;
    }

    @Override
    public Converter createConverter(AuthClient authClient) {
        try{
            return new TistoryConverter((TistoryClient) authClient);
        }
        catch(Exception e){
            Utils.printMessage(e.getMessage());
        }
        return null;
    }
}

테스트 코드

Naver2Tistory Unit Test

TistoryClient가 들어있는 부분 빼고는 가능한 한 많은 module들에 unit test code를 작성했다.

coverage를 측정하고 싶은데 순수 java 프로젝트는 jacoco test coverage를 확인할 수가 없어서, 임시로 maven 프로젝트를 하나 만들고 그 내부에서 jacoco coverage를 돌렸다. 패키지 앞의 aaaa.는 임시로 붙여둔 거니까 무시하고 생각하면 된다.

직접 API 통신을 해야 하는 auth 패키지, 전체를 통합하는 migrator 패키지, http 연결 등이 있는 util 패키지를 제외하고는 85%의 커버리지가 나온다. 낮게 나온 3가지 패키지를 확인해 보자.

scrappers 패키지

직접 블로그에서 scrap하는 동작이 없기 때문에 전체가 coverage 0%로 나온다. `BlogScrapper.java`는 오류 부분만 빨간 줄.

음.. 내가 작성한 것은 unit test고, 이쪽은 통합 테스트 쪽에 가까워서.. 추후 시간이 나면 통합 테스트를 작성하는 식으로 가야 하나 고민이 된다.

tistory 패키지 - TistoryConverter

TypeConverter 패키지는 3항 연산자에서 하나를 확인 안해서 71%이고, `TistoryConverter.java`의 경우 위와 마찬가지로 통합 테스트가 없다보니 `convert()`가 호출되지 않아서 그런 듯 하다.

tistory.typeConverter

`ImageConverter`만 매우 낮게 나오는데, 다른 converter들은 string을 입력으로 받는 테스트 케이스를 작성했는데, image는 테스트 코드에 resource를 할당하지 않았기 때문이다. 그래서 동작만 확인해서 밑에 다 빨간 줄 나는 것 같다.

총평

시간이 나면 통합 테스트를 작성해서 전체 커버리지를 올릴 수 있도록 하는 게 좋을 것 같다.

후기

이렇게 모든 리팩토링한 내용을 살펴봤다. 코드를 짜면서 Clean Code를 읽으면서 느꼈던 읽기 좋은 코드, Clean Architecture를 읽으면서 느꼈던 유지보수하기 좋은 코드, SOLID principles를 보면서 배웠던 점들을 최대한 적용하려 고민했고, 그 결과로 마음에 드는 부분도, 배운 것도 많은 과정이었다.

목표 달성?

리팩토링을 시작했을 때 아래와 같은 4가지를 달성하고자 했었다.

주석 삭제. 의도를 설명한 주석, 유지보수 시 참고가 될 만한 주석만 남기고 모두 삭제. JavaDoc은 필요한 public 함수에만 남기고자 했다.
예외처리를 간소하게. 곳곳에 퍼져 있는 try-catch문을 응집시키고자 했다.
최대한 의존성을 줄이고 확장성 있게 코드를 작성하고자 했다.
- 이 프로그램은 Naver2Tistory이지만 추후에 Naver2Notion처럼 목적지 블로그를 추가할 수도 있고, Medium2Tistory처럼 출발지 블로그를 추가할 수도 있다고 가정했다.
- 현재 지원하는 스타일 이외에 다른 스타일들이 추가될 수 있다고 가정했다.
- 의존성을 줄이기 위해서 interface나 abstract class를 사용하고, if-else문을 줄이기 위해 map을 사용하는 방식을 채택했다.
테스트 코드 작성. 사용자 아이디/패스워드가 필요한 TistoryClient와 TistoryClient를 사용하는 class를 제외하고는 최대한 unit test를 진행하고자 했다.

일단 필요없는 주석들은 대부분 지웠고, 주석은 최대한 지우되 유지보수하는 사람의 입장에서 필요한 부분에만 남기고자 했다. 예를 들면 interface의 구현체를 어디에 추가하면 되는지 등등.

try-catch문도 상당히 응집시켰다. UrlProcessor, Scrapper, Converter, AuthClient들은 모두 Exception을 던지기만 하고, 이 module을 직접적으로 사용하는 TargetBlogConfigFactory와 Migrator에서 모든 Exception들을 받아 처리하게 만들었다.

interface, abstract class 등을 다양하게 사용해 의존성을 줄였고, strategy pattern을 사용해 확장하기 쉬운 코드를 작성했다.

테스트 코드도 작성했다!

초기에 설정한 목표들은 모두 달성한 것 같다.

배운 점들

interface와 abstract class의 사용 구분

일단 배운 점들 중 하나는 언제 interface/interface + static method/abstract class를 사용하는지 나름의 철학이 생겼다는 것이다.

일단 interface를 사용하고
공통 함수만 필요한 경우 static이나 default를 사용하고
1. 만약 static으로 처리할 수 있는 변수면 interface를 사용한다.
2. 만약 abstract class를 사용하는 것이 유지보수에 이점이 있다고 판단하면 abstract class를 사용한다.
멤버 변수가 필요한 경우 abstract class를 사용한다.

strategy pattern

다음으로 배운 것은 Strategy pattern이었다. 사용하면 코드 복잡도가 올라간다는 단점이 있지만, 유지보수가 매우 쉬워지고 시간복잡도가 O(n)인 if-else문에 비해 map을 사용하면 O(logn)으로 처리할 수 있다는 시간적 이점도 있었다.

한편, template method pattern과 abstract factory pattern도 사용했는데 이 둘의 차이점에 대해서도 알아야 할 것 같다.

template method pattern은 사실상 interface 구현체나 abstract class의 상속을 사용한 polymorphism을 사용하는 기법이고, abstract factory pattern은 object를 생성하는 기법이다... 이 정도.

느낀점

이렇게 확장성과 유지보수성을 신경쓰면서 코드를 짜니 닥치는 대로 구현하는 방식보다 배는 많은 시간이 들어갔다. 특히 초반에 설계 부분에서 많은 시간이 걸렸다. 그러나 이렇게 구조화하면서 짜니, 처음 설계가 어려웠지 코드 구현은 생각한 대로 쭉쭉 짜졌다. 물론 중간에 생각치 못했던 여러 이슈들이 있었지만(고민했던 점들) 모듈화가 잘 되어 있었기에 이들을 해결하기 쉬웠다.

또 하나 느낀 점은, unit test code를 꼭 작성해야 한다는 것이다. unit test를 실행함으로써 해당 module이 잘 작동한다는 것을 바로바로 알 수 있었기 때문에 테스트에 걸리는 시간이 확 줄게 되었다. 아무리 처음에 설계를 잘 짜더라도 구조를 조금씩 조금씩 바꿔가는 일이 무조건 생겼는데 unit test로 인해 원래 작동하던 것이 잘 작동함을 보장받으니 마음이 너무 편했다. 처음에 만드는 것은 귀찮았지만...

또, module을 쓰고 바로바로 테스트 코드를 돌리면서 결과를 볼 수 있었어서 더 좋았던 것 같다.

23.08.21. 풀었던 문제들 복기

hyelie — Mon, 21 Aug 2023 17:37:42 +0900

Leetcode 459. Repeated Substring Pattern, 15분

주어진 대로 구현만 하면 되는 문제.

일단 substring으로 원 string을 표시하기 위해서는 substring의 길이가 s의 약수여야 한다. 만약 그렇다면, 해당 substring을 q개(s.length()/substr.length())만큼 만들어서 전체를 살펴보면 된다.

// Runtime 19 ms Beats 64.17%
// Memory 15.4 MB Beats 38.41%

class Solution {
public:
    bool repeatedSubstringPattern(string s) {
        int len = s.length();
        for(int i = 0; i<len/2; i++){
            if(len % (i+1) == 0){
                string substr = s.substr(0, i+1);
                bool repeated = true;
                for(int q = 1; q<len/(i+1); q++){
                    if(s.substr(q*(i+1), i+1) != substr) {
                        repeated = false;
                        break;
                    }
                }
                if(repeated) return true;
            }
        }
        return false;
    }
};

23.08.17. 풀었던 문제들 복기

hyelie — Thu, 17 Aug 2023 18:11:36 +0900

Leetcode 542. 01 Matrix, 20분

0과 1만 있는 matrix에서 0으로부터 거리를 리턴하면 되는 문제.

나는 BFS를 사용했다.

모든 0지점부터 BFS 탐색을 시작한다. 단, 갱신할 수 없는 위치라면(다른 0으로부터 더 가깝다면) 그곳은 탐색하지 않는다.
하나의 최적화를 추가하는데, 0에서 BFS를 각각 수행하는 것이 아니라(그렇게 하면 BFS가 10000번 수행될 수도 있다.)
- 모든 0을 queue에 넣고 한 칸씩 BFS 해 나가는 것이다. 그러면 0에 인접한 칸은 그 개수만큼 방문하지만, 다음 갱신할 칸은 1번씩만 방문한다.

그러면 worst case 최대 1만번 겹치는 탐색이 존재하고, 모든 칸을 1만번씩 방문하게 되므로 시간 내에 충분히 풀 수 있다.

// Runtime 62 ms Beats 91.36%
// Memory 30.2 MB Beats 86.75%

typedef pair<int, int> pii;
int dr[4] = {1, 0, -1, 0};
int dc[4] = {0, 1, 0, -1};

class Solution {
public:
    vector<vector<int>> updateMatrix(vector<vector<int>>& mat) {
        int m = mat.size(), n = mat[0].size(), INF = 10001;
        vector<vector<int>> answer(m, vector<int>(n, INF));
        queue<pii> q;
        for(int i = 0; i<m; i++){
            for(int j = 0; j<n; j++){
                if(mat[i][j] == 0){
                     answer[i][j] = 0;
                     q.push({i, j});
                }
            }
        }

        while(!q.empty()){
            pii cur = q.front(); q.pop();
            for(int i = 0; i<4; i++){
                int nr = cur.first + dr[i];
                int nc = cur.second + dc[i];
                if(0 <= nr && nr < m && 0 <= nc && nc < n && answer[cur.first][cur.second] + 1 < answer[nr][nc]){
                    answer[nr][nc] = answer[cur.first][cur.second] + 1;
                    q.push({nr, nc});
                }
            }
        }

        return answer;
    }
};

시간복잡도

BFS에 O(V+E)인데 V = 1만, E=4만, 추가적으로 O(V)만큼의 시간이 필요하다. 그러니까 O(V)이다. (V는 1만)

공간복잡도

정답 배열을 만들기 위해 O(mn) size 배열을 만들어야 한다.

BOJ 14725. 개미굴, 25분

이 문제는 그다?지 어렵지 않은 문제다. tree의 개념과 tree traverse를 알고 있다면 간단하게 풀 수 있는 문제. 단, [어떤 node의 child들이 여러 개가 들어갈 수 있다는 것 + child들이 이름 순으로 정렬되어야 한다는 것]을 유의해야 한다.

일단 child들이 여러개가 들어갈 수 있으며 정렬되어야 하기 때문에 vector는 사용하지 않았다. 정렬하기 힘들기 때문이었다. 그러면 set, map이 남는데... set은 비교 함수를 만들어야 해서 map을 사용했다. child의 먹이 이름을 key, child node를 value로 설정했다. 그러면 child 먹이 이름을 사용해 쉽게 접근할 수 있을 뿐더러 정렬도 되어있기 때문에 위 조건을 만족하기 쉬웠다.

메모리까지 최적화하기 위해서는 set을 사용하는 것이 낫다. 내가 구현한 것은 map key에 name이 들어가고, 또 node에도 name이 들어가기 때문이다. 그러나 속도를 위해 이렇게 구현했다.

struct Node{
    string name;
    map<string, Node*> childs;
};

Node* root = new Node();

int N;

// 순회하며 먹이 이름을 출력
void traverse(Node* cur, int depth){
    for(int i = 0; i<2*depth; i++) cout<<'-';
    cout<<cur->name<<'\n';

    for(auto &elem : cur->childs){
        traverse(elem.second, depth+1);
    }
}

void solve(){
    // 입력과 동시에 tree 구성
	cin>>N;
    int K;
    for(int i = 0; i<N; i++){
        cin>>K;
        string name;
        Node* cur = root;
        for(int j = 0; j<K; j++){
            cin>>name;
            if(cur->childs.find(name) == cur->childs.end()){ // 없는 경우 새로 만들어 넣음.
                Node* new_node = new Node();
                new_node->name = name;
                cur->childs[name] = new_node;
                cur = cur->childs[name];
            } else{ // 있는 경우 기존 것으로 이동
                cur = cur->childs[name];
            }
        }
    }

    // traverse 및 출력
    for(auto &elem : root->childs){
        traverse(elem.second, 0);
    }
}

시간복잡도

먹이 정보 개수 N은 1000보다 작으모, 각 먹이 정보 개수의 길이는 15보다 작다. 즉, depth가 최대 15인 tree이며 width가 최대 1000이라는 뜻이다. 그러면 worst case node 개수는 15000이다.

tree traverse에 O(V+E)가, tree에 넣을 때 O(depth * logN)만큼이 걸린다. 그러면 O(V+E)가 더 우세하므로 O(15000)정도 걸릴 것으로 예상된다.

공간복잡도

node 개수는 worst case 15000개이므로 O(15000)이다.