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

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만리 떠날 수 있는 큰 문제