코드 짤 때 Long 이 Integer 보다 유리하군요.
2015.10.16 15:19
지금까진 용량 작은 게 당연히 처리속도가 더 빠른 줄 알았습니다만
속도 및 최적화 관련해서 검색해보니 32bit CPU 에 맞게 Long 을 쓰는게 더 속도가 빠르다네요 @_@
그래서 처리속도는 Long - Integer - Byte 순으로 느려지게 되고
실수 연산인 Single 은 당연히 Double 보다 빠릅니다.
가장 느린 건 Currency 라네요.
참고로 자바는 Integer 가 32비트이고 Long 이 64비트라 그냥 Integer 쓰는게 낫네요.
VBA 는 Long 이 32비트, Integer 는 16비트, Byte 는 8 비트로 이루어져 있죠.
64q비트 정수형을 쓰려면 64비트 오피스를 설치하고 LongLong 을 쓰면 된다고 합니다.
코멘트 11
-
해색주
10.16 15:58
으아아, 대충은 알겠는데 이렇게 초까지 계산하면서 뭔가를 해본적은 없네요. 근데, 대부분의 신규시스템은 다 64비트니까 기업용은 그냥 넘어가면 되지 않나요? 참고로 제가 쓰는 통계 팩키지는 업그레이드 하면서 더이상 32비트를 지원하지 않더군요. 하하하, 그래서 32비트 엑셀과 맞추느라 삽질을 좀 합니다.
-
DoNotDisturb
10.16 16:58
어떤 수식이냐에 따라 다르지만 (적어주실수 있나요?)
32비트 이하의 정수형 데이터는 연산속도가 사실상 같습니다.
32비트보다 작은 데이터는, 일단 32비트 가져와서 나머지는 다 버리는 식으로 다룹니다.
64비트 데이터가 가장 빠른 이유는 64비트 데이터 처리를 위한 여러 종류의 하드웨어 최적화 때문입니다.
64비트 통으로 다 쓰는게 가장 빠릅니다. -
정수는 +10 -10
실수는 +11.111 -11.111 요.
Byte 가 256 한계가 있어서;
-
DoNotDisturb
10.16 23:45
두 수를 더하고 빼는걸 반복하는 수식인거죠?
예측가능한 경우에는 64비트를 쓰는게 차이 날 정도로 더 빠릅니다.
루프도 10억번으로 예측이 가능하고 (인덱스가 0부터 10억-1까지 순증하기 때문에 terminal condition (인덱스가 10억이 될 때)을 제외하고는 예측 가능해서 가속화 됨)
수식도 +와 -가 반복되기 때문에 가속화 할 수 있습니다. (수식이 조건에 따라 변하지 않음)
그런데 하드웨어 가속화는 64비트 데이터를 쓸 때 더 빠를 수 있습니다. (32비트일때도 빨라질 수 있긴 함)
이래저래 64비트를 다 쓰는 쪽이 빠릅니다.
가속을 위한 신기술도 real 64비트 모드에 많이 적용되어 있고요.
32비트만을 위한 아키텍처 개선은 요즘엔 거의 없습니다.
-
10억번 연산ㅎㄷㄷ;;
-
왕초보
10.17 01:04
옛날에 계산 많이 하는 프로그램을 만들어서 논문 만들고 있었는데 (쓰고 있지는 않았다는게 함정), 파스칼로 만들고 있었답니다. real로 연산을 하면, math co-processor를 안 쓰는데, 마침 이게 꽂힌 귀한 컴터가 있길래 double로 바꿨더니 훨씬 빨라지더란.. 가끔 한개씩 찍히는 숫자가 주왁 스크롤되어서 올라가는 느낌이란.. ㄷㄷㄷ그것에 비하면 이건 거의 차이가 없는 셈이네요. ^^
-
piloteer
10.17 11:13
DoNotDisturb님 말씀대로 32비트 환경에서 16비트 변수를 쓰면 보통 32비트로 할당하고 윗 16비트부분은 버리는 식으로 진행합니다. 64비트에서도 마찬가지로 32비트 변수나 그 이하를 쓰면 남는 공간은 버립니다. 굳이 하려면 메모리를 꽉 채워쓸 수 있지만 메모리가 넉넉한 일반 윈도기반 컴퓨터 기준으로는 오히려 연산속도에 해가 되어서요.이 덕에 실제로 나는 성능차이는 그렇게 크지는 않은 편입니다.
그나저나 VBA는 아직도 integer를 16비트로 잡나 보군요. x86에서 동작하는 경우 대부분의 언어는 int를 32비트나 그 이상으로 잡는 것으로 기억하고 있었습니다만.. C언어같은 경우 표준상으로는 int를 16비트로 해도 되지만 보통 32비트 cpu상에서는 그냥 32비트로 구현하거든요..
제가 VBA는 써본 적이 없는지라 currency 변수는 뭔지 잘 모르겠고.. long long이 빠른 이유는 64비트 환경에서 테스트하신 덕인 것 같군요. 32비트환경에서도 돌아는 가겠지만 속도가 느려질 것 같습니다. VBA가 바이너리를 생성하는지, 아니면 스크립트어처럼 가동하던가 잘 모르겠습니다만.. 전자이며 64비트 바이너리만 생성한다면 다른 변수를 써도 32비트 머신에선 동작하지 않겠지요. 아니라면 64비트 변수를 쓰셔도 32비트 머신에서도 일단 가동자체는 될 것입니다. 성능은 저하되겠지만요..
-
아 망했네요...
64비트 데이터타입 LongLong 이나 LongPtr 은 값을 저장하는데만 쓰지 For 같은 루프문에서는 사용 못하도록 막아두었습니다. 사실상 최종값 계산하는데 말곤 쓰지 말라는 거네요.
-
아주 먼 오래전 이야기인데..
웹 솔루션 하나 만들어서 쓰던 회사에서 처음에는 프로그램이 잘 돌아갔는데, 어느 순간부터 금액이
맞지 않다고 해서 봤더니... 4byte 정수형을 사용해서 계산 되도록 만들어져 있더군요.
그걸 만든 사람은 왜 4바이트 정수형을 사용했는지 ... 아무튼 그 부분 때문에 부가세 계산 하는 부분도
문제가 있어서 싹 뜯어 고쳤던 게 생각나네요.
-
음;;;
VB (비주얼스튜디오) 에서는 다른 결과가 나오네요.
50억번 연산으로 VBA 보다 5배 더 시간이 걸리는 작업입니다.
Integer - 13.65초
Long - 16.6초
Single - 22.07초
Double 22.09초
엑셀보다 5배 더 빠르네요 ㄷㄷ
실제로 테스트해보니 조금 다르네요; 루프문 10억번 덧셈뺄셈 해봤습니다.
Byte : 14.44 초
Integer : 14.29 초
Long : 14.24 초
LongLong : 11.46초
Single : 21.01 초
Double : 21.48초
Currency : 12.06 초
운영체제는 윈도7 64비트에 64비트 오피스 2013입니다.
여러번 수식을 바꿔도 가장 속도가 빠른 건 64비트 코드인 LongLong 과 Currency 네요.
데이터 타입 전부 이걸로 바꾸면...32비트 윈도에선 안 돌아가겠죠 ㅡ.,ㅡ