'int'에 해당되는 글 1건
2008.06.05 14:40
 이 글은 http://kuwamoto.org/ 에 올라온 Avoid ints in ActionScript의 번역 포스팅입니다.
에이레네님이 올리신 글을 보고 알게 된 포스트인데 상당히 좋은 내용이라서 번역하여 올려봅니다.
엉터리로 번역되었을 가능성 다분함.. 태클환영..;

2009. 8. 19. 내용 추가

이 글은 작성시 부터 여러 많은 개발자 분들이 내용에 오류가 있다고 지적해주셨습니다. 글의 내용에 대해서 지적해주시고 하는 것은 정말 감사드립니다. 제가 부족한 점이 많아 이해를 제대로 못하였거나, 글 작성에 문제가 있을 수 있기때문에 여러분의 덧글 하나하나가 정말 도움이 많이 되고 있습니다.

제가 본문을 수정하거나 혹은 이 글을 삭제하려고 했으나, 혹시 필요하신 분들이 있을 것 같아 본문을 수정하거나 삭제하지는 않겠습니다. 글을 다 읽으신 후 밑에 다른 분들의 덧글도 읽어보시면 더욱 좋은 것들을 배우실 수 있다고 생각합니다.

ActionScript 에서 int는 피하자구요!
Flex에 대해 알아갈수록, int에 대해서 알게 될수록, int를 사용하지 않게 되었습니다.
int가 정말 필요하지 않는 이상 int는 더 이상 사용하지 않을 것입니다.

이유 1 : Number가 int보다 실제적으로 더 빠릅니다.

놀랍게도, 사실입니다. ECMAScript Edition 4는 ECMAScript 이전 버전과 호환이 가능하게 설계되었습니다.
그래서 수학적으로 완전 무결하게 옳다라는 것을 보장하기가 어렵습니다.



어떤 방법이 더 빠를 것 같은가요? 제가 사용하는 컴퓨터에서는 int 를 사용하여 331ms 걸렸고, Number 는 291ms 걸렸습니다.



▲ 실제로 이 글을 읽는 분이 걸린 시간.

왜 그럴까요? 다음의 표현식을 보시죠.


만약 여러분이 j = 2^23 - 1 로 값을 시작했으면 어떠할 것 같습니까? 일부 프로그래밍 언어에서는 15번 더하자 마자 오버플로우 문제가 나타날 것입니다. 그러나 ECMAScript는 수의 개념이 좀 느슨합니다. 시스템에서 필요시 int에서 double로 변환되는 것을 지원하고 있습니다. 이 때문에 실질적으로 모든 수학적 계산은 내부적으로 int가 아니라 Number로 합니다.

Number로 모든 것이 완료되는 것을 감안해보면 int를 Number로 변환하는 비용과 그 만큼의 시간이 왜 int 를 사용하면 시간이 더 걸리는지에 대한 이유입니다.

다음은 Number는 실제로 int 보다 정확하게 정수 값을 저장시키기 때문에, int보다 Number 를 써야 되는 이유입니다.  

이유 2 : Number는 더 많은 bit를 가집니다.

이 이유는 후에 확실하게 할게된 Number에 대한 놀라운 사실입니다. 어떻게 알게된 것인지 설명해보겠습니다.

Date 객체에는 1970년 1월 1일 자정 부터의 시간을 milliseconds 단위의 숫자로 반환하는 time 이라는 속성이 있습다. 그 값은 정수형 값이고 ActionScript에는 long 타입이 없기 때문에, 반환 타입이 진짜 int (아니면 아마도 uint) 라고 가정했습니다.



왜 버그가 나는 걸까요?
 back of the envelope calculation 에서 1970년 1월 1일부터 2^32 milisecond 보다 더 값을 가지기 때문에 결과가 오버플로우 난다는 것을 알려주고 있습니다. 바보같은 실수죠.

int로 받으면 2,129,587,200, Number로 받으면 1,209,015,397,376. (2008년 4월 24일 기준)
위의 값으로 Date() 객체에 다시 넣어보면 각각 1970년 1월 26일, 2008년 4월 24일 이 출력됨. - 검쉰


그렇다면 int의 bit보다 더 큰 수를 써야할 때, ActionScript는 Long 타입이 없는 상태에서 어떻게 오버플로우나 이런 부정확한 값을 해결할 수 있을까요?



속을 살펴보면, Number는 아래에 있는 숫자형을 포함하고 있습니다.

  • int
  • uint
  • IEEE double

저는 항상 정수의 계산를 위해 double 형태를 사용하는 것을 피했습니다. 왜냐하면 모든 자리수가 보존될 것이라고 전혀 확신할 수 없었기 때문입니다. 왜냐하면, 개인적인 견해로는 정확성 측면에서 보자면 double은 int 보다 더 큰 범위의 수를 저장하기 때문입니다.

결국엔 ActionScript 의 경우에, Number는 더 큰 수의 범위를 저장할 수 있습니다. 그리고 어떤 정수형보다 정확합니다. 그건 아마도 ActionScript 는 64bit 의 정수형 타입이 없기 때문인 것 같습니다.

IEEE double 포멧은 다음과 같이 구현되어 있습니다.


부호를 위한 1 bit, 지수를 위한 11 bit, 숫자부분을 위한 52 bit. 따라서, 정밀도의 손실 없이 int보다 더 큰 bit의 수를 확실히 저장할 수 있습니다.

언제 int를 사용해야 될까요?

다음은 int의 적당한 사용방법입니다.

  1. 메모리를 절약하고 싶을 때 (비록 아주아주 많은 양의 저장공간이 있다 하더라도 결국에는 좋지 않은 영향을 줄 것입니다)
  2. 정수 값으로 강제변환 시 (예를 들어 var i: int = j / 2)
  3. 클라이언트에서 서버쪽으로 정수값을 보낼 때 버그를 줄이기 위해서 (값 전달용 객체안에 int 필드가 있을 때).

이제 다 설명했으니, 저는 이제 제 코드의 대부분의 Number를 확인해 볼 것입니다.


 4. loop 시에 카운터로 사용 - 예를 들어 for(var i:int = 0; i < X.length; i++)


--- 2008년 6월 16일에 추가

참고 : 제가 추가로 좀 더 서술하자면, 위에서 int보다 Number가 더 빠르다는 것은 특정 상황에 대해서 그렇다는 것입니다.

 int로 어떤 연산을 진행하는 것이 int보다 더 큰 Number로 연산을 진행하는 것 보다 더 빠른 것이 당연합니다. int가 Number보다 처리해야할 bit가 적으니까요. (var i:int = 0; i++; 이런경우) 다만, int형으로 연산중에 int형의 크기보다 더 큰 수를 처리해야하는 경우에 다른 언어에서는 잘못된 값이 출력이 됩니다만(이유 2에서 이런 문제를 지적하고 있습니다), AS3는 자동으로 Number 로 변환하여 연산을 진행합니다.
 이런 이유에서 "int가 내부적으로 Number로 변환되는(int의 크기를 넘어서는 연산) 경우에는 Number로 진행하는 것이 더 빠르다." 라는 것이 이 포스트의 속도 문제에서의 핵심입니다.

원저자가 약간 int에 대한 매우 안좋은 감정이 있긴 한 모양입니다만, 이 글을 보신 분들은 때에 따라서 잘 사용하시면 좋겠죠?


신고
Favicon of http://sunyoungheo.tistory.com BlogIcon 다롱냥 | 2008.04.24 15:04 신고 | PERMALINK | EDIT/DEL | REPLY
요호... 유용한 정보네염 꺅, 검쉰님은 머쨍이 히히
Favicon of http://warkyman.tistory.com BlogIcon 검쉰 | 2008.04.25 11:17 신고 | PERMALINK | EDIT/DEL
감사감사
Favicon of http://lovedev.tistory.com BlogIcon lovedev | 2008.04.25 11:46 신고 | PERMALINK | EDIT/DEL | REPLY
저도 느낌만으로 int는 절약할 때
Number는 정확한 숫자결과를 찾고 싶을때(나눗셈이나 좌표에 대한 controll을 할 때등) 사용하고 있었는데
이 글에서 명확하게 설명해 주셨네요.
좋은 정보 감사드립니다 : )
Favicon of http://warkyman.tistory.com BlogIcon 검쉰 | 2008.04.25 15:27 신고 | PERMALINK | EDIT/DEL
어설픈 번역으로 잘못된 정보를 접하신건 아닌지 더 걱정이. ^^;
방문해주셔서 감사합니다.
CyD707 | 2008.05.07 19:37 신고 | PERMALINK | EDIT/DEL | REPLY
저는 몇번을 테스트해봐도 number보다 int가 2배정도 더 빠른데요..;;;;
제 컴퓨터가 이상한건가요=_=;;;;
Favicon of http://warkyman.tistory.com BlogIcon 검쉰 | 2008.05.07 23:02 신고 | PERMALINK | EDIT/DEL
회사컴이나 제 노트북, 기타 등등 에서 본 페이지 열어서 해봐도 Number 가 빠른 걸로 나오긴 합니다만.. ^^;

컴퓨터 사양이 어떤가요?
Favicon of http://blog.jidolstar.com BlogIcon 지돌스타 | 2008.05.10 14:21 신고 | PERMALINK | EDIT/DEL | REPLY
좋은 정보입니다. 적절하게 잘 사용하면 될거라 생각해요.
Favicon of http://warkyman.tistory.com BlogIcon 검쉰 | 2008.05.10 22:34 신고 | PERMALINK | EDIT/DEL
이 포스트 번역하고 깨달은 사실인데,
레퍼런스에는 항상 루프 카운터는 int 로 쓰더군요 ㅎ
Favicon of http://blog.naver.com/kieat_seo BlogIcon 남남남 | 2008.05.12 12:25 신고 | PERMALINK | EDIT/DEL | REPLY
안녕하세요... actionscript를 사용하면서 오래전에 생겼던 의문이 하나 있는데요... 늘 해답을 찾지 못하고 있는데 좀 도와주시겠어요?
http://blog.naver.com/kieat_seo 에 와보시면 제가 포스팅해놓은게 있습니다.
Favicon of http://warkyman.tistory.com BlogIcon 검쉰 | 2008.05.12 17:40 신고 | PERMALINK | EDIT/DEL
AS3 의 버그인 것으로 사료됩니다.
저도 예전에 비슷한 문제를 겪었는데, 난감하더군요.
제가 겪었던 문제는 소수점 아래의 값들이 제대로 계산이 안되는...;;;
공룡 | 2008.05.14 00:43 신고 | PERMALINK | EDIT/DEL | REPLY
소수 부분이 2진수의 배수로 처리되서 나오는 어쩔수 없는 오차 입니다.
컴퓨터 자체의 처리 오차 죠...

2진수 :1 1 1 1 1 1 1 1 1 1 1 1 1
자릿수:4 3 2 1 0 -1 -2 -3 -4 -5 -6 -7 -8
값 :16 8 4 2 1 0.5 0.25 0.125 0.0625 0.03125 0.015625 0.0078125
비교해 보시면, 실제 0.4을 만들기 위해서는 0.25 + 0.0.... 이런 식으로 2진수의 1/2승수로 밖에 갈수 없어 가장 유사한 수를 가지고 계산 하게됩니다.

그래서 0.5는 2진수 0.1 로 나오나 특정의 수는 완전 일치 하는 수가 나올수 없는, 즉 최악의 경우 1/2^52의 오차가 생기게됩니다.
이를 근본적으로 해결하면, 실수가 아닌, (문자열) Decimal 처리 식이 있으나, 속도및 메모리의 문제로 인하여, 아주 정밀한 연산에서만 설계되어 사용됩니다.
<span class="name" | 2008.05.14 01:43 신고 | PERMALINK | EDIT/DEL
아하.. 그런 이유가 있었군요 ;)
좋은 정보 감사합니다.

그렇다면 정밀한 연산을 플렉스에서 한다는 자체가 부담이겠네요.... 음..
<span class="name" | 2008.05.14 11:41 신고 | PERMALINK | EDIT/DEL
String(mynum)대신에 mynum.toFixed(2)를 사용하니까 오차가 안 생기고 결과값이 딱 0.05씩 증가하더군요... ^^제 블로그에 수정한 swf파일을 업로드 했습니다....
박스농사 | 2008.05.21 15:07 신고 | PERMALINK | EDIT/DEL | REPLY
닌텐도 파는날 모이는건가요?
Favicon of http://warkyman.tistory.com BlogIcon 검쉰 | 2008.05.21 15:08 신고 | PERMALINK | EDIT/DEL
벌써 팔았답니다?
dongland | 2008.05.30 18:06 신고 | PERMALINK | EDIT/DEL | REPLY
j 랑 m 에 연산 부분에서 "/" 나누기 등 연산땜에 느려지는 듯 싶습니당
걍 단순히 연산을 ++ 증감 해두고 계산해 보면... Number 가 더 느립니다.
int 가 더 빠르더군요. 즉.. 속도가 int 가 더 느리다는 아닌듯 싶네요~


var intTime : Number;
var numberTime : Number;

var i : int;
var j : int = 0;

intTime = (new Date()).time;
for (i=0; i&lt;10000000; i++)
j++;

intTime = (new Date()).time - intTime;

var n : Number;
var m : Number = 0;

numberTime = (new Date()).time;
for (n=0; n&lt;10000000; n++)
m++;

numberTime = (new Date()).time - numberTime;

var message : String = "int version: " + intTime + "ms\n" +
"Number version: " + numberTime + "ms";

trace(message);
-------------
결과
-------------
int version: 63ms
Number version: 78ms
Favicon of http://warkyman.tistory.com BlogIcon 검쉰 | 2008.05.30 18:56 신고 | PERMALINK | EDIT/DEL
나누기 연산이 키 포인트입니다. ;)
증감 같은 경우는 당연히 크기가 작은 int가 더 빠릅니다. 하지만, 나누기 같은 경우는 내부적으로 int도 Number로
변환해서 작업을 하기때문에 그냥 Number로 하는 것 보다 더 시간이 오래 걸리는 것이지요. (이유1에 마지막에 서술)

들어주신 예처럼 j++ 경우는 int가 더 빠르기때문에 for문의 카운터로 이용하면 좋다. 라고 제가 글의 마지막 부분에 추가 서술해놓았습니다.

상황에 맞게 선택해서 사용하면 좋겠습니다. ;)
의견 감사합니다. ;)
Favicon of http://hangunsworld.com BlogIcon Han Sanghun | 2008.06.09 08:53 신고 | PERMALINK | EDIT/DEL | REPLY
이게 CPU에 따라서 다른 결과가 나오는 것인지???
어떤 컴퓨터에서는 int가 어떤 컴퓨터에서는 Number가 더 빠르네요.
Favicon of http://warkyman.tistory.com BlogIcon 검쉰 | 2008.06.09 09:48 신고 | PERMALINK | EDIT/DEL
대부분의 컴퓨터에서는 Number 가 빠르게 나옵니다만,
몇몇 분들이 int가 더 빠르다고 하시네요 ^^;
약간 의심 가는 상황이 있습니다만, 정확하진 않네요 ^^;
혹시 알게되면 좀 가르켜주세요 ^^;;;
Favicon of http://wooyaggo.tistory.com BlogIcon wooyaggo | 2008.06.16 11:48 신고 | PERMALINK | EDIT/DEL | REPLY
아 제가 이 부분을 만나는 분들마다 설득하느라 가끔 고생하는데
검쉰님도 이부분을 오해하고 계신거 같습니다.

예전 Flash 9 알파때 해외 블로거의 포스트에서 발발된 내용인데
물론 아직도 갑론을박하는 분들도 계시는거 같은데
결론은 "쓰임새에 맞게 사용하면 int 가 더 빠른것이 맞다." 입니다.

즉 굳이 Number 타입을 int 에 넣는 행위를 반복하는 테스트로
int 가 느리다라는 결론은 옳지 않다는 것입니다.
AVM 은 Number 타입을 int 에 대입할때는
소숫점을 버리고 int 형으로 계산하는 과정을 거치게 되므로 당연히 그만큼의 시간이 더 걸리게 되죠.

int 에 정수값을 넣고 테스트하고
Number 에도 정수값을 넣고 테스트해야지만 올바른 테스트가 아닐까 합니다.

즉 이 테스트의 오류가 시작된 부분은 Number 에 유리한 숫자로 테스트를 진행했다라는 것입니다.

이상 제 의견이었습니다^0^
Favicon of http://warkyman.tistory.com BlogIcon 검쉰 | 2008.06.16 14:19 신고 | PERMALINK | EDIT/DEL
덧글 달아주신 내용은 충분히 이해하고 있습니다 ;)

이 포스트는 제가 작성한 것이 아니고 번역한 거라서.. ㅎㅎ 원본 포스트에서 제가 이해한 것은 지적하신 것과 같이 Number에 유리한 숫자로 진행한 경우에 int보다 Number가 더 빠르다... 라는 것입니다.
물론 int에 유리한 숫자(예를 들어 i++) 같은 경우는 int가 빠른게 당연하겠죠 ;)

상황에 따라 알맞게 사용하는게 가장 중요한 것 같습니다. ;)
drawtree | 2009.03.03 00:06 신고 | PERMALINK | EDIT/DEL | REPLY
http://www.onflex.org/ACDS/AS3TuningInsideAVM2JIT.pdf

25페이지를 참조하기 바랍니다.

ECMA스크립트 사양에서 일부 수치 연산시 int에서 Number로의 암시적 형변환이 일어나며, 이 식을 int를 요구하는 연산으로 바로 전달하면 다시 int로의 암시적 형변환이 일어납니다. 이 두번의 암시적 형변환 때문에 성능이 저하되는 것이며, 부동소수 형식에 내재된 오류를 보정해야 한다는 것을 생각하며, 실제로는 int가 훨씬 더 빠릅니다.

int가 유리한 상황이나 Number가 유리한 상황이 따로 존재하기는 하지만 위에 올려진 포스트는 그것과는 무관하며, 암시적 형변환을 생각하지 못했기 때문에 도출된 결론입니다.

또한 Number는 부동소수 형식이며, 연산오류가 누적되기 때문에, 특히 for문의 인덱서로는 거의 사용할 수 없습니다. 굳이 사용해야 한다면 매 회마다 정수로 보정해야 하기 때문에 성능이 좋을 수 없습니다. (int형이 없고 인덱싱 오류가 발생해도 좋은 상황에서만 사용됩니다. double연산이 int와 속도가 같다 해도, 이러한 이유들 때문에 Number는 for문에서 좋은 성능을 보일 수 없습니다. 본문에서 for문의 인덱서로 부동소수를 사용하면서 오류 보정을 하지 않고 있는데, 그것 자체가 버그입니다.

하지만, ECMA스크립트 명세상 Number로 암시적 형변환이 일어날 수 밖에 없는 상황이라도 결과식을 다시 int로 강제 형변환을 수행해주면 컴파일러가 전체 식을 int연산으로 추론할 수 있으므로 최적화할 수 있다고 위 문서에서 밝히고 있습니다.

주의할 것은, 일반적인 언어에서는 오버플로우를 무시나 예외로 해결하지만, ECMA스크립트에서는 더 큰 용량의 수로 암시적인 형변환을 통해 이를 해결합니다. 일반적인 C 계열 언어에서 i+1 과 같은 코드는 절대적으로 결과가 int일 것이 보장되지만, AS는 Number로 형변환합니다. 이러한 암시적 형변환에 대해 잘 알지 못하면 위와 같이 int가 느리다는 결론을 얻을 수도 있습니다.

또한 본문 중에 실제적으로 모든 수를 Number로 수행한다고 언급한 부분이 있는데, 위와 같이 형식을 강제해주면 컴파일러가 형변화을 피하도록 최적화할수 있으므로 그렇지는 않습니다.

그리고, Number가 가장 정확하다는 언급이 있는데, 이는 보는 관점에 따라 달라집니다. 단순히 실제 수치와 일치를 말한다면 Number는 정확하지 않습니다. 하지만 수치 표현 범위를 기준으로 비교한다면 좀 더 정확하다고 말할 수도 있습니다. 하지만 일반적으로 정확하다는 표현은 수치의 일치를 가리키고, 수치 표현 범위를 가리킬 때는 좀 더 '정밀하다'는 표현을 사용합니다. 원문에서 precise라는 단어를 사용해 혼란을 주고 있는데 accurate라고 하는 것이 일반적입니다.

int가 필요한 상황은 한가지밖에 없습니다. 수치적으로 정확한 고성능 정수 연산이 필요한 경우입니다. 하지만 대부분의 성능 문제는 for문이나 배열 엑세스같은 카운트나 인덱스에서 발생하고, 이런 곳에는 int 외에는 답이 없습니다.

제생각에 이 포스트의 제목은 잘못되었습니다. 성능 때문이라면 위와 같은 for문에서는 int를 더욱 적극적으로 사용해야 합니다. 위에서 언급된 성능 문제는 Number로의 형변환 때문에 생기는 것이지 int의 문제가 아닙니다.

제가 뭐라할 부분은 아니지만, 구글 광고를 게시하는 블로그에서 자극적인 제목의 잘못된 정보를 게시하는 것은 사실 좋게는 안보이지요.
태클환영이라 태클 좀 달아봤습니다.
Favicon of http://blog.flashplatform.kr BlogIcon 검쉰 | 2009.03.04 20:58 신고 | PERMALINK | EDIT/DEL
긴 글 쓰시느냐 고생많으셨겠습니다. 지적 감사합니다.

그리고 폼으로 달아놨던 구글광고는 삭제했습니다. 내용적인 부분에서 태클은 항상 환영합니다.
뭐라할 부분이 아닌데 뭐라해주셔서 기분이 썩 좋지는 않군요.

당분간 글을 쓰지 않을 생각입니다만, 앞으로도 글 내용에 문제가 있으면 태클걸어주시면 감사하겠습니다.
Favicon of http://www.iruis.net BlogIcon ☆~ | 2009.08.17 12:26 신고 | PERMALINK | EDIT/DEL | REPLY
글 내용은 좋지만 int, uint는 이제 버려라. 라는 내용으로 와닿는 것에 대한건 어쩔 수 없네요. drawtree님의 지적이 그렇기 때문인듯합니다.
(아마 직접 작성한 글 내용이 아니라 번역 한 글인데 저렇게까지 지적당한것에 불쾌하신게 아닐까 생각되네요. 이젠 번역하기에 앞서 문제점부터 알아봐야 할듯하네요.)

본론으로 들어가자면 위의 댓글 중 남남남님의 소숫점 버그란것은 엑션스크립트의 버그가 아닙니다. IEEE표준에 의해 처리 되는 모든 소숫점 처리에 공통으로 가지고있는 문제입니다(참고: http://msdn.microsoft.com/ko-kr/library/c151dt3s.aspx).
남남남님의 댓글에서 해당 문제에 대해 포스팅 해보겠다는 내용을 보았는데 포스팅이 되어 있지 않아서 혹시나 아직도 AS의 버그로 아시는건 아닐까... 하는 생각에 오래 지난 글이지만 이렇게 댓글을 답니다.
Favicon of http://blog.flashplatform.kr BlogIcon 검쉰 | 2009.08.19 10:36 신고 | PERMALINK | EDIT/DEL
오해의 여지가 있어 글 자체를 삭제하려다가 그냥 두었습니다. 번역한 글 자체를 지적하는 것은 상관없습니다만(제 글에 대해 내용적으로 반박하는 것도 환영입니다), 그외의 것인 제 블로그에 이래라저래라 하는 것이 불쾌한 것이죠.

보다 건설적인 방법으로는 위의 drawtree님처럼 저렇게 글 하나를 쓸 정도의 덧글을 쓰는 것 보다는 자신의 블로그에 해당 글을 올려서 공유한다면 더 유익하지 않을까요? 트랙백이라는 유용한 기능이 있으니까요.
제가 심심해서 번역한 것이 아니라 유익하다 판단하여 공유하고자 올린 글이기때문에 더더욱 제 블로그에 대해서 지적한 것이 불쾌합니다.
앞으로는 왠만하면 외국 블로거의 글을 번역하지는 않겠습니다. 해서 좋은 소리 못듣겠군요.

그리고 소숫점 버그에 대한 의견은 감사합니다. 공통적으로 가지고 있는 문제라면, 해당 문제에 대해 API 에서 공지하던지, 아니면 해결했어야 된다고 생각합니다. 저 같이 경험이 일천한 개발자로써는 해당 내용을 잘 몰랐으니까요.
관련 내용에 대해 글을 쓰셔서 다른 개발자들을 위해 공개해주시는 것은 어떨까요?
공명 | 2009.09.18 10:36 신고 | PERMALINK | EDIT/DEL | REPLY
이상하네요!!
왜 저는 int가 number 보다 빠르게 나올까요??
제 컴이 이상한걸까요??
Favicon of http://blog.flashplatform.kr BlogIcon 검쉰 | 2009.09.20 02:01 신고 | PERMALINK | EDIT/DEL
이번에 새로 산 (Intel Q9550) 컴퓨터에서 테스트해보니, 저도 int 형이 더 빠르게 나오네요.
FP 는 10,0,32,18 입니다.

뭔가 바뀐 것이 있는 모양입니다.
그냥 적절하게 사용하여야 된다. 라고 이해해주시면 좋겠네요.
Favicon of http://blog.chanik.com BlogIcon 찬익 | 2009.10.01 18:26 신고 | PERMALINK | EDIT/DEL | REPLY
둘다 1ms 1ms 나와서 성능 비교 불가 (...)
Favicon of http://blog.flashplatform.kr BlogIcon 검쉰 | 2009.10.03 18:25 신고 | PERMALINK | EDIT/DEL
대충 짜자. -ㅁ-;;;
- 덧글 좀..(굽신굽신) : 장문의 덧글은 트랙백을 이용해주세요 ;^)
Name
Password
Homepage
Secret
prev"" #1 next

티스토리 툴바