추석기간 FIX인코더 새로 만들었는데, 이번에 FIX엔진 만든 것은 L2캐쉬를 적극적으로 이용해서 성능을 높였네요.
오픈소스 FIX엔진으로 많이 쓰이는 것이 quick fix라고 있는데, fix8이라는 곳에서 자신들이 성능이 더 좋다고 하면서 테스트 자료를 올린 것이 있더군요. 흔히 이런 곳에서 자기들 속도 높다고 하면서 하는 것이 for문 십만번 돌리기, 백만번 돌리기입니다.
아래에 있는 것이 테스트 구문하고 그 결과인데, 십만번 돌리고 걸린 시간을 나눠서 인코더가 1.63마이크로초 디코더가 7.05마이크로초가 걸렸다고 하는 군요. 그런데 for문 십만번 돌리기에는 문제가 있습니다. L2메모리 이상에서 캐쉬되어서 속도가 엄청나게 빨라지게 됩니다. 그리고 컴파일러에 따라서는 자동으로 옵티마이즈되어서 병렬처리가 되기도 합니다. 그래서 일반적인 상황보다 성능이 크게 향상된것 처럼 보이게 됩니다.
이번에 제가 만든 인코더 자랑질좀 하면서 실제 사례를 보여드리죠 ㅋ
인코더를 3가지 스타일로 실행을 시켜보겠습니다.
첫번째는 하나 실행시키고 속도 측정하고 1초 쉬고해서 3번을 하는 예제입니다.
두번째 예제는 1초 쉬지 않고 바로 실행시켜봅니다.
세번재는 십만번 돌리기입니다.
아래는 3가지의 실행결과입니다. 단위는 나노초이구요.
첫번째 실행시킨 것은 5마이크로초, 3마이크로초 정도 나왔군요. 돌려보면 거의 3마이크로초 때가 나옵니다. 그러나 두번째 실행시킨
것 한번 보시죠. L2캐쉬 적극적으로 활용하여서 좀 극적이기는 한데 두번째 실행부터는 속도가 10배가 빨라졌습니다.
300나노초, 400나노초가 나왔군요. 이거는 좀 심하게 개선이 된 것이지만, 바로 이어서 실행시키면 보통 L2캐쉬, L1캐쉬에
올라가게 되어서 실행속도가 빨라지게 되어 있습니다. 세번째는 십만번 돌리기 십만번 돌리니 평균 151나노초 걸린 것으로 나왔군요. FIX8보다 10배 이상 빠른 결과군요. ㅎㅎ 그러나 For문 십만번 돌리기는 솔직히 성능 제대로 측정 안되는 사기입니다. L1, L2캐쉬 정도가 아니라 거의 레지스터에 붙고, 컴파일러에서 최적화시켜주고 그렇게 해서 나오는 정말 특수한 경우인거죠.
그래도 이처럼 HFT프로그래밍을 할때 L1, L2캐쉬 적극적으로 활용하면 성능이 극적으로 올라간다는 것은 알 수 있습니다. 직접적으로 프로그램에서 L2캐쉬를 제어할 방법은 없지만, L2캐쉬에 남아있을 가능성이 높도록 프로그래밍을 할 수는 있습니다. 이번 인코더가 두번째 실행에서 성능이 급격하게 올라간 것도 L2캐쉬를 고려해서 프로그램한 것이 잘 적용이 된 것 같네요. 지난 번에는 저 정도로 차이가 많이 나지는 않았는데 말이죠. 제가 만든 인코더가 처음 실행될때 3마이크로초 정도 나오게 되는데, 아직 개선의 여지가 있네요. 좀 더 만들고 최적화 시킬 계획입니다.
며칠만에 FIX엔진 만드는 것은 많이 다뤄본 것도 있지만, FIX프로토콜 전부다 구현하는 것이 아니라 필요로 한 것만 구현을 해서네요.
'backup' 카테고리의 다른 글
[HFT 시스템 트레이딩]FX마진거래 시장에 대한 이해 (0) | 2013.10.17 |
---|---|
HFT 테스트 (0) | 2013.10.16 |
지난달부터 네번째 FIX엔진 완전히 갈아엎고 있네요. ㅋ (0) | 2013.09.17 |
zeromq 또는 cep를 쓰는 빠른 HFT 거래 시스템? (3) | 2013.09.12 |
HFT 시스템 개발 순서 (0) | 2013.09.12 |