프로젝트 a 와 프로젝트 b 를 병렬로 진행하고 있었는데, 두개의 리포지토리를 합치고 싶어지는 경우가 있습니다. 예컨대 프로젝트 a 의 성격이 보다 범용이 되었고 프로젝트 b 는 프로젝트 a 를 위한 도구적 성격이 되는 경우가 있겠죠. a 프로젝트에 ‘b’ 디렉토리를 만들고 그 아래 기존 프로젝트 b 의 파일들을 위치하고 싶습니다. 하지만 기존 b 프로젝트의 git 히스토리들도 유지하고 싶습니다. 비슷한 사례로 리눅스 커널 메모리 모델 프로젝트는 별도의 리포지토리[1] 로 개발되었지만 리눅스 업스트림 리포지토리의 tools/ 디렉토리 아래로 머지[2] 되었는데, 이 때 기존 개발 히스토리를 유지했죠....
프로젝트 a 와 프로젝트 b 를 병렬로 진행하고 있었는데, 두개의 리포지토리를 합치고 싶어지는 경우가 있습니다. 예컨대 프로젝트 a 의 성격이 보다 범용이 되었고 프로젝트 b 는 프로젝트 a 를 위한 도구적 성격이 되는 경우가 있겠죠. a 프로젝트에 ‘b’ 디렉토리를 만들고 그 아래 기존 프로젝트 b 의 파일들을 위치하고 싶습니다. 하지만 기존 b 프로젝트의 git 히스토리들도 유지하고 싶습니다. 비슷한 사례로 리눅스 커널 메모리 모델 프로젝트는 별도의 리포지토리[1] 로 개발되었지만 리눅스 업스트림 리포지토리의 tools/ 디렉토리 아래로 머지[2] 되었는데, 이 때 기존 개발 히스토리를 유지했죠....
경우에 따라서 SPEC CPU2006 의 벤치마크 중 일부의 소스코드를 수정하고 싶을 수 있습니다. 예를 들어 특정 벤치마크가 구체적으로 어떻게 동작하는지 알아보기 위해 디버깅 메세지를 추가하고자 할수도 있고, 코드 변경을 통해 성능을 높인다거나 해볼 수도 있겠죠. 그러나, SPEC CPU2006 은 엄정한 벤치마크 수트이기 때문에 소스코드는 물론, 소스코드를 사용하는 도구가 변경된 경우 에러 메세지를 내고 수행을 거부합니다. 수정된 소스코드로 얻어진 결과는 벤치마크 결과로 적합하지 않기 때문이죠. 때문에, 어쩔 수 없이 수정이 필요하면서도 기존의 수행 방법을 따르려면 이 에러를 내는 곳을 없애는 게 한가지 방법이 될 수 있습니다....
경우에 따라서 SPEC CPU2006 의 벤치마크 중 일부의 소스코드를 수정하고 싶을 수 있습니다. 예를 들어 특정 벤치마크가 구체적으로 어떻게 동작하는지 알아보기 위해 디버깅 메세지를 추가하고자 할수도 있고, 코드 변경을 통해 성능을 높인다거나 해볼 수도 있겠죠. 그러나, SPEC CPU2006 은 엄정한 벤치마크 수트이기 때문에 소스코드는 물론, 소스코드를 사용하는 도구가 변경된 경우 에러 메세지를 내고 수행을 거부합니다. 수정된 소스코드로 얻어진 결과는 벤치마크 결과로 적합하지 않기 때문이죠. 때문에, 어쩔 수 없이 수정이 필요하면서도 기존의 수행 방법을 따르려면 이 에러를 내는 곳을 없애는 게 한가지 방법이 될 수 있습니다....
Database 를 위해 사용되는 벤치마크는 크게 OLTP vs OLAP 로 나뉩니다[1]. OLTP 계열의 대표주자는 TPC-C 이고, OLAP 계열의 대표주자 중 하나로 TPC-H[2] 가 있습니다. 이 글에서는 TPC-H 를 MariaDB 에서 돌리는 방법에 대해 설명합니다. Environment Setup 이 글을 작성하면서 사용한 운영체제와 소프트웨어들의 버전은 다음과 같습니다. Ubuntu 16.04.2 Server MariaDB 10.2.8 TPC-H toolkit 2.17.2 Automated Scripts 아래 설명할 모든 내용을 자동화 해서 손쉽게 TPC-H 를 돌릴 수 있도록 소스코드 변경부터 빌드, 수행까지 정리한 스크립트들을 github 에 올려 두었습니다: https://github....