감사합니다.

C언어를 사용하다가, 자바스크립트로 프로그램(?)을 작성하니,

- C언어에서 자주 사용하는 구조체, enum, #define 등의 기능을 사용할 수 없어, 힘듦

- 변수명이 중복되거나, 다른 용도로 사용할 경우, 원인찾기가 어려움.

- static 변수 선언이 안됨. 모두 전역변수. (트릭을 사용하면 되나, 불편함)

- 웹브라우져마다 안되는 코드가 있어, 불편함.

기존 장비의 프로그램에 문제가 있어, 수정하고 있습니다.

다른 사람이 만든거라, 거의 새로 작성해야합니다.

기존 프로그램 코드는 여러가지 문제가 많아,

도저히 "부분수정"이 안됩니다.

"블랙박스모델"처럼, 입출력 동작 데이터만으로

"재구현"이 필요합니다.

물론 시간이 많이 걸립니다.

"부분수정", "최소수정"을 하려고, 다각도로 검토해보았으나.

시간만 많이 소요되고, 별 진전이 없고, "어차피 전체 수정이 필요하다"는 결론이 나옵니다.

지난번 장비 수정에서 약 50%의 시간이, "부분수정, 최소수정 검토"하는데 시간이 소모되었습니다.

"어떻게 수정할것인지에 대한 검토"는 반드시 필요하나, 발견되지 않은(않는) 문제때문에, 불필요하게 시간이 소요되는 경우가 맣습니다.

그냥 차라리, 블랙박스 모델로 새로 만드는것이 더 확실하고, 깔끔합니다.

그런데말입니다. 여기서 또 문제가 있습니다.

기능이 복잡한 경우에는 시간이 많이 소요됩니다.

최소수정으로 하려고하나, 안되는 경우에는 울며겨자먹기로, "재프로그램"을 하게 됩니다.

물론, 이경우에는 더 많은 시간이 소요됩니다.

고정소수점 연산은 소수점이 특정위치에 있다고 가정하고, 정수연산을 한 후, 특정위치에 소수점을 찍는 방식이다.

또는 모든 소수점에 특정값을 곱해서, 정수로 만든 후, 연산을 하고, 다시 원래대로 특정값으로 나누는 방식이다.(이 경우에는 오차가 커질 수도 있고, 불필요한 연산이 발생한다)

고정소수점은 q31, q15등의로 표시하는 경우가 많다.

q31은 32비트중 31비트가 소수점이라는 이야기 이다.

이는 최대값을 1.0으로 하여 계산하는 방식이다.

이 방식의 장점은 연산이 쉽다는 것이다.

고정소수점연산의 범위 정하는 방법

1) 부동소수점으로 계산하고, 각 단계별로, 각 변수의 최대, 최소값을 측정한다.

2) 각 단계별로, 해단 변수가 최대, 최소값을 넘어서지 않도록, 소수점 위치를 조정한다.

고정소수점 연산은 대부분 q31과 같이 획일적으로 계산한다.

이 경우, 작은 숫자와, 큰 숫자를 계산할 경우, 오차가 커지는 문제가 있다.

이럴 경우에는 각 단계별로 소수점위치를 조정하여, 더 정밀한 연산을 할 수 도 있다.

물론, 프로그래밍하는데, 더 많은 시간이 들어간다.

또한, 고정소수점의 곱셈이나 나눗셈에서, 두 숫자의 소수점자리를 고려해서, 양쪽의 소수점의 위치를 이동해서 계산하는 트릭도 유효하다.

고정소수점 라이브러리를 잘 작성해 놓으면,

#define 매크로 하나로, 부동소수점으로 바꿀 수 도 있고, 고정소수점연산으로 바꿀 수 도 있다.

이 경우, 모든 연산은 매크로 함수로 표현이 된다.

보통 C언어를 사용하여, float, doube등의 실수연산을 할 경우,

오차가 발생한다.

계산기로 간단히 계산하면,

2/3=0.666667

처럼 066666....인 숫자가 666667이 된다.

이값으로 다른 계산에 넣으면, 또 오차가 더 커진다.

대부분, 이작은 오차는 문제가 되지 않으나, 특정 연산에서는 중요한 문제가 된다.

원인은 컴퓨터가 다루는 실수는 이진수를 바탕으로하며, 소수점이하의 이진수는 나타낼 수 없는 값이 존재하기때문이다.

이를 해결하는 방법은 

1) 고정소수점연산을 사용

2) 연산순서를 재배치

    곱셈,덧셈,뺄셈부터 계산후, 마지막에 나눗셈

하는 방법이 있다.

물론, 위 2가지를 같이 사용하면, 더 정확해진다.

부동소수점은 실수표현범위가 넓으나, 정밀도는 떨어진다.

고정소수점은 실수 표현범위가 부동소수점에 비해 매우 좁으나, 정밀도는 부동소수점보다 정확하다.

부동소수점이나 고정소수점이나 모두 오차가 존재한다.

고정소수점이 오차가 비교적 적다.

고정소수점연산에서는 소수점을 몇자리로 할것인지를 결정해야한다.

표현하는 범위를 넘어서는 경우가 발생하면, 전혀 엉뚱한 결과가 나올 수 도 있다.

(부동 소수점은 범위에 상관없이 대부분, 오차는 있어도, 예상되는 결과가 나온다.)

고정소수점연산은 소수점자리를 정하는것이 가장 큰 일이다.

고정소수점연산은 컴퓨터에서 정수연산으로 처리가된다.

마이컴 같은 임베디드 CPU에서는 실수연산 회로가 없어, float, double연산을 하게되면,

에뮬레이션되어, 매우 느려진다.

PC에서는 부동소수점처리장치가 정수연산속도와 비슷하여, 대부분의 경우에는부동소수점으로 계산하는것이 좋다.

마이컴 같은 임베디드 CPU에서는 정수연산만을 사용하는 고정소수점형식으로 연산을 하면, 매우빠른 속도로 실수연산이 가능하다.

주식에서 시스템 트레이딩이라하면, OpenAPI등을 통해 프로그램을 만들고, 그 프로그램으로 주식을 거래하는 방식이다.

일반 주식거래는 사람이 직접 가격을 모니터링하고, 매수/매도 주문을 내는 반면,

시스템 트레이딩은 프로그램이 가격을 모니터링하고, 자동으로 매수/매도 주문을 낸다.

시스템트레이딩을 하게되면, 자동으로 매매가 이루어지며, 사람이 하는것보다 수백배 빠른 주문을 할 수 있으며, 수백 종목이상을 모니터링 할 수 있다.

엄청나게 대단한 기능이다.

하지만, 프로그램에의한 매매라는것은 특정 기준이 있어야 하며, 이런 매매 알고리즘은, 프로그램되어져야 한다.

아무리 뛰어난 알고리즘이라도, "변수"가 존재한다.

예) 서브프라임 사태등

이런 "변수"까지 모두 적용한 완벽한 프로그램은 존재하지 않는다.

미국의 한 업체가 "왠만하면 돈번다"는 아주 기막힌 알고리즘을 개발하여, 실제 회사도 차리고, 돈도 많이 벌었다.(실화)

그러나, 서브프라임등의 커다란 악재를 만나면, 한순간에 어마어마한 손해를 보게된다.

그래서 그회사도 망했다.

미국 경제 다큐를 보면, 어떤 회사인지 알것이다.

당시 그 회사 직원이 말하길, 하루아침에 엄청난 손실을 보자, 

"몇년동안 돈 잘벌었는데, 도저히 믿을 수 없다."는 말을 했다고 한다.

시스템 트레이딩으로 돈을 벌 수 는 있다, 하지만, 언젠가 한번 크게 손해를 볼 것이다.

아니면, 조금조금 벌다가, 조금 더 큰 손해를 볼 수 도 있다.

또는 계속 조금씩의 이익을 볼 수 있다.

또는 크게 이익을 계속볼 수 도 있다.

시스템트레이딩은 "매우 빠른 도구"일뿐이다.

남들보다 매우 빠르다고 해서, 항상 돈을 벌 수 는 없다.

본인도 시스템트레이딩을 하면서, 수없이 알고리즘을 바꿔오고 있지만, 이익을 내는건 매우 힘들다.

중요한건 알고리즘이다.

그리고 시장을 보는 눈.

매순간 순간 가격을 체크하는것 보다, 차라리 한달에 한번 매매를 하는편이 더 정확할 수 도 있다.

void main()

{

int a;

int b;

int c;

a=1;

b=1;

c=a+b;

...

}

위와 같은 코드가 있을때,

컴파일 속도에 영향을 미치는 요인은 어떤것들이 있을까요?

눈에는 보이지 않지만, 문장의 끝에는 \r\n 2개의 문자가 들어 있습니다.

그리고 앞에는 Tab문자가 들어 있습니다.

컴파일러는 1문자당 1바퀴 루프를 돌게 되는게 일반적입니다.

루프문 1바퀴를 돌려면, 여러가지 조건이 있고, 이 조건을 포함해서 돌게되면,

최소 몇 클럭은 필요합니다.

1문자 때문에 최소 몇클럭씩 낭비가 되는것입니다.

위 코드를 아래와 같이 바꾼다면,

void main()

{

int a,b,c;

a=1;

b=1;

c=a+b;

...

}

개행문자(\r\n) 4문자와 "int " 2개, Tab 2개가 없어졌으니,

총 4+4+4+2=14문자가 사라졌습니다.

컴파일러는 14문자만큼의 루프를 덜 돌아도 되며, CPU클럭으로 따지면, 

1문자당 3클럭으로 계산해도, 최소 42클럭이상 빨라진것입니다.

또한 소스코드를 로딩할때도 이미 소모된 클럭이 있으므로, +@로 처리시간이 단축됩니다.

여기서 조금 더 나아가면,

- 변수명을 짧게

- 불필요한 공백을 사용안함

하면 +@의 효과를 얻을 수 있습니다.

물론, 코드의 가독성은 떨어집니다.

적당히 줄이세요.

"그거 줄여봐야 얼마나 되겠어?"

"요즘 CPU가 얼마나 빠른데?"

하시겠지만, 이런 수천 라인의 소스파일, 수천개를, 컴파일하게되면, 분명히 시간차이가 발생합니다.

또한, 파일에 저장하기위한 공간도 줄어듦니다.

무리하게 할 필요는 없고, 지금부터라도, 불필요한 공백은 자제합시다.

요약 : 불필요한 중복된 문자(동일한 변수형 반복), 불필요한 개행문자, 긴 변수명은 자제하자.

우스개 소리로, 예전에 마이크로 소프트사와 유닉스 진영에서 개행문자(\r\n)에 대한 논의(?)가 있었습니다.

유닉스진영에서는 개행문자가 \n 1바이트입니다만, 마이크로 소프으 윈도우에서는 \r\n 2바이트입니다.

컴퓨터에 있는 파일의 적지않은 용량의 파일이 택스트 문서이고,

해당 문서에서 개행문자때문에 소모되는 공간도 무시할 수 없다는 것입니다.

지구상의 모든 컴퓨터의 하드디스크에서 무시할 수 없는 공간이 낭비된다는 것입니다.

하드디스크 공간이 비약적으로 늘어나서, 그 피해가 너무 작을뿐, 낭비되는것은 맞습니다.

마이크로 소프트사에서는 이 문제 때문에, \r\n을 \n 으로 바꾸려는 시도를 하기도 했었습니다만, 엑셀, 비쥬얼베이직 같은 프로그램에서 문제가 발생하여, 중단한것으로 알고 있습니다.

유니코드문자를 사용하는 요즘에는 2배로 낭비되고 있습니다. ㅎㅎ