과연 구형 OS가 더 효율이 좋을까요? 컴퓨터 이야기



자꾸 사람들 레퍼런스 레퍼런스 그러는데 레퍼런스가 그렇게 중요한가요?
 <=- 트랙백 입니다.


안녕하세요?


요즘 IT(다른 밸리도 마찬가지지만,)를 뜨겁게 달구고 계신 희망의빛™ 님께 부족하지만, 두서 없는 약간의 말씀을 드려보고자 해요.


희망의빛™ 님...
 

Windows XP가 우수한 OS라는 주장은 열심히 읽어봤어요. 그런데 이런 점도 있답니다.


들어가기에 앞서 64비트 시스템에 대한 이야기부터 한 번 풀어보죠. 몇 건의 게시물과 덧글 등을 통해 보면 64비트 OS라던가 64비트 시스템에 대해서 어떻게 생각하고 계신지 조금 궁금하더라구요.

아시다시피 컴퓨터/디지털 기기는 기본적으로 데이터를 다루게 되고 이러한 데이터는 비트라는 단위를 최소 단위로 하고 있지요. 그러한 비트들이 모여서 이루어진 데이터를 읽고, 쓰고, 복사하고, 조작하고, 지우고, 사실 이게 다잖겠어요? 그 단순한 행위를 보다 빨리 효율적으로 하기 위해 수많은 기술이 등장하고 우리는 그 결과를 향유하는거죠.

그리고 여러 비트가 모인 데이터를 처리한다고 말씀 드렸듯이 그 비트를 단독으로 사용하는 것이 아니라 여럿을 모아서 한 번에 사용하다보니 몇 비트 시스템 이런 말이 나오게 되는 것이지요. 단순하게 생각하기에도 한 번에 더 많은 비트를 처리하는 시스템이 더 빠르게 효율적으로 일을 할 수 있겠고, 비트라는 것이 기본적으로 2진수고 컴퓨터 쪽은 보통 2의 제곱을 사용하다보니 16비트니, 32비트니, 64비트로 올라가는 것이겠지요.


자, 그러면 그 시스템의 비트 수는 과연 무엇을 기준으로 할까요?

일단, 컴퓨터에 비트 수로 표기하는 대표적인 부분들은, 연산 비트 수, 데이터 전송 비트 수 그리고 메모리 접근 주소 비트 수 정도가 아닐까 해요. 이 중 무엇을 기준으로 그 시스템의 비트 수를 나타내는가는 좀 생각해볼 문제이지만, 연산 폭을 기준으로 하는게 보편적이지 싶어요. 즉, 64비트 CPU라 하면, 네이티브하게 64비트 데이터를 한 번에 연산해낼 수 있는 것이고 64비트 OS라 하면, 이러한 64비트 연산을 제대로 지원하는 OS가 되겠지요. 그 다음이 부차적으로 메모리 주소 폭이겠고 이 주소 폭에 의해 최대 허용할 수 있는 물리적 메모리 용량이 결정되는 것이고요. 그런데, 메모리 주소 폭을 한 단계 아래 두는 이유는 연산 폭과 반드시 일치하지는 않기 때문이에요. 멀게는 x86의 효시라 할만한 i8086/8088의 Segment, Offset을 이용한 20비트 주소에서 가깝게는 32비트 시스템에서 36비트 이상으로 주소를 확장하는 PAE 등이 있거든요. 마지막으로 데이터 전송 폭이 있는데, 시스템의 비트 수를 논할 때는 거의 논할 대상은 되지 못할거에요. 가령 Pentium 은 32비트 시스템이었지만, 데이터 전송 폭(일반적으로 버스라고 하죠?)은 64비트였고 현재의 시스템들도 상당히 넓은 폭을 가지고 있거든요. 반대로 데이터 전송 폭은 좁은데 대신 높은 클럭으로 동작함으로써 대역폭을 넓히는 경우도 있고요.

여기서 문자코드는 끼어들 여지가 별로 없죠. 어차피 처리되는 데이터일뿐이거든요?
(참, 그리고 ASCII는 7비트랍니다.)


렇다면, 왜 비트를 자꾸 늘리려 할까요?

앞서 본 순서에 의해 바라보도록 하면, 먼저 한 번에 다룰(연산) 수 있는 데이터의 비트 수가 두 배로 늘어난 다는 것은 연산의 정밀도를 크게 높일 수 있다던지, 두 번에 할 연산을 한 번에 해서 연산 시간을 단축한다던지 하는 잇점이 생기는데, 솔직히 와 닿지는 않으실 것 같네요. 실제로 이 잇점을 누리기 위해서는 64비트로 제작된 프로그램을 사용하기도 해야 하고 그렇더라도 정량적으로 2배 성능 증가 이런건 아닌데다가 일반적으로 사용하는 대부분의 프로그램에서는 그다지 체감을 많이 느낄 것 같지는 않아서요. 그보다는 역시 사용가능한 메모리 양 증가가 와 닿으시겠죠. 그 부분에 대해서는 인지하고 계신 것 같기도 하고요. 대용량의 메모리를 사용하는 활용 분야 같은 복잡한 이야기를 할 것도 없이 요즘 메모리가 꽤 저렴한 부품에 속하다보니 다들 최하 4GBytes 이상은 마련하는 추세이고 이제는 32비트 주소로는 부족하죠. 물론, 이 역시도 별로 하는 일이 없고 그냥 웹 브라우저나 몇 띄우고 문서 작업이나 한다면, 솔직히 별 문제는 없어요. 간혹 부족하면 가상 메모리로 충당되기도 하고요. 하지만, 이미지 작업이라도 한다치면, 이야기가 달라지죠. 큰 사이즈의 이미지를 메모리에 올리고 작업을 한다면, 메모리가 부족할 경우 페이징 작업으로 인해 작업 효율은 급격히 떨어지죠. 또한, 게임의 경우도 서서히 64비트가 나오기 시작하는데, 오픈 월드 게임 등과 같이 많은 메모리를 필요로 하는 경우에는 보다 큰 메모리가 매력적이겠지요.

물론 필요한 사람의 이야기긴 하지만, 굳이 사용할 수 있다면 충분한 리소스를 확보하는게 여러모로 유리하지 않을까요?
하지만, 64비트를 제대로 지원하는 OS는 사실상 Windows 7부터에요.

럼 조금 다른 이야기를 해볼까해요.

얼마전 CPU 캐쉬에 대해 설명하시면서 간단한 도식과 함께 뭔가 구조적인 말씀을 하셨는데, 보다 빠른 시스템을 위해 과연 어떤 식으로 발전해나가고 있을까요? 사실 동일 아키텍쳐에서는 클럭을 높이는게 최선이고 과거에는 공정의 발전과 함께 클럭이 쑥쑥 올라갔어요. 한 때 인텔에서 겁도 없이 10 Ghz를 돌파하겠다는 장담을 한 적도 있으나, 결국 4Ghz의 벽을 넘지 못하고 열과 전력 소모에 굴복하여 방향을 선회해야했지요. 이제는 공정 향상으로 그만큼 전력 소모 감소와 열 감소에 힘입어 클럭과 성능이 쑥쑥 올라가던 시기는 지났거든요. 많이 들어보셨을꺼에요. 공정도 서서히 물리적 한계에 도달하고 있고 다양한 문제로 인해 공정 이전에 천문학적인 금액과 시간이 소요된다고. 그리고 그런 것을 극복하기 위해 아키텍쳐도 복잡해지고 다양한 개념과 기술이 도입되고 있죠. L3 캐쉬도 그 중 하나이고요. 연산 유닛을 늘린다던지 (참, 하나의 코어는 한 클럭당 하나의 명령 처리라고 하셨는데, 실제로는 최적의 조건에서 2개 이상의 명령이 처리 가능하기도 해요.) 이런저런 방법을 도입하고 있지만, 효율이라는 측면에서 한계는 있지요. 그래서 또 다른 방향을 모색하는 것이 전용 명령셋 추가 같은 부분이에요. 가령 기존 명령 체계로는 여러 명령을 사용해서 해야 할 계산을 전용 명령과 회로를 통해 한 번에 효율적으로 할 수 있다 하면? 이 역시 성능의 향상으로 이어지겠죠. 그런 이유로 MMX 이후로 새로운 아키텍쳐가 등장할 때마다 꾸준히 새로운 명령셋이 추가되어오고 있고 이는 최근에 나온 AVX 등의 명령셋까지 이어지고 있어요.

자, 이쯤에서 한 번 생각해보죠. 새로운 명령이 추가 됐으면, 그걸 사용해야겠죠? 당연히 소프트웨어 특히 OS의 도움이 필요한거에요. 그런데 그 명령셋이 존재하기 전에 나온 OS에서 얼마나 해당 기능을 지원해줄 수 있을까요?
가령, 조금 전에 언급한 AVX의 경우는 Windows 7 SP1 이후 지원 가능한 명령셋이에요.

음으로 Windows XP가 가볍다고 하셨는데,

당연히 더 많은 기능, 더 화려한 UI, 그리고 보안적 문제로 이것저것 챙길것이 많이 들어가게 되는 신형 OS가 구형 OS보다 더 복잡하고 무거울 수 밖에 없는 것이 사실이긴 해요. 하지만, 그럼에도 더 가볍고 사용하기 좋다는 것은 바로 저런 것이에요. 더 나중에 나온 더 성능 좋은 신형 H/W를 제대로 사용함으로써 효율을 발휘하는거죠. 아무리 자체는 더 가벼워도 결국 구형 H/W에 최적화 되어 최신 H/W를 제대로 사용할 수 없는 OS가 최신 OS에 대해서 그다지 잇점을 가질 수 없는 부분인거죠.

오래된 구형 저성능 H/W에 무거운 최신 OS를 사용하는건 당연히 효율이 나쁠 수 있어요. 하지만, 그렇다고 구형 OS를 사용하고자 계속 구형 H/W를 고집한다던지 신형 H/W에 구형 OS를 설치하고 제 기능을 발휘 못하는 건 더 이상하지 않을까요? 뭐든지 적당한 매칭이 있다고 생각해요.


지막으로, 멀티 코어에 대해서도 말씀 하셨었는데,

물론 Windows XP도 멀티코어를 지원해요. Professional 이상은 SMP도 지원하고요. 그런데, 그 부분에서도 조금 문제가 있어요. 일례로 하이퍼스레딩도 알고 계신 듯 한데, 이를 Windows XP에서 사용할 경우와 Windows 7에서 사용할 경우는 효율성이 크게 차이가 나죠. 하이퍼스레딩을 전혀 고려하지 못했던 Windows XP의 경우는 스케쥴러에서 작업을 분배할 때 하나의 코어에 하이퍼스레딩을 통한 두 스레드를 따로 배려하지 못하고 그냥 차곡차곡 채워넣어버려요. 즉, 물리적으로 분리된 다른 코어가 놀고 있어도 하나의 코어에 두 개의 스레드를 돌려버리는 상황이 발생하는 것이죠. 반면 Windows 7 이후로는 그런 경우가 발생하지 않도록 스케쥴러가 설계되어있어요.

그 이외에도 요즘 많이 사용하는 SSD에 대한 지원 부분도 극명하게 갈리고요. 이 부분은 심지어는 Windows 7 과 Windows 8 조차도 차이가 나요.

서비스팩(사실상 패치들의 묶음)으로 할 수 있는 부분이 있고 근본적으로 어려운 부부도 있어요. 물론 어떻게든 땜질로 만들어낼 수 있을지 모르겠지만, 처음 설계된 기본적인 한계가 있는데, 효율이 얼마나 좋을까요? 그보다는 새로운 기술들로 새로운 H/W에 맞추어 새로 만들어지는 OS가 더 효율적이지 않을까요?

익숙한 점이나 취향으로 WIndows XP를 선호하는건 타인이 간섭할건 아니라 생각해요. 하지만, 최소한 주관적인 부분과 객관적인 부분은 분리해서 생각하면 좋겠네요.


그럼...
루였어요~♤


P.S.

OS는 Windows 기준입니다.

덧글

  • RuBisCO 2014/06/19 02:59 # 답글

    에, 64비트 지원이라면 비스타부터 지원 자체는 완성된 편이죠. 비스트 자체가 좀 아쉬운게 많아서 문제지. 그나저나 하나의 코어가 한번에 하나밖에 처리 못한다고 하신 분이 있다니 80년대 분이신가 봅니다. 슈퍼스칼라 마이크로프로세서가 상용화된게 어느 옛날인데...
  • 루루카 2014/06/19 07:51 #

    네, 이미 Windows Vista부터긴 하죠. 어차피 커널 버번이 6.X 대로 메이저 버전이 같기도 하고요.
    개인적으로는 Windows Vista도 잘 사용했지만, "사실상"이라는 단서를 붙인걸 이해하시리라 봐요.
    ^_^`...

    이미 펜린 시절에도 4개까지였죠? 사실 그래서 파이프라인을 한 번 보시라고 말씀을 드렸던건데...
  • 오린간 2014/06/19 04:16 # 답글

    오 이거 굉장히 좋은 글이네요!!!!!
  • 루루카 2014/06/19 07:51 #

    좋은 글이라니 고맙습니다.

    아는 바가 적어서 두리뭉실 적었을 뿐인데...
  • 희망의빛™ 2014/06/19 07:35 # 답글

    좋은글 잘 읽었습니다. 본문 중에 아스키코드가 7비트라고 하셨는데 확장아스키 문자까지 포함하면 8비트 아닌가요? 그리고 요즘 코어는 레지스터가 많으니까 한 클럭에 몇개의 명령어는 처리할 수가 있을 겁니다. 그 부분은 제가 미처 설명이 부족했던 것 같습니다. 저도 잘 몰랐구요. 다만 한 클럭에 일련의 명령어셋(?)의 처리가 이뤄진다는 사실은 변함이 없겠지요. 보충설명 감사드립니다. 그리고 제 넷북에서 XP의 하이퍼쓰레드 동작은 결과적으로 윈도우7보다 빠르게 동작했던 건 사실이었습니다. 작업관리자 그래프나 웹브라우저, 응용프로그램 등을 실행해 보면서 알 수 있었지요.

    암튼 좋은 내용을 작성해 주셨네요. 호호.
  • 루루카 2014/06/19 07:52 #

    그러시군요.
  • ουτις 2014/06/19 20:50 #

    요즘 코어에서 한 클럭에 여러 명령 처리가 가능한 것은 레지스터와는 무관합니다. 파이프라이닝, 수퍼스칼라, SIMD등과 상관 있죠. :-/
  • 이명준 2014/06/19 13:51 # 답글

    초중기 넷북 부동소수점연산 정수연산 자체가 굉장히 처참하다는걸(동클럭 펜티엄4급의 성능..) 생각하면 진짜 저 사람 화나게함

    고작 간단한 사무작업과 웹서핑에만 최적화 된 물건 가지고 나불나불 되니.. 후우
  • 루루카 2014/06/19 09:52 #

    솔직히 무슨 작업을 하셨는지 궁금하긴 해요.
    그리고, A사의 불도저 CPU를 사용하는 데스크탑도 있으신 것 같던데,
    거긴 깔아보고 싶은 마음이 없으시겠지요.

    결국 Windows 7을 사용해보고자 설치했다기보다는... 좀 부정적인 심정으로 한 번 보자 정도로 접근하신게 아닐까 조심스레 추정해봅니다.
  • 긁적 2014/06/19 13:05 #

    음;; 아마도 부정소수점이 아니라 부동소수점^^;;
    소수점이 떠다닌다고-_- 뜰 부자 움직일 동자 쓰는 걸로 압니다. 참고하세요.
  • 이명준 2014/06/19 13:51 #

    오타입니다 .
  • Halkrine 2014/06/19 09:18 # 답글

    디테일하게 정리해주셨는데 받아들이는 분은 결국...
  • 루루카 2014/06/19 09:50 #

    안타깝게도 상정 범위의 반응이셔서...
    이 글을 적은건 이런저런 다양한 심정의 복합적 결과랍니다.
  • 총통 R 레이퍼 2014/06/19 09:50 # 답글

    결국 겁나게 좋은 이야기 해줬지만 받아들이는 쪽을 받아드릴 생각 없음......
  • 루루카 2014/06/19 09:52 #

    뭐, 그런거죠. 알면서 쓴걸요?
  • 아이비스 2014/06/19 10:02 # 답글

    답답한 고집불통 블로거분의 등장으로 밸리가 오염된 부정적 면도 있지만,
    이렇게 반박을 통해 유익한 정보가 올라오는 긍정적인 면도 있네용 +ㅅ+)b
    작성하느라 고생 많으셨습니다!
  • 루루카 2014/06/19 10:33 #

    유익하다니 기쁘네요. 좋은 하루 되세요~
  • 무명병사 2014/06/19 10:06 # 답글

    뭐 윤찬이 볍저씨한테는 뭔 말을 해도 소용없지만, 평범한 사람들한테는 매우 좋은 글입니다.
    그러나 전 머리가 아파서... 으으으;;
  • 루루카 2014/06/19 10:33 #

    저... 저도 머리가 아파요. 수면도 부족하고... 쿨럭...
  • 콜드 2014/06/19 11:20 # 답글

    그랬다. 룰루 아저씨는 컴덕이였다(?)
  • 루루카 2014/06/19 11:23 #

    아니! 그러니까 왜요? 전 그저 선량한 일반인이에요.
  • jei 2014/06/19 11:44 # 삭제 답글

    먹고살기 힘들어서 컴관련 공부를 몇년 쉬었더니 완전히 문외안이 됀느낌인데
    저사람은 뭔 배짱으로 저러고 사는지

    그래도 저사람덕분에 그동안 벌어진 텀을 어느정도 회복이 가능했습니다(는 개뿔 뭔소리하는지 이해가 안돼네요 ㅠ.ㅜ 머리가 굳었어요 OTL) 286부터 써왔고 나름 이쪽부분에 공부도 좀 했었지만 역시 기술의 발전은 개인이 따라잡기는 힘들더군요

    아무튼 이상한사람이 뻘소리 해대서 그거 바로잡느라 다들 고생이 많으십니다
  • 루루카 2014/06/19 11:49 #

    저도 깊이가 없어서 그냥 두리뭉실 적었는걸요.

    좋은 하루 되세요~
  • liars 2014/06/19 12:12 # 답글

    나중에 자세히 한번더 읽어봐야겠네요,이글루스를 하면서 많은걸 알아가는 느낌입니다, 감사합니다.
  • 루루카 2014/06/19 13:31 #

    도움이 되신다니 기쁘네요. 즐거운 하루 되세요~
  • 긁적 2014/06/19 13:07 # 답글

    이거 보고 돈생기면 윈8질러야겠다고 결심했슴다 ㅋㅋ. 포스트 감사요~
  • 루루카 2014/06/19 13:31 #

    어어! 그게 어찌 그리 연결되시죠? 아무튼 도움이 되셨다니... 기뻐요~
  • 긁적 2014/06/19 13:41 #

    SSD 지원 때문에요. 조만간 하드 자원 엄청 먹는 대규모 컴파일 돌릴 일이 생길 거 같아요 ㅠ.ㅠ..
  • 루루카 2014/06/19 14:09 #

    퍼포먼스 쪽은 7과 8.1이 엎치락 뒷치락 대동소이 한 것 같은데,
    Windows 8.1은 자잘한 파일에 대한 요청이 NCQ에 꽉꽉 채워졌을 때 효율이 더 좋아보여요.

    그리고 제가 다르다고 한 더 큰 이유는 그 관리에 대한 부분이에요.
    Windows 7의 경우는 SSD를 인식하고 조각모음 등에서 배제하는 수준이었다면,
    (물론 내부 TRIM은 지원되지만,)
    Windows 8/8.1은 한 걸음 더 나아가 드라이브 최적화 메뉴에서 아예 "SSD(반도체 드라이브)"라는 항목으로 표기하며, 최적화 기능을 제공하고 있어요. "마지막 실행 이후 XX일" 이라는 표시까지 나오죠.

    이건 도움이 될지 모르겠지만, 개인적으로 사용중인 시스템들의 실측값들이에요.
    (스펙은 명시되어있으니 참고만 하세요.)
    http://rouxlouka.egloos.com/2351583
    http://rouxlouka.egloos.com/2434633
  • 긁적 2014/06/19 14:12 #

    오오오오오오오. 감사합니다 ㅠ.ㅠ.ㅠ.ㅠ.ㅠ.ㅠ.ㅠ.ㅠ.
  • 아침북녘 2014/06/19 14:49 # 답글

    오오, 뭔가 굉장히 깔끔한 글이네요! 저도 컴퓨터에 관심이 많지만 겉핥기식이라 어디가서 컴퓨터 만진다는 소린 안하거든요... 이걸보니 정리가 되었습니다! 감사합니다! 하지만 그분은 g.g...
  • 루루카 2014/06/19 17:54 #

    부족한 글인데 도움이 되셨다면, 기쁘겠네요. 좀 답답하지만, 이제는 안타까워서...
  • 나인테일 2014/06/19 16:53 # 답글

    OS X나 우분투처럼 매년 자잘하게 업데이트 해 대도 몇 년 지나가면 결국 예전 버전이랑 비교해 보면 호환성 등에서 차이 확 나는건 마찬가지더군요. 서비스팩이나 계속 올리자는 주장에 가장 가까운게 저 두 제품입니다만 그래봤자 시간 지나가면 별 차이 없다는게 함정;;
  • liars 2014/06/19 16:56 # 답글

    한번더 읽어보았습니다, 기본적으로 요즘나오는(샌디브릿지이후..) 클럭의 상승폭도 적은데 성능이 올라가는것이 의아해 했는데, 그렇군요 명령어가 추가가 되는형식으로 이젠 업그레이드가 되는군요..
  • 루루카 2014/06/19 18:22 #

    아, 조금 오해가 있으셨군요?
    AVX는 SandyBridge에서, AVX2는 Haswell에서 포함되었지만, 그것만으로 올라간건 아니에요.
    기본적인 내부 스펙도 향상되었어요. 각종 버퍼, 유닛 개수가 늘고 레이턴시, 대역폭 등이 보다 강화되었죠. 그런 결과라고 보셔야 해요. (물론 Haswell은 전력 절감 쪽에 무게가 많이 주어지긴 했지만,)
    단지, 제 글의 요지는 그런식으로 상승도 무작정 늘릴 수만은 없고 (여러가지로 균형을 맞춰야 하니까요) 그와 병행해서 전용 명령셋/레지스터 등을 추가함으로써 해당 기능을 지원할 경우 더 높은 성능 향상을 볼 수 있다라는 거죠.
    즉, 병행한다고 보시는 편이 좋을꺼에요.
  • 은화령선 2014/06/19 18:49 # 답글

    윈 8.1 ssd 달아서 써야겟네요
    비싸더라도 256gb써야 되나
    물론 64비트로 램은 8기가로 꽉채워서 가버렷!
  • 루루카 2014/06/19 20:33 #

    지금 산다면, 250~256GBytes 급은 해주는게 좋겠죠.
    그리고 너무 소심하시다~ 하다못해~ 32GBytes는 해야 가는거에요!!!
  • 은화령선 2014/06/19 20:38 #

    아 물론 단일 램이라면 32가겟지만..
    다른것도 다 포함시키면.. 흙흙.. 으앙
    루카저씨가 사주세요! ㅋㅋㅋㅋㅋㅋㅋㅋ
    전역하면 루카저씨 한번 뵈야되는데
  • Windows XP 2014/06/19 22:10 # 삭제 답글

    텔레비젼 나와도 라디오 필요합니다.

    4륜차가 잘 나가도 2륜차 필요합니다.

    32비트 전용 운영체제의 필요성 사라지지 않을 것으로 봅니다.



    [연산 명령어 세트]로는 16비트에서도 충분합니다. (6만개 이상의 기계어 명령어가 필요할까요?)

    피연산자를 한번에 담는 [연산 비트 수]도 프로그래밍에서는 32비트로 충분합니다.

    과거 특정 과학기술분야에서 보다 편리한 수치연산을 위해 64비트를 열렬히 선호했지만,

    어차피 64비트 수치연산에 만족할 사람들이 아니라 정수나 실수의 연산은 64비트를 넘는 연산들을

    기필코 쓸 사람들은 이미 32비트 운영체제 환경에서 구현해서 사용하고 있습니다.

    일반적인 프로그램에서는 64비트로 수치연산을 할 필요도 없고, 수치 연산 속도 차이도 나지 않습니다.

    쉽게 말해, 32비트로 연산하든 64비트로 연산하든 1 + 1 을 연산하는 속도는 똑같습니다.



    [데이터 전송 비트 수]는 늘릴 수록 회로에서 차지하는 면적과 공간이 늘어나게 된다는 점도 있습니다.

    미래의 웨어러블 모바일 환경의 초소형, 극소형, 저전력 기기를 위해 면적과 공간을 물리적으로 줄여야

    되는 아키텍처 관점의 입장도 있습니다. 즉, 데이터 전송 비트 수는 장치 사이의 일치와 호환에 관한

    것으로 그것이 작을 수록 좋은 경우도 있어서 64비트로 가야하는 이유나 근거가 될 수는 없습니다.



    [메모리 접근 주소 비트 수]도 사실 WindowsXP도 32비트 운영체제임에도 불구하고 처음에는

    4GB를 모두 제대로 쓸 수가 없었습니다. 물론 나중에는 됐습니다. 즉, 프로그래밍의 문제일 뿐이죠.

    32비트 운영체제에서도 명령어 세트를 변경해서 4GB 이상의 메모리 주소를 한번에 접근할 수 있습니다.

    물론 메모리 때문에 기존 명령어 세트를 변경 하느니 64비트로 바꾸겠다고 핀잔을 줄 수도 있겠지만,

    32비트 연산 환경에서 최적화가 필요한 미래의 웨어러블 등, 초소형, 극소형, 저전력 기기를 위해

    4GB 초과 거대용량 메모리 접근을 지원하는 명령어 세트를 마련하는 것을 꺼려할 일도 아닙니다.



    32비트 전용 운영체제의 필요성 사라지지 않을 것으로 봅니다.

    물론 그것이 꼭 기존 Windows XP가 아닐 수도 있겠습니다만,

    만약 32비트 전용 운영체제가 필요하다면, 지배적으로 커다란 사용 경험자층을 보유했던 점을 이유로,

    완성도 높게 개조된 Windows XP로 살아남을 개연성이 있습니다.




    글을 마무리 하자면...

    어차피 Windows XP의 생명력은, 지금까지 IT기술이 그래왔듯이,

    사용자의 선호에 의해 시장에서 결정될 것이므로,

    굳이 선호하는 사용자를 어줍잖게 타일러서 Windows XP를 사장시킬 필요도 없고

    타이른다고 그렇게 의도대로 되지도 않을 것이라는 것입니다.



    이와 같이, 시장과 사용자가 선호하여 어떠한 수익이 창출된다면 MS에서도 다시 살릴 수도 있고,

    32비트나 Windows XP를 위해 수익모델을 갖춘 공개소스 정책이 나올 필요도 있다고 봅니다.
  • 루루카 2014/06/19 23:18 #

    먼저 어떤 이유에서, 마음으로 이런 덧글을 장황하게 달아주셨는지 조금 여쭙고 싶네요?

    제 글이 이정도로 공격적으로 나오실 만한 글이었는지에 대해서는 좀 생각해봐야겠군요?
    일단 64비트 OS에 대해서 클레임을 거셨으니 답변 드릴께요.

    [연산 명령어 세트]는 딱히 언급하지 않았습니다만, 연산 명령어 셋트가 16비트라 하여, 65536개 하나하나가 기계어 명령어로 의미를 지니는 셋트가 만들어지는 것은 아니라는 것을 아실 듯한 분께서 조금 실수하신 듯 하군요?

    [연산 비트 수]에 대해서도 일반적인 영역에서는 딱히 체감하기 어렵다라고 언급 드렸고요.

    [데이터 전송 비트 수]에 대해서도 장/단점을 언급하지도 않았고 오히려 그건 시스템의 비트수를 구분 짓는 요소로서 보기는 어렵다라고 언급했지요? 또한, 비트 수를 늘리는 이외에 오히려 적은 비트수에 클럭을 고속으로 올리는 방법도 함께 소개했고요. 어차피 비트 수가 올라가면 말씀하신 것처럼 회로의 면적/복잡도 이외에도 점점 고속으로 갈수록 각 비트간의 타이밍 문제도 발생하기도 하죠. 장비의 호환성이라는 부분에 대해서는 솔직히 연관지어 설명을 드릴만한 부분이 아니라 보이네요.

    [메모리 접근 주소 비트 수]는 그중 일반적으로 체감/효용성이 있다고 언급했지만, 그 이외에 이미 PAE 등의 방법도 언급했죠. 실제로 서버급의 Windows OS들은 32비트에서도 최대 128GBytes까지 가능한 버전이 있었기도 하고요. 그런데, 그에 대한 문제도 이미 답을 직접 적으셨네요?

    마지막 결론에 대해서도 제가 이 글을 적게 된 동기와 대상의 수준을 이해하셨다면, 굳이 그렇게 말씀하실 필요는 없어보이네요.

    어떤 경로를 통해서 제 글을 보았고 어떻게 받아들이셨는지 모르겠지만, 다른 덧글들에서 보시고 뭔가 느끼신 것이 없으셨는지요?

    제 결론 글에서도 개인의 XP 선호에 대해서 타인이 뭐라 간섭할건 아니라 한다고 분명히 언급했답니다. 물론,써보니 좋은데 써보라고 한 두번 권해볼 수는 있겠지요. 그리고, 굳이 64비트를 지원하는 시스템이 있고 추가 금액이 안 드는 상황에서 제약이 있는 32비트를 고집할 필요는 없지 않은가 하고 생각하긴 하지만, 그래도 굳이 쓴다면 그것도 그 사람 선택이라 보고요.

    솔직히 반대를 위한 반대성 덧글이라는 기분을 지울 수 없지만...

    답변이 되었기를 바랍니다.
  • 이젤론 2014/06/19 23:16 #

    이분 도플갱어인듯?
  • 루루카 2014/06/19 23:19 #

    글 적는 패턴이나, 그동안 그 분이 보여온 지식 수준을 비교해볼 때...
    그럴것 같지는 않지만, 만약 진짜라면 뭔가 무서워지네요?
  • 디베스테이터 2014/06/21 08:14 #

    아, 필요한 곳은 있죠.

    근데 이륜차 필요하다고 초창기 발로 차는 나무자전거를 쓰고 라디오 필요하다고 진공관 라디오를 쓰던가요?
  • 루루카 2014/06/21 08:32 #

    디베스테이터 님...

    그렇게 간단한 방법이 있었는데, 제가 너무 장황하게 답글을 달아버렸네요.
    생각해보니 32비트 버전의 Windows 7 이상도 있는데, 그걸 생각을 안 해버렸다랄까요?

    말은 좀 기술적으로 적었지만, 결국 주장은 그 누구랑 같은 사람이다보니...
    많이 당황했었나봐요.
  • Temjin 2014/06/19 23:15 # 답글

    4살먹은 냇북에 SSD쑤셔넣고선 하는일이 인터넷 벵킹이전부인 저에게는...(으허엉...ㅠㅜ)
  • 루루카 2014/06/20 00:24 #

    용도에는 딱 적합하지 않으신가요? ^_^`...
    그건 그렇고 정말 붓으로 1/144 인형 칠하시는거 보면 존경스러워요.
    (이미 민메이 칠하셨을 때 눈치 챘어야 했는데...)
  • Arcturus 2014/06/22 01:45 # 답글

    XP에서 8로 바로 넘어갔는데, 다른 건 몰라도 자동으로 드라이버 잡는 것과 부팅 속도만으로도 윈8은 찬양받아야 마땅합니다:)
  • 루루카 2014/06/22 13:22 #

    부팅 속도는 사실상 반쯤은 절전모드로 들어가는 수준인데다가,
    UEFI를 제대로 지원할 수 있다는 점도 있지요.

    드라이버야...
    아무래도 더 신형 OS다보니 더 많은 디바이스에 대한 드라이버를 내장한 덕을 보는 것이라 보는게 좋을 듯 하구요.

    또 다른 하나는 징그럽게 쏟아지는 업데이트 수가 많이~~~ 줄어든다죠.
    (이건 Windows 7 조차도 이제는 패치가 엄청 많이 쌓여서 다 하려면 한숨 나오죠.)
댓글 입력 영역