해결책
에드 네이더의 1983년 USENET 에세이 '멜 이야기, 진짜 프로그래머'에서 멜은 값싼 드럼 메모리 기계인 LGP-30과 더 새로운 RPC-4000을 만드는 Royal McBee Computer Corp.의 프로그래머다. 컴파일러를 못마땅하게 여긴 멜('프로그램이 자기 코드를 다시 쓸 수 없다면 무슨 소용인가?')은 회사에서 가장 인기 있는 프로그램을 순수 16진수로 작성했다. 모든 컴퓨터 쇼에서 LGP-30 부스를 가득 메웠고, IBM 영업사원들은 서로 이야기나 나누고 서 있었던 블랙잭 게임이었다.
멜의 기예는 타이밍이었다. 드럼 기계에서 코드가 빠르게 실행되려면 각 명령어가 이전 명령어가 끝나는 바로 그 순간 판독 헤드에 도착해야 한다. 이를 위한 최적화 어셈블러가 존재했지만, 멜은 그 배치가 예측 불가능하고 별도의 상수를 강제한다는 이유로 거부했다. 모든 연산 코드의 숫자 값을 알고 자신의 드럼 주소를 지정했기에, 그는 어떤 명령어든 숫자 상수로 취급할 수 있었다 — 앞선 덧셈 명령어를 가져와 그것으로 곱하는 식이다.
그는 가장 안쪽 루프 본체를 먼저 작성하여 최적의 드럼 위치를 차지하게 했고, 판독 헤드 바로 뒤에 의도적인 지연을 두어 한 바퀴 전체를 돌게 했다 — '가장 최악의(most pessimum)'. 네이더는 멜이 손으로 최적화한 프로그램과 같은 코드를 최적화 어셈블러로 돌린 결과를 비교했다: '멜의 것이 항상 더 빨랐다.' 에세이는 영업 부서가 고객이 블랙잭에서 이길 수 있도록 감지 스위치를 달자고 요청한 변경 요청서로 끝맺는다.
멜은 그 부정직함에 반발했지만 결국 따랐다 — 다만 테스트를 거꾸로 작성해서, 스위치를 켜면 기계가 속임수를 써서 매번 이기게 했다. 그는 자신의 잠재의식이 통제 불가능할 만큼 윤리적이라고 선언하고 고치기를 거부했으며, 네이더의 에세이는 이 사건을 컴퓨팅에서 가장 많이 재인쇄된 전설 중 하나로 만들었다.
이룬 것
가장 안쪽 루프를 먼저 작성하고 각 명령어를 판독 헤드에 정확히 제때 도착하도록 배치하라 — 연산 코드의 숫자 값을 자기 수정 코드의 상수로 사용하면서.
통한 이유
드럼 지연 때문에 명령어 배치가 빠른 코드와 극도로 느린 코드를 가르는 차이가 되었다.
최적화 어셈블러는 배치를 최적화했지만 프로그래머의 통제권을 파괴했다.
가장 안쪽 루프를 먼저 작성하면 가장 뜨거운 코드가 다른 무엇보다 먼저 최적의 주소를 차지할 수 있었다.
연산 코드를 상수로 쓰는 산술을 통한 자기 수정 코드는 별도의 상수를 완전히 없앴다.
진정한 최적화는 툴체인이 아니라 기계의 물리적 특성을 활용한다: 모든 연산 코드의 숫자 값을 아는 사람은 상수를 코드로, 타이밍을 설계 재료로 바꿀 수 있다.
그 후
이 에세이는 컴퓨팅에서 가장 많이 재인쇄된 전설 중 하나가 되었고, '완전히 최적은 아님'이라는 표현이 멜의 '가장 최악의(most pessimum)' 조어를 통해 프로그래머 어휘에 들어왔다. RPC-4000과 Royal McBee 자체는 오래전에 사라졌고, 주로 이 이야기를 통해 기억된다.
근거 확인하기
출처
- The Story of Mel, a Real Programmer (Ed Nather, USENET, 21 May 1983) University of Utah folklore archive · users.cs.utah.edu ·