원상이 워크스테이션 ryzen5 2600으로 변경.(pbzip2 test)

SMT(하이퍼쓰레드) 성능이 과장인가 쓸만한가 확인을 해봄.

pbzip2  bzip2

/tmp$ time tar -I pbzip2 -cvf a.tar.bz '(alpha=1,d='*  (alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat

real    0m17.179s
user    3m13.663s
sys     0m4.838s

/tmp$ time tar -I bzip2 -cvf a.tar.bz '(alpha=1,d='*      (alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat

real    2m16.867s
user    2m16.205s
sys     0m2.733s

일단 bzip2 pbzip2 테스트에서는 따로 프로세서 개수 같은 옵션을 주지 않아도 적당히 잘 최적화해서 돌아감.  

일단 대략 6C/12T에서 8배 정도의 성능 이득을 보고 있음.
(원상이 결과파일이 어떻게 생긴지 관심이 없지만 일단 bzip이나 gzip이나
둘다 465MB로 압축이 되므로 딱히 이거 쓸 이유는 없음)

pigz /gzip

/tmp$ time tar -I pigz -cvf a.tar.gz '(alpha=1,d='*  (alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat

real    0m5.315s
user    0m37.190s
sys     0m2.640s
/tmp$ time tar -I gzip -cvf a.tar.gz '(alpha=1,d='*      (alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat

real    0m20.482s
user    0m19.309s
sys     0m1.886s
/tmp$ time -p  tar -I 'pigz -p 10'  -cvf a.tar.gz '(alpha=1,d='*  (alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat
real 3.90
user 32.34
sys 2.09

bzip2 계열과 다르게 여기는 알고리즘이 어떻게 되어 있는지 모르겠지만, 병렬효율이 지나치게 떨어짐. 6C12T로 4배정도의 성능 이득 밖에 없음.  근데 원래 빠른게 더 빨리 끝나는거라. 그리 나쁘지 않음. 
  그래도 코어수보다 성능이 떨어지길래 테스트 해본결과 processor 개수를 10개까지 늘리는 동안에는 조금이라도 빨라지기는 함.  이 테스트는 효율이 워낙 떨어지다보니 외국 포럼에서 해석하기로는 가상코어를 코어수로 인식하지 못하는게 아닌가 라는 추축이 있었서 진짜 그런가 확인해 본 것임.  불도저나 옛날 코어 시리지에 대한 글이긴 했지만... 나도 느리길래 한번 해본것 

일단 코어하나만 써도 pigz쓰면 15%정도의 오버헤드가 생기고, 효율이 극히 떨어지고 뭔가 성능변화도 연속성이 이상함. 아무래도 pigz 코드에 뭔가 이상한게 많이 있나봄. (뭐 한계속도인듯 나중에 다른해석도 있음)


일단 알 수 있는 것, 적당히 잘 짠 코드의 경우, 6C12T 라이젠의  경우  8배 정도의 성능이득이 있음. (그냥 압축파일 짜르는 사이즈 마다 나눠놓고 각자 쓰레드에 일 맡기는 거라 효율이 좋을 수 밖에... )

원상이 코드 기준으로 눈대중으로 q9550보다 대략 2~2.5배 정도 빠름. 
10년도 더 된 cpu랑 비교해서 미안하지만 원상이가 계산 느리다고 해서 산거니까... 충분히 이득...   
비교대상은 윈도우에서 visual c로 Realease한 거랑 gcc로 optimize option 안주고 한거를 비교한거라, -O3, -O2정도면 3배까지도 차이날 수 있음. 

걍 때려박는 성능차이가 2배정도 나고, 세대차이로 인한 명령어 차이가 또 한 1.5배 해서 차이가 나는 것으로 예상됨. 


음 pigz가 pbzip2의 비해 병렬 효율이 매우 떨어지는것 처럼 보여도, pigz를 쓰는게 건강상 좋음. ..(일단 결과가  2.5GB의 데이터이기 때문에 이미 디스크 한계속도의 도달한거라 저 오버헤드는  sata3로 연결된 SSD의 오버헤드일 가능성이 크긴함... 이라고 생각했으나 작업 장소가... /tmp라서... 그냥 구린건가... 
사이즈가 워낙 크니까 /tmp가 어떤식으로 구성이 되있는지를 모르니... 

그냥 빨리 끝나니까 프로세서수 생각하지말고 pigz로 압축하자... 대략 30기가에 1분이라고 생각하면 겁나 빠른거니까... 1분이 4분이 되고, 1시간이 4시간이 된다고 생각하면 이거 쓰게 되어 있음. 



---------------------------------------------------------------------------

wslee@wslee-MS-7A37:/tmp$ time -p  tar -I 'pigz -p 12'  -cvf a.tar.gz '(alpha=1,d='*
(alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat
real 5.47
user 37.23
sys 2.74
wslee@wslee-MS-7A37:/tmp$ time -p  tar -I 'pigz -p 1'  -cvf a.tar.gz '(alpha=1,d='*   
(alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat
real 23.30
user 22.34
sys 1.75
wslee@wslee-MS-7A37:/tmp$ time -p  tar -I 'pigz -p 4'  -cvf a.tar.gz '(alpha=1,d='*  
(alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat
real 6.55
user 24.53
sys 2.64
wslee@wslee-MS-7A37:/tmp$ time -p  tar -I 'pigz -p 5'  -cvf a.tar.gz '(alpha=1,d='*  
(alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat
real 5.66
user 25.80
sys 2.25
wslee@wslee-MS-7A37:/tmp$ time -p  tar -I 'pigz -p 8'  -cvf a.tar.gz '(alpha=1,d='*  
(alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat
real 4.29
user 29.35
sys 2.26
wslee@wslee-MS-7A37:/tmp$ time -p  tar -I 'pigz -p 10'  -cvf a.tar.gz '(alpha=1,d='*  
(alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat
real 3.87
user 32.25
sys 2.16
wslee@wslee-MS-7A37:/tmp$ time -p  tar -I 'pigz -p 12'  -cvf a.tar.gz '(alpha=1,d='*   
(alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat
real 5.78
user 37.36
sys 2.68
wslee@wslee-MS-7A37:/tmp$ time -p  tar -I 'pigz -p 10'  -cvf a.tar.gz '(alpha=1,d='*  
(alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat
real 3.89
user 32.44
sys 2.05
wslee@wslee-MS-7A37:/tmp$ time -p  tar -I 'pigz -p 11'  -cvf a.tar.gz '(alpha=1,d='*  
(alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat
real 4.03
user 33.52
sys 2.38
wslee@wslee-MS-7A37:/tmp$ time -p  tar -I 'pigz -p 9'  -cvf a.tar.gz '(alpha=1,d='*   
(alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat
real 4.07
user 31.06
sys 2.14
wslee@wslee-MS-7A37:/tmp$ time -p  tar -I 'pigz -p 10'  -cvf a.tar.gz '(alpha=1,d='*  
(alpha=1,d=2)Hatree_theta_data.dat
(alpha=1,d=3)Hatree_theta_data.dat
(alpha=1,d=4)Hatree_theta_data.dat
real 3.90
user 32.34
sys 2.09

클러스터나 슈퍼컴퓨터에서 계산한 파일을 가져오기와 관련한 데이터 압축이야기

나 같은 경우는 MD simuation을 하는데, 얻는 rawdata 중에는 입자의 d.o.f 만큼의 실수 정보와 자기 인덱스와 관련한 정보 등을 text형식인 것이 있다. 

이런 것들이 입자수를 곱하고, 여러 시간의 스냅샷을 포함하다 보면 이 데이터의 양은 참으로 클 수 밖에 없다. 

내 경우에는 이 데이터의 양이 한번 돌릴 때마다, 12GB나 되는 굉장한 양이 나온다.  그 중에 더미가 있어서 실제로는 8기가 가량 되는 것 같다. 

이 데이터를 그대로 네트웍으로 받는다면 기가비트 환경에서 1분정도, 

100메가비트 환경에서 10분정도를 최저로 잡고 소요되나, 같은 건물이 아닌 이상 저 속도가 나올리가 없다.  나 같은 경우는 대략 20메가비트 정도 나오면 잘되는 듯하는 상황이라, 이대로 받아버리면 안정적으로 계속 다운로드가 될 때, 50분이 걸린다.  1분이나 10분 정도는 충분히 잠시 일보고 오는 식으로 소비할 수 있는 시간이다.   그런데 50분이란 시간도 그럴까? 아닐 것이다. 

(문제는 내가 저 시간을 아껴서 제대로 사용하는 사람이고 싶은 사람이지 그런 사람이 아니라는거...)

그렇다면 방법은 압축을 해서 데이터량을 줄인 후, 방법을 사용해야 할 것이다. 그렇다면 어떤 압축툴을 사용해야 할까?  

  보통 보관용과 전송용으로 차이를 둘 수 있겠다. 압축이란건 투자한 시간만큼 공간을 줄일 수 있다. 보관용은 공간을 줄이는데 관심을 가진다. 적당히 시간을 더 투자하고 공간을 적정선까지 줄이는 것이 목표라면 bzip2으로 시작해서 좀 더 극단적인 부분까지 줄이는게 목표라면 xz(or lzma:7zip의 알고리즘 사용)를 사용하게 된다. 

  우리는 전송용이기 때문에 당연히 gzip을 사용하면 되겠다. 리눅스는 Archiving tool과 Compresion tool을 따로 두는식으로 문화가 형성되어 있어서 Archiving tool로는 tar를 사용하고, gzip을 사용하여 압축을 많이 한다. 이렇게 해도 보통 zip(pkzip)보다는 속도나 압축률면에서 우수하다고 한다. (근거달기는 귀찮다. )

대게 tar cvfz 압축파일이름.tar.gz 내역들 

으로 그냥 사용하지만 문제는 data가 워낙 많아서 시간이 많이 필요하다는 거다. 그런데 기본으로 linux 배포판에 있는 gzip은 병렬로 계산하지 않기 때문에 이것도 한 세월 걸린다는 단점이 있다.  (gzip bzip2 xz 모두 그러함)

하지만 이쪽 사람들은 필요하면 만드는 사람들이기에 찾으면 해당하는 툴이 있다.   나같은 경우는 pigz라는 툴을 사용한다. gzip의 이름을 섞어서 말장난 하는 식의 이름이지만 매우 훌륭하다. 압축알고리즘 자체가 병렬화 되는 것은 아니고, 압축을 할 때, 어차피 파일을 특정 사이즈 마다 쪼개서,  압축을 하니까? 쪼개진 부분을 여러 계산유닛들이 기존 알고리즘으로 압축을 하면 되는 방식이다. 

그렇기 때문에, pigz를 컴파일해서 설치하는데는 root 권한 따위는 필요하지 않고, 필요한 라이브러리는 왠만해서는 서버에 있다. 이 친구들이 쓰는 헤더파일이 없으면, 루트가 제공하는 툴말고는 아무것도 못쓸 정도로 환경이 척박하므로 그냥 기대를 말고, 기존 루틴대로 살면 되겠다. 

tar 명령어에 외부 압축프로그램 바로 지정하는 방식을 사용한다면, 

tar -I pigz   -cvf blah.tar.gz blah blah    압축하기 

tar -I pigz   -xvf blah blah blah     압축풀기

이런 식으로 사용하면 되고 귀찮고 하드공간이 넉넉하면 tar로 먼저 묶고 

pigz로 압축 pigz -d로 풀기를 하면 되겠다. 

압축하는 시간이 기존 싱글쓰레드로 8분가량 걸린다면 16노드인 서버에서는 30초 정도로 끝날테니  굉장히 시간을 절약할 수 있다. 

수치해석 rawdata 전용 압축 툴이나온다면 압축률을 더 높일 수 있을 것 같으나, 그런건 없는 것 같고, 대략 압축을 하면 압축률이 42%정도 나온다. 

파일이 작으면 이건 개 뻘짓이지만. 파일이 커서 굉장이 좋은 방법이 되었다. 

기존 방법으로는 통으로 50분이 걸리던지, 아니면 21+압축시간 걸리던 것이 21+압축시간/nodes  로 시간이 확 줄어드어 쓸만해 진다. 

음 대학교가 연구기관이라면 kist 같은 국가 연구기관들과 100Gb 네트웍으로 연결되고 내부망은 최소 기가비트 건물간은 10기가비트로 연결되어야 정상이 아닐까...?

건국대학교는 이과대학이 내부망이 아직 100메가비트이고, 연구기관들끼리 연결된것은 우회망이 없어서인지 이쪽 대역폭을 어떻게 나눠쓰는지 모르겠는데 너무 느리다. 빨리 좀... 어떻게 해주면 좋겠다. 

아 그리고 이런짓을 할 필요 없이, rsync 나 scp에 압축 옵션이 있다. 

그런데 scp는 이어받기 옵션이 없어서 배제 대상이 되고 rsync에 압축옵션을 넣어서 다운받으면 되겠다. 근데 이건 익숙하지가 않아서 전송용으로만 쓰고 있다. 

  그리고 데스크탑을 리눅스로 쓰는 나같은 리눅서는, 이쪽 철학을 지켜서 각 프로그램들의 기능을 최소화하고 서로 연결해서 사용하는 것이 심적으로 편하다. 그냥 이렇게 쓰도록 하자.