SF / 과학 포럼
SF 작품의 가능성은 어떻게 펼쳐질 수 있을까요? 그리고 어떤 상상의 이야기가 가능할까요?
SF에 대한 가벼운 흥미거리에서부터 새로운 창작을 위한 아이디어에 이르기까지...
여기는 과학 소식이나 정보를 소개하고, SF 속의 아이디어나 이론에 대한 의견을 나누며, 상상의 꿈을 키워나가는 곳입니다.
( 이 게시판은 최근에 의견이나 덧글이 추가된 순서대로 정렬됩니다. )
기사 링크(영문):
http://phys.org/news/2015-07-code-faster-expert.html
MIT 컴퓨터과학자들과 Adobe 엔지니어들이 대다수의 회사들이 겪는 문제인 비트-썩음(bit-rot -_-)을 해결하기 위해 뭉쳤다.
Adobe의 성공작이자 벌써 25주년을 맞은 포토샵 에디터가 바로 비트-썩음의 좋은 예이다.
지난 세월동안 포토샵은 특정 하드웨어에 대해 최적화를 하기 위해서 엄청난 양의 코드 수정을 했는데,
문제는 그 하드웨어가 지금은 낡았다는 점이다.
MIT 교수이자 컴퓨터과학인공지능연구소(CSAIL)에서 연구자로 일하고 있는 사만 아마라싱은
''이미지 처리에 쓰이는 고성능 코드를 얻으려면 소프트웨어를 엄청나게 최적화해야 합니다''라고 말한다.
''문제는 최적화를 하면 할수록 코드가 점점 덜 효율적으로 되고 점점 더 이해하기 어려운 것이 된다는 점이지요''
그 결과는 사만 아마라싱의 표현대로 ''수십 억 달러짜리 문제'이다.
Adobe와 같은 회사들은 몇 년에 한 번씩 코드를 검토하기 위해 엄청난 인력을 투입해야 하며,
해당 프로그램을 어떻게 패치해야 할지 다양한 전략을 짠 다음 일일히 수작업으로 테스트를 해봐야 한다.
하지만 자동으로 오래된 코드를 수정하는 컴퓨터 프로그램이 있어서 엔지니어들이
좀 더 생산적인 일(새 프로그램의 개발)에 전념할 수 있다면 어떨까?
상기 연구팀이 개발한 Helium은 몇 시간 또는 몇 분만에 원래 소스를 볼 필요도 없이 코드를 최적화시켜준다.
상기 연구팀은 프로그램을 구성하는 가장 기본 요소이면서도 분석하기가 어려운, 디버그 기호를 제거한
이진법 코드로부터 시작했다. 이 이진법 코드는 포토샵과 같은 사유(특허) 소프트웨어에 대해 얻을 수 있는
이진법 코드들 중 극히 일부분에 지나지 않는다.
포토샵과 같은 소프트웨어에서 자주 쓰이는 커널들 중에는 '스텐실 커널'이 있다.
스텐실 커널은 사용자로 하여금 픽셀 면적 전체에 대해 작업을 할 수 있도록 도와준다.
스텐실 커널은 소프트웨어를 업데이트할 때 특히 중요한 부분인데, 왜냐하면 스텐실 커널은
엄청난 양의 메모리와 계산능력을 소요하며, 새로운 하드웨어가 등장할 때마다 스텐실 커널의 성능은
빠르게 감소하기 때문이다.
연구진은 Helium을 사용하여 이 커널들을 이진법 코드로부터 끄집어 낸(lift) 다음,
CSAIL에서 만든 이미지 처리용 프로그래밍 언어 Halide로 읽을 수 있는 고급 언어로 변환하는데 성공했다.
연구책임자 채리스 멘디스의 말에 따르면, 이진법 코드에서 고급 언어로의 변환은 연구진이 생각지도 못한 성과였다.
"최적화된 이진법 코드는 실행절차가 매우 복잡하기 때문에 고급 언어로 만들기가 아주 까다롭습니다''라고
채리스 맨디스가 말했다. ''하지만 스텐실 커널의 경우 똑같은 계산을 계속해서 반복하기 때문에,
원래의 알고리즘을 복원하는데 충분한 데이터를 얻을 수 있었습니다''
이진법 코드를 고급 언어로 변환하고 나면, Helium은 이 고급 언어를 가지고 원래의 비트-썩은 부분을 재최적화된 부분으로
대체한다. 실험을 해본 결과 Helium은 특정 포토샵 필터의 성능을 75% 개선하였으며,
최적화가 덜 된 Microsoft Windows의 IrfanView 경우 그 성능을 400 ~ 500% 개선하였다.
''우리는 Helium이 인간 엔지니어들이라면 3달 걸렸을 업데이트를 하루만에 끝낼 수 있음을 발견했습니다.''라고
아마라싱이 말했다. ''Helium과 같은 시스템은 회사로 하여금 새로운 코드가 예전의 코드보다 빠르게 실행될지를
확인하는데 도움을 주며, 수 백명의 사람들이 이런 문제에 매달리는 일을 피할 수 있습니다.
유타대학의 컴퓨팅학과 교수인 메리 홀은 ''우리는 컴퓨터 아키텍처가 빠르게 변화하는 시대에 살고 있으며,
따라서 코드가 다양한 플랫폼에서 작동되도록 만드는 것이 중요합니다.
Helium은 스텐실 커널의 계산절차를 고급 표현으로 바꾸어 미래의 컴퓨터 아키텍처에서 쉽게 작동하도록 만들 수 있는
흥미로운 접근방식이라고 할 수 있습니다''
해당 실험을 수행하는 과정에서 예상치 못한 수확은, 프로그래머들이 오래된 코드를 최적화할 때 사용하는
다양한 트릭(trick)들을 연구자들이 알 수 있었다는 점이다. 이는 마치 고고학자들이 화석을 발굴하는 것과 유사하다.
''저희는 프로그래머들이 소프트웨어를 최적화하기 위해 어떤 트릭을 썼는지 알 수 있었습니다.''라고 아마라싱이 말했다.
''그와 동시에 프로그래머들이 다양한 코딩 문제를 해결하기 위해 어떤 접근방법을 쓰는지 더 잘 이해할 수 있었지요''.
...
네줄요약:
1) 이진법 코드를 구한다.
2) 이진법 코드를 Helium 시스템에 넣는다.
3) Helium 시스템이 이진법 코드를 가지고 고급 언어로 바꾼다.
4) Helium 시스템이 고급 언어에서 최적화가 안 된 부분을 최적화가 된 부분으로 대체한다.
저는 "최적화"와 "효율적"이라는 게 관점에 따라 방향이 전혀 다르다는 게 눈에 밟히네요.
"속도"가 빠른 결과를 내는 게 최적화라면, 프로그래밍은 통으로 함수 없이 짜는 게 최적입니다.
처리속도를 빠르게 하는 관점으로 최적화를 할 수도 있는 것이죠.
하지만 이렇게 하면 반복적으로 재사용하는 구문이 있을 때 불편하므로,
함수를 만들어서 호출해서 불러오는 게 최적화일 수도 있습니다.
- 프로그래밍하는 사람이 스스로 자신의 공수를 덜어내는 것이죠.
이건 벌써 다른 관점의 최적화입니다. 일 하는 사람의 효율성을 우선시 한 겁니다.
당연히 처리속도 관점에서는 약간의 손해를 야기할 수도 있는 겁니다.
이게 극단으로 가면, 일하는 사람의 이해를 돕는 방향으로 프로그래밍하는 겁니다.
쉽게 이해할 수 있는 구문, 정형화되어 금새 파악할 수 있도록 짜는 것이죠.
그리고 재활용성을 극도로 높이고, 모든 것을 객체화하여 조립할 수 있게 합니다.
이런 방향의 최적화도 있을 수 있는 것이죠. 당연히 처리 속도면에서는 손해가 발생합니다.
요는...
목적에 따라 "최적화"라는 게 서로 다르다는 겁니다.
심지어 둘 이상의 목적을 동시에 달성하고자 하는 상황에서,
어느 쪽의 목적과 방향성을 먼저 우선순위를 두고 그 것에 맞게 먼저 최적화한 후
그 다음 우선순위의 목적을 달성하기 위해 최적화를 하는 방식의 멀티 최적화도 있습니다.
- 이런 것은 목적을 순차적으로 달성시킨다고 해서, 골 프로그래밍(Goal Programming)이라고 합니다.
위 기사를 보면...
"최적화를 더 잘 해준다"는 게 얼마나 단순무식한 이야기인지 알 수 있습니다.
어떤 목적으로, 어떤 방향성에 맞게 최적화하는 게 최선인지, 프로그램이 그것을 판단할 수 있을까요?
불가능합니다. 그것은 사람이 선택하는 문제이죠.
이거 전문가 앞에서 아는 척 했다가 본전도 못찾는건 아닌가 싶지만, 그래도 하나 보태고 싶어서 거듭니다.
원문에서는 "효율적(efficiency)"이라는 표현은 나오지 않습니다. "효과적(effective)"에 대한 이야기는 나오지만, 부정적인 의미에서 나오죠. 효율적인 것과 효과적인 것은 비슷하지만 다른겁니다. 비효율적인건 작동은 하지만 별로 좋은 방법은 아닐때를 의미하고, 비효과적인건 아예 안맞아서 작동도 안한다는 말입니다.
또한 최적화를 자동화 한다는게 아니라 "과거의 최적화를 자동적으로 잘라낸다"고 합니다.
중요한 부분을 간과하고 넘어간게 비트-썩음인데, 이게 또 사전에 실린 낱말이 아니라 애매한 뜻이 됩니다만, 위키페디아 대로라면 software rot의 경우를 의미하는거라고 생각 할 수 있겠습니다. 처음 듣는 분이라도 레거시 코드라고 하면 바로 알아들으실겁니다.
레거시 코드에는 여러가지가 있겠지만, 개중에는 "과거에 판매된 제품 중 현재에는 사장되어 사라진 기술을 지원하는 코드"도 있습니다. 이런게 신제품 어플리케이션에서도 여전히 남아서 문제를 일으키거나 혹은 성능을 저하시키는 "비효과적"인 레거시 코드들이 상당수 남아 있고, 이걸 인력으로 해결하려 할 경우 수천만줄의 코드를 하나하나 재확인해야 하는 "비효율적"인 짓을 해야 한다는거죠.
결론은, 번역의 문제가 좀 있어서 여러사람 헷갈리게 만든게 아닐까 싶습니다.
다시 내용을 간추리자면 "구형 머신에 최적화된 코드를 신형 머신에 맞게 자동으로 고쳐주는 인공지능 패치 프로그램을 만들었고, 꽤나 효과적이더라"가 되겠네요.
여기에 대한 논문의 제목은 아래와 같구요.
"Helium: Lifting High-Performance Stencil Kernels from Stripped x86 Binaries to Halide DSL Code"
x86 바이너리에서 해당 동작과 버퍼만 뽑아내고 분석하여, (아마도)결과에 영향이 없는 동작을 제거한 추상구문트리를 작성한다는 것 같습니다.
현대 컴파일러나 런타임들이 하는 투기적인 성능 최적화를 생각해보면 미래적인 기술은 아닌 것 같구요. 저비용으로 레거시 코드를 재사용할 수 있다는 점에 의미가 있어보입니다.
알고리즘을 신뢰할수 있을까요?