DevMemo

병렬처리 설계를 할 때 살펴보아야 할 3가지 포인트가 있습니다. 1. 확장성(Scaling) 코어 개수의 변화에 따라 성능이 더욱 좋아지도록 설계를 하여야 합니다. 데이터 병렬처리에서 100개의 데이터를 처리한다고 하였을 때 코어가 2개일 때는 각각 50개씩, 코어가 4개일 때는 각각 25개씩 처리할 수 있게 설계하는 것 같은 것이 좋은 예일 것입니다. 2. 적절성(Correctness) 병렬 처리를 통한 성능 향상에 최적화되도록 설계를 하여야 합니다. 병렬처리 프로그래밍은 멀티 쓰레드가 동시에 한 자원에 접근하였을 때 발생하는 동기화 문제가 발생할 수 있습니다. 또한 데드락 문제도 발생할 수 있습니다. 이는 멀티 쓰레드의 개별 쓰레드처럼 병렬 처리의 각각의 쓰레드도 처리를 위하여 자원을 사용하기 때문입..

병렬처리는 사용 개념적으로 보았을 때 크게 데이터 처리 기반 병렬처리와 태스크 처리 기반 병렬처리로 나누어 질 수 있습니다. 데이터 처리 기반 병렬 처리(Data Parallelism) 큰 데이터를 분할하여 여러 개의 프로세스가 처리하는 것을 말합니다. 간단히 4개 코어를 기반으로 100개의 데이터를 처리한다고 하였을 때 1~25, 26~50, 51~75, 76~100 이렇게 데이터를 나누어서 4개의 코어가 각각 처리하는 것을 예로 들 수 있습니다. 이렇게 처리하면 데이터를 처리하는 부분은 이론적으로 N배의 성능 향상을 가져올 수 있습니다. 태스크 처리 기반 병렬 처리(Task Parallelism) 여러 개의 작업을 각각의 프로세스에게 분배하여 다중 처리하는 것을 의미합니다. 3개의 코어가 3개의 함수..

병렬처리를 한다고 무조건 성능 향상이 되는 것은 아닙니다. 병렬처리를 하여 성능이 향상될 수 있는 부분이 존재할 때 성능이 향상될 수 있습니다. 병렬처리를 하여 성능이 향상되는 부분이란 쉽게 이야기 하여 처리를 여러 개의 코어에서 나누어 연산할 수 있는 부분을 의미합니다. 병렬처리를 통한 성능 향상은 전체 처리의 관점에서 보아야 합니다. 부분에서의 몇 백%의 성능 향상을 할지라도 그게 전체 처리에서의 몇 백%의 성능 향상을 의미하지는 않기 때문입니다. 그럼, 병렬처리를 통하여 어느 정도의 성능 향상을 가져올 수 있을까요? 이 문제에 대하여 이론적인 계산을 가능하게 하는 방법이 암달의 법칙입니다. 암달의 법칙은 연산의 P비율만큼만 병렬화가 가능하여 S만큼의 성능 향상이 있을 경우, 최대 속도 향상은 1 /..

오래 전에는 프로세스에 코어라는 개념으로 이야기한다면 1개의 코어만을 가지고 있었습니다. 또한 여러 개의 프로세스를 가지는 경우는 서버나 워크스테이션 같은 고가의 컴퓨터에만 존재하였습니다. 이 때는 병렬 처리는 대중적이지 않았습니다. 하지만 하나의 프로세스에 N개의 코어를 가지는 컴퓨터가 대중화된 현재 시점에서는 멀티 코어를 활용하여 성능을 올리는 것이 점점 대중화되고 있습니다. 대표적으로 최신 게임 중에서 멀티 코어를 활용하여 성능을 올리는 것을 찾아보는 것은 그리 어렵지 않습니다. 잠시 병렬 처리의 대중화를 만들고 있는 멀티 코어가 CPU 구조에서 대세가 된 배경을 잠시 살펴보면 아래와 같습니다. CPU의 클럭이 발열과 추가적인 전기 소모 문제로 현재 이상의 높은 클럭으로 가기가 쉽지 않습니다. 또한..

병렬처리 혹 다른 표현으로 멀티프로세스 프로그래밍이란 쉽게 이야기하여 하나의 프로그램을 하나의 프로세스가 아닌 N개의 멀티 프로세스를 이용하여 개발하는 것을 의미합니다. 이렇게 개발하는 이유는 여러 개의 프로세스를 동시에 활용하여 성능을 향상시키기 위함입니다. 참고로 최근에는 쓰레드 별로 프로세스를 할당하여 비슷하여 보이지만 기본적으로 하나의 프로세스에서 N개의 쓰레드를 실행하는 멀티쓰레드 와는 다른 개념입니다. 멀티 쓰레드 프로그래밍은 IO 관련 처리에서 비약적으로 성능을 향상시켜주는 데 비하여 멀티 프로세스 프로그래밍, 병렬 처리는 CPU 관련 처리에서 비약적으로 성능을 향상시켜줍니다.

IO 관련 처리란 파일 처리, 소켓 처리와 같이 용어 그대로 IO 관련 처리를 말합니다. CPU 관련 처리란 연산 관련 처리를 말합니다. 이 둘의 처리에 대해서 말하는 이유는 이 둘을 구분하여 현재 프로그램을 보는 것이 성능을 크게 향상 시킬 수 있기 때문입니다. IO 관련 처리와 같은 경우 관련 IO API를 호출한 뒤에 API내에서 IO처리를 하는 동안 CPU가 노는 경우가 생길 수 있습니다. 이런 경우 성능을 올리기 위해서는 비동기 IO를 사용하거나 IO쓰레드를 만들어서 비동기적으로 처리하여 CPU가 노는 시간을 줄여 성능을 올릴 수 있습니다. CPU 관련 처리와 같은 경우 성능 좋은 알고리즘을 사용하여 연산을 줄이거나 멀티프로세스 프로그래밍을 활용하여 성능을 올릴 수 있습니다. 흔히 하는 실수가 ..

폴(Poll) 방식의 네트워크 처리란 쉽게 말하여 주기적으로 소켓에 데이터가 왔는지를 체크하고 처리하는 방식입니다. 보통 처리 방식을 슈도 코드로 나타내면 아래와 같을 것입니다. while(true) { bool data_recieved = 소켓에 받은 데이터가 있는지 체크(); if (data_recieved) { 소켓 데이터 처리(); } 소켓처리 외의 로직(); } 이런 방식을 사용하는 이유는 네트워크 처리 외의 로직을 네트워크 처리 쓰레드에서 함께 하기 위함입니다. 물론 이런 폴(Poll) 방식를 사용하지 않고 네트워크 처리 쓰레드와 네트워크 처리 외의 로직 쓰레드를 분리하여 처리하고 양쪽 쓰레드들에서 사용하는 공유 객체와 같은 경우 동기화 처리를 할 수도 있습니다. 이런 폴(Poll) 방식을 이..

유니코드를 출력하는 wcout이나 유니코드를 인자로 요구하는 함수와 같은 경우 __FUNCTION__, __FILE__이 제대로 출력되지 않습니다. 구글링 해보면 #define을 이용하여 새롭게 정의하여 출력하는 방식이 나와 있습니다. 처음에는 그렇게 사용했는데 비주얼스튜디오와 같은 경우(현재 2019 이용) 해당 __FUNCTION__, __FILE__의 유니코드 버전인 __FUNCTIONW__, __FILEW__을 corecrt.h에서 정의하고 있었습니다. 어느 버전부터 지원하는 지는 모르겠지만 최신 비주얼 스튜디오를 사용하신다면 그냥 __FUNCTION__, __FILE__을 유니코드로 사용하여야 한다면 __FUNCTIONW__, __FILEW__을 사용하시면 됩니다.

invoke_result는 C++ 17부터 추가된 함수의 리턴 타입을 알아내는데 사용되는 함수 입니다. 기존에는 C++ 11에 추가된 result_of가 사용되었는데 C++ 20에서 삭제된 관계로 더 이상 result_of는 사용할 수 없습니다. 해당 함수는 템플릿을 프로그래밍을 할 때 사용할 수 있는 함수인 관계로 일반적인 프로그래밍에는 별로 사용되지 않을 듯 보입니다. 사용법은 invoke_result::type 입니다. 비주얼 스튜디오에서 제대로된 인자를 넣지 않을 경우 인텔리센스에서 멤버로 type이 나오지 않습니다. 아래 예제는 std::result_of, std::invoke_result(https://en.cppreference.com/w/cpp/types/result_of)을 응용하여 작성..

C++ 11에 추가된 것으로 기존 assert이 실행 시간에 오류를 검증하는데 비하여 static_assert은 컴파일 타임에 오류를 검증합니다. static_assert은 컴파일 타임에 오류를 검증할 수 없는 변수 값을 대입하는 경우 상수 값이 있어야 한다는 오류를 냅니다. 이런 특성을 가진 관계로 주로 템플릿 프로그래밍에서 타입 체크 등에서 사용됩니다. 비주얼 스튜디오에서는 코드 작성 중에 static_assert이 false일 경우 표시를 해주어서 편합니다. 사용 예는 아래와 같습니다. static_assert(1

Unity 스크립트를 비주얼 스튜디오에서 수정 및 저장 후 Unity로 돌아오면 Reload Script... 혹은 Hold... 와 같은 타이틀을 가진 스크립트 관련 대화상자가 뜨면서 기다리게 됩니다. 비주얼 스튜디오에서 수정 및 저장한 후에 솔루션 빌드를 하고 Unity로 돌아오면 해당 대화상자가 뜨지 않거나 상대적으로 짧은 시간 뜨는 것을 확인할 수 있습니다. 솔루션 빌드 시간은 Unity가 변경된 스크립트 관련 처리를 하는 시간에 비하여 상대적으로 적은 시간 만을 필요로 합니다. 작은 팁이지만 해당 방법은 실제적으로 개발 시간을 많이 줄여줄 수 있습니다.

가변 인자를 받는 함수에서 가변 인자들을 가변 인자를 받는 다른 함수를 호출할 때 ...를 생략할 때 발생할 수 있습니다. 에러가 발생하는 아래 예제 코드를 살펴보겠습니다. template void thread_log_t(const std::wstring fmt, arguments ... args) { wstring str = format_string(L"thread[%d]: ", std::this_thread::get_id()); str += format_string(fmt, args ...); str += wend_line; wcout args ... 와 같이 가변 인자를 제대로 넘기면 에러가 해결됩니다. 가변 인자를 넘기기 위하여 ...가 추가되었다는 것에 주의바랍니다. 해당 에러가 수정된 코드 예..

boost asio io_service(io_context)를 통하여 이벤트를 호출하는 방식은 크게 poll과 run으로 나눈다고 할 수 있습니다. 간단히 두 방식을 살펴보면 아래와 같습니다. poll은 이름 그대로 poll방식으로 이전 poll 호출 후 쌓인 socket 이벤트를 실행하고 제어권을 함수를 호출한 쪽에 넘깁니다. run은 socket 이벤트를 실행하고 제어권을 함수를 호출한 쪽으로 넘기지 않고 다음 이벤트를 기다립니다. poll로 run을 구현한다고 한다면 아마 아래와 같은 코드가 될 것입니다. while(true) { poll(); } 서버에 연결하는 클라이언트에서 사용된다면 아마도 poll이 좋은 선택이 될 것입니다. 문제는 서버와 같은 경우는 이 두가지 중 어느 방식을 사용할지는 서..

유니티 쉐이더 그래프를 설명한 동영상입니다. 저자가 설명을 잘한 관계로 상대적으로 짧은 시간에 이런 것이 쉐이더구나라는 이해가 들것입니다. 여기서 영감을 얻어 쉐이더 그래프를 코드로 작성하는 것도 좋을거 같습니다.