Snow Leopard, 개발자들의 생각 1

casaubon · 2009-08-31, 02:02 AM

> Snow Leopard : l'avis des développeurs
Posté le 24.08.2009 à 17:59 par Florian Innocente

맥오에스텐 스노레퍼드가 나왔다. 스노레퍼드는 일단 개발자들이 주고객이 될만한 기술이 여러가지 들어가 있지만, 우리들 일반 사용자에게도 상당히 좋을 기능들이 많으리라 기대하고 있다. 3D 프레임웍 계산에 쓰이는 그래픽 프로세서를 사용하게 될 OpenCL서부터, 메모리를 더 많이, 더 빠르게 이용하게 될 64 비트, 컴퓨터 프로세서 코어 간에 태스크 배치를 단순화시키게 될 Grand Central Dispatch에 이르기까지 매우 다양하다.

스노레퍼드가 최종화된 지금, 본지는 간단한 질문 두 가지를 여러 개발자들에게 물어 보았다. 위 기술을 사용할 것인지, 그것이 사용자들에게 어떤 이득이 있는지이다. 최근 컨퍼런스에서 애플은 성능 시연을 해보인 바 있다. 이 기술을 사용한 iMovie나 Aperture에서 스톱워치라도 내세울까 기대했는데, 전혀 그렇지 않았다. Mail이나 Safari가 얼마나 빨라졌는지 정도에 대한 통계만 나왔을 뿐이다. 시스템 전반적으로, 그리고 애플리케이션 속도에 어느 정도 개선이 있으리라는 약속은 나왔다. 그러한 개선으로 최종 시스템이 더 좋아지리라는 것이었다.

개발자들의 답변을 읽어보면, 애플이 스노레퍼드에 대단히 괄목할 만한 기능을 효과적으로 집어 넣었다는 인상을 받는다. 하지만 그 구현이 그리 간단해보이지는 않다. 시간과 노력이 필요하리라는 의미다. PowerPC에서 G4 AltiVec으로, 맥오에스텐으로, 그리고 인텔 칩으로의 이주할 때와 같다... 새로운 이주의 시기가 열렸다.

수 주일 뒤면 각종 이 기술을 사용할 프리웨어와 셰어웨어가 나올 것이다. 제목만 바뀔 경우도 있을 것이며, 정말 속도가 빨라지거나, 손쉽게 수정을 가하여 동 기술을 사용할 프로그램도 있을 것이다. 하지만 대규모 애플리케이션에 대해서는 의문이 남는다. OpenCL과 그 외 기술은 맥오에스텐을 윈도보다 훨씬 돋보이게 만들어주지만, 애플용과 마이크로소프트용을 동시에 내놓는 어도비가 두 OS용으로 계속 솔루션을 과연 선보일까? 과연, 64-비트로 이주할 수밖에 없을 두 OS용으로 동시에 튜닝을 할 이유가 있을까? 쿼크나 마이크로소프트에게도 마찬가지이다. 설사 마이크로소프트의 맥 사업부가 맥에 고유한 기술을 사용할 만한 곳이더라도 말이다.

그런데 이런 대규모 개발사들만이 아니다. 구체적으로 선도를 해야 할 곳은 애플이다. 애플 또한 스노레퍼드의 덕을 볼 수 있는 오디오와 비디오용 소프트웨어를 많이 내고 있다. 그런데 iLife나 Aperture, Fical Cut Studio의 메이저 업데이트를 낼 때까지 좀 기다려야 할까? 스노레퍼드의 가격을 감안할 때, "스노레퍼드 최적화" 마크가 있는 애플리케이션 가격을 올릴 동기도 상당하다고 봐야 할 것이다. 물론 우리야 더 저렴해질 시나리오를 기대하고 있다. 일단 기술활용 정도로 그칠 소소한 업데이트가 곧 나오기를, 그리고 2010년께에 메이저 업데이트가 이뤄지기를 말이다.

INTERVIEW

Matthieu Kopp : Aquafadas의 공동창립자. 전문가용과 일반인용 오디오/비디오 솔루션 제작업체

"스노레퍼드는 OpenCL과 Grand Central Dispatch라는 주목할 만한 기술이 들어가 있습니다. 즉, Quartz Composer에 신기능이 대단히 많이 들어갔다는 얘기죠. 개발 측면에서 보자면 스노레퍼드는 완전히 새로운 유틸리티를 갖고 있어요. 대단히 기쁜 일입니다.

개인적으로 성능 개선만 보자면 좀 그렇습니다. 특정 기능에서는 정말 개선이 있습니다. 하지만 우리 코드에 적용시키려면 상당한 시간을 투자해야 하지요. 퀵타임 로레벨과 같은 작업에 이미 많은 시간을 투자했다면, 어려운 결정입니다. 64비트의 장벽을 넘나드는 것이 아니기때문에 검토가 더 필요합니다. Grand Central Dispatch도 마찬가지에요. 재컴파일만으로 눈에 보이는 개선이 있긴 합니다. 하지만 더 좋게 만들려면, 코드를 샅샅이 뒤져서, 잘 정리해 두어야 하죠.

이런 이주가 원래 그렇습니다. 예전 시스템을 조절해야 하죠. 스노레퍼드 전용 프로그램으로 할까요, 아니면 레퍼드 호환으로 해야 할까요? 업데이트 비용이 매우 낮은 것은 사실입니다만, 우리 애플리케이션 대부분은 타이거 호환이기도 합니다. 그래도 Grand Central Dispatch와 같은 특정 기술 통합을 위한 검토작업을 할 계획입니다.

OpenCL이 정말 흥미로운 기술이죠. 그동안 작업해온 기술이기도 합니다. 하지만 문제가 있어요. 몇몇 머신에서는 안돌아가는 문제죠. 성능 개선도 눈에 크게 띄지는 않습니다. 특정 그래픽 카드에 의존하니까요. 꽤 최근에 나온 아이맥 24인치도 크게 개선이 안보일 정도입니다. 하지만 우리 고객은 주로 전문 사용가들, 특히 미들타워(코어 두 개와 엔트리급 그래픽카드) 맥 사용자들입니다. 이들마저도 이 기술을 활용할 수 없죠.(*) 결론은 이렇습니다. 조급하게 하지 말자. 하지만 이 기술을 테스트하자, 입니다."

(*) OpenCL 최소사양은 다음과 같다. : NVIDIA GeForce 8600M GT, 8800 GT, 8800 GTS, 9400M, 9600M GT, GT 120, GT 130. ATI Radeon 4850과 4870.

Nick Fletcher : 웹사이트 저작용 프로그램과 이미지 관련 프로그램을 만드는 Realmac Software의 저자

"스노레퍼드가 나왔으니 RapidWeaver와 LittleSnapper 업데이트도 곧 나오게 될 겁니다. 스노레퍼드에 잘 작동해야 할 뿐더러 고유 기능도 활용해야 하죠. LittleSnapper의 64비트 컴파일은 해 놓았는데요. Rapidweaver 4.3은 하지 않았습니다. 아직 때가 안되어서 그런 건데요. 우리가 사용하려는 스노레퍼드의 여러 가지 기술과는 달리, LittleSnapper 1.5.1의 경우는 10.6에 있는 Xcode 버전을 사용하여 컴파일만 다시 해도, 괄목할만한 성능 개선이 있었습니다. 앞으로도 흥미로운 점이 대단히 많이 있습니다. 당장 발표해드릴 것은 없습니다만, 개발자는 물론 사용자 관점에서 봐도 그렇습니다."

Antoine Rosset : 의학 이미지용 프로그램인 OsiriX의 저자.

"스노레퍼드는 사용자 측면에서도 상당히 흥미롭게 개선이 됐습니다. 당장 보면 OS의 여러 부분과 프로그램들이 64비트로 이주를 단행하였죠. 단기간에 말입니다. 특정 기능에 따라서 성능 개선이 30%까지 올라갈 수 있습니다. 장기적으로는(수 년 걸리겠죠?), OpenCL과 Grand Central Dispatch 프로그램 기반의 개발에서 기대할 부분이 있습니다. 하지만 신기술을 누리기 위해서, 자기 코드를 재작성할 개발자가 몇이나 되느냐가 큰 문제죠. OpenCL과 Grand Central Dispatch이 약속하는 바는 거대합니다. 하지만 당장 보면, 시연해 보인 프로그램 몇 가지가 있긴 했지만, '기능을 제대로 발휘할' 프로그램을 보장한 것은 아닙니다.

이론상의 개선을 바라고 3D 엔진을 누가 재작성 할까요? 이런 종류의 엔진은 간단한 C++ 코드로 해서 이미 수 년이 걸립니다. OpenCL처럼 다른 언어나 Grand Central Dispatch같은 개념을 집어 넣을 경우, 엄청난 시간이 필요하게 되죠.

OsiriX의 경우도, 최종적으로 성능 개선이 최소한 50%나 될지, 100%가 될지 전혀 확신하지 못합니다. 그럼 재작성까지 못하게 되죠. 일단 몇 달, 혹은 수 년 기다릴 것입니다. 다른 프로그램에서 이 기술이 실제로 어느 정도 개선을 보이는지 지켜봐야죠. 이런 종류의 거대한 투자를 하기에 제 시간이 너무나 제한적이라서요."

MacGeneration : 말씀으로 미루어보면, 완전히 재작성까지 해야 한다고 하시는데요. 상당히 버겁게 들립니다. 애플이 혹시 과정을 크게 단순화시키지 않았다는 말씀이신지요?

"애플의 말이 틀리지는 않습니다. 가령 OsiriX 코드 중에 60%는 인터페이스입니다. 이 비율은 바뀌지 않겠죠... 하지만 나머지 40%의 재작성이 정말 까다롭습니다. OpenCL로 보자면, 시연된 것은 사실 2D 회선(convolution) 그래픽과 푸리에(Fourrier) 전환, 프랙탈 연산과 같은 기본적인 것 뿐입니다. JPEG2000 라이브러리나 레이트레이싱 엔진같은 것을 시연했으면 훨씬 더 좋았겠죠.... 시연을 보면 Altivec이 좀 떠오르더군요. SIMD(Single Instruction Multiple Data) 개념도 꽤 비슷합니다... PowerPC와 Altivec 조합도 가끔 잘 작동하지 않았고, 애플 또한 실질적인 사례를 보여주지 않았죠. OpenCL로 보자면, (개발자들이 사용하기 쉬운) "하이레벨" 급 라이브러리가 있으면 싶습니다. 하지만 사양을 보면, "로 레벨"만 있죠... 모두를 만들어내야 한다는 의미입니다! 한 가지 눈에 띄는 점을 말씀드리자면요. OpenCL 기술은 GPU가 필요한 가속을 의미하기도 합니다만, nVidia와 ATI로부터 인텔이 통합 그래픽 프로세서로 가겠다는 표현이기도 할 겁니다. OpenCL의 수혜자가 인텔일까요? (주: 인텔도 OpenCL 지지 기업 중 하나이다.)

그 외에, 퀵타임 API가 100% 코코아/64비트가 된 것이 기쁩니다. 이 기술을 OsiriX에 사용하기가 대단히 간편해졌어요. 퀵타임 API는 그동안 정말 늙어졌거든요. (시스템 6.0 시절로 돌아갈 정도입니다.) 객체 지향적이지도 않았고, 멀티-쓰레딩과 호환성도 없었으며(즉, 같은 프로그램 상에서 두 개의 압축을 벌일 수 없었습니다), 64비트 애플리케이션과 호환성도 없었습니다. 그래서 OsiriX 드라이브도 32비트로 작성할 수밖에 없었죠. 프로그래밍이 어려워질뿐 아니라, 퍼포먼스에도 좋지 않습니다.

마지막으로, 적어도 2년 정도는 스노레퍼드 전용 OsiriX가 나오지는 않을 겁니다. 굉장히 많은 수가 10.5에 남아 있으리라 보기 때문이죠. 즉, 즉각적인 변화가 없으리라는 의미입니다. 그런 분들을 잃을 수는 없지요!"

Glen Aspeslagh : 오디오/비디오 유틸리티와 웹캠용 드라이버를 만드는 Ecamm의 저자

"스노레퍼드에서 우리 애플리케이션을 많이 최적화시키지는 않았습니다. 우리의 웹캠용 블루투쓰와 아이챗 간 호환성을 갖추려면 할 일이 굉장히 많다는 말씀이기도 하죠. 스노레퍼드의 64비트 프레임웍때문에 퀵타임의 옛날 코드를 굉장히 많이 못쓰게 되었으니까요. 하지만 스노레퍼드만으로도 성능 개선이 눈에 보이리라고 봅니다. 하지만 그 기반이 대단히 많이 바뀌었기 때문에, 애플리케이션이나 플러그인이 제대로 작동하지 않을 경우가 많을 테고요. 저는 다룰 준비가 되었습니다. 정말 필요한 부분이 그렇다면 실망스럽겠지만요. 그런 점들을 빼면, 사용자들도 충분히 만족하리라고 봅니다."

Mark Pearson : 그래픽용 소프트웨어인 Plasq의 저자

"스노레퍼드용으로 우리 애플리케이션이 제대로 돌아가는지를 확인하기 위해 특별히 다른 뭔가를 하지는 않았습니다. 예전 시스템과의 호환성을 유지하기 위해서였죠. 다음에 나올 제품에서는 스노레퍼드의 새로운 가능성을 활용할 수 있게 되기를 적극 기대합니다."

Cet article peut être consulté à cette adresse :
Snow Leopard : l'avis des développeurs

© 1999 - 2009 MacGeneration - L'essentiel du Mac en français.

casaubon · 2009-08-31, 02:03 AM

> Snow Leopard : l'avis des développeurs (suite)
Posté le 27.08.2009 à 10:08 par Florian Innocente

본 기사는 스노레퍼드에 대한 개발자 인터뷰이다. 주요 질문은 다음과 같다. 주요 질문은 다음과 같다. OpenCL과 Grand Central Dispatch, 64비트의 신기술을 사용할 것인지? 전편에서 보셨듯, 이 개념들로 인해 개발자들은 맥오에스텐의 엔진이 얼마나 바뀌는지, 얼마나 중요한지를 강조하고, 향후 투자에 대한 시각을 보여주었다. 지금으로써 이용자들 또한 맛배기만 보아도 만족해할 것이다.

Oliver Breidenbach : 오디오와 사진, 비디오를 제작하는 Boinx 대표

"전체적으로 이 기술들은 현대화의 기반을 제공합니다. 더 쉽게 애플리케이션을 만들 수 있게 해 주죠. 대단히 좋게 보고 있습니다. 29유로면 모두에게 있어서 좋은 가격이기도 합니다. Grand Central이 우리 프로그램의 프로세서 사용을 훨씬 효율적으로 배분시키겠죠. 64비트 또한 더 많은 메모리를 사용할 수 있게 해주고, OpenCL은 3D와 관련되지 않은 작업에 대해서도 그래픽카드 프로세서의 힘을 손쉽게 사용해줄 수 있게 해 줍니다.

"애플이 이런 기술을 사용한다는 점에 의미가 있습니다. OS 스스로가 훨씬 효율적으로 작동하니, 그만큼 남는 자원을 우리 애플리케이션에게도 더 돌릴 수 있다는 사실이죠. 이런 관점에서 볼 때, 우리 제품을 그리 많이 변화시킬 필요는 없습니다. 사용자 측면에서 보더라도, 우리 프로그램들이 훨씬 더 빠르게 작동해서 반응성이 좋아질 겁니다. 물론 속도가 빨라졌다는 인식은 그저 순간적으로 떴다가 사라지는 것에 대한 익숙함일 뿐이지만 말입니다."

William Shipley : Delicious Monster의 창립자이자 Omni Group의 공동-창립자

"스노레퍼드용으로 분명히 Delicious Library를 최적화시킬 겁니다. 개발자들 입장에서 스노레퍼드는 정말 멋진 부분이 많아요. 정말 개발자를 위한 OS입니다. 맥오에스텐의 근간을 세탁시키고 현대화시켰으니까요.

스노레퍼드는 모든 부분에서 Grand Central을 사용하기 때문에, 새로 개발을 하면 어떻게든 서비스받게 되어 있습니다. 일반적으로 본다면, 프로세서 속도가 그리 크게 빨라지지 않으리라는 점을 애플이 깨달은 것이죠. 주파수를 더 늘릴 때마다 발열량이 배로 늘어납니다. 따라서 더 이상의 진전이 매우 어려워요. 이 상황을 타개하기 위해 인텔과 다른 회사들은 칩 하나 안에다가 수 개의 프로세서를 집어넣기 시작했습니다. 요리사가 많은 주방을 생각해 보세요. 더 빠르게 일하도록 주문할 수 있겠죠.

하지만 주방의 비유로 다시 돌아간다면, 사람이 많아질 경우, 순서를 조절해야 합니다. 믹서가지고 싸우게 된다면, 다른 이들은 그냥 뒤에 물러나 앉아있겠죠. Grand Central은 이 경우, 모든 요리사들이 자기 할 일을 하게 만드는 역할입니다. 윈도나 리눅스 등의 다른 운영체제도 "다중 프로세스" 개념을 사용하기는 하지만, 다른 운영체제의 경우 개발자들이 일일이 다중 프로세스 사용을 집어넣어 줘야 해요. 따라서 "멀티쓰레드" 프로그램을 성공적으로 만들기란 정말, 정말 어렵습니다. (옴니웹 2.0의 경우 이 시스템을 활용하는 첫 프로그램 중 하나였습니다. 하지만 코드 작성하기가 정말 괴물같았답니다.)

Delicious Library 2를 예로 들자면, 이 경우에서도 저는 프로세스를 이미 배분시켜 놓았습니다. 웹캠으로 바코드를 스캔할 때, 별도의 프로세서가 코드 해석을 하는 식이죠. 저장한 다음 웹에 올려 놓으려 할 때에도 코드의 네트워크 부분이 동시에 두 번째 프로세서를 사용합니다.

Grand Central이 있으면 수고를 훨씬 덜 들이고도 더 많은 일을 할 수 있죠. 가령, 바코드 이미지를 웹캠으로 캡쳐할 때마다 하나의 프로세서가 모든 이미지를 다루게 하는 대신, 다른 프로세서에게 분석을 시킬 수 있죠. 여러 프로세서가 들어간 머신이라면, (사실 한 이미지의 분석시간이 특정 제한시간을 넘어서는 경우, 다른 이미지로 바로 넘어가는 식입니다만,) 초당 많은 이미지를 다룰 수 있게 될 겁니다.

윈도에 비해 대단히 좋은 기반을 갖게 됨을 의미하기도 합니다. 2코어에서 4, 8코어에서 16코어로 가는 경우, 스노레퍼드용 애플리케이션은 별다른 수정 없이도 점점 더 빨라질 겁니다. 그러나 윈도 개발자들은 소프트웨어를 돌리기 위해서만이라도 갈아엎어야 하겠지만요.

제 경우에 있어서 64비트는 대단히 큰 이득을 줍니다. 별다른 수고도 없이요. 64비트화가 정말 좋다는 얘기죠. 무엇보다도 64비트는 64비트용으로 재컴파일한 애플리케이션의 경우 약 15% 더 빠르게 해 줍니다. 프로세서로 얻어진 직접적인 개선이죠. 이틀 동안 Delicious Library 2를 64비트 포팅해 보았는데요. 아직은 테스트를 더 해야 합니다만, 포팅만으로도 15%의 놀라운 속도향상이 이루어졌습니다. 딱 이틀 일했는데 말이죠.

재밌는 부분은, 이런 속도개선이 다른 효과도 가져온다는 것이죠. 64비트로의 이주는 메모리 제약에서 벗어난다는 의미이기도 합니다. 32비트 프로그램의 경우, 애플리케이션이 사용할 수 있는 최대 "가상 메모리"는 4G입니다. 이론상의 수치죠. 개발자가 정말 심각한 노력을 하지 않을 경우, 4G가 넘어가는 파일을 작업할 수 없으리라는 의미입니다. 디스크 공간이나 RAM과 상관 없이 말이죠.

사실 실질적인 제한이 4G는 아닙니다. 시스템 프레임웍과 비디오 메모리가 사용하는 부분이 있죠. 32비트의 경우라면, 2.5G 정도밖에 사용할 수 없게 됩니다. (64비트의 경우 RAM과 가상메모리는 어느정도 무한대입니다.)

가령 3G가 넘어가는 이미지를 열거나 1G 짜리 이미지 세 개를 열기란 불가능합니다. (그래도 열려면 프로그램에 엄청난 코드 작업을 해 넣어야 합니다.) 이미지가 더 무거워질수록 더 안좋아지죠.

Delicious Library 2에서, 고해상도의 비쥬얼 이미지를 수 만 가지 다루는 사용자들도 있습니다. 이들의 라이브러리가 위의 제한에 따라 비율을 알아서 정하게 되지요. 하지만 스노레퍼드 최적화 버전에 있는 라이브러리라면, 한계는 디스크 공간 크기 뿐입니다.

똑같은 스타일로, 비록 RAM이 4G나 8G라 하더라도, 단일 프로그램이 32비트 상에서 2.5G 이상의 메로리를 사용할 수 없습니다. (32비트 어드레싱에 따라 메모리와 가상메모리가 한계를 갖기 때문입니다.) 따라서 맥에 8G의 RAM을 넣고는, 'Delicious Library의 내 라이브러리는 본좌급이지'라 말한다면 실망하실 겁니다. 하지만 64비트라면 정말 본좌가 될 수 있죠.

OpenCL은 제가 다루기에 더 어렵습니다. 저는 알지 못하는 새로운 언어이기 때문이죠. 즉, 이것을 활용하려면 재작성을 해야한다는 의미이기도 합니다. 하지만 메인 CPU보다 훨씬 속도가 더 빠르고 강력한 그래픽 프로세서를 끌어들였어요. 애플로서는 대단히 뛰어난 전략입니다. 일반적인 프로그램 사용도 상대적으로 쉽게 하고 싶어하니까요.

Delicious Library 2는 훨씬 더 민감한 바코드 스캐너 버전이 들어가게 될 겁니다. 그래픽 카드 프로세서로 돌아가기 때문입니다. 바코드를 더 정확하고 선명하게 분석할 수 있도록 각 이미지별 운용에 필요한 힘을 그래픽 카드 프로세서가 쓸 수 있죠."

MacGeneration : 그렇다면 혹시, 애플리케이션 최적화가 이뤄지기 전에는 이용자들 입장에서 좀 실망스러워하지는 않을까요?

"솔직히 말씀드리면, 이용자들 대다수는 스노레퍼드로부터 별다른 장점을 못느끼실 겁니다. 단기적으로 말이죠. 스노레퍼드는 핵심 수준을 다시 만든 OS이지, 인터페이스 변화나 새로운 기능을 많이 집어넣지는 않았으니 말입니다.

차가 오래되면 엔진을 새로 바꾸는 것과 마찬가지입니다. 성능도 더 좋아지게 되고, 엔지니어들이 나중에 다른 수정을 가할 때도 더 편리해지니까요. 지금으로서는 별다른 차이를 못느끼시겠지만, 앞으로 10년 후가 되면, 그 혜택은 이루 말할 수 없을 정도입니다.

다른 비유를 할 수도 있겠네요. 이번 버전은 전구에서 형광등, 형광 다이오드 램프로의 이주에 비견할 수 있겠습니다. 완전히 빛에 둘러싸일 수 있게 되죠. 단, 그 빛은 미래로 향하는 빛입니다. 매년 시간이 흐를 때마다, 이 변화에 대해 더 행복하게 느끼실 겁니다."

Cet article peut être consulté à cette adresse :
Snow Leopard : l'avis des développeurs (suite)

© 1999 - 2009 MacGeneration - L'essentiel du Mac en français.

jurtitia · 2009-08-31, 02:57 AM

당장 사용자의 입장에서도 RamDisk가 2.2GB의 한계를 벗어나 사용할 수 있다는데서 눈에 띄는 이점이 있네요..

Ram을 많이 꽂아도 제대로 활용하지 못했는데, 많은 Ram을 우선 Ramdisk로라도 활용할 수 있습니다.

항상 좋은 글을 소개하고, 번역해주시는 casaubon님꼐 감사드립니다.

firemanx · 2009-08-31, 09:37 PM

맥은 어플리케이션만 봐도 눈을 버려 버리는 듯 해요.
위에서 언급된 3가지의 어플리케이션을 보고나니 새로운 맥이 사고 싶어 집니다.

잙 읽었습니다.

lineroh · 2009-09-01, 01:05 AM

'푸리에 변환'을 '푸리에 전환'으로 번역하신걸 보니 까소봉님은 공대&이과대 전공자는 아니시군요 ㅎㅎㅎ

seungjin · 2009-09-01, 03:40 PM

개발자들이 느끼는건 대소동이 하지 않을까 합니다.
그리고 그러한 이유때문에, 전 스노우 레오파드로의 이주를 서두를 계획이 전혀 없고요. 25불의 가격에도 말입니다.
제가 제작하는 프로그램이 64비트로 진행되지 않는한 그리고 제가 쓰는 툴들이 앞으로 6개월간은 64비트에서 그렇게 퍼포먼스를 내지 않을것을 알기떄문에..

10.5.8이 10.6 보다 정신건강에 낳을거라고 믿습니다.
하지만 10.6.4쯤 지나서는, 고려를 해봐야 겠죠.

64비트쓰고 싶었으면 진즉에 리눅스로 갔겠지요. 하지만 리눅스 64비트를 두고 32비트 맥을 택하고 맥에서 작업하는건 편할려고였습니다. 모 설치해서 잘 안되서 검색했더니 64비트 32비트간의 호환문제라면 맥빠지죠.

스노우 레오파드가 발매된날 10.5.8로 업그래이드 했습니다. 이전까진 10.5.6이던가였더군요. ^^
빠르다고 모든게 능사는 아닌 삶을 지향해봅니다.

2009-08-31, 02:02 AM	#1
casaubon Moderator Registered: Sep 2001 My Mac: iMac 24" 3.06GHz Posts: 2,399 온라인	Snow Leopard, 개발자들의 생각 1 > Snow Leopard : l'avis des développeurs Posté le 24.08.2009 à 17:59 par Florian Innocente 맥오에스텐 스노레퍼드가 나왔다. 스노레퍼드는 일단 개발자들이 주고객이 될만한 기술이 여러가지 들어가 있지만, 우리들 일반 사용자에게도 상당히 좋을 기능들이 많으리라 기대하고 있다. 3D 프레임웍 계산에 쓰이는 그래픽 프로세서를 사용하게 될 OpenCL서부터, 메모리를 더 많이, 더 빠르게 이용하게 될 64 비트, 컴퓨터 프로세서 코어 간에 태스크 배치를 단순화시키게 될 Grand Central Dispatch에 이르기까지 매우 다양하다. 스노레퍼드가 최종화된 지금, 본지는 간단한 질문 두 가지를 여러 개발자들에게 물어 보았다. 위 기술을 사용할 것인지, 그것이 사용자들에게 어떤 이득이 있는지이다. 최근 컨퍼런스에서 애플은 성능 시연을 해보인 바 있다. 이 기술을 사용한 iMovie나 Aperture에서 스톱워치라도 내세울까 기대했는데, 전혀 그렇지 않았다. Mail이나 Safari가 얼마나 빨라졌는지 정도에 대한 통계만 나왔을 뿐이다. 시스템 전반적으로, 그리고 애플리케이션 속도에 어느 정도 개선이 있으리라는 약속은 나왔다. 그러한 개선으로 최종 시스템이 더 좋아지리라는 것이었다. 개발자들의 답변을 읽어보면, 애플이 스노레퍼드에 대단히 괄목할 만한 기능을 효과적으로 집어 넣었다는 인상을 받는다. 하지만 그 구현이 그리 간단해보이지는 않다. 시간과 노력이 필요하리라는 의미다. PowerPC에서 G4 AltiVec으로, 맥오에스텐으로, 그리고 인텔 칩으로의 이주할 때와 같다... 새로운 이주의 시기가 열렸다. 수 주일 뒤면 각종 이 기술을 사용할 프리웨어와 셰어웨어가 나올 것이다. 제목만 바뀔 경우도 있을 것이며, 정말 속도가 빨라지거나, 손쉽게 수정을 가하여 동 기술을 사용할 프로그램도 있을 것이다. 하지만 대규모 애플리케이션에 대해서는 의문이 남는다. OpenCL과 그 외 기술은 맥오에스텐을 윈도보다 훨씬 돋보이게 만들어주지만, 애플용과 마이크로소프트용을 동시에 내놓는 어도비가 두 OS용으로 계속 솔루션을 과연 선보일까? 과연, 64-비트로 이주할 수밖에 없을 두 OS용으로 동시에 튜닝을 할 이유가 있을까? 쿼크나 마이크로소프트에게도 마찬가지이다. 설사 마이크로소프트의 맥 사업부가 맥에 고유한 기술을 사용할 만한 곳이더라도 말이다. 그런데 이런 대규모 개발사들만이 아니다. 구체적으로 선도를 해야 할 곳은 애플이다. 애플 또한 스노레퍼드의 덕을 볼 수 있는 오디오와 비디오용 소프트웨어를 많이 내고 있다. 그런데 iLife나 Aperture, Fical Cut Studio의 메이저 업데이트를 낼 때까지 좀 기다려야 할까? 스노레퍼드의 가격을 감안할 때, "스노레퍼드 최적화" 마크가 있는 애플리케이션 가격을 올릴 동기도 상당하다고 봐야 할 것이다. 물론 우리야 더 저렴해질 시나리오를 기대하고 있다. 일단 기술활용 정도로 그칠 소소한 업데이트가 곧 나오기를, 그리고 2010년께에 메이저 업데이트가 이뤄지기를 말이다. INTERVIEW Matthieu Kopp : Aquafadas의 공동창립자. 전문가용과 일반인용 오디오/비디오 솔루션 제작업체 "스노레퍼드는 OpenCL과 Grand Central Dispatch라는 주목할 만한 기술이 들어가 있습니다. 즉, Quartz Composer에 신기능이 대단히 많이 들어갔다는 얘기죠. 개발 측면에서 보자면 스노레퍼드는 완전히 새로운 유틸리티를 갖고 있어요. 대단히 기쁜 일입니다. 개인적으로 성능 개선만 보자면 좀 그렇습니다. 특정 기능에서는 정말 개선이 있습니다. 하지만 우리 코드에 적용시키려면 상당한 시간을 투자해야 하지요. 퀵타임 로레벨과 같은 작업에 이미 많은 시간을 투자했다면, 어려운 결정입니다. 64비트의 장벽을 넘나드는 것이 아니기때문에 검토가 더 필요합니다. Grand Central Dispatch도 마찬가지에요. 재컴파일만으로 눈에 보이는 개선이 있긴 합니다. 하지만 더 좋게 만들려면, 코드를 샅샅이 뒤져서, 잘 정리해 두어야 하죠. 이런 이주가 원래 그렇습니다. 예전 시스템을 조절해야 하죠. 스노레퍼드 전용 프로그램으로 할까요, 아니면 레퍼드 호환으로 해야 할까요? 업데이트 비용이 매우 낮은 것은 사실입니다만, 우리 애플리케이션 대부분은 타이거 호환이기도 합니다. 그래도 Grand Central Dispatch와 같은 특정 기술 통합을 위한 검토작업을 할 계획입니다. OpenCL이 정말 흥미로운 기술이죠. 그동안 작업해온 기술이기도 합니다. 하지만 문제가 있어요. 몇몇 머신에서는 안돌아가는 문제죠. 성능 개선도 눈에 크게 띄지는 않습니다. 특정 그래픽 카드에 의존하니까요. 꽤 최근에 나온 아이맥 24인치도 크게 개선이 안보일 정도입니다. 하지만 우리 고객은 주로 전문 사용가들, 특히 미들타워(코어 두 개와 엔트리급 그래픽카드) 맥 사용자들입니다. 이들마저도 이 기술을 활용할 수 없죠.() 결론은 이렇습니다. 조급하게 하지 말자. 하지만 이 기술을 테스트하자, 입니다." () OpenCL 최소사양은 다음과 같다. : NVIDIA GeForce 8600M GT, 8800 GT, 8800 GTS, 9400M, 9600M GT, GT 120, GT 130. ATI Radeon 4850과 4870. Nick Fletcher : 웹사이트 저작용 프로그램과 이미지 관련 프로그램을 만드는 Realmac Software의 저자 "스노레퍼드가 나왔으니 RapidWeaver와 LittleSnapper 업데이트도 곧 나오게 될 겁니다. 스노레퍼드에 잘 작동해야 할 뿐더러 고유 기능도 활용해야 하죠. LittleSnapper의 64비트 컴파일은 해 놓았는데요. Rapidweaver 4.3은 하지 않았습니다. 아직 때가 안되어서 그런 건데요. 우리가 사용하려는 스노레퍼드의 여러 가지 기술과는 달리, LittleSnapper 1.5.1의 경우는 10.6에 있는 Xcode 버전을 사용하여 컴파일만 다시 해도, 괄목할만한 성능 개선이 있었습니다. 앞으로도 흥미로운 점이 대단히 많이 있습니다. 당장 발표해드릴 것은 없습니다만, 개발자는 물론 사용자 관점에서 봐도 그렇습니다." Antoine Rosset : 의학 이미지용 프로그램인 OsiriX의 저자. "스노레퍼드는 사용자 측면에서도 상당히 흥미롭게 개선이 됐습니다. 당장 보면 OS의 여러 부분과 프로그램들이 64비트로 이주를 단행하였죠. 단기간에 말입니다. 특정 기능에 따라서 성능 개선이 30%까지 올라갈 수 있습니다. 장기적으로는(수 년 걸리겠죠?), OpenCL과 Grand Central Dispatch 프로그램 기반의 개발에서 기대할 부분이 있습니다. 하지만 신기술을 누리기 위해서, 자기 코드를 재작성할 개발자가 몇이나 되느냐가 큰 문제죠. OpenCL과 Grand Central Dispatch이 약속하는 바는 거대합니다. 하지만 당장 보면, 시연해 보인 프로그램 몇 가지가 있긴 했지만, '기능을 제대로 발휘할' 프로그램을 보장한 것은 아닙니다. 이론상의 개선을 바라고 3D 엔진을 누가 재작성 할까요? 이런 종류의 엔진은 간단한 C++ 코드로 해서 이미 수 년이 걸립니다. OpenCL처럼 다른 언어나 Grand Central Dispatch같은 개념을 집어 넣을 경우, 엄청난 시간이 필요하게 되죠. OsiriX의 경우도, 최종적으로 성능 개선이 최소한 50%나 될지, 100%가 될지 전혀 확신하지 못합니다. 그럼 재작성까지 못하게 되죠. 일단 몇 달, 혹은 수 년 기다릴 것입니다. 다른 프로그램에서 이 기술이 실제로 어느 정도 개선을 보이는지 지켜봐야죠. 이런 종류의 거대한 투자를 하기에 제 시간이 너무나 제한적이라서요." MacGeneration : 말씀으로 미루어보면, 완전히 재작성까지 해야 한다고 하시는데요. 상당히 버겁게 들립니다. 애플이 혹시 과정을 크게 단순화시키지 않았다는 말씀이신지요? "애플의 말이 틀리지는 않습니다. 가령 OsiriX 코드 중에 60%는 인터페이스입니다. 이 비율은 바뀌지 않겠죠... 하지만 나머지 40%의 재작성이 정말 까다롭습니다. OpenCL로 보자면, 시연된 것은 사실 2D 회선(convolution) 그래픽과 푸리에(Fourrier) 전환, 프랙탈 연산과 같은 기본적인 것 뿐입니다. JPEG2000 라이브러리나 레이트레이싱 엔진같은 것을 시연했으면 훨씬 더 좋았겠죠.... 시연을 보면 Altivec이 좀 떠오르더군요. SIMD(Single Instruction Multiple Data) 개념도 꽤 비슷합니다... PowerPC와 Altivec 조합도 가끔 잘 작동하지 않았고, 애플 또한 실질적인 사례를 보여주지 않았죠. OpenCL로 보자면, (개발자들이 사용하기 쉬운) "하이레벨" 급 라이브러리가 있으면 싶습니다. 하지만 사양을 보면, "로 레벨"만 있죠... 모두를 만들어내야 한다는 의미입니다! 한 가지 눈에 띄는 점을 말씀드리자면요. OpenCL 기술은 GPU가 필요한 가속을 의미하기도 합니다만, nVidia와 ATI로부터 인텔이 통합 그래픽 프로세서로 가겠다는 표현이기도 할 겁니다. OpenCL의 수혜자가 인텔일까요? (주: 인텔도 OpenCL 지지 기업 중 하나이다.) 그 외에, 퀵타임 API가 100% 코코아/64비트가 된 것이 기쁩니다. 이 기술을 OsiriX에 사용하기가 대단히 간편해졌어요. 퀵타임 API는 그동안 정말 늙어졌거든요. (시스템 6.0 시절로 돌아갈 정도입니다.) 객체 지향적이지도 않았고, 멀티-쓰레딩과 호환성도 없었으며(즉, 같은 프로그램 상에서 두 개의 압축을 벌일 수 없었습니다), 64비트 애플리케이션과 호환성도 없었습니다. 그래서 OsiriX 드라이브도 32비트로 작성할 수밖에 없었죠. 프로그래밍이 어려워질뿐 아니라, 퍼포먼스에도 좋지 않습니다. 마지막으로, 적어도 2년 정도는 스노레퍼드 전용 OsiriX가 나오지는 않을 겁니다. 굉장히 많은 수가 10.5에 남아 있으리라 보기 때문이죠. 즉, 즉각적인 변화가 없으리라는 의미입니다. 그런 분들을 잃을 수는 없지요!" Glen Aspeslagh : 오디오/비디오 유틸리티와 웹캠용 드라이버를 만드는 Ecamm의 저자 "스노레퍼드에서 우리 애플리케이션을 많이 최적화시키지는 않았습니다. 우리의 웹캠용 블루투쓰와 아이챗 간 호환성을 갖추려면 할 일이 굉장히 많다는 말씀이기도 하죠. 스노레퍼드의 64비트 프레임웍때문에 퀵타임의 옛날 코드를 굉장히 많이 못쓰게 되었으니까요. 하지만 스노레퍼드만으로도 성능 개선이 눈에 보이리라고 봅니다. 하지만 그 기반이 대단히 많이 바뀌었기 때문에, 애플리케이션이나 플러그인이 제대로 작동하지 않을 경우가 많을 테고요. 저는 다룰 준비가 되었습니다. 정말 필요한 부분이 그렇다면 실망스럽겠지만요. 그런 점들을 빼면, 사용자들도 충분히 만족하리라고 봅니다." Mark Pearson : 그래픽용 소프트웨어인 Plasq의 저자 "스노레퍼드용으로 우리 애플리케이션이 제대로 돌아가는지를 확인하기 위해 특별히 다른 뭔가를 하지는 않았습니다. 예전 시스템과의 호환성을 유지하기 위해서였죠. 다음에 나올 제품에서는 스노레퍼드의 새로운 가능성을 활용할 수 있게 되기를 적극 기대합니다." Cet article peut être consulté à cette adresse : Snow Leopard : l'avis des développeurs © 1999 - 2009 MacGeneration - L'essentiel du Mac en français. __________________

2009-08-31, 02:03 AM	#2
casaubon Moderator Registered: Sep 2001 My Mac: iMac 24" 3.06GHz Posts: 2,399 온라인	Snow Leopard, 개발자들의 생각 2 > Snow Leopard : l'avis des développeurs (suite) Posté le 27.08.2009 à 10:08 par Florian Innocente 본 기사는 스노레퍼드에 대한 개발자 인터뷰이다. 주요 질문은 다음과 같다. 주요 질문은 다음과 같다. OpenCL과 Grand Central Dispatch, 64비트의 신기술을 사용할 것인지? 전편에서 보셨듯, 이 개념들로 인해 개발자들은 맥오에스텐의 엔진이 얼마나 바뀌는지, 얼마나 중요한지를 강조하고, 향후 투자에 대한 시각을 보여주었다. 지금으로써 이용자들 또한 맛배기만 보아도 만족해할 것이다. Oliver Breidenbach : 오디오와 사진, 비디오를 제작하는 Boinx 대표 "전체적으로 이 기술들은 현대화의 기반을 제공합니다. 더 쉽게 애플리케이션을 만들 수 있게 해 주죠. 대단히 좋게 보고 있습니다. 29유로면 모두에게 있어서 좋은 가격이기도 합니다. Grand Central이 우리 프로그램의 프로세서 사용을 훨씬 효율적으로 배분시키겠죠. 64비트 또한 더 많은 메모리를 사용할 수 있게 해주고, OpenCL은 3D와 관련되지 않은 작업에 대해서도 그래픽카드 프로세서의 힘을 손쉽게 사용해줄 수 있게 해 줍니다. "애플이 이런 기술을 사용한다는 점에 의미가 있습니다. OS 스스로가 훨씬 효율적으로 작동하니, 그만큼 남는 자원을 우리 애플리케이션에게도 더 돌릴 수 있다는 사실이죠. 이런 관점에서 볼 때, 우리 제품을 그리 많이 변화시킬 필요는 없습니다. 사용자 측면에서 보더라도, 우리 프로그램들이 훨씬 더 빠르게 작동해서 반응성이 좋아질 겁니다. 물론 속도가 빨라졌다는 인식은 그저 순간적으로 떴다가 사라지는 것에 대한 익숙함일 뿐이지만 말입니다." William Shipley : Delicious Monster의 창립자이자 Omni Group의 공동-창립자 "스노레퍼드용으로 분명히 Delicious Library를 최적화시킬 겁니다. 개발자들 입장에서 스노레퍼드는 정말 멋진 부분이 많아요. 정말 개발자를 위한 OS입니다. 맥오에스텐의 근간을 세탁시키고 현대화시켰으니까요. 스노레퍼드는 모든 부분에서 Grand Central을 사용하기 때문에, 새로 개발을 하면 어떻게든 서비스받게 되어 있습니다. 일반적으로 본다면, 프로세서 속도가 그리 크게 빨라지지 않으리라는 점을 애플이 깨달은 것이죠. 주파수를 더 늘릴 때마다 발열량이 배로 늘어납니다. 따라서 더 이상의 진전이 매우 어려워요. 이 상황을 타개하기 위해 인텔과 다른 회사들은 칩 하나 안에다가 수 개의 프로세서를 집어넣기 시작했습니다. 요리사가 많은 주방을 생각해 보세요. 더 빠르게 일하도록 주문할 수 있겠죠. 하지만 주방의 비유로 다시 돌아간다면, 사람이 많아질 경우, 순서를 조절해야 합니다. 믹서가지고 싸우게 된다면, 다른 이들은 그냥 뒤에 물러나 앉아있겠죠. Grand Central은 이 경우, 모든 요리사들이 자기 할 일을 하게 만드는 역할입니다. 윈도나 리눅스 등의 다른 운영체제도 "다중 프로세스" 개념을 사용하기는 하지만, 다른 운영체제의 경우 개발자들이 일일이 다중 프로세스 사용을 집어넣어 줘야 해요. 따라서 "멀티쓰레드" 프로그램을 성공적으로 만들기란 정말, 정말 어렵습니다. (옴니웹 2.0의 경우 이 시스템을 활용하는 첫 프로그램 중 하나였습니다. 하지만 코드 작성하기가 정말 괴물같았답니다.) Delicious Library 2를 예로 들자면, 이 경우에서도 저는 프로세스를 이미 배분시켜 놓았습니다. 웹캠으로 바코드를 스캔할 때, 별도의 프로세서가 코드 해석을 하는 식이죠. 저장한 다음 웹에 올려 놓으려 할 때에도 코드의 네트워크 부분이 동시에 두 번째 프로세서를 사용합니다. Grand Central이 있으면 수고를 훨씬 덜 들이고도 더 많은 일을 할 수 있죠. 가령, 바코드 이미지를 웹캠으로 캡쳐할 때마다 하나의 프로세서가 모든 이미지를 다루게 하는 대신, 다른 프로세서에게 분석을 시킬 수 있죠. 여러 프로세서가 들어간 머신이라면, (사실 한 이미지의 분석시간이 특정 제한시간을 넘어서는 경우, 다른 이미지로 바로 넘어가는 식입니다만,) 초당 많은 이미지를 다룰 수 있게 될 겁니다. 윈도에 비해 대단히 좋은 기반을 갖게 됨을 의미하기도 합니다. 2코어에서 4, 8코어에서 16코어로 가는 경우, 스노레퍼드용 애플리케이션은 별다른 수정 없이도 점점 더 빨라질 겁니다. 그러나 윈도 개발자들은 소프트웨어를 돌리기 위해서만이라도 갈아엎어야 하겠지만요. 제 경우에 있어서 64비트는 대단히 큰 이득을 줍니다. 별다른 수고도 없이요. 64비트화가 정말 좋다는 얘기죠. 무엇보다도 64비트는 64비트용으로 재컴파일한 애플리케이션의 경우 약 15% 더 빠르게 해 줍니다. 프로세서로 얻어진 직접적인 개선이죠. 이틀 동안 Delicious Library 2를 64비트 포팅해 보았는데요. 아직은 테스트를 더 해야 합니다만, 포팅만으로도 15%의 놀라운 속도향상이 이루어졌습니다. 딱 이틀 일했는데 말이죠. 재밌는 부분은, 이런 속도개선이 다른 효과도 가져온다는 것이죠. 64비트로의 이주는 메모리 제약에서 벗어난다는 의미이기도 합니다. 32비트 프로그램의 경우, 애플리케이션이 사용할 수 있는 최대 "가상 메모리"는 4G입니다. 이론상의 수치죠. 개발자가 정말 심각한 노력을 하지 않을 경우, 4G가 넘어가는 파일을 작업할 수 없으리라는 의미입니다. 디스크 공간이나 RAM과 상관 없이 말이죠. 사실 실질적인 제한이 4G는 아닙니다. 시스템 프레임웍과 비디오 메모리가 사용하는 부분이 있죠. 32비트의 경우라면, 2.5G 정도밖에 사용할 수 없게 됩니다. (64비트의 경우 RAM과 가상메모리는 어느정도 무한대입니다.) 가령 3G가 넘어가는 이미지를 열거나 1G 짜리 이미지 세 개를 열기란 불가능합니다. (그래도 열려면 프로그램에 엄청난 코드 작업을 해 넣어야 합니다.) 이미지가 더 무거워질수록 더 안좋아지죠. Delicious Library 2에서, 고해상도의 비쥬얼 이미지를 수 만 가지 다루는 사용자들도 있습니다. 이들의 라이브러리가 위의 제한에 따라 비율을 알아서 정하게 되지요. 하지만 스노레퍼드 최적화 버전에 있는 라이브러리라면, 한계는 디스크 공간 크기 뿐입니다. 똑같은 스타일로, 비록 RAM이 4G나 8G라 하더라도, 단일 프로그램이 32비트 상에서 2.5G 이상의 메로리를 사용할 수 없습니다. (32비트 어드레싱에 따라 메모리와 가상메모리가 한계를 갖기 때문입니다.) 따라서 맥에 8G의 RAM을 넣고는, 'Delicious Library의 내 라이브러리는 본좌급이지'라 말한다면 실망하실 겁니다. 하지만 64비트라면 정말 본좌가 될 수 있죠. OpenCL은 제가 다루기에 더 어렵습니다. 저는 알지 못하는 새로운 언어이기 때문이죠. 즉, 이것을 활용하려면 재작성을 해야한다는 의미이기도 합니다. 하지만 메인 CPU보다 훨씬 속도가 더 빠르고 강력한 그래픽 프로세서를 끌어들였어요. 애플로서는 대단히 뛰어난 전략입니다. 일반적인 프로그램 사용도 상대적으로 쉽게 하고 싶어하니까요. Delicious Library 2는 훨씬 더 민감한 바코드 스캐너 버전이 들어가게 될 겁니다. 그래픽 카드 프로세서로 돌아가기 때문입니다. 바코드를 더 정확하고 선명하게 분석할 수 있도록 각 이미지별 운용에 필요한 힘을 그래픽 카드 프로세서가 쓸 수 있죠." MacGeneration : 그렇다면 혹시, 애플리케이션 최적화가 이뤄지기 전에는 이용자들 입장에서 좀 실망스러워하지는 않을까요? "솔직히 말씀드리면, 이용자들 대다수는 스노레퍼드로부터 별다른 장점을 못느끼실 겁니다. 단기적으로 말이죠. 스노레퍼드는 핵심 수준을 다시 만든 OS이지, 인터페이스 변화나 새로운 기능을 많이 집어넣지는 않았으니 말입니다. 차가 오래되면 엔진을 새로 바꾸는 것과 마찬가지입니다. 성능도 더 좋아지게 되고, 엔지니어들이 나중에 다른 수정을 가할 때도 더 편리해지니까요. 지금으로서는 별다른 차이를 못느끼시겠지만, 앞으로 10년 후가 되면, 그 혜택은 이루 말할 수 없을 정도입니다. 다른 비유를 할 수도 있겠네요. 이번 버전은 전구에서 형광등, 형광 다이오드 램프로의 이주에 비견할 수 있겠습니다. 완전히 빛에 둘러싸일 수 있게 되죠. 단, 그 빛은 미래로 향하는 빛입니다. 매년 시간이 흐를 때마다, 이 변화에 대해 더 행복하게 느끼실 겁니다." Cet article peut être consulté à cette adresse : Snow Leopard : l'avis des développeurs (suite) © 1999 - 2009 MacGeneration - L'essentiel du Mac en français. __________________

2009-08-31, 02:57 AM	#3
jurtitia Senior Member Registered: Sep 2007 My Mac: MacPro(1.1),MBP15.4(5.3) Posts: 353 오프라인	당장 사용자의 입장에서도 RamDisk가 2.2GB의 한계를 벗어나 사용할 수 있다는데서 눈에 띄는 이점이 있네요.. Ram을 많이 꽂아도 제대로 활용하지 못했는데, 많은 Ram을 우선 Ramdisk로라도 활용할 수 있습니다. 항상 좋은 글을 소개하고, 번역해주시는 casaubon님꼐 감사드립니다. __________________ 수집이 취미는 아닙니다만, 자꾸 바꾸게 되네요.. iPhone 3GS(32GB, White) MacPro2006(1.1) ; 2.66X2,13GB, Vertex 120GB+30"Cinema MBP2009 15.4"(5.3) ; C2D 3.06, 8GB, SSD256 MacMini2008(wife) ; C2D,4GB Nano 8GB 내보낸 것들 MBP17(2006early), MBA 2008(1G: C2D,2GB),MBP2008 15.4"(C2D,4GB), ,iPod Touch 32G, Touch 16G,

2009-08-31, 09:37 PM	#4
firemanx Veteran Member Registered: Feb 2006 My Mac: iMac Intel Core Duo 20", MacBook 2.0 White, iPod Video 30G Posts: 801 오프라인	맥은 어플리케이션만 봐도 눈을 버려 버리는 듯 해요. 위에서 언급된 3가지의 어플리케이션을 보고나니 새로운 맥이 사고 싶어 집니다. 잙 읽었습니다. __________________ 맥도리의 블로그 : http://macdory.blogspot.com

2009-09-01, 01:05 AM	#5
lineroh Senior Member Registered: May 2007 My Mac: 맥북 Posts: 312 오프라인	'푸리에 변환'을 '푸리에 전환'으로 번역하신걸 보니 까소봉님은 공대&이과대 전공자는 아니시군요 ㅎㅎㅎ __________________ iPod touch 호모 파베르에게 이제야 쓸만한 도구가 쥐어졌어요.

2009-09-01, 03:40 PM	#6
seungjin Elite Member Registered: Oct 2003 My Mac: MacBook Pro (15-inch Early 2008), iMac (20-inch Mid 2007), iPhone 3GS, iPod Shuffle (2nd generation), Airport Express Posts: 1,171 오프라인	개발자들이 느끼는건 대소동이 하지 않을까 합니다. 그리고 그러한 이유때문에, 전 스노우 레오파드로의 이주를 서두를 계획이 전혀 없고요. 25불의 가격에도 말입니다. 제가 제작하는 프로그램이 64비트로 진행되지 않는한 그리고 제가 쓰는 툴들이 앞으로 6개월간은 64비트에서 그렇게 퍼포먼스를 내지 않을것을 알기떄문에.. 10.5.8이 10.6 보다 정신건강에 낳을거라고 믿습니다. 하지만 10.6.4쯤 지나서는, 고려를 해봐야 겠죠. 64비트쓰고 싶었으면 진즉에 리눅스로 갔겠지요. 하지만 리눅스 64비트를 두고 32비트 맥을 택하고 맥에서 작업하는건 편할려고였습니다. 모 설치해서 잘 안되서 검색했더니 64비트 32비트간의 호환문제라면 맥빠지죠. 스노우 레오파드가 발매된날 10.5.8로 업그래이드 했습니다. 이전까진 10.5.6이던가였더군요. ^^ 빠르다고 모든게 능사는 아닌 삶을 지향해봅니다.

글타래 옵션
프린트 메일