MIDAS LOG

11.01

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

드디어 출시... 출시하느라 밀렸던 문서들 작성하고, 출시하면서 겪었던 인스톨관련 문제점들 개선하기

11.04

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

드디어 출시... 출시하느라 밀렸던 문서들 작성하고, 출시하면서 겪었던 인스톨관련 문제점들 개선하기

11.05

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

문서 작성

11.06

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

문서 작성

자잘한 UI들 개선

11.07

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

문서 작성

자잘한 UI들 개선

11.07

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

문서 작성

자잘한 UI들 개선

11.08

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

문서 작성

자잘한 UI들 개선

11.11

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

신입사원 교육

문서 작성

자잘한 UI들 개선

11.12

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

신입사원 교육

문서 작성

자잘한 UI들 개선

11.13

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

DB Core System : DB 변수 정의하기

(DB Reflection 개발 중, DB의 변수들은 제한되게 관리되어야 할 필요성을 느꼈다.) 1. Size 제한 (Data 별 Offset 관리가 확실하게 되어야 함) -> 전 버젼 DB 호환이 가능해짐 2. Query로 확장시키기 위한 제한 3. Polymorphic 자료형의 위험성 4. 많은 자원 낭비 (충분히 작은 크기의 데이터로 표현할 수 있는데 큰 데이터로 정의할 경우)

메뉴얼 작성!

//////////////////////////////////////////////////////////////////////////
// 사용가능한 MIDAS DB 변수
//
// MIDAS Object 정의
// * Vector Type의 정의는 MTArray 사용할 것 (In MTArray.hpp)
// 1) MKey (In here)
// 2) MIterator (In here)
// * 4 or 8 : MIterator(DWORD_PTR) : System Dependent
// * DWORD_PTR 존재의 이유
// Polymorphic 자료형 : 다양한 모습이 있는, 다형적 이라는 뜻
// 포인터 기반의 자료를 표현하기 위해 만들어진 자료형
// 컴퓨터의 주소 비트(32비트 또는 64비트) 환경에 따라 주소를 표현할 수 있는 크기가 다르다.
// 그렇기 때문에 어떤 데이터의 주솟 값의 변수를 다형적으로 표현해야 할 요구사항이 생겨났기 때문이다.
// 우리의 MData의 주솟 값을 나타내는 MIterator도 사실은 DWORD_PTR 이 아이이다.
// 3) MVector (In here)
// 4) MPlane (In here)
// 5) MMatrix (In MMatrix.hpp)
// * MMatrix 의 Reflection 정의 방법
// 이차원 배열은 Reflection 변수 정의 타입 중 지원할 수 있는 타입이 없기 때문에, 하나씩 Reflection을 추가하도록 한다.
// ex) InstancingDef.h
//
// 문자열 관려 (In MShortStr.hpp)
// 16 : MParamStr
// 32 : MShortStr
// 64 : MStr;
// 128 : MLongStr;
// 260 : MPathStr;
//
// 일반 데이터 정의
// Reference : https://docs.microsoft.com/ko-kr/cpp/cpp/data-type-ranges?view=vs-2019
//
// 1) 불리언 타입 변수
// 4 : BOOL (사실 난 없애고 싶음..ㅠㅠ)
// 1 : bool
// 2) 정수형 변수
// 1 : char
// 1 : unsigned char, BYTE
// 2 : short
// 2 : unsigned short, wchar_t
// 4 : int (Typically 2 bytes on old architectures)
// 4 : unsigned int, UINT(얘도 없애고 싶음ㅠㅠ)
// 4 : long
// 4 : unsigned long
// 8 : long long
// 8 : unsigned long long, size_t
// 3) 실수형 변수
// 4 : float
// 8 : double
// 4) Enum, Enum Class (Same as int)
// 5) Color (Same as int)
//////////////////////////////////////////////////////////////////////////

신입사원 교육

문서 작성

자잘한 UI들 개선

11.14

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

DB Core 계속!

신입사원 교육

문서 작성

자잘한 UI들 개선

11.15

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

Code Review

DB Core 계속!

신입사원 교육

문서 작성

자잘한 UI들 개선

11.18

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

Code Review

DB Core 계속!

신입사원 교육

문서 작성

자잘한 UI들 개선

11.19

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

Code Review

DB Core 계속!

신입사원 교육

DB Reflection 설계

구조체 메모리 패킹

  1. 왜 구조체의 메모리 패킹 방식을 정렬해 놓을까?

    • 바이트 패딩 : 적은 수의 컴파일러는 구조체의 필드를 메모리에 위치시킬 때, 중간에 빈 공간 없이 쭉 이어서 할당한다. 하지만 대부분의 컴파일러는 성능 향상을 위해 CPU가 접근하기 쉬운 위치에 필드를 배치하는데 이를 바이트 패딩이라고 한다. 그리고 중간에 빈 공간에 들어간 것을 패딩비트 라고 한다.

    • 참고로 OS 32bit 환경에서는 4바이트 패킹 방식이 빠르고

    • OS 64bit 환경에서는 8바이트 패킹 방식이 빠르다고 한다.

  2. 왜 빠를까?

    • 패딩 비트가 없을 경우 어떤일이 일어나는지 생각해보자.

    • CPU는 메모리를 읽어올 때 한번에 4바이트 혹은 8바이트를 읽어온다.

    • ex) char 변수 1, int 변수 1이 있는 구조체를 생각해보면, 32 bit OS의 컴퓨터는 int 변수를 읽기 위해, 2~4 바이트에 위치한 메모리를 읽기 위해 첫 4바이트의 메모리를 읽는다. 그리고 5바이트에 위치한 나머지 int의 메모리를 읽기위해 또 4바이트의 메모리를 읽는다. 즉 만약 패딩 비트로 char 뒤에 3바이트가 채워져있었다면, int 변수를 읽기위해 한번만 메모리를 읽어도 될 것을 2번 읽게 된 것이다. 이런 식으로 구조체 메모리 패킹 방식을 정렬해놓으면 쓸데 없이 메모리를 읽는 것을 막기 때문에 성능저하가 발생하지 않는다.

    • Visual Studio 컴파일러 MSVC는 Default Packing 방식이 8바이트로 지정되어 있다. (운영체제에 의존하는 방식이 아닌, 컴파일러에 의해 정해짐을 유의한다.)

  3. 어디에 주로 쓰일까?

    • 네트워크를 통한 구조체 전송시 바이트 패딩이 중요하다고 한다.

      • 서로 다른 컴퓨터 시스템에서 메모리를 읽는 방식이 다르기 때문에, 패킹 시 채워진 패딩비트 때문에 각 컴퓨터에서 구조체를 다르게 읽을 수가 있기 때문 (그 시기에는 패킹 정렬 방식을 1바이트로 맞춰 놓는다고 한다.) 더해서 그 상태에서 직렬화 한 후 전송하여 퍼포먼스도 향상시키는 방법을 사용한다고 한다.

  4. 8 byte packing이라는 것은 무엇일까.

    • 메모리가 들어가는 것을 보니, 디폴트 패킹 방식이 8바이트여도 구조체의 크기가 8의 배수로 맞춰지지 않는다. 왜 그럴까?

    • 8 byte packing이라는 것은 구조체의 정렬 방식을 8의 배수로 맞추겠다는 게 아니라, 8 보다 큰 변수가 있을 경우 정렬을 포기하겠다는 뜻이다.

    • 즉 만약 패킹 크기를 4로 바꾼다면, double이나 long long 같은 타입들이 사용되었을 때는 더이상 정렬을 보장하지 않게된다. 그러므로 default packing 방식이 8인 것이다.

의문점

  1. 8바이트 패킹 방식이 OS bit에 의존적인 프로그램이 아닐 경우 기본적으로 빠르고, 좋은 것은 알겠다.

  2. 허나 읽는 속도는 빨라질지언정 전체 클래스의 크기는 늘어나게 될 것이다.

  3. Ram에서 올라가는 메모리가 느는 것!

  4. 파일에 저장하는 것은 어차피 JSon + 직렬화를 이용한다.

  5. 사용자가 RAM에 더 큰 메모리가 올라가도 괜찮겠지..

11.20

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

Code Review

DB Core 계속!

신입사원 교육

11.21

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

Code Review

DB Core 계속!

신입사원 교육

구조체 메모리 패킹 퍼포먼스 실험

실험 1. 실무 검증 (Release 환경)

  • DB의 모든 구조체를 4바이트 패킹했을 시와, 8바이트 패킹했을 시

  • 실무에서 사용하는 389개의 리그레션 테스트 모듈을 모두 돌렸을 때의 시간을 비교

  • 결과 시간 차이 없음 (측정하기 불가능할 정도로)

실험 2. 더미 데이터(테스트 베드) 구축

  • 64bit os에서 4바이트 패킹한 구조체 중 막대하게 손해볼 수 밖에 없는 구조체를 가상으로 생성

  • 여러 반복을 통한 시간 검증 (8바이트 패킹과, 4바이 패킹에 대한 시간 비교)

  • 100000000의 반복문에서 한 구조체를 메모리에 올렸다가 내렸다가 한 결과

  • 4byte packing 시 8.3 ~ 8.5초, 8byte packing 시 7.09 ~ 8.03초

  • 약 0.3초의 시간이 차이나는 것이 의미가 있는지 모르겠다...

  • 비율로 봐도 얼마 차이가 없다.

  • 아마 OS단에서 캐싱하거나, CPU가 알아서 너무 반복적인 작업은 한번에 처리하는 알고리즘? 이 있는 것 같다.

결론

  • 블로그에서 다들 오버헤드가 엄청 난다. c++ 프로그래머는 변수의 순서를 맞춰 메모리 정렬을 맞춰야 한다.

  • 이런 얘기를 하는데, 직접 실험해본 결과 의미가 있는 행위인지 잘 모르겠다.

  • 어쨋든 테스트 베드 환경을 만들던, 실무 모델로 테스트 하던 차이가 없었고, 이런 환경에서 OS, CPU, 컴파일러 누가 최적화 해줬던 간에 일반 개발자들은 구조체 메모리 정렬을 생각하며 개발해야 한다는 것에 동의하지 못할 것 같다...

  • 네트워크 개발 시 서로 다른 OS별 bit 수가 다를 때 1바이트로 packing 해야하는 경우 말고는 의미 없는 것 같다.

그 외

  • 구조체 안의 구조체 변수는 메모리 정렬을 안해줌!! 신기 (MSVC 기준)

11.22

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

Code Review

DB Core 계속!

신입사원 교육

11.25

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

DB Core 계속!

개발자의 글쓰기

  • 조사, 순서, 숫자, 하다, 기호만 붙이고 나머지는 띄어쓴다.

11.26

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

MDay

DB Core 계속!

개발자의 글쓰기

  • 조사, 순서, 숫자, 하다, 기호만 붙이고 나머지는 띄어쓴다.

11.27

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

Phase & Alice UI 교육

DB Core 계속!

Phase 문서화

프레임워크 개발 시, C++ Type Traits과 컴파일 상수와 if constexpr

패딩 비트 다시 정리

c++ 공부

  • map의 try_emplaceinsert_or_assign

11.28

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

Phase & Alice UI 교육

DB Core 계속!

Phase 문서화

c++ 공부

  • map의 try_emplaceinsert_or_assign

11.29

공부, 정리할 것

Main

  • [기반] Phase, Alice UI, DB, Select

Phase & Alice UI 교육

DB Core 계속!

Phase 문서화

c++ 공부

std::byte

Contents
go home! :house_with_garden:
11.01
공부, 정리할 것
Main
드디어 출시... 출시하느라 밀렸던 문서들 작성하고, 출시하면서 겪었던 인스톨관련 문제점들 개선하기
11.04
공부, 정리할 것
Main
드디어 출시... 출시하느라 밀렸던 문서들 작성하고, 출시하면서 겪었던 인스톨관련 문제점들 개선하기
11.05
공부, 정리할 것
Main
문서 작성
11.06
공부, 정리할 것
Main
문서 작성
자잘한 UI들 개선
11.07
공부, 정리할 것
Main
문서 작성
자잘한 UI들 개선
11.07
공부, 정리할 것
Main
문서 작성
자잘한 UI들 개선
11.08
공부, 정리할 것
Main
문서 작성
자잘한 UI들 개선
11.11
공부, 정리할 것
Main
신입사원 교육
문서 작성
자잘한 UI들 개선
11.12
공부, 정리할 것
Main
신입사원 교육
문서 작성
자잘한 UI들 개선
11.13
공부, 정리할 것
Main
DB Core System : DB 변수 정의하기
신입사원 교육
문서 작성
자잘한 UI들 개선
11.14
공부, 정리할 것
Main
DB Core 계속!
신입사원 교육
문서 작성
자잘한 UI들 개선
11.15
공부, 정리할 것
Main
Code Review
DB Core 계속!
신입사원 교육
문서 작성
자잘한 UI들 개선
11.18
공부, 정리할 것
Main
Code Review
DB Core 계속!
신입사원 교육
문서 작성
자잘한 UI들 개선
11.19
공부, 정리할 것
Main
Code Review
DB Core 계속!
신입사원 교육
DB Reflection 설계
구조체 메모리 패킹
의문점
11.20
공부, 정리할 것
Main
Code Review
DB Core 계속!
신입사원 교육
11.21
공부, 정리할 것
Main
Code Review
DB Core 계속!
신입사원 교육
구조체 메모리 패킹 퍼포먼스 실험
결론
그 외
11.22
공부, 정리할 것
Main
Code Review
DB Core 계속!
신입사원 교육
11.25
공부, 정리할 것
Main
DB Core 계속!
개발자의 글쓰기
11.26
공부, 정리할 것
Main
MDay
DB Core 계속!
개발자의 글쓰기
11.27
공부, 정리할 것
Main
Phase & Alice UI 교육
DB Core 계속!
Phase 문서화
프레임워크 개발 시, C++ Type Traits과 컴파일 상수와 if constexpr
패딩 비트 다시 정리
c++ 공부
11.28
공부, 정리할 것
Main
Phase & Alice UI 교육
DB Core 계속!
Phase 문서화
c++ 공부
11.29
공부, 정리할 것
Main
Phase & Alice UI 교육
DB Core 계속!
Phase 문서화
c++ 공부