저 사양의 컴퓨터로 달 탐사를 헀다니...
엄청나네요

심지어 복잡한 계산도 인력으로 했습니다.

미적분 포함한 각종 계산을 담당하는 인원(아마 4명)이 앞에 앉아 계산기 역할을 했다고 합니다. 4명인 이유는 오류정정을 위해...
https://en.wikipedia.org/wiki/Slide_rule
이런 물건을 썼다고 하네요.

저세상 프로그래밍..

적어도 예산 잡아먹는 괴물은 구석 어딘가에 있을거라 짐작합니다.

요즘은 전력 소비가 문제인지라 성능을 계속 신경 쓸 수 밖에 없는 현실...

연산 당 전력 소비는 계속 줄어들고 있고, 성능에 대한 압박은 예전보다 줄어들긴 했죠. 반대로 사람 쓰는 값은 계속 오릅니다. 현대에는 성능 신경쓴다고 프로그래머를 하나 더 뽑는 것보다 컴퓨터 한 대 더 굴리는 게 유지비도 저렴합니다.

물론 슈퍼컴퓨터처럼 HPC 동네로 가면 성능을 신경쓸 수 밖에 없는건 맞습니다.

CMOS 공정의 빠른 발전 덕에 그래왔지만 물리적인 한계까지는 어떻게 못 하죠. 그간 "한계" 라고 생각한 벽들을 깨오기는 했지만 결국 진짜 물리법칙까지는 어떻게 못 하고.. 그래서 언제까지나 CPU의 발전에 의존할 수는 없습니다. 이미 발전이 많이 느려졌습니다.

대신 컴파일러 최적화를 더 갈아넣는 건 가능하긴 하겠지요. 추상화에 신경쓴 코드도 컴파일러가 알아서 다 최적화해서 뽑아주기만 한다면야 걱정할 필요가 없습니다. 아직 그건 조금 먼 이야기라 문젠데요. 지금 당장의 해법은 가능한 한 남이 짜둔 라이브러리에 의존하는거고요. 어차피 최적화라는 건 병목이 되는 부분 위주로만 해주면 되니까 그걸 남이 짜둔 코드로 땜빵할 수 있다면 되는 일..

컴퓨터가 빨라졌으니 그만큼 프로그램 대충 짜도된다는 말은 20년전에도 많이들 했는데 그 때마다 뭔가 더 CPU를 많이 쓸 수 밖에 없는 새로운 기술이나 더 낮은 전력소모가 필수인 기술들이 발견되더라고요. 요즘은 기어코 GPU마저도 신경망으로 튀기고 있죠.

뭐 별 기능 없는 단순한 앱이야 진짜 발로 짜도 되기야 하는데요. 근데 또 간단한 채팅 클라이언트조차 일렉트론에 쓸데없는 효과로 도배해서 저사양 컴퓨터에서 버벅대는 걸 보면 그것조차 썩 올바르진 않은 거 같기도 하고 뭐 그렇습니다.

적어도 옛날 아버지 세대에는 C 같은 고급언어보다 어셈같은 언어를 성능때문에 당연히 배워서 써 왔다면

지금은 C 같은 원시언어보다는 자바나 파이썬같은 고급언어를 사용한다고 하니 성능의 발전이 좋기는 좋습니다.

사실 C만 봐도 컴파일러가 후달리던 시절에는 성능을 뽑아내기 위해 인라인 어셈블리를 도배해둬서 이게 C인지 어셈블리인지 하던 시절도 있었다죠.

확실히 CMOS 공정에도 한계도 왔고, 고성능/저전력이 필요한 기술은 항상 존재하더군요. 그런 기술 쪽으로 가면 아예 관계 없는 말이긴 합니다.

다만 클럭 향상/OoO를 통해 얻던 기존 CPU 성능 향상방법의 대안으로 떠오르는 기술이 멀티코어 프로그래밍이라던가 C to HDL이라서, 성능 때문에 코드 안에 race condition 같이 로직과는 상관없지만 대응이 필요한 부분을 일일이 집어넣으면서 코딩하기는 힘들지 않을까요. 특히 멀티코어 프로그래밍이든 HDL이든 디버깅이 악랄할 정도로 어려운 분야라서 말이죠. 아예 버그 재현이 불가능하다시피한 하이젠버그도 있고요. (사실 지금도 CPU의 디테일 정도는 C 컴파일러도 알아서 손봐주긴 합니다만은, 애초에 명령형이 멀티코어 프로그래밍을 하기 좋은 패러다임은 아닌 것 같네요)

그리고 프로그램을 대충 짜는 건 추상화와는 상극이죠. 나중에는 빠르지도 않고 아무도 읽을 수 없는 무언가가 되어 있더군요

"대충 짜는 것" 과 "추상화"는 사람 입장에선 상극이지만.. 컴파일 될 때는 입장에서는 그냥 최적화가 난해할 수도 있는 코드일 뿐이죠 (최적화가 난해한 이유는 다를 수도 있습니다만...). 예엣날에 나눴던 말을 그대로 쓴 거라 그런데 그 때는 유지보수를 따질 만큼 한국 소프트웨어쪽이 성숙하지 않았어서 그런 식의 내용이 되었었을겁니다.

병렬화야 짜증나긴 하는데.. 뭐 하고싶어서 하는게 아닙죠 보통. 다행히도 많은 경우 남이 대신 해 주긴 할 건데요. 발로 짠 일렉트론 앱 같은 게 대충 돌아가는 것도 열심히 크로뮴이 멀티코어를 갈궈주는 덕도 있고 그렇죠. 뭐 그렇게 남들이 해둔 것에 얹혀갈 수 있는 프로젝트인 경우에는 편한 시대이긴 할 것 같습니다. 저도 평상시에는 가능한 한 얹혀가려고 노력; 하는 편이고요.

확실히 선생님 말대로 라이브러리를 쓴다면 편한 시대인 것 같습니다. 파이썬이 성공한 이유기도 하겠죠.

PC를 벽에 바를 수는 없는 노릇이라...
본문 내용인 8051이나 Cortex-M0 레벨에서는 최저 전력으로 성능을 얻기 위한 압박이 매우 큽니다.
코드 한 줄이 한 줄이 다 소비 전력이기 때문에... 추상화는 커녕 아직도 어셈 쓰는 이유이기도 하고..
벽에 바를 수 있는 프로세서가 나오려면 얼마나 더 빡세게 튜닝 해야할지... 결론은 누진제 아웃!

제 눈에는 ASIC을 안 쓰고 CPU를 쓴다는 것 자체가 신기하더군요

그리고 벽에 바르는 컴퓨터 말입니다만, 분산 프로그래밍을 얘기하는 대목이라 아마 실제로 동작하는 실리콘 비율은 어마어마하게 낮을 겁니다.

그야말로 돈낭비...

불행히도 연산성능이 늘어나면 그만큼 써야할 곳도 늘어나기때문에 최적화에서 늘 자유로울 순 없습니다. 마치 연봉이 두배가 되고 세배가 되어도 결과적으로 늘어난 연봉만큼 쓸 곳이 생겨서 여전히 아껴써야 하는 것처럼요.

최적화를 아예 포기한다는 말은 아닐겁니다. 저 분이 애초에 실험적인 패러다임을 개발하시던 분인데다(논리형 프로그래밍/초기 OOP), 컴퓨터 자체를 추상적인 아이디어를 표현하는 도구로 봐서 더더욱 그런 것도 있지만 말이죠. Fine-grained 한인 패 최적화를 위해서 OOP같은 직관적러다임을 내칠 수는 없는 노릇이죠. 게임이나 AI같이 고성능을 필요로 하는 곳에서는 언제나 성능만을 신경쓸 수 밖에 없지만요.

뭐 그래도 예전엔 C++로 눈물의 최적화를 한 스타크래프트1 에 비하면 요즘에는 유니티에 C#으로 만드는 3D게임도 있다던가 하죠. 웹서버 쪽은 PHP도 쓰고 Python도 쓰고 Ruby도 쓰고 하고요. Whatsapp은 Elixir로 작성했다죠?

일부러 구형컴 찾아서 넣었죠 ㅋㅋ

정확히는 구형 설계를 가져와서 칩 생산 재료를 실리콘+사파이어로 바꿨다고 합니다.

정정하겠습니다. 8086/80386 쓰는 시스템에는 실제로 시중에 있던 8086/80386을 쓴 듯 합니다. 그런데 1차 출처를 찾지를 못하겠네요.

찾아보니 보이저 1/2호 이후 우주탐사선에서 8086/80386을 썼다고 합니다. 보이저는 TTL 18비트(!) 컴퓨터를 썼다고 하네요.

아직 ccd는 상용화 되기 전이라 비디콘튜브 라는 무식한 방식의 카메라에 지구로 보내는 데이터 전송 속도도 눈물날 만큼 느렸죠 ㅜㅜ