CPPCon 2016 The strange details of std::string at Facebook

동영상 링크
ppt링크

뭐가 제일 페이스북에 효율적인지

string은 제일 중요한 요소중 하나
cpu전체의 18%가 std안에서 쓰임

string을 간단하게 만드는 것

gcc string(v < 5) Implementation

sizeof string is 8 (in gcc same as pointer)
다른 모든것보다 제일 많이 쓰이는 string? => empty string
but empty string is no empty
malloc을 해서 매 번 overhead를 감수하고 할껀가?
gcc는 매번 25byte arry를 가지고 있음 So empty is not empty

Q:왜 empty가 없는건데?
A:그러면 매 번 비어있는 string인지 체크해야함 if NullString || ptr != null_ptr 등등

gcc copy on write
copy 생성자를 받을때 original string의 레퍼런스를 하나 증가시킴 그후 메모리를 수정시킬때만 write함
(지금은 c++11 concurrency문제 때문에 drop)


fbstring

string관련 처리 코드에서 병목현상이 발생

  • 다른 페이지를 매번 접근
  • malloc에서 걸림

매번 힙을 사용하다 보니 문제가 생겨서 작은 사이즈의 string의 경우 스택을 사용해서 최적화를 진행

fbstring 구조

Normal String : data | size(14) | capacity(15) (data제외 29 바이트)

union

Small String : data \0 .... emty size (25바이트)

union으로 되어있기 때문에 small string의 사이즈를 넘어가게 되면 normal string으로 넘어가게 됨
이런 방식으로 하면 마지막에 널바이트로 덮으면서 남은 capacity도 표현 가능… 개똑똑)


최적화

  • normal string인지 small string인지 구분할 flag가 필요.
    facebook 에서는 JEmalloc이라는 메모리 할당을 씀
    bucket에서 쓸 수 있는 메모리를 리턴해주는데
    8byte align을 해서 29byte를 요청하면 32byte를 리턴해 줌.
    fbstring은 이 사실을 알고 있기 때문에 남은 3바이트를 flag에 사용하는 비트로 이용함
  • 일정 사이즈 이상 커지면 big size string으로 해서 ref conut를 사용(Copy on Write)

Performance of fbstring

gcc_string.size()

movq (%rdi), %rax
movq -24(%rax), %rax

fbstring.size()

movabsq $-4611686018427387904, %rax
testq %rax, 16(%rdi)
je .L7
----is_small-----
movq 8(%rdi), %rax
ret
.L7:
movsbq 23(%rdi), %rdx
movl $23, %eax
subq %rdx, %rax
ret

딱봐도 fbstring이 훨씬 길다.
small string인지 normal string인지 구분을 먼저하고 길이를 리턴 해야 하기 때 문에 라인 수도 더 길다.

근데 밴치마크를 하게 될 경우
gcc string : 1.6ns
fb string : 0.9 ns
???? 브랜치 까지 있는 9줄의 코드가 어떻게 하면 2줄짜리 코드보다 더 빠를 수 있지????

-> gcc string은 모두 힙을 쓰기 때문에 page fault가 자주 일어나게 됨 align된 string사이즈라면 fault가 더 적게 나서 fbstring보다 빠르지만 일반적인 경우 fbstring이 더 빠름

그래서 std::string 을 folly::fbstring으로 교체 해봤다.
-> 1% 성능향상 (적은것 같아 보일 수 있지만 fb에서 사용하는 모든 c++의 성능이 1%향상 되었다고 보면.. 티끌모아 태산이다. )

Killing the null terminator

fbstring lazily wrote \0

보통 string을 쓰나보면 push_back을 이용해서 concat하는 경우가 많음.
그래서 굳이 계속 \0을 붙여줄 필요 없이 필요할 때만 붙여줌
But this is illegal (표준에 맞는 구현이 아님 Concurrency를 생각하면 좋은 구현 X)
하지만 대부분의 사람은 null에 굳이 상관 없는 코드를 작성 하기 때문에 그냥 씀
c_str(), data()는 \0을 붙이게 됨

Problem in c_str()

const Char * c_str() const {
...
data[size()] = ‘\0’;
return data;
}

fb에서는 global read only string 변수를 두고 다양한 쓰레드에서 c_str()을 호출한다.
c_str은 구현대로 라면 const함수이기 때문에 원본 데이터에 대해서 변경이 없어야 함.
프로그래머 입장에서 보면 const라 데이터에 변화가 없다고 생각하지만 Cpu입장에서 보면 string마지막에 \0를 붙임으로써 cache line을 다 날려버린다..! 느려질 수 밖에

그래서 \0이 있는경우는 체크해서 data에 안쓰기로 결정!

const Char * c_str() const {
...
if (data[size()] != ‘\0’) //Problem Undefined behavior  
data[size()] = ‘\0’;
return data;
}

위에 저 if 안의 diff는 broken code.
초기화 되지 않은 메모리를 읽을 수 도 있음.
문자열 길이가 128바이트라면 129byte의 메모리가 필요함.
근데 je malloc에서 malloc을 하게 될 경우 128이란 숫자는 페이지 크기에 align 시키기 편한 숫자(gcd 4096 92) 이라 페이지의 맨 마지막(page last - 128)에 배치.

다른 97같이 align안 맞는 경우는 ok(뒤에 align을 맞추기 위해 보통 몇바이트 더 할당되기때문에)
128byte를 할당하면 페이지 맨 끝 부분에 할당되게 되면서 남는 메모리 공간이 없게됨

문제가 되는 부분은 if문

if(data[size()]==0)

data[size()]에 read 하게되면 129번째인데 할당되지도 않고 쓰지도 않은 메모리에 접근하게됨

근데 커널에서 Undefined mem(할당되지 않고 write도 안한 경우)에 접근하게되면 0을 리턴함. 그렇기 때문에 저 if문이 broken이라는 표현을 쓴듯
그래서 Null을 안쓰고 포인터를 리턴하게되고 write를 하게되면 믈리 페이지가 맵핑되면서 129번째에 널이 없는채로 리턴. 문자열 관련처리를 하다가 널을 찾아 3만리 떠날 수 있는 큰 문제


WRITTEN BY
Jen6
jen6의 개발, 보안 블로그 까끔가다 쓸대 있는걸 올리려고 노력중

받은 트랙백이 없고 , 댓글  3개가 달렸습니다.
  1. 이해가 쏙쏙되어요! 감사합니당 천사 건씌
  2. 정말 감사합니다 ! ^^ 오늘 행복한 하루 지내세요 ㅎㅎ
  3. 코잘남이되고싶어요 2017.04.05 17:53 신고
    역시 갓건! 정말 감사해요~
secret

binary 관련 간단한 정리

정수표현

정수타입에서 대부분 최상위 비트(Most Siginificant Bit)가 음수인지 정수인지를 구분한다는 것은 알고있을 것 이다. 나도 그냥 그렇게만 알고 음수표현은 양수에서 최상위 비트만 반전되는줄 알고 있었다. (하지만 그게 아니다..)

그러다 학교에서 친구가 파이썬에서 ‘~’ 가 뭐냐고 물어봐서 not이라고 대답해 주다가 이상한 부분을 발견했다. 0b101 을 not연산을 하게 되면 -0b110이 나오는 이상한 일이 일어난거다.

5 : 0b0101
!5 : 0b1010
내 생각으로는 최상위 비트가 1이고 나머지가 정수라면 -2가 되야한다고 생각했지만 음의 정수는 그렇게 표현하지 않는다.


source code

0을 0b0000으로 두고 -1부터는 0b000에서 1을 뺀 0b1111이 되는 방식이였다. 별거 아니지만 왜 정수형에서 대부분 양수만 설명하고 음수가 어떻게 되는지는 설명 안되어있어서 정리해 두었다.


binary 뺄셈

우리는 일반적으로 뺄셈을 계산할 때 7 -2 = 5 라고 계산한다. 하지만 CPU는 단순한 일 즉 덧셈만 할 수 있다. 우리가 하는 곱셈 나눗셈 등등 많은 일들도 모두 cpu는 덧셈으로 동작시킨다. 그렇기 때문에 7 - 2를 7 + (-2)로 바꿔서 계산해야 한다. 덧셈으로 뺄셈을 하는 방법은 두 가지가 있다.

1의 보수(One’s Complement)

7 - 2 
7  = 0b0111
2  = 0b0010

1의 보수에서는 먼저 음수가 될 수를 반전(Bit flip)시킨다.

2  = 0b0010
!2 = 0b1101

그 후 7과 더해준다

7  = 0b0111
!2 = 0b1101
------------
올림수(Carry) 0b1 | 결과 0b0100

지금과 같이 올림수가 나왔을 경우 2^0자리에 다시 더해준다

0b0100
0b0001
--------
0b0101 = 5

1의 보수를 이용하여 덧셈을 이용하여 뺄셈을 하였다. 1의 보수는 not연산을 통해 구해진다. 그래서 파이썬 같은 프로그래밍 언어들의 not 연산자의 영문 설명을 보면 bit flip or complement라 적혀있다.


2의 보수(Two’s Complement)

1의 보수는 올림수가 발생할 경우 계산이 복잡해진다. 이런 복잡함을 완화하기 위해 2의 보수를 사용하기 시작했다. signed와 unsigned의(쉽게 얘기하자면 부호 구분을 하는지 안하는지) 구분없이 덧셈 뺄셈이 가능하고 CPU구현도 간단해서 요즘 사용되는 CPU대부분은 2의 보수를 사용한다.
2의 보수는 계산을 할때 음수로 만들 수를 1의 보수(not연산)로 만든다음 1을 더해준다.

7  = 0b0111
!2 = 0b1101
!2 + 1 = 0b1110 = -2 in binary

0b0111
0b1110
-------
0b0101 = 5 (올림수는 버린다)

2의 보수를 만들게 되면 위에서 알아본 2진수로 음수를 표현하는 방식 그대로가 된다.


‘!’연산자와 ‘~’연산자 차이점

‘!’ 와 ‘~’ 모두 찾아보면 not operation을 수행한다고 나와있다.
하지만 둘에는 큰 차이점이 있는데 비트연산을 할 때는 ‘~’논리연산을 할 때는 ‘!’을 쓴다. 어떤 차이점이냐면.. 0b0111 이런 비트에 관한 연산을 할 때는 ‘~’을 쓰고 true false 와 같은 논리적인 것들에 대한 연산을 할 때에는 ‘!’연산자를 쓴다.
bitwise operator and logical operator

도움을 주신 이경문 멘토님 감사합니다


WRITTEN BY
Jen6
jen6의 개발, 보안 블로그 까끔가다 쓸대 있는걸 올리려고 노력중

받은 트랙백이 없고 , 댓글이 없습니다.
secret

애플은 왜 아이폰7에서 이어폰잭을 뻇을까? 기사
이번 아이폰7에서 3.5파이 이어폰 단자가 빠졌다. 언젠간 없어질 부분이라 생각했었는데 솔직히 좀 빨리 빼서 놀랐다.
개인적으로 이어폰 단자가 없어진 이유는 크게 두 가지로 본다.

  1. 디자인 철학
    예전부터 애플의 디자인에서 가장 빨리 없어지는건 ‘선’들 이였다.
    데스크탑용도로 쓰이는 아이맥에도 무선랜 포트를 넣었고 키보드와 마우스(혹은 트랙패드) 모두 무선이다. 심지어 타임캡슐을 이용한 백업도 모두 무선으로 진행된다. 이런 번잡스러운 선을 없앰으로서 애플 디자인의 최대 철학인 “단순함”을 살리고 있다.
    (에어팟 자체 모양은 좀 별로긴 하다..)

  2. 좋은 제품을 만들기 위해
    애플은 신기술 도입에 망설설지 않아왔다. 그 결과 애플이 과감하게 들여온것들은 관련 기술의 발달과 사용자들의 변화를 이끌어왔다. 예를 들자면 아이폰과 같은 모바일 기기에서 플래시를 제한하자 html5등 현대적인 웹들이 발전했고 usb c type도 맥북에 도입하게 되면서 다른 제조사 노트북에 들어가기 시작했다. 앱스토어야 말한것도 없고.. 충전하면서 노래를 못듣는 불편함을 알면서도 굳이 뺀 이유는 소비자들에게 좋은 제품을 주고싶어서가 아닐까 생각된다. 아직 무선이어폰이 조금 더 불편할 뿐이지 앞으로 유선이어폰에게 더 뒤쳐질 이유는 분명히 없다. 위글에 나온 말처럼 몇년뒤에는 우리가 왜 그렇게 이어폰 잭에 집착했을까 라고 생각할것 같다는 기분이 든다.
    더 좋은 제품을 제공하기 위해 기존에 것을 뺸다느건 스티브 잡스가 예전에 연설한 동영상을 보면 어떤 의도인지 알 수 있다.

에어팟에서 들어간 자동페어링이나 빼면 노래가 멈추는 듯한 기능들은 기존의 무선이어폰 제조사들에게 이렇게 만들어라 하는 가이드라인이 될정도로 기능적인 면은 잘 만든것 같기도 한데 디자인은 좀…

아무튼 수능 끝나면 이번에는 아이폰7 사봐야지

'etc' 카테고리의 다른 글

왜 애플은 이어폰잭을 뺏을까?  (0) 2016.09.16
NSA HACKED!  (0) 2016.08.16
필기  (0) 2014.03.06

WRITTEN BY
Jen6
jen6의 개발, 보안 블로그 까끔가다 쓸대 있는걸 올리려고 노력중

받은 트랙백이 없고 , 댓글이 없습니다.
secret