Fast Byte Order 엄청 오래된 내용ㅋ

이제는 이럴 필요도 없을 것 같은데 그때 그 시절엔 왜 이런 거에 예민했는지 ㅋㅋㅋ

 

네트워크 프로그램 제작할 때,

#include <winsock2.h>를 이용해서

y = htons(x); 나

y = htonl(x);를

사용하는데, 저게 얼마나 느린 걸까? 한 번 생각해봤다.

/* Using Winsock2 normaly */
#include <iostream>
#include <winsock2.h>
using namespace std;

int main()
{
    unsigned short x = 0x3399;
    unsigned short y;

    unsigned int a = 0xff0102ff;
    unsigned int b;

    cout << "using winsock2" << hex << endl;

    for(int i=0;i<1000000000;i++)
    y = htons(x);
    cout << "x = " << x << "y = " << y << endl;

    for(int i=0;i<1000000000;i++)
    b = htonl(a);
    cout << "a = " << a << "b = " << b << endl;

    return 0;
}

그래서 일단 테스트로 asm 코드를 이용해서 htons와 htonl을 구현했다.

asm 코드는 인터넷에서 검색하면 ibm이랑 joinc랑 블로그랑 여러곳에서 나타난다.

C로 된 마스킹 처리해서 쉬프터 연산하는 것도 있던데 그건 속도가 느릴거고...

 

하드코드 테스트 결과는 무지 차이가 났다.

결과는 ASM코드의 승리! (당연한건가... 컴파일된 크기도 84바이트 적다.)

물론 이런 결과가 나온건 내가 쓰는 컴파일러가 MingW라서 일 수도 있다.

Visual C에서 컴파일하면 최적화되서 속도차이가 안나거나 더 빠를 수도 있다. (확인불가)

구분	1억회 계산	10억회 계산
ASM코드	0.687s	6.761s
winsock2	1.374s	13.070s

 

하지만 함수형태로 바꾸니까별로 차이가 나지 않았다.

그래서 함수 형태로 써볼려고...했더니 차이가 나지 않았다.

라는 얘기는 winsock2도 asm 코드랑 같은 거겠지.

구분	1억회 계산	10억회 계산
ASM코드	1.325s	13.491s
winsock2	1.374s	13.179s

 

#define문 사용해서 재정의한 fastHtons & fastHtonl

결국은 #define으로, 이렇게 하면 소스 중간에 들어가게 되니까 함수 호출이 없어지고 속도가 빨라진다.

대신 용량이 fastHtonX의 사용 횟수 만큼 늘어난다. 그래봤자 몇번 안 쓰잔냐...ㅋ

구분	1억회 계산	10억회 계산
ASM코드	0.687s	6.761s
winsock2	1.374s	13.070s

 

빠른 바이트 오더 소스코드

FastByteOrder.cc

/* fast byte order */
#include <iostream>
using namespace std;

#define fastNtohl fastHtonl

#define fastNtohs fastHtons

#define fastHtons(in, out) \
     asm ("movw %1, %%ax;"\
             "xchg %%ah, %%al;"\
             "movw %%ax, %0;"\
            :"=r"(out)\
            :"r"(in)\
            :"%ax","%ah","%al");

#define fastHtonl(in, out) \
     asm ("movl %1, %%eax;"\
             "bswap %%eax;"\
             "movl %%eax, %0;"\
            :"=r"(out)\
            :"r"(in)\
            :"%eax");

int main()
{
    unsigned short x = 0x3399;
    unsigned short y;

    unsigned int a = 0xff0102ff;
    unsigned int b;

    cout << "fast byte order" << hex << endl;

    for(int i=0;i<1000000000;i++)
    fastHtons(x, y);
    cout << "x = " << x << "y = " << y << endl;

    for(int i=0;i<1000000000;i++)
    fastHtonl(a, b);
    cout << "a = " << a << "b = " << b << endl;

    return 0;
}

 

위 두 소스코드의 실행 속도 차이 비교

왼쪽 : Winsock2.h : 13.429s

오른쪽 : Fast Byte Order : 6.745s

다른 사람들은 모르겠지만 난 앞으로 이걸 쓸거다. 그리고 코딩 방식도 함수 호출을 줄이고, 메모리 주소에 곱하기도 줄이고, 완전 하드코딩으로 ㅋㅋㅋ

라고 생각해봤지만, 그건 코드가 100줄 이하일 때나... 결국은 객체 설계 방식으로 만들게 되겠지...

게다가 #define macro의 단점인... 여러 줄로 작성할 경우 도저히 디버깅 할 수 없는 사태가 발생하면 그걸로 사망이다. ㅋㅋㅋ (물론 한줄로 바꾸면 해결 됨-_ -;)

 

혹시 내가 오해한 건가 싶어서 한번 더 확인해봄.

디버깅 모드랑 릴리즈 모드가 있더라? 그래서 다시 테스트 해봤다. ㅎㅎㅎ

1차는 전부 첫 컴파일 후 실행, 2차는 1차 종료 후 실행, 3차는 2차 종료 후 실행.

byte order by (asm)

구분	Debug모드	Release모드
크기	604,188B	276,480B
1차	8.796s	2.546s
2차	8.750s	2.500s
3차	8.750s	2.484s

byte order by (masking & shift)

구분	Debug모드	Release모드
크기	1,322,981B	276,480B
1차	9.656s	3.953s
2차	9.609s	3.906s
3차	9.593s	3.906s

byte order by (winsock2)

구분	Debug모드	Release모드
크기	604,188B	276,480B
1차	13.296s	8.984s
2차	13.046s	8.968s
3차	13.062s	8.953s

byte order by (asm function)

구분	Debug모드	Release모드
크기	604,254B	276,480B
1차	13.296s	6.421s
2차	13.250s	6.375s
3차	13.250s	6.375s

 

의외로 마스킹 & 쉬프트도 빠르구나! 그리고 함수로 바꿔서 쓰면 winsock2랑 비슷한데 조금 빠르긴 하지만 10억번 테스트니까 의미가 있나 싶기도?