64Bit CPU 시대의 도래

지리즈의 이미지

INTEL 386이 등장한지도 이제 10년이 조금 넘어가고 있습니다.
8 Bit Cpu 시장은 상당히 길었던 반에
16Bit CPU시장은 다른 32bit, 8bit에 비해 단명한 감이 있죠.
아마도 64bit시장 역시 16bit때 처럼 단명하지 않을까 싶습니다.
길어도 5~6년정도 반짝하다가 128Bit의 시장으로 넘어갈 것 같습니다.

이번에 AMD 64가 시장에 등장했습니다.
물론 RISC칩중에는 이미 64,128bit의 CPU가 사용되고 있지만,
일반 대중을 위한 CPU가 64bit로 등장한다는 데에 의미를
두어야 하지 않는가 싶네요.

64Bit CPU등장이 우리에게 어떠한 변화를 주게될지...
32Bit CPU가 우리에게 어떠한 것을 남겨 주었는지 한번 생각해고 싶습니다.

댓글

Necromancer의 이미지

286과 386이 공존하던 시절처럼 당장에는 필요 없을 걸로 보입니다.
심지어 486시절에도 16비트 프로그램들을 아주 많이 썼으니까요.
하지만 64비트로의 전환은 대세겠죠.
시간이 얼마나 걸릴지 모르겠습니다.

32bit 메모리공간의 부족 현상은 현재 워드치는 용도의 개인용 데탑에서는 별로 없습니다.
하지만 고해상도 그래픽이나 동영상을 다루는 쪽에서는 문제가 되고 있죠. 서서히
이것도 도스시절 640k 메모리공간의 제약으로 머리 싸맸던 시절에 비하면 덜하다고 느껴지네요.

Written By the Black Knight of Destruction

mastercho의 이미지

64 비트면 테라 단위의 크기입니다

현재 32비트의 4기가 모자라는 경우는 대형 시스템에서나 그렇지 일반 용도로는 거의 부족함이 없습니다

일반 개인용으로 64비트는 거의 불필할 정도죠
[128비트가 쓰이는곳이 있나요? 세계에 몇 안되는 슈퍼 컴퓨터가 아닐지?]

예전의 도스 시절의 16비트와 32비트 를 비교하기에는 무리며, 그 차이도 많이 다르다고 봅니다

인텔이 32비트 시스템을 계속 추구하는것도 이런 맥락이라 봅니다

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만 패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다.
- 하비스

지리즈의 이미지

우리 주변에 32bit로 구성된 것들중 많이 쓰이는 것들이 있는데.
예를 들면.. IP Address, 알파채널을 포함한 True Color ...
single형 부동소수점연산... 32bit integer, 등..
인터넷 멀티미디어 쪽에서 많이 활용되는 것들입니다.

이것들이 64Bit로 전환되었을 때 어느정도...
실질적인 이득은 있을 것도 같은데...

물론 이런 식의 결론이라면..
IPv6를 위해서는 128bit CPU를 활용하는게.. 낫다는 말이 되긴 하지만...

어떻습니까?

32bit에 비해 64bit cpu는
단순한 메모리 어드레싱 능력말고 향상점이 없나요?

There is no spoon. Neo from the Matrix 1999.

지리즈의 이미지

mastercho wrote:
128비트가 쓰이는곳이 있나요?

트랜스메타의 크루소 칩이 128, 256bit 방식입니다.
몇몇 워크스테이션에서는 64,128bit 방식의 RISC cpu가 사용되는 걸로 알고 있습니다.

There is no spoon. Neo from the Matrix 1999.

익명 사용자의 이미지

64비트가 가장 필요한 분야는 바로 time() 콜이 아닐지요. :)

2038년인가에 고갈된다고 합니다.
Y2K를 능가하는 대혼란이 발생될겁니다.
Y2K처럼 프로그램만 수정해서 될 게 아니라 구 기계를 완전히 못쓰게 될테니까요. (단순히 커널만 패치해서 될 게 아니라 수많은 응용프로그램들을 모조리 고쳐서 컴파일해야 할테니... 2038년 닥쳐서 준비하면 너무 늦죠... 현재의 소스코드가 사라진것도 있을테고 심지어 컴파일러 자체가 없어졌을 경우도 있구요.)

아직 64비트 time() 콜을 제공하는 운영체제는 못봤지만..
10년 이내로 다들 옮겨가리라 생각됩니다.
80년대에 도입한 구기계가 아직도 돌아가는 곳이 꽤 있다는걸 생각해 보면.. 지금부터 64비트를 준비하더라도 그때 되면 한바탕 혼란이 일어나지 않을까.. 생각이 드네요.

hanbyeol의 이미지

IT 3대 사기 가운데 하나로 일컬어지고 있습니다. 99년도에 회사분들 가운데 해외로 나간 사람 꽤 됩니다. 당시 COBOL 하던 사람 인기 좋았습니다.

무어의 법칙이 완화되더라도 지금부터 30여년 뒤에 컴퓨팅 환경은 어떻게 될지 모릅니다. 10여년전만 하더라도 인터넷을 모르는 사람이 대부분이었고 일반인들에게는 통신환경은 모뎀 정도였습니다. 그런데 지금은? 그렇다면 지금부터 30년뒤는?

2038년이 다가오면 이에 대한 buzzword와 FUD가 난무하겠죠. 결과는 어떻게 될지 모르지만 ...

ziyo79의 이미지

amd의 이번 64bit 아키텍쳐는 새로운 도약이 아닐까요. 여러 벤치마킹에서도

우수한 성능을 보이는 걸 보면요. intel이 아직까지 개인용 피시에서 32bit 체제를

고수하는 것은 예전부터 하위호환을 위한 어쩔 수 없는 결정이라는 기사를 본

것이 기억납니다. 그런 면에서 이번에 amd가 64bit 베이스에 32bit 호환

프로세서를 들고 나온 것은 새로운 도약이라 생각합니다. 하지만 모든 프로세서가

그렇듯이 성공을 위해서는 그에 적합한 운영체제가 필요한 것 같습니다.

개인 데스크탑 사용자의 90%이상이 윈도우를 쓰는 상태에서 ms가 64bit지원

운영체제의 발표를 내년 말로 잡고 있는 상태에서 얼마나 많은 사용자가 pc에서

64bit 프로세서를 선택할런지 궁금하네요. 그런 의미에서 리눅스나 맥 os가 새로운

대안으로 떠오를지도 모르는 일이고요.

궁금한 것은 64bit 운영체제에 32bit 응용프로그램이 어떻게 동작하는가입니다.

앞으로는 모든 프로그램이 64bit를 기준으로 하게 되겠죠..?

ziyo's idea

blog : http://ziyo.tistory.com
mail to : youngkook.cho@gmail.com

maddie의 이미지

저는 개인적으로 64비트로 가는 것이 대세가 아닐까 생각합니다.

mastercho wrote:

일반 개인용으로 64비트는 거의 불필할 정도죠
[128비트가 쓰이는곳이 있나요? 세계에 몇 안되는 슈퍼 컴퓨터가 아닐지?]

지금은 그렇습니다만, 제 짧은 지식으로는 개인 사용자도 멀티미디어에 대한 요구가 급증하고 있는 현재 상황에서 64비트는 상당히 훌륭한 플랫폼이 아닐까 생각합니다. 당장에 게임때문에 컴퓨터를 업글하는 지금의 트렌드에서는 그렇지 않을까요? :)

물론 지금 apple의 G5나 AMD의 64비트는 왠지 마케팅에서 인텔을 잡기 위해 일부러 논의를 확대시키는 경향이 있다고 생각되지만 실제 퍼포먼스가 좋아진다면 예기가 틀릴것이라는 게 제 생각입니다.

저도 옵테론을 구입하려고 장기 기획을 세우고 돈을 모으고 있는 중입니다. ㅡ.ㅡ 아~ 아직은 비싸요~ 물론 맥보다는 싸지만 ㅡ.ㅡ

그리고 크루소가 128비트인가요? :shock: Libretto를 쓰고 있지만 그말은 생소한데요. 자세한 설명해 주시면 감사하겠습니다. :)

힘없는자의 슬픔

ihavnoid의 이미지

제 생각에는, 64비트는 그다지 단명할 것 같지는 않습니다.

사실 64-bit니 32-bit 하는데, 32-bit 프로세서는 뭐가 32-bit이고, 64-bit 프로세서는 뭐가 64-bit일까요?
instruction 폭이 64-bit이고, 어떤 register은 32-bit이고, 어떤 register은 64-bit인. 그러면서 address는 32-bit 인 프로세서는 32-bit인가요 64-bit인가요?

그러면, 지금 얘기한 각 측면 - instruction, data, address 세가지에서 64-bit의 수명이 어떨지 생각을 해봅시다.

1번 instruction의 경우에는 이미 IA64같은 프로세서는 128비트짜리 instruction이 나오고 있는 걸 봐서는(좀 더 정확히 말하자면 여러 instruction을 묶은 것이 128비트겠지만), 그리고 현재도 VLIW 프로세서들이 쏟아져나오고 있는 걸 봐서는, 128비트, 256비트 등등으로 올라갈 가능성이 많습니다. 뭔가 새로운 패러다임이 나오지 않는 한, 올라갈 수도 있고 그대로 있을 수도 있을 것 같습니다. 전형적인 RISC 스타일이라면 64비트에서 머물 것 같습니다. (레지스터 갯수가 극단적으로 1000개가 넘는다면 모르겠지만, 제 생각에는 그러기는 좀 힘들 것 같습니다)

2번 data의 경우에는, SIMD가 아니라면 사실 32-bit 이상은 힘들 것이라는 생각입니다.
32-bit 정수만 따져도 사실 상당히 큰 범위입니다. 우리가 일상 생활에서 흔히 쓰는 숫자 범위는 거의 다 커버하는 셈이죠.
64-bit 정수를 쓰는 애플리케이션은 어느 정도 있습니다. 그렇지만 128-bit 정수를 이용해야 하는 application은 어디 있을까요? 굳이 128비트 데이터 레지스터를 만들어서 성능 향상을 많이 얻지는 못하겠죠. (그냥 생각해서, 10^37쯤 되는 정수가 필요한 애플리케이션이 얼마나 될까요?)
단, SIMD로 갈 경우에는 상황이 달라지리라 생각합니다. 128비트 register을 4개의 32-bit 값으로 쪼개서 연산을 할 경우, 많은 이득을 볼 수 있겠죠.

3번 address의 경우에는, 128-bit address는 그다지.... 메리트가 안 보이는군요.
128-bit address로 얼마만큼의 address를 allocate할 수 있는지 생각을 해보면....

1테라가 2^40 입니다.
10억대의 컴퓨터가 1테라만큼의 주소를 allocate해도, 2^70 입니다.

그러니까, 10억대의 컴퓨터에 1테라씩 allocate하더라도 2^70이니, 아직도 58비트가 남는군요.

사실 64-bit 갖고 address를 할당하기만 하더라도, 10억(2^30)개의 프로세스를 동시에 띄우면서 각 프로세스당 4기가(2^32)의 unique한 주소를 할당하고, 남은 주소는 램 뿐만 아니라 옆에 있는 1테라 디스크 100만개를 묶은 1엑사바이트(2^60)짜리 디스크 어레이에다가 몽땅 주소를 할당해 줄 수도 있겠죠. 그래도 한참 남는군요..-_-;

지금 최고 high-end 서버의 메모리가 1테라라고 하고, 매년 메모리가 두배씩 증가하더라도 64-bit address space가 부족하려면 24년이 걸립니다.. -_-;

물론, 이바닥이 워낙에 알수없는 동네기 때문에, 제 예측이 완전히 틀릴수도 있겠죠.

Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24

ihavnoid의 이미지

maddie wrote:

그리고 크루소가 128비트인가요? :shock: Libretto를 쓰고 있지만 그말은 생소한데요. 자세한 설명해 주시면 감사하겠습니다. :)

지금 트랜스메타 홈페이지가서 확인해 봤는데, 128비트짜리 VLIW instruction을 쓰고 있다고 합니다.. :)
그렇지만, register은 32-bit가 아닐까 생각합니다. 어차피 32-bit 프로세서를 에뮬레이션하기 위해 나온 놈이니까, 64-bit을 쓸 필요가 없었겠죠.

꽤 오래된 것이지만, 크루소에 관한 글입니다.
http://www.arstechnica.com/cpu/1q00/crusoe/crusoe-1.html

덤으로, 크루소 다음버젼인 이피시온은 256비트짜리 VLIW instruction이라고 합니다.

Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24

ux의 이미지

ihavnoid wrote:
제 생각에는, 64비트는 그다지 단명할 것 같지는 않습니다.

사실 64-bit니 32-bit 하는데, 32-bit 프로세서는 뭐가 32-bit이고, 64-bit 프로세서는 뭐가 64-bit일까요?
instruction 폭이 64-bit이고, 어떤 register은 32-bit이고, 어떤 register은 64-bit인. 그러면서 address는 32-bit 인 프로세서는 32-bit인가요 64-bit인가요?

제가 궁금한 점인데요...^^;;

32bit CPU / 64bit CPU 를 정의할 때 무엇을 보고 하나요

지금 생각에는 CPU 내부의 General Register의 크기 같은데 맞나요?

@UX... Vnn~

vacancy의 이미지

General Register의 크기라고 하는 쪽도 있고,
Memory Address의 폭이라고 하는 쪽도 있습니다.
그래서 General Register의 크기와
Memory Address의 폭이 다른 Architecture의 경우
사실 어중간해서 말하기 나름이죠. -_-

개인적으로는 64bit Architecture가
나름대로는 꽤 유용할거라고 생각하는데요.
2^32는 사실 큰 범위라는 생각이 안들어서 -_-;
일례로 주기억 장치와 관련된 건 아니지만,
지금 개인 유저들이 쓰고 있는 보조기억장치들의 크기만해도
2^32는 가볍게 넘어가고 있죠.
( 뭐 사실 I/O dependent한 보조기억장치 관련 작업에 )
( 연산 몇개 빨라진다고 크게 달라지지야 않겠습니다마는요. -_-a )
( 뭔가 심플해지는 기분이 들잖을까 하는 -_-; )
시간을 표현하는 것에도 32bit가 한계에 다다르고 있고요.
IPv6 패킷 헤더 등도 64bit Architecture에 맞춰
설계된 것 같습니다만. o_oa

128bit는 당분간 쓸일이 별로 없겠다는 생각이 듭니다만,
64bit 정도는 꽤 적당하지 않나 싶네요.

Scarecrow의 이미지

64bit라고 말하는 기준은 General-purpose Register Size를 두고 하는 말일 겁니다.

기타 AMD64에 대한 재미난 글들은...
http://amd.kbench.com/
에 많이 있습니다.

재미삼아 읽어보시면 좋을 듯합니다.

andysheep의 이미지

하드웨어적인 지식은 별로 없지만, CPU의 bit가 늘어나면 처리속도는 당연히 빨라집니다. 특히, 수학적인 데이타 계산, 컴퓨터 그래픽의 이미지 처리는 눈에 띄게 향상이 되죠.

소니의 PlayStation 2는 128bit CPU를 사용합니다. 일반 사용자가 미화 $200 이하의 가격으로 128bit 컴퓨터를 사용한다는 것은 놀라운 일입니다.

소니의 PS2를 사용해 클러스터 형태의 수퍼컴퓨터를 실험용으로 사용하는 대학이 벌써 생겼습니다.

과학기술이나 그래픽, 게임, 멀티미디어 분야는 더 빠른 처리속도의 CPU를 요구합니다. 이유는 기술이 발달할 수록 인간이 필요하는 정보의 양과 정보처리의 질 (오차범위)이 점점 극한으로 치닫고 있습니다.

더 많은 메모리, 더 빠른 처리속도를 가지는 CPU의 요구는 앞으로 계속될겁니다.

아래는 스펙의 일부.
CPU: 128 Bit "Emotion Engine"
System Clock: 300 MHz
System Memory: 32 MB Direct Rambus Memory
Bus Bandwidth: 3.2 GB per second
Co-Processor: FPU (Floating Point Multiply Accumulator x 1, Floating Point Divider x 1)
Vector Units: VU0 and VU1 (Floating Point Multiply Accumulator x 9, Floating Point Divider x 1)
Floating Point Performance: 6.2 GFLOPS
3D CG Geometric Transformation: 66 million Polygons Per Second Compressed Image Decoder: MPEG2

mastercho wrote:
64 비트면 테라 단위의 크기입니다

현재 32비트의 4기가 모자라는 경우는 대형 시스템에서나 그렇지 일반 용도로는 거의 부족함이 없습니다

일반 개인용으로 64비트는 거의 불필할 정도죠
[128비트가 쓰이는곳이 있나요? 세계에 몇 안되는 슈퍼 컴퓨터가 아닐지?]

예전의 도스 시절의 16비트와 32비트 를 비교하기에는 무리며, 그 차이도 많이 다르다고 봅니다

인텔이 32비트 시스템을 계속 추구하는것도 이런 맥락이라 봅니다

Devuan 1.0 (Debian without systemd)
amd64 station: AMD FX(tm)-6100 Six-Core Processor, 8 GB memory, 1 TB HDD
amd64 laptop: HP Touchsmart

글쇠판: 세벌 최종식, 콜맥 (Colemak)

지리즈의 이미지

ihavnoid wrote:

1번 instruction의 경우에는 이미 IA64같은 프로세서는 128비트짜리 instruction이 나오고 있는 걸 봐서는(좀 더 정확히 말하자면 여러 instruction을 묶은 것이 128비트겠지만), 그리고 현재도 VLIW 프로세서들이 쏟아져나오고 있는 걸 봐서는, 128비트, 256비트 등등으로 올라갈 가능성이 많습니다.
<중략>

2번 data의 경우에는, SIMD가 아니라면 사실 32-bit 이상은 힘들 것이라는 생각입니다.
32-bit 정수만 따져도 사실 상당히 큰 범위입니다. 우리가 일상 생활에서 흔히 쓰는 숫자 범위는 거의 다 커버하는 셈이죠.
64-bit 정수를 쓰는 애플리케이션은 어느 정도 있습니다. 그렇지만 128-bit 정수를 이용해야 하는 application은 어디 있을까요? 굳이 128비트 데이터 레지스터를 만들어서 성능 향상을 많이 얻지는 못하겠죠. (그냥 생각해서, 10^37쯤 되는 정수가 필요한 애플리케이션이 얼마나 될까요?)
단, SIMD로 갈 경우에는 상황이 달라지리라 생각합니다. 128비트 register을 4개의 32-bit 값으로 쪼개서 연산을 할 경우, 많은 이득을 볼 수 있겠죠.


메모리에 대한 의견에 대해서는 동감합니다. 개인피씨에선 32bit로도 당분간은 충분하리라고 봅니다.

근데.. 2번 data의 경우... 퀘이크의 엔진 제작자가 현재 32bit depth(color)의 한계에 대해서 불만을 토로하면서.. 64, 128 혹은 256 이상의 컬러의 필요성을 주장한적이 있습니다.(컬러는 Integer를 사용하지요.)

더 16bit가 32bit로의 전환이 빨랐던 이유는
메모리의 어드레싱의 한계가 주도 했지만...
32bit -> 64bit 혹은 그 이상의 전환을 유도하는 동기는
32bit의 변환과 사뭇 다른 느낌을 받습니다.

멀티미디어와 3D엔진을 기본으로 하는 게임과 가상현실...
그렇다면.. 보다 큰 Instruction의 변화가 계속적으로
요구되지 않을까 보는데요...
이런 면은 어떻게 생각하십니까?

여담입니다만, MS의 대 AMD64에 대한 전략은...
Intel의 하이퍼쓰레딩정도의 기술로 보고 있는 것 같은 느낌이 듭니다.
어쩌면... 하이퍼쓰레딩이 준 영향정도의 충격(사실 미비)정도로...
64Bit 시장이 열릴 것 같은 느낌도 드네요...

There is no spoon. Neo from the Matrix 1999.

sDH8988L의 이미지

VLIW가 몇 Bit을 사용하던 간에 그건 실제 우리가 말하는 32bit, 64bit과는 별로 연관이 없다고 생각합니다...

그것들은 한 번에 처리하는 DATA의 Size가 아니기 때문이죠...

위에서 많은 분들이 이야기 하셨다 시피, General Register의 Size로 32bit이냐 64Bit이냐를 생각해야 하는 거 아니겠습니까???

VLIW가 128 Bit 쓰면서 32Bit 4개를 묶어서 사용한다면, 그게 진정한 128Bit이 아닐테니까요...

흠... 그건 그렇고 이제 64Bit로 들어오고 IPv6까지 정식으로 사용하게 된다면, 이제 남는 문제는 뭐가 있을까요???

2000년에 들오면서 년도 표기에 관한 Bug가 한바탕 몰아쳤고...

2038년이면 Time()에 관한 문제가 도래한다고 하니...

IPv6를 사용하면 일단, Network Place에 대한 인식에서는 부족함이 없으리라고 보는데...

Data 공간 영역에서도 64Bit을 사용하는 것은 정말 아주 먼 이야기일테고...

그럼 어떤 문제가 가장 빨리 64bit의 한계로 닥칠까요???

winner의 이미지

우선 Super Computing 은 이미 64bit 아닌가요?
Server 도 64bit 가 많이 진입한 것 같구요.

32bit 는 PAE(Page Addressing Extension)을 사용하지 않는다면 잘해야 4GB 의 memory 를 사용할 수 있는데 이미 Windows XP 는 사용할려면 256MB 는 필요하고, 넉넉하게 사용할려면 512MB 가 필요한 느낌입니다.

LongHorn 이 나온다면 각각 요구량이 2배이상 뛸 거라고 보는데요... -_-

물론 그 이전에 64bit 로의 이행이 속히 요구되는 분야가 있을지도 모르겠군요.

아, 그런데 궁금한 것이 있는데 PAE 훌륭한가요? Intel 에서는 PAE 를 통해 64bit 는 큰 쓸모가 없다고 말하는 것으로 아는데...

대용량 memory 를 가진 server 를 운영해보신 분이 답글 달아주시면 좋겠군요.

bh의 이미지

seearomi wrote:
64비트가 가장 필요한 분야는 바로 time() 콜이 아닐지요. :)

2038년인가에 고갈된다고 합니다.
Y2K를 능가하는 대혼란이 발생될겁니다.


계산해보니깐,,
2038년엔 제나이가 61살이네요.. -_-;
손자들이 IPv6로 인또넷을 하는시대.. -_-;;

--
이 아이디는 이제 쓰이지 않습니다.

fibonacci의 이미지

일반 사용자들에게는 큰 문제가 되지 않겠지만
그래픽이나 음악 개발자들에게는 64BIT 컴퓨팅이 절실합니다.
압축하기 전의 원래의 DATA들의 크기는 이미 기가 단위거든요.
수많은 소프트웨어들이 2G단위로 파일을 잘라서 작업을 하고 있습니다.
아마 이런 작업을 하는 하이엔드 유저들에게 각광을 받지 않을까 합니다.

No Pain, No Gain.

cjh의 이미지

seearomi wrote:
64비트가 가장 필요한 분야는 바로 time() 콜이 아닐지요. :)

time()의 문제는 CPU문제가 아니라 time_t의 문제 아닌가요?

time_t가 대부분 OS에서 32비트 정수로 정의되어 있어서 생기는 문제입니다. 이걸 64비트 정수로 바꾸면 그만인 것이죠. 32비트 CPU에서 64비트 정수를 못쓰는 것도 아니고...

다만 하위 호환 때문에 - 이렇게 되면 바이너리 호환이 깨지고 그외 생각하지 못한 많은 문제가 생길 수 있습니다. 기존 어플리케이션 포함... - 쉽게 바꾸기 어려운 것이 아닌가 생각하고 있습니다.

현재 추세라면 2038년 되기 전에 현재 쓰는 PC는 다 못쓰게 될 겁니다. :) 새 OS가 나오게 되면 전환이 되겠죠.

--
익스펙토 페트로눔

지리즈의 이미지

치명적인 32bit의 한계는 없을지도 모릅니다.(수년이래로는)
16bit의 시장에서의 빠른 퇴진을 요구했던 메모리 문제도 32bit는 아직은 여유가 있고...
여전히 펜티엄500Mhz대 컴퓨터를 불편없이 사용할 수 있을 정도로... CPU파워는 여전히 넘처나고 있습니다.
새시대를 열어줄것 같이 요란법석하게 마케팅을 펼쳤던, 하이퍼쓰레딩도 그렇고 그런 기술인 것처럼...
개인용 피시에 있어서는 64bit CPU도 당분간은 "필수"가 아닌 "선택"일 가능성이 매우 높습니다.

물론 멀티미디어에서 상당한 향상을 가져올 것은 분명하며... 일부 개발자들은 64bit도 부족하다고 주장하고 있습니다. 하지만.. 여전히 옵션임에는 분명한것 같습니다.
어쩌면... 64bit CPU 시대에는 64bit 혹은 그이상의 CPU를 취향과 용도에 맞게 선택하는 시대가 도래할 것 같습니다. 마치..지금의 하이퍼쓰레딩 기술과, x-86의 확장된 명령어 셋처럼말이죠.

아 ~ MS윈도우용 어플리케이션을 개발하고 있는 개발자 입장에서는 암울하네요... 특히 장비를 제어에 관련된 소프트웨어를 개발하는 입장에서는요...

MS도 IA32용 OS와 AMD의 IA64용, INTEL의 IA64용의 각기 다른 바이너리를 준비해야 하니깐요...
각각 다른 바이너리를 위한 크로스 컴파일러를 Visual Studio에서 제공하겠지만....
하드웨어를 로레벨로 제어하고... 미션크리티컬한 포퍼먼스를 요구되는 장비쪽에서는 닷넷이나 자바는 한계가 있을 거고...

아 64bit CPU의 등장이 MS개발자들의 좋은 시절의 종말을 고하려고 하는 것 하나는 분명할 것 같군요. 흠....

There is no spoon. Neo from the Matrix 1999.

익명 사용자의 이미지

cjh wrote:
seearomi wrote:
64비트가 가장 필요한 분야는 바로 time() 콜이 아닐지요. :)

time()의 문제는 CPU문제가 아니라 time_t의 문제 아닌가요?

time_t가 대부분 OS에서 32비트 정수로 정의되어 있어서 생기는 문제입니다. 이걸 64비트 정수로 바꾸면 그만인 것이죠. 32비트 CPU에서 64비트 정수를 못쓰는 것도 아니고...

다만 하위 호환 때문에 - 이렇게 되면 바이너리 호환이 깨지고 그외 생각하지 못한 많은 문제가 생길 수 있습니다. 기존 어플리케이션 포함... - 쉽게 바꾸기 어려운 것이 아닌가 생각하고 있습니다.

현재 추세라면 2038년 되기 전에 현재 쓰는 PC는 다 못쓰게 될 겁니다. :) 새 OS가 나오게 되면 전환이 되겠죠.

왜냐면 time_t가 32비트 long 이기 때문입니다.
32비트 레지스터를 가진 시스템에서 32비트 long 타입을 +1 하는데는 큰 오버헤드가 필요하지 않지만 64비트 long long 타입을 +1 하는건 추가적인 오버헤드가 발생되죠.
64비트 레지스터를 가진 시스템에서 64비트 long long 타입을 쓰면 32비트 시스템에서 64비트 long long을 쓰는 것에 비해 훨씬 수월하지 않을까요?

cjh의 이미지

seearomi wrote:
cjh wrote:
seearomi wrote:
64비트가 가장 필요한 분야는 바로 time() 콜이 아닐지요. :)

time()의 문제는 CPU문제가 아니라 time_t의 문제 아닌가요?

time_t가 대부분 OS에서 32비트 정수로 정의되어 있어서 생기는 문제입니다. 이걸 64비트 정수로 바꾸면 그만인 것이죠. 32비트 CPU에서 64비트 정수를 못쓰는 것도 아니고...

다만 하위 호환 때문에 - 이렇게 되면 바이너리 호환이 깨지고 그외 생각하지 못한 많은 문제가 생길 수 있습니다. 기존 어플리케이션 포함... - 쉽게 바꾸기 어려운 것이 아닌가 생각하고 있습니다.

현재 추세라면 2038년 되기 전에 현재 쓰는 PC는 다 못쓰게 될 겁니다. :) 새 OS가 나오게 되면 전환이 되겠죠.

왜냐면 time_t가 32비트 long 이기 때문입니다.
32비트 레지스터를 가진 시스템에서 32비트 long 타입을 +1 하는데는 큰 오버헤드가 필요하지 않지만 64비트 long long 타입을 +1 하는건 추가적인 오버헤드가 발생되죠.
64비트 레지스터를 가진 시스템에서 64비트 long long 타입을 쓰면 32비트 시스템에서 64비트 long long을 쓰는 것에 비해 훨씬 수월하지 않을까요?

CPU오버헤드때문에 전환이 지연된다는것은, 32비트 CPU에서 long long이 불가능한게 아니라면 선뜻 이해 안되는 부분입니다. 지금도 많은 프로그램에서 64bit int를 사용해서 프로그램을 하고 있는데, 그래서 64비트 프로세서가 필요하다는 것은 좀...

이런 기능은 컴파일러에서 지원만 되면 프로그래머는 그걸 생각하지 않아도 되므로, time_t의 전환같은 것은 지금도 얼마든지 가능합니다(e.g. 16비트 프로세서는 64비트 int를 아예 사용할 수 없죠. 컴파일러에서 해 주는 방법도 있지만...).

--
익스펙토 페트로눔

송지석의 이미지

지리즈 wrote:

IPv6를 위해서는 128bit CPU를 활용하는게.. 낳다는 말이 되긴 하지만...

지리즈님, 주제랑 별 상관없는 글 올려 죄송합니다...
낳다 /나타/ 는 아이를 낳을 때 쓰는 말이고
원하신 말은
더 좋다, 또는 병이 낫다에 쓰이는 '낫다' /나따/가 맞습니다.
다시한번 정말 죄송합니다. 지리즈님이 틀린 것을 지적하는 것이라기 보다 많은 분들이 이렇게 쓰셔서 언어 자체가 변할까봐 그럽니다. 쓰레드 잘 읽고 있습니다. 용서를..
지리즈의 이미지

수정하였습니다.
다음부터 주의하겠습니다.
감사합니다. :oops:

늘 생각하지만.. 한국말.. 정말 어렵습니다. :wink:

송지석 wrote:
지리즈 wrote:

IPv6를 위해서는 128bit CPU를 활용하는게.. 낳다는 말이 되긴 하지만...

지리즈님, 주제랑 별 상관없는 글 올려 죄송합니다...
낳다 /나타/ 는 아이를 낳을 때 쓰는 말이고
원하신 말은
더 좋다, 또는 병이 낫다에 쓰이는 '낫다' /나따/가 맞습니다.
다시한번 정말 죄송합니다. 지리즈님이 틀린 것을 지적하는 것이라기 보다 많은 분들이 이렇게 쓰셔서 언어 자체가 변할까봐 그럽니다. 쓰레드 잘 읽고 있습니다. 용서를..

There is no spoon. Neo from the Matrix 1999.

방준영의 이미지

(으... 맞춤법 지적은 이제 더이상 게시판에서 안하기로 저번에 암묵적 합의가 이루어지지 않았나요)

프로세서 종류를 구분하기 위해 OS나 컴파일러쪽에서는 LP32란 말과 LP64란 말을 씁니다. 롱변수와 포인터가 32비트면 LP32 머신이고, 64비트면 LP64 머신이지요. 여기서 LP를 떼고 우리가 흔히 말하는 것이 "32비트", "64비트"가 되겠습니다. 트랜스메타 프로세서들은 레지스터 크기가 128/256비트가 아니고, RISC 비스무레한 32비트 고정 길이 명령("원자")을 4/8개 이어서 하나의 아주 긴 명령("분자")을 만든 다음 병렬적으로 실행하는 방식으로 알고 있습니다(그 이상의 내용은 회사 기밀이라... :-). 그러니 LP128은 아니고, 그냥 LP32 머신이죠.

방준영의 이미지

cjh wrote:
CPU오버헤드때문에 전환이 지연된다는것은, 32비트 CPU에서 long long이 불가능한게 아니라면 선뜻 이해 안되는 부분입니다. 지금도 많은 프로그램에서 64bit int를 사용해서 프로그램을 하고 있는데, 그래서 64비트 프로세서가 필요하다는 것은 좀...

32비트 기계에서 64비트 변수를 쓰는 것은 생각보다 오버헤드가 상당합니다. 특히나 x86처럼 범용 레지스터 개수에 굶주린(?) 기종은 정도가 더 심하지요. MMX나 SMD 명령처럼 64/128비트 전용 레지스터를 쓰면 되지 않냐고 할 수도 있지만, 모든 프로그램이 다 MMX/SSE 레지스터를 쓰게 되면 컨텍스트 전환에 따르는 부하가 어마어마하게 커집니다. 그런데 문제는 전세계 데스크탑의 90% 이상이 x86이라는 것...
sDH8988L의 이미지

ㅎㅎㅎ

이제 time()이나 time_t 이야기는 하지 않아도 되지 않을까요???

지금은 절대다수의 '데스크탑'이 32bit이지만, time_t가 고갈되는 2038년까지 남아 있을 '데스크탑'이 있을 지는 의문입니다...

만일, 남아 있더라도 '데스크탑'이기 때문에 치명적인 뭔가가 발생하는 것은 아닙니다...

문제는 Server 쪽이죠...

이제 64Bit Machine이 나온 판이고 하니 기업 시장에서는 아마 10년 이내에는 거의 다 64Bit으로 교체해 나가겠죠...

남아 있을 곳이 있다면.... 글쎄요... 학교??? 사실, 지금 제가 다니고 있는 학교도 1977년에 처음 MainFrame 들여왔지만, 10년도 안되어서 없어졌습니다...
지금 운영하고 있는 Server들도 다 도입한 지 5년 이내 제품들이죠...

그렇다면, 2038년까지 대체 뭐가 남아 있을 지 의문입니다...

64Bit으로 time을 계산한다면, 사실상의 무한에 가까운 시간이 될테니까 이제 time이나 Address 공간에 대한 부족은 느끼지 못하게 될 겁니다...

2038년이라는 시각은 우리가 아무런 걱정하지 않아도 될 마지노선이라고 생각합니다...

다만, 64Bit에서 걱정 아닌 걱정이 되는 것은 바로 낭비입니다...

절대 다수의 Computation이 64Bit을 필요치 않겠죠...

Address 계산, time 계산 등등의 분야를 제외하고는 64Bit을 64Bit 답게 사용하는 Computation이 무엇인가 싶습니다...

물론, Address 계산은 CPU가 해야할 연산 중에 아주 많은 부분을 차지하고 있기는 합니다만, 제가 말씀 드리는 부분은 Address 계산 이외의 부분에서는 64Bit은 너무 크다는 거죠...

그렇다면, Address 계산과 같이 꼭! 64Bit이 필요한 부분에서만 64Bit을 사용하고 나머지 부분에 대해서는 VLIW와 같은 형식으로 32Bit 묶어서 사용해도 되지 않을까요???

지리즈의 이미지

fpu는 상관없나요?
64bit면 double형 연산이 커버가 될텐데...
double 연산이 되면... 3D쪽의 콸리티가 많이 향상되지 않을까요?
정수쪽으로는 컬러 Depth하고 밀접하게 관련되구요..

이래저래 멀티미디어 쪽은 이득이 있을 것도 같은데...

mmx나 3dnow, sse같은데서도 그건 지금도 지원되고 있으니 문제가 없을지도.. 음...

필요없나 당분간은 64bit...

There is no spoon. Neo from the Matrix 1999.

ydongyol의 이미지

sDH8988L wrote:

다만, 64Bit에서 걱정 아닌 걱정이 되는 것은 바로 낭비입니다...

절대 다수의 Computation이 64Bit을 필요치 않겠죠...

Address 계산, time 계산 등등의 분야를 제외하고는 64Bit을 64Bit 답게 사용하는 Computation이 무엇인가 싶습니다...

갑자기 펜티엄1이 처음 나왔을때 그 cpu를 소개하던 문구가 생각나는 군요

Quote:
전문수학자에게나 필요한 고성능 cpu

--
Linux강국 KOREA
http://ydongyol.tistory.com/

sDH8988L의 이미지

FPU 쪽에서는 이미 64Bit 사용하는 것으로 알고 있습니다...

그건 당연하겠죠... 32Bit 끼리의 곱셈과 나눗셈이 있으니...

그러니 특별히 64Bit 체제 아니면 안된다는 좀 그런 거 같습니다...

64Bit int 연산이 되면, FPU는 128Bit이 필요하겠죠...

그리고 32Bit으로 Color Depth를 표현하는데 문제가 있다는 것은 얼른

이해가 되질 않습니다...

일단, 제가 Color를 정수와 어떻게 Mapping하는 지는 잘 몰라도 32Bit이라면,

거의 43억가지의 Color가 가능하다고 알고 있습니다...

RGB 3개로 나눈다고 하더라도 (2Bit 손해보겠네요...)10억 7천만 가지 정도의 색은 표현할 수 있는 거 아닌가요???

그렇다면, 그 정도의 색이 어쩨서 문제가 되는지 궁금합니다...

인간의 눈이 구별할 수 있는 색은 어차피 2천만 가지도 안되는 것으로 알고 있는데요...(흠... 예전에 들은 이야기라서 근거가... -____-)

그리고 VGA에 대한 지식이 별로 없어서 그런데요...

실질적으로 그런 Color와 같은 연산은 보통 어디서 하나요???

VGA Card의 Core Chip에서 하나요 아니면, CPU에서 하나요...

김희상의 이미지

음....딴소리하는건지는 모르겠지만,
몇몇분들이 조금 혼동하고 계신거 같아서 첨언합니다.

위에서 어느분이 언급하신것 같지만.......

64비트라고 해서 모든(?) 연산이 64비트 이상의 연산은 아닙니다.
LP64 -> long과 포인터가 64비트이죠.

int형은 여전히 4바이트입니다.
long 씨리즈(?) 변수들이 64비트이고요...

32비트에서는 int, long int는 4바이트이고, long long만이 64비트죠?

그러니깐...64비트 환경에서도 대부분(?)의 연산은 여전히 32비트입니다.
(int가 가장 많이 쓰이는 타입...맞지요????)
뭐..좀 특이한 프로그램같은 경우는 당연히 예외겠지요...

또한, 당연히 64비트와 32비트 레지스터들도 구분이 되고요....
(물론(?), 128비트 레지스터들도 가지고 있습니다.)

포인터야...당연히 어드레싱을 할려면 그 크기만큼의 공간이 필요할테고요...
게다가, 경우에 따라서는 32비트 모드로도 동작이 가능하게 할 수도 있습니다(즉, 4바이트 포인터지요...이게 모든 64비트 CPU에서 가능한지는 잘 모르겠습니다...아닌것 같기도 하고요...)
64비트 어플과 32비트 어플이 동시에 돌아가는거죠...성격이 완전히 다르지만 겉으로 보기엔 32비트 윈도우에서 16비트 도스용 프로그램이 돌아가는 것과 유사해 보이기도 합니다.

p.s. 최소한 제가 본 64비트 프로세스들은 그렇습니다만....잘못된게 있으면 지적해주세요~

vacancy의 이미지

64bit 환경에서는 원래 int가 64bit여야 맞습니다.
64bit 환경에서 int가 32bit의 결과를 내는 건,
32bit 환경에서 쓰시던 컴파일러를 쓰셔서 그런것 같네요.

그리고 general purpose register는 일반적으로
floating-point register를 포함하지 않고 얘기하는 것일 겁니다.
이미 fp register들이 gp register보다 큰 processor는 많이 있죠.

DarKMinD의 이미지

원래 int가 64bit 라는 표현이 맞을지 모르겠습니다.
int의 정의는 short와 같거나 커야 한다, 또한 long보다 작거나 같아야 한다. 라고 정의 되어 있다고 보았습니다.
long은 4바이트이죠. 결국 int는 정의 상으로는 64비트 값이 될 수 없다 라고 생각합니다.
(물론 현재로서 자바와 닷넷에선 저 규칙이 깨어졌긴 합니다만... 일단 C언어 관점입니다.)

또한 직접 64비트 리눅스 상의 gcc에서 컴파일 해본 결과 int는 sizeof를 돌려보니 4가 출력되더군요.

김희상의 이미지

음...조금 더 상세하게 쓸걸 그랬나보군요.

64비트 환경이라고 해서 int가 무조건 64비트가 '정상' 또는 32비트가 '정상'이라는 의미는 아닙니다.

LP64, ILP64, LLP64 프로그래밍 모델이 있는데요....

LP64에서는 int, long, pointer 크기가 32, 64, 64이고,
ILP64에서는 64, 64, 64이며,
LLP64에서는 32, 32, 64의 크기를 가집니다.....(long long은 64)

각각의 프로그래밍 모델이 장단점을 가지고 있지만, 상대적으로 기존의 32비트환경에서 검증받은 각종 구현과 정의들을 수용하는데에 충격이 적은 모델이 LP64 모델입니다.
그래서 아직은 상대적으로 64비트 환경이 초창기라고 할 수 있고, 기존에 검증받은 많은 구현들을 쉽게 수용하기 위해 LP64모델을 대부분 적용하고 있는 걸로 알고 있습니다.
뭐, 수년(수십년?)이 지난 다음에야..'이것이 진정한 64비트 환경이다!'라고 하면서 ILP64또는 LLP64모델이 일반화될지는 두고볼 일이겠지만 말입니다...

수정 1:
음....약간...관점이 다른 점이 있군요...저는 프로그래밍이라는 관점에서 일반적인 모델에 따른 크기를 말한거였고.....
'xx 비트 프로세서다!'라고 하는건 역시, int 형 또는 워드 크기(뭐, GR쯤 되겠죠..특이한 경우가 아니면)를 기준으로 하는게 맞으니깐, '64비트다'라고 하면 'int=64'가 맞겠죠...
음...하여간, LP64가 아닌건 아직 못봤는데....호환성 모드때문에 ILP64와 LLP64모델을 적용한 케이스는 당분간 보기 힘들것 같다는 조심스런 예상을 해봅니다.

방준영의 이미지

정확하게는 I32LP64라고 써야 되는데 앞부분을 빠뜨렸네요. 윽...

김충길의 이미지

방준영 wrote:
cjh wrote:
CPU오버헤드때문에 전환이 지연된다는것은, 32비트 CPU에서 long long이 불가능한게 아니라면 선뜻 이해 안되는 부분입니다. 지금도 많은 프로그램에서 64bit int를 사용해서 프로그램을 하고 있는데, 그래서 64비트 프로세서가 필요하다는 것은 좀...

32비트 기계에서 64비트 변수를 쓰는 것은 생각보다 오버헤드가 상당합니다. 특히나 x86처럼 범용 레지스터 개수에 굶주린(?) 기종은 정도가 더 심하지요. MMX나 SMD 명령처럼 64/128비트 전용 레지스터를 쓰면 되지 않냐고 할 수도 있지만, 모든 프로그램이 다 MMX/SSE 레지스터를 쓰게 되면 컨텍스트 전환에 따르는 부하가 어마어마하게 커집니다. 그런데 문제는 전세계 데스크탑의 90% 이상이 x86이라는 것...

예전에 ECC(Elliptic Curve Cryptography) 구현 코드를 Intel 어셈으로 변환한적이 있는데 128비트 레지스터를 사용하기 위해 MMX 레지스터를 사용했었죠.

생각보다 향상이 없더군요. 그게 컨텍스트 전환의 문제였나 보군요..

screen + vim + ctags 좋아요~

김충길의 이미지

아이테니엄은 3개의 마이크로 코드를 가지고 있다고 들은거 같습니다.

그래서 윈도우 OS, HP-UX, Linux를 다 실행할 수 있다고 하더군요.

맞나요?

멀티 OS를 지원하고 RISC 계열중에서 GH 클럭을 꽤 높이고 가격이

예전 CPU에 비해 1/2 가격이라고 하더군요. 최근 Oracle 성능 시험에서

꽤 높은 점수를 받았다는 소식도 있더군요.

screen + vim + ctags 좋아요~

지리즈의 이미지

24bpp를 true color라고 보통 칭하죠.(3 bytes)
천 6백만 컬러정도를 표현할 수 있습니다.
이 정도면 인간이 식별할 수 있는 컬러의 정밀도를 충분히 넘고 있지요...

32bpp 컬러의 구성은 R, G, B
그리고 Alpha(투명정도)를 위해서 사용되고 있습니다.(4 bytes)
(지금도 2D동영상쪽에는 많이 사용되고 있습니다. )

근데 128bpp 컬러, 혹은 그 이상의 컬러가
논의되고 있는 이유는..
바로 shades(그림자) 때문이라고 합니다.
3D쪽에서는 상당한 이득이 있다고 하네요...
이론상으론 2배이상의 성능향상을 얻을 수 있다고 합니다.
요즘 그래픽 카드에서는 내부적으로 지원하고 있는 걸로 알고 있습니다.
http://www.xbitlabs.com/news/video/display/20030415075522.html

There is no spoon. Neo from the Matrix 1999.

죠커의 이미지

andysheep wrote:
소니의 PlayStation 2는 128bit CPU를 사용합니다. 일반 사용자가 미화 $200 이하의 가격으로 128bit 컴퓨터를 사용한다는 것은 놀라운 일입니다.

128bit cpu는 아닙니다.

이모션 엔진은 r3000의 개량형의 형태입니다. ps2가 싼것은 좋지만 이모션 엔진이 놀랄만큼 좋은 cpu는 절대 아닙니다.

ihavnoid의 이미지

CN wrote:
andysheep wrote:
소니의 PlayStation 2는 128bit CPU를 사용합니다. 일반 사용자가 미화 $200 이하의 가격으로 128bit 컴퓨터를 사용한다는 것은 놀라운 일입니다.

128bit cpu는 아닙니다.

이모션 엔진은 r3000의 개량형의 형태입니다. ps2가 싼것은 좋지만 이모션 엔진이 놀랄만큼 좋은 cpu는 절대 아닙니다.

128비트 cpu가 아니라, 32비트 인스트럭션을 4개씩 실행하는 VLIW 프로세서라고 설명을 하는 게 맞겠죠.. -_-;

Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24

체스맨의 이미지

지리즈 wrote:
24bpp를 true color라고 보통 칭하죠.(3 bytes)
천 6백만 컬러정도를 표현할 수 있습니다.
이 정도면 인간이 식별할 수 있는 컬러의 정밀도를 충분히 넘고 있지요...

32bpp 컬러의 구성은 R, G, B
그리고 Alpha(투명정도)를 위해서 사용되고 있습니다.(4 bytes)
(지금도 2D동영상쪽에는 많이 사용되고 있습니다. )

근데 128bpp 컬러, 혹은 그 이상의 컬러가
논의되고 있는 이유는..
바로 shades(그림자) 때문이라고 합니다.
3D쪽에서는 상당한 이득이 있다고 하네요...
이론상으론 2배이상의 성능향상을 얻을 수 있다고 합니다.
요즘 그래픽 카드에서는 내부적으로 지원하고 있는 걸로 알고 있습니다.
http://www.xbitlabs.com/news/video/display/20030415075522.html

첨언하면, 색상 요소당 8비트가 할당되는 24비트 색상은 색상 가지수로는
천6백만이지만, 회색 단계로는 2^8 = 256 단계 밖에 되지 못합니다.
이 정도의 단계 변화로는 3차원 렌더링에서 부드러운 명암 단계 변화가
잘 나타나지 않는 경우가 많습니다.

픽셀당 128 비트로 색상요소당 32비트가 사용되는 경우라면, 2^32
단계의 회색단계가 표현되므로, 매우 부드러운 음영 표현이 가능하겠죠.
하지만, 1024*768 모드에 대해 1024*768*16 = 약 12M 의 화면
메모리와, 픽셀 전송 속도 ( blit ) 등을 고려하면 하드웨어가 앞으로
꽤 많은 시간동안 좋아져야 될 것으로 보입니다.
(게임 같은 분야에 응용하고자 한다면.)

말씀하신 성능이 속도 성능보다는 색상 성능을 의미하신 것 같은데요...

참고로 픽셀당 16비트가 할당되는 555 또는 565 픽셀 모드는
음영단계가 32 (또는 64)까지 표현되는데, 이때 나타나는 음영상의
왜곡은 트루컬러 디더링으로 극복될 수 있습니다. 실제로 디더링이
적용되면 32비트 색상과의 차이를 쉽게 느끼지 못합니다. 물론
속도는 더 느려지겠죠. 현재로서도 32비트 픽셀에 대한 트루컬러
디더링에 의해 보다 높은 음영 해상도를 얻을 수도 있을 것입니다.

Orion Project : http://orionids.org

ironiris의 이미지

ydongyol wrote:
sDH8988L wrote:

다만, 64Bit에서 걱정 아닌 걱정이 되는 것은 바로 낭비입니다...

절대 다수의 Computation이 64Bit을 필요치 않겠죠...

Address 계산, time 계산 등등의 분야를 제외하고는 64Bit을 64Bit 답게 사용하는 Computation이 무엇인가 싶습니다...

갑자기 펜티엄1이 처음 나왔을때 그 cpu를 소개하던 문구가 생각나는 군요

Quote:
전문수학자에게나 필요한 고성능 cpu

80286나왔을때도 잡지의 논평에서 그랬다죠?
개인이 필요없는 CPU 업무적으로나 필요한 CPU

익명사용자의 이미지

IT 산업 분야가 독특한게,
수요가 시장을 만드는 일반적인 산업분야와 달리
기술이 시장을 만들고 수요를 만들어 내고 있다는 거죠.
또한 이러한 흐름이 한창 진행중이고, 앞으로 수십년간은 더욱 그러할 것 이라는 거죠.
어디까지 갈지 아무도 모르죠. ^^

64bit 가 일반적인 환경에서 필요하느냐 아니냐,
64Bit을 64Bit 답게 사용하는 Computation이 무엇인가 는 별로 중요하지 않습니다.
필요하게 만들거니까요.
특히 멀티미디어 쪽에서는 좀더 다양한 효과, 기능이 추가 할수 있는 환경에 아주 목매달고 있는 상황입니다.
개발자, 엔지니어로서 좀더 열려있는 상상력이 필요하지 않을까 싶네요.

sorigae의 이미지

fibonacci의 이미지

3D 그래픽 프로세서들은 이미 128BIT색상을 이용하고 있는 것으로 알고 있습니다. 인간의 눈에 직접 관련된 프레임 버퍼의 색상은 32BIT면 충분합니다만, 내부적으로 오브젝트의 색깔이 렌더링되는 과정에서는 32BIT로는 모자랍니다. 모델링 되는 공간이 더욱 정밀하게 모델링되어야 렌더링된 결과도 더욱 자연스럽다는 원리입니다. 마치 음악을 듣기에는 보통 MP3정도 수준이면 부담없이 들을 수 있지만, 음원을 만들고 변형하는 사람들에게는 CD의 WAV수준의 음원도 모자라는 것과 같습니다.

No Pain, No Gain.

지리즈의 이미지

묘하네요.

당시에는 64bit CPU 사용은 왠지 요원하게 느껴졌었는데,
지금 제가 사용하고 있을 줄이야.

그런데, 데스크탑환경에서는 다소 시기 상조인 것은 분명한 것 같습니다.
(삽질이 너무 많아요 :-( )

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

지나가다가의 이미지

님의 글은 대체로 맞기는 하지만..
64비트에서 128비트로 넘어 가기엔 시간이 좀 걸리 지 않나 싶습니다.
32비트 CPU가 포화 상태이긴 하지만 64비트가 32비트의 2배가 아니라 2^32배 입니다. ^^;
따라서 메모리 공간상의 문제는 당분간은 거의 해결되지 않나 싶읍니다.
(아마도 나노튜브 컴터가 나오면 이야기가 달라 지겠지만요..)
지금의 메모리 구조로 보면 32/64비트가 자료를 표현하는 주류가 될것 입니다.
그러나 메모리 버스는 아마도 128비트 256비트 8K비트 처럼 확장된 버전이 나올 것 같읍니다.
더불어 64B비트 CPU를 (NxM) 처럼 병렬로 사용하는 방식도 많아 지겠죠..
암튼 내 생각에는 한 동안 64비트 CPU한계를 넘기 힘들 듯 합니다.
단 산술 연산에서는 지금도 80비트 이상이 쓰이고 있으니 아마 128비트 floating point 연산이
많이 사용되리라 생각합니다.
미래는 아직 알 수 없지만은요 ^^;

freemckang의 이미지

누군가 프로그램을 구동시키는데 640KB 이상은 필요없다 라고 말했던게 생각나네요... -_-;;

句日新, 日新 日新 又日新.

句日新, 日新 日新 又日新.

sphawk의 이미지

윈도우즈 서버 프로그래밍에 관한 이야기입니다만,
이쪽에서는 64bit 가 상당히 큰 의미를 갖습니다.

64bit OS에서는 non-paged pool의 크기 제한이 없습니다.
이거 하나만으로도 넘어갈 가치가 충분하죠.

violino의 이미지

최근에 나온 Core 2 Duo 도 64비트로 알고 있는데요.
XP 64bit eval 하고, Solaris x86 64bit 버전 깔아서 돌려보는데 잘 돌아가더라구요.
물론 32bit 기계엔 아예 설치도 못하던 OS 들이죠.
이게 64bit인지 아닌지 알기 위해 인텔 사이트를 다 뒤져봤죠.
Core 2 Duo 초반 모델은 32비트였고, 요즘 나오는 모델들이 64비트더군요.

http://www.intel.com/products/processor/core2duo/specifications.htm
http://www.intel.com/technology/architecture-silicon/intel64/index.htm

익명 사용자의 이미지

전 지금 2007년 11월 현재에도 64bit시대가 도래했는지, 잘 못느끼겠습니다. (아직도 Pentium III 1G를 쓰고 있어서 그런가 ???)

하여튼, 아직도 완전한 64bit CPU시대가 도래했다기 보다는, 32bit와 64bit의 중간단계쯤의 과도기가 아닐까 생각합니다...

지금 대중적인 CPU중에서 "완전한 64bit CPU"라면 어떤 것이 있을까요 ?

2007년 11월 10일.

지리즈의 이미지

생각보다 오래갈 것 같습니다.

32bit와 64bit가 공전하는 시대가 5년쯤은 더 갈 것 같아요.
(느낌같아서는 10년쯤도 갈것도 같습니다. :P)

이 글을 올렸을 즈음 AMD가 처음으로 데스크탑용으로 64bit CPU를 내놓았었고..
그 후로 거의 5년정도 시간이 흘렀는데도 불구하고 일부 리눅서들을 제외하고는
64bit 운영체제를 사용하는 사람을 거의 못 보는 것 같습니다.

저 같은 경우는 64bit 리눅스위주로만 사용한게 2년쯤됬으니까..
적어도 저에게 있어서는 완전히 도래했다고 느껴지네요 ^^

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

익명 사용자의 이미지

저는 뭐 현재 Pentium III 800Mhz를 사용하고 있는데, 현재 전혀 사용하는데 불편함을 못 느끼겠습니다. 초고속인터넷, E-mail, OpenOffice로 문서작업, Spreadsheet계산작업 등등...

지리즈의 이미지

게다가 kde이구요.

전체 설치하는데, 풀로 36시간 정도 걸리더군요. ^^

저는 cpu 덕을 gentoo로 인해 좀 보고 있습니다.

그나마, gentoo라도 안쓰면 fm할때 (그것도 요즘은 못하네 ㅠ.ㅠ.)를 제외하고는
그다지 쓸모가 없네요.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

죠커의 이미지

아마 클록이나 코어수가 많은 128비트 CPU가 싼 가격에 나올때까지 64비트 시장이 되겠죠? :-)

- CN의 낙서장 / HanIRC:#CN

brianjungu의 이미지

XP쓸때는 2GB로도 충분하다고 생각했는데, 비스타 깔려있는 씽크패드 X61s사면서 완전히 마음이 바뀌었습니다. 아범의 ThinkVantage들 때문에 그런것도 있지만, 서비스들이 워낙 많아서 결코 메모리가 충분치 않습니다. XP때는 OS가 차지하는 메모리가 5~700메가 사이였지만, 비스타 설치후에는 1GB를 육박하게 됐습니다.

결국 웬만한 서비스 다 내리고, ThinkVatage 내려버려서, 800메가 안쪽으로 줄이긴 했지만, 여전히 2GB로는 안되겠다는 생각이 드는게 사실입니다.

근데 4GB로 늘려도, 32비트에서는 3.25GB만 인식을 하니, 64비트로
올리고 싶은 마음이 강하게 듭니다.

그전에도 그랬지만, 역시 운영체제 업그레이드와 게임이 하드웨어 업그레이드를 요구하는 것 같습니다.

warpdory의 이미지

PC 시장에서, CPU 만 놓고 본다면 ...
이제는 거의 64 비트가 차지하고 있다고 볼 수 있습니다.

운영체제는 아직 32 비트일지라도 말이죠.

마치 386 이 나온지 한참 지났었어도, 운영체제는 도스를 계속 썼던 것과 같은 거라고 봅니다.

---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.
http://akpil.egloos.com


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

magingax의 이미지

Intel CPU는 현제까지 32bit 모드가 기본이고 64bit 처리는 예외적인 처리를 해서 32bit 모드보다 현저히 성능이 떨어진다고 들었습니다.
64비트의 의의는 메모리를 넓게 쓸수 있는정도라고...
자세히 아시는분 설명좀..

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

라스코니의 이미지

한번에 읽어드릴수 있는 데이터의 사이즈가 증가한다는 것입니다.
최재 메모리 사이즈가 늘어나는 것이 큰 장점이 아니죠. 64 bit 만 해도 지원하는 메모리 사이즈가 어마어마 하니까요.

한번에 128 bit, 256 bit 를 읽어드릴 수 있다면 그것 자체로도 32 bit 프로세서에 비해서 대폭적인 메모리 밴드폭 관련 성능향상이 있는 것입니다.
똑같은 동작 메모리에서 4배의 성능을 내니까요.

앞으로 컴퓨터는 점점 가상화(가상현실) 기술이 주가 될 터인데, 128, 256 bit 프로세서 기술이 많이 활용될 것 같습니다. 비디어, 게임은 말할 것도 없죠.

drinkme의 이미지

최대 메모리 사이즈가 늘어나는 것은
중요한 장점중의 하나라고 생각합니다.
32bit 어드레싱으로 가능한 size가 4GB 맞죠?

그리고,
CPU가 32bit라고 해서, 메모리 bus가 32bit라던가,
64bit라고 해서, 메모리 bus가 64bit라던가...
일반적으로 이렇게 되는 것 같지만, 항상 그런것은 아닙니다.

CPU의 레지스터가 64bit로 늘어나게 되면,
연산단위가 커지게 되기 때문에, large size의 데이타 연산시에 32bit보다 장점이 있겠지만....
메모리 대역폭은 조금 다른 얘기이지 않나 싶습니다.

pinebud의 이미지

별차이가 없으리라 봅니다.
64비트 메모리 주소 스페이스를 사용할 날이 과연 올까요?
사실 이미 예전부터 개인용 컴퓨터의 성능은 CPU보다는 그래픽 카드나 사운드같은 주변기기 성능 문제로 옮겨간 것 같습니다.
블루레이보고 3D게임하는데 CPU성능은 별 영향이 없는 것 같습니다. 서버쪽에서는 어떤 성능이 중요할까요?

A rose is a rose is a rose..

hiseob의 이미지

64비트의 메모리 주소는 지금도 필요합니다..
현재 메모리 가격이 엄청 쌉니다 (옛날에 비해서..)
컴퓨터를 새로 사면 기본 4기가는 끼우고 시작하시는분들이 많죠..
코어 i7 같은경우엔 트리플 채널이라 6기가 쓰시는분도 있구요.
현재 리눅스에서야 4기가 이상이라도 다 사용이 가능 하지만 윈도우에서는 3.25기가 정도 밖에 인식이 안되서 나머지를 램디스크로 잡아서 쓰지 않는 이상 나머지 용량을 버릴수 밖에 없죠.

Daiquiri의 이미지

그런 메모리 대부분이 낭비되고 있지 않을까요?

molla의 이미지

제 작업용 PC가 2G 메모리를 사용하고 있는데, 툭하면 메모리가 부족하다고 어플이 죽곤 합니다. (스왑을 사용하지 않았을 때... Windows 는 메모리 관리가 개판이라 스왑을 쓰면 무조건 느려지기 때문에 가급적 사용하지 않으려 합니다만 어쩔 수가 없더군요.)
뭐 그렇다고 무식한 프로그램들을 띄워놓는 것도 아닙니다. 메일을 보기 위한 천둥새 하나, 작업을 위한 터미널 참 여러개, 문서를 보기 위해 워드 또는 파워 포인트, 잠시 딴짓할 때 IE 창 여러개 정도입니다. (창 수만 보면 많지만 흔히들 사용하는 프로그램들이니...)
요즘엔 메모리가 남아돈다고 생각해서인지, 어플들도 메모리를 마구 낭비하는 경향이 매우 심합니다. (특히 IE!) 그래서 창 몇개 띄워놓고 작업하다 보면 수 G 는 쉽게 사용하더군요.

송효진의 이미지

놋북에 4G 쓰는데 답답해요.
8G 는 놋북 한대값이라 값이 내리기만을 목빠지게 기다리고 있습니다.

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇 개 안돼요~
http://xenosi.de/

Daiquiri의 이미지

그렇군요.
전 사양이 안 좋은 것들만 써와서 부하가 안 걸리는 작업만 하다 보니 다른 개인용 컴퓨터에서 무슨 일들이 일어나는지 알지 못하고 있었습니다.

magingax의 이미지

최적화를 안하게 되죠..

남자라면 512MB 에서 개발하는 근성..쿨럭..

이번달 보너스나옴..피씨부터 바꾸리라..

LISP 사용자모임
http://cafe.naver.com/lisper

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

Daiquiri의 이미지

이번달 보너스나옴..피씨부터 바꾸리라..(2)

ballsun의 이미지

논란 종결하러 2019년에서 왔습니다.
현재는 램 8GB는 기본이고 스트리밍같은건 32기가도 많고 드물게 64기가도 달아서 64비트는 필수입니다.
요즘 32비트는 프로그램이면 몰라도 32비트 윈도우는 구닥다리 컴퓨터 쓰는사람 아니면 거의 안쓰죠

mineco의 이미지

동의? 어보감

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.