이론상으로는 64bit register를 이용하면 16EB까지 addressing이 가능하지만, 지금까지 나온 64bit cpu들을 보면 그렇게 될거 같지는 않네요. 정확한 숫자는 기억이 안나지만, 64bit 전체를 addressing에 쓰는 것이 아니라 40~50bit 정도만을 사용하도록 되어 있더군요. AMD64의 경우에는 flat addresssing을 사용하면 256TB( 2^48 )의 메모리 address 공간을 사용할 수 있다고 하는군요.
address 공간이 늘어나게 되면, 그에 따라서 page table등의 공간이 늘어나기 때문에, 필요 이상으로 공간을 늘리게 되면 오히려 효율성이 낮아질 수도 있기 때문이라고 생각이 드는데요.
16bit에서 32bit로 바뀌었을때 address 공간은 약 6만5천배 증가했지만, 32bit에서 64bit로 바뀌게 되면 address 공간이 약 40억배 증가하는 셈이기 때문에, 지금부터 그 모든 공간을 다 쓸 필요는 없지 않을까 싶네요.
만일 64bit윈도우에서 32bit프로그램을 사용할 경우,
총 몇G까지 메모리를 사용할 수 있나요?
1) 32bit 윈도우와 마찬가지로 2G까지.
2) OS가 사용하던 2G의 제약이 없어지므로 4G까지.
어느쪽일까요>
답변 부탁드려요.
64bit윈도우에서 32bit프로그램을 사용하면, 호완성 유지를 위해 기존 OS의 제한을 그래도 유지할 것 같네요. (OS를 잘 뜯어고치면 호완성 유지하면서 더 많은 메모리를 프로그램에게 할당하는게 가능은 하겠지만, 32bit프로그램을 위해서 그렇게 노력을 들일만한 사람은 없지 않을까요? :) )
>>> 2**64
18446744073709551616L
>>> _/64 # 64 bit data bus
288230376151711744L
>>> _*1e-9 # access time 1ns
288230376.15171176
>>> _/3600/24 # a day
3335.9997239781455
>>> _/365 # a year
9.1397252711730008
36비트란거는 프로세서가 사용가능한 물리주소를 말한겁니다.
인텔의 경우는 펜티엄프로였던가 2였던가 그 이후부터 36비트 물리주소를
지원하죠. 만일 이 기능을 사용할 경우 페이지테이블 구조에서는
프로그램이 사용하는 가상주소(선형주소)는 32비트로 되어 있고, 거기에
대응되는 물리주소가 36비트가 됩니다. 물리주소가 더 크다 해도
가상주소는 어차피 돌아가는 프로세스마다 4G씩 다 줄 수 있기 때문에
상관 없습니다.
AMD64의 경우 내부를 안 파(?) 봤지만, 프로그램이 실제 쓰는 가상주소는
48비트로 알고 있습니다. 64비트는 아닙니다. (나중에 이것도 한계에 달한다면
어떤 확장으로 더 늘릴 수 있겠죠)
36비트란거는 프로세서가 사용가능한 물리주소를 말한겁니다.
인텔의 경우는 펜티엄프로였던가 2였던가 그 이후부터 36비트 물리주소를
지원하죠. 만일 이 기능을 사용할 경우 페이지테이블 구조에서는
프로그램이 사용하는 가상주소(선형주소)는 32비트로 되어 있고, 거기에
대응되는 물리주소가 36비트가 됩니다. 물리주소가 더 크다 해도
가상주소는 어차피 돌아가는 프로세스마다 4G씩 다 줄 수 있기 때문에
상관 없습니다.
AMD64의 경우 내부를 안 파(?) 봤지만, 프로그램이 실제 쓰는 가상주소는
48비트로 알고 있습니다. 64비트는 아닙니다. (나중에 이것도 한계에 달한다면
어떤 확장으로 더 늘릴 수 있겠죠)
Quote:
Most people never knew that the Pentium's original design included 36-bit addressing,
Page Address Extension은 펜티엄 1부터 있었고 36비트 어드레싱이 지원되고 있었습니다. 최근의 IA-32에서는 40비트까지 지원하는 것으로 알고 있습니다. 윈도우즈의 경우에는 Advanced Server 이상에서만 PAE를 지원했고 Address Windowing Extensions라는 특별한 API를 호출해야 이용할 수 있었기 때문에 제한이 있습니다. 아이테니엄(IA-64)의 경우에는 44비트를 직접 접근이 가능하다고 합니다.
AMD64의 경우에는 물리 주소는 40비트 가상 주소는 48비트를 지원하고 있다고 스펙에 나와 있군요. 가상 주소의 범위가 더 넓네요.
어쨌든 어드레스 버스가 지원하는 비트수만큼 승수한게 최대가 되겠죠... 혹은 구현환경에 따라 2, 4 정도 나눠준 값?
Quote:
16bit에서 32bit로 바뀌었을때 address 공간은 약 6만5천배 증가했지만, 32bit에서 64bit로 바뀌게 되면 address 공간이 약 40억배 증가하는 셈이기 때문에, 지금부터 그 모든 공간을 다 쓸 필요는 없지 않을까 싶네요.
맞습니다. 중요한건 이렇게 많은 양의 메모리를 사용하는 경우가 드물다는 것이겠죠. :D
하지만, 32bit 어드레스 버스 출시 초기때 누가 4GB 메모리를 상상이라도 했겠습니까?
발전속도가 기하급수적으로 늘어나니까 언젠가는 64bit도 부족해질 수 있겠네요... :)
흐음. 제 표현이 좀 부적절했나보네요.. 설명하는건 잘 못하는 편이라.
발전속도가 기하급수적인것은 맞습니다. 하지만 32bit->64bit로 바뀌게 되면 메모리 용량이 기하급수적으로 증가한다고 해도 그 공간이 부족하게 느껴지려면 16bit->32bit로 바뀌었을 때에 비해서 2배의 시간이 더 걸리게 되죠. 16->32으로 바뀐게 약 20년 전이라 보면, 64에서 더 늘릴 필요가 생기는건 앞으로 40년 후 정도가 되겠네요.(지금과 같은 속도로 메모리가 늘어난다면 이겠지만요. :))
위의 제 글은 '지금 현재는' 그만한 주소 공간이 불필요하다는 뜻이었는데요. 64bit로 addressing이 가능한 공간을 지금부터 제공하기에는, 64bit addressing을 하는데 따른 추가적인 저장공간(Page table등)이 크기가 현재의 일반적인 메모리 양을 고려해 봤을 때 상당한 부담이 되기 때문에, 점차적으로 늘려가는 쪽이 좋을 것 같다는 의미로 쓴 글이었는데.. 지금봐도 설명이 많이 부족하군요. ^^;
64bit 를 쓰는 이유가 32bit 어드레싱의 한계를 극복하기 위해서
64bit 를 쓰는 이유가 32bit 어드레싱의 한계를 극복하기 위해서 이니까
2GB 이상 쓸수 있어야만 되겠죠..
하지만 4G 는 아니고.. 아마도 2^63 이 답 아닐까요?
이론적으로는 그렇겠지만 칩셋에 따라 제한이 있을 듯 합니다. 그래야 파는
이론적으로는 그렇겠지만 칩셋에 따라 제한이 있을 듯 합니다. 그래야 파는 쪽이 뭐 하나라도 더 팔테니까-_-
실제로 32비트 환경에서라면 4기가 램을 이용할 수 있어야 하는데 많은 경우 2기가 정도로 제한이 되곤하더군요. 실제로는 어떤 부분이 문제인지는 잘 모르겠군요...
life is only one time
[quote="akudoku"]이론적으로는 그렇겠지만 칩셋에 따라 제한이
윈도우는 원래 32bit 환경에서 2G 유저메모리와 2G 시스템 메모리로 할당이 제한되어 있습니다.
원래 OS 설계가 그렇게 되어 있습니다.
어쨌든 64bit OS가 출시되면 한가지는 확실하겠군요..16EB
어쨌든 64bit OS가 출시되면 한가지는 확실하겠군요..
16EB(엑사바이트) 혹은 8EB 근처가 될 것이라구요 ㅎㅎ
[quote]어쨌든 64bit OS가 출시되면 한가지는 확실하겠군요..
이론상으로는 64bit register를 이용하면 16EB까지 addressing이 가능하지만, 지금까지 나온 64bit cpu들을 보면 그렇게 될거 같지는 않네요. 정확한 숫자는 기억이 안나지만, 64bit 전체를 addressing에 쓰는 것이 아니라 40~50bit 정도만을 사용하도록 되어 있더군요. AMD64의 경우에는 flat addresssing을 사용하면 256TB( 2^48 )의 메모리 address 공간을 사용할 수 있다고 하는군요.
address 공간이 늘어나게 되면, 그에 따라서 page table등의 공간이 늘어나기 때문에, 필요 이상으로 공간을 늘리게 되면 오히려 효율성이 낮아질 수도 있기 때문이라고 생각이 드는데요.
16bit에서 32bit로 바뀌었을때 address 공간은 약 6만5천배 증가했지만, 32bit에서 64bit로 바뀌게 되면 address 공간이 약 40억배 증가하는 셈이기 때문에, 지금부터 그 모든 공간을 다 쓸 필요는 없지 않을까 싶네요.
될대로 되라지..
[quote]만일 64bit윈도우에서 32bit프로그램을 사용할 경우
64bit윈도우에서 32bit프로그램을 사용하면, 호완성 유지를 위해 기존 OS의 제한을 그래도 유지할 것 같네요. (OS를 잘 뜯어고치면 호완성 유지하면서 더 많은 메모리를 프로그램에게 할당하는게 가능은 하겠지만, 32bit프로그램을 위해서 그렇게 노력을 들일만한 사람은 없지 않을까요? :) )
될대로 되라지..
[quote="idned"]어쨌든 64bit OS가 출시되면 한가지는 확
32비트 CPU라고 멕시엄 32비트는 아닙니다. 펜티엄 CPU도 칩 자체는 32비트 어드레싱의 제약이 없습니다. (다른 환경의 제약이지요.) 64비트 칩이라고 해도 최소 64비트 어드레싱은 아닐 가능성도 높을 테구요.
데이타 비트 수와 상관없이 현실적인 요구에 의해서 메모리 사용량은 정해질 것 같습니다.
- 죠커's blog / HanIRC:#CN
Understand linux kernel 에서 본 바로는 리눅스에서는
Understand linux kernel 에서 본 바로는 리눅스에서는 36 bit인가를 어드레싱에 사용해서 총 64G를 사용할수 있는걸로 압니다. 하지만 뭐 사실 제대로 활용하면 64bit 전부도 사용할수는 있지 않을까 싶군요;
2^64 bit memory를 scan했을때...
아주 멋지구리한 숫자가 나오는군요. :D
비교로 2^32 bit memory scan시에는...
:D
--------------------------------------------------------------------------------
＼(´∇`)ノ ＼(´∇`)ノ ＼(´∇`)ノ ＼(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)
IA32 아키텍쳐에서 한 어플이 쓸 수 있는 최대메모리는 4G입니다. (
IA32 아키텍쳐에서 한 어플이 쓸 수 있는 최대메모리는 4G입니다. (32비트)
36비트란거는 프로세서가 사용가능한 물리주소를 말한겁니다.
인텔의 경우는 펜티엄프로였던가 2였던가 그 이후부터 36비트 물리주소를
지원하죠. 만일 이 기능을 사용할 경우 페이지테이블 구조에서는
프로그램이 사용하는 가상주소(선형주소)는 32비트로 되어 있고, 거기에
대응되는 물리주소가 36비트가 됩니다. 물리주소가 더 크다 해도
가상주소는 어차피 돌아가는 프로세스마다 4G씩 다 줄 수 있기 때문에
상관 없습니다.
AMD64의 경우 내부를 안 파(?) 봤지만, 프로그램이 실제 쓰는 가상주소는
48비트로 알고 있습니다. 64비트는 아닙니다. (나중에 이것도 한계에 달한다면
어떤 확장으로 더 늘릴 수 있겠죠)
[quote="Anonymous"]IA32 아키텍쳐에서 한 어플이 쓸 수
Page Address Extension은 펜티엄 1부터 있었고 36비트 어드레싱이 지원되고 있었습니다. 최근의 IA-32에서는 40비트까지 지원하는 것으로 알고 있습니다. 윈도우즈의 경우에는 Advanced Server 이상에서만 PAE를 지원했고 Address Windowing Extensions라는 특별한 API를 호출해야 이용할 수 있었기 때문에 제한이 있습니다. 아이테니엄(IA-64)의 경우에는 44비트를 직접 접근이 가능하다고 합니다.
AMD64의 경우에는 물리 주소는 40비트 가상 주소는 48비트를 지원하고 있다고 스펙에 나와 있군요. 가상 주소의 범위가 더 넓네요.
아마도 현실적으로 40비트 정도의 물리 공간만 의미가 있는 듯합니다.
- 죠커's blog / HanIRC:#CN
어쨌든 어드레스 버스가 지원하는 비트수만큼 승수한게 최대가 되겠죠...
어쨌든 어드레스 버스가 지원하는 비트수만큼 승수한게 최대가 되겠죠... 혹은 구현환경에 따라 2, 4 정도 나눠준 값?
맞습니다. 중요한건 이렇게 많은 양의 메모리를 사용하는 경우가 드물다는 것이겠죠. :D
하지만, 32bit 어드레스 버스 출시 초기때 누가 4GB 메모리를 상상이라도 했겠습니까?
발전속도가 기하급수적으로 늘어나니까 언젠가는 64bit도 부족해질 수 있겠네요... :)
[quote="IDNed"]어쨌든 어드레스 버스가 지원하는 비트수만큼 승
흐음. 제 표현이 좀 부적절했나보네요.. 설명하는건 잘 못하는 편이라.
발전속도가 기하급수적인것은 맞습니다. 하지만 32bit->64bit로 바뀌게 되면 메모리 용량이 기하급수적으로 증가한다고 해도 그 공간이 부족하게 느껴지려면 16bit->32bit로 바뀌었을 때에 비해서 2배의 시간이 더 걸리게 되죠. 16->32으로 바뀐게 약 20년 전이라 보면, 64에서 더 늘릴 필요가 생기는건 앞으로 40년 후 정도가 되겠네요.(지금과 같은 속도로 메모리가 늘어난다면 이겠지만요. :))
위의 제 글은 '지금 현재는' 그만한 주소 공간이 불필요하다는 뜻이었는데요. 64bit로 addressing이 가능한 공간을 지금부터 제공하기에는, 64bit addressing을 하는데 따른 추가적인 저장공간(Page table등)이 크기가 현재의 일반적인 메모리 양을 고려해 봤을 때 상당한 부담이 되기 때문에, 점차적으로 늘려가는 쪽이 좋을 것 같다는 의미로 쓴 글이었는데.. 지금봐도 설명이 많이 부족하군요. ^^;
될대로 되라지..
댓글 달기