SpaceX 수석 소프트웨어 엔지니어 Stephen Jones의 업계 관점

공간
Stephen Jones는 의 수석 소프트웨어 엔지니어입니다. 스페이스 엑스 그리고 전 CUDA 건축가 NVIDIA
이 게시물에서 Stephen Jones는 많은 관심을 끄는 기술 측면에 대한 자신의 관점을 제시합니다. Rescale님의 사용자입니다. 의 주요 기여자로서 CUDA, Rescale의 많은 사용자는 GPGPU 기술에 대한 그의 작업을 활용하여 분석을 실행했으며 다른 사용자는 CUDA 라이브러리를 사용하여 자신의 코드를 만들었습니다. 개인적인 관점에서 볼 때, 일반 소프트웨어 엔지니어링에서 수년을 보낸 후 엔지니어링 소프트웨어 작업으로 돌아왔기 때문에 Stephen에게 최근 몇 년간의 기술 발전과 그가 미래 동향을 어떻게 보는지에 대해 몇 가지 질문을 하는 것이 흥미로울 것이라고 결정했습니다.
공을 굴리기 위해 저는 병렬 컴퓨팅의 진화부터 시작했습니다.
스티븐 존스: 약 10년 전에는 모든 컴퓨팅이 병렬 컴퓨팅으로 바뀌었습니다. 프로세서가 개별적으로 더 빨라지는 것을 멈췄으며 무어의 법칙 더 많은 프로세서를 추가하여 계속되었습니다(소비자 프로세서에는 모두 최소 4개의 코어가 있고 서버에는 16개 이상이 있을 수 있습니다. 따라서 모든 비병렬 프로그램은 시스템의 25% 이하를 사용합니다). 병렬 프로그래밍은 몇 가지 근본적인 방식으로 직렬 프로그래밍과 다르므로 훨씬 더 어려워지기 때문에 중요한 효과가 발생한다고 생각합니다. 나는 미래에 병렬 프로그래밍이 인간이 아닌 도구(컴파일러, 라이브러리, 자동화된 프로그래밍 언어)에 의해 수행되는 것을 볼 수 있을 것으로 기대하며, 이는 모든 프로그래밍에 접근하는 방식에 큰 변화를 가져올 것입니다.

Rescale은 다양한 고객층을 보유하고 있습니다. 업계 또는 학계의 많은 파트너가 온프레미스에서 고성능 컴퓨팅(HPC) 클러스터를 사용하고 있습니다. 저는 Stephen에게 HPC가 그에게 어떤 의미인지 물었습니다.
스티븐 존스: 저는 이것이 최첨단 컴퓨팅 기술을 포괄하는 일반적인 용어라고 생각합니다. 우주는 복잡하기 때문에 우리가 그것을 정확하게 모델링할 수는 없습니다. 그러므로 우리는 항상 더 큰 컴퓨터에 대한 작업을 찾을 수 있습니다. 컴퓨터가 할 수 있는 일이 기술이 발전함에 따라 이전에는 공격할 수 없었던 새로운 문제가 발생하게 됩니다. HPC는 항상 존재하며 항상 틈새 시장이 될 것입니다. 반면에 앞서 언급한 우주의 복잡성으로 인해 "충분히 강력한" 데스크탑이 곧 이를 대체하지는 않을 것입니다. 하드웨어와 소프트웨어 측면에서 매우 흥미로운 기술 인큐베이터 역할을 합니다.
전 세계의 엔지니어와 과학자들이 리스케일 플랫폼 조직이 제공할 수 있는 리소스를 보완하고 확장합니다. 나는 Stephen에게 HPC에서 클라우드 기술의 활용을 어떻게 보는지에 대해 물었습니다.
스티븐 존스: 이것은 지난 10년 동안 가장 큰 원동력 중 하나입니다. 특히 Amazon의 클라우드는 판도를 바꾸고 있으며 (내 생각에는) 컴퓨팅 세계에서 가장 놀라운 것 중 하나입니다. 이제는 스타트업에 자금을 지원하려고 할 때 "내 인프라는 AWS이므로 하드웨어에 돈을 쓰지 않습니다"라고 말하는 것이 허용됩니다. 특히 흥미로운 점은 기본 IT 인프라뿐만 아니라 HPC도 가능하므로 이전에는 소규모 기업이 접근할 수 없었던 대규모 컴퓨팅을 통해 스타트업이 새로운 일을 수행하는 모습을 볼 수 있다는 것입니다. 실제로 과거보다 100배 더 많은 인력이 HPC용으로 개발할 수 있게 되었으며, 이를 위해서는 새롭고 흥미로운 애플리케이션을 생산해야 합니다.
Rescale에서 애플리케이션 엔지니어로 일하는 동안 저는 최근 Rescale 플랫폼에서 CUDA 및 NVIDIA 하드웨어를 활용하는 오픈 소스 패키지를 구축하고 설치했습니다. 나는 Stephen에게 CUDA에서 일한 개인적인 경험에 대해 물었습니다.
Stephen Jones: 제가 수년 동안 CUDA의 설계자였기 때문에 이것에 대해 객관적이기는 분명히 어렵습니다. 병렬 및 HPC 프로그래밍 언어에서 볼 수 있는 한 가지는 매우 "최저 공통 분모" 접근 방식입니다. 누구도 단일 시스템에서만 실행되고 다른 시스템을 구입하지 못하게 하는 매우 복잡한 코드에 투자하고 싶어하지 않습니다. 그 결과는 "위원회에 의해 설계됨" 문제와 "무엇이든 마스터" 결과가 결합됩니다. CUDA는 의도적으로 다른 극단으로 나아간다는 점에서 흥미롭습니다. 즉, 단일 유형의 기계에서만 작동하지만 모든 사람을 만족시키려고 노력함으로써 제한되지 않기 때문에 경계를 넓힐 수 있습니다. NVIDIA GPU가 HPC에서 널리 보급되어 있기 때문에 현재 잘 진행되고 있습니다. 그 결과 CUDA는 많은 새로운 프로그래밍 모델 측면을 먼저 조사합니다. 많은 CUDA 기능은 유용한 것으로 확인되어 어떤 형태로든 다른 언어(OpenCL, OpenMP, Renderscript)로 진출합니다. CUDA를 실제로 가능하게 하는 것은 언어 디자이너가 칩 디자이너로부터 하드웨어 지원을 받을 수 있다는 것입니다(같은 회사에 있기 때문에). 따라서 독립적인 언어 디자이너에게는 열려 있지 않은 새로운 한계를 밀어붙일 수 있습니다. CUDA에는 혁신적인 것들이 많이 있으며, 이러한 긴밀한 연관성의 결과로 앞으로 더 많은 것들이 나올 것입니다.
새로운 코드에서 제가 주목한 한 가지는 연구원들이 과학 프로젝트에서 Python을 현명하게 사용함으로써 생산성 향상을 달성하고 있다는 것입니다. 나는 Stephen에게 실제 작업을 수행할 수 있도록 최대의 생산성을 달성하고자 하는 과학자나 엔지니어에게 어떤 도구 조합(언어 포함)을 추천할지 물었습니다.
Stephen Jones: 저는 항상 최고 수준의 언어와 가능한 최소한의 줄 수로 소프트웨어를 작성해야 한다고 믿습니다. 고성능 코드에서도 코드 라인의 10%만이 사이클의 90%를 소비하는 경우가 많습니다. 이 10%가 잘 알려진 알고리즘(선형 대수, 푸리에 변환 등)을 구현하는 경우 다른 사람이 미세 조정한 기성 구현을 사용할 수 있는 경우가 많습니다.
즉, SciPy 또는 NumPy와 같은 고급 언어로 *모든* 작업을 수행하지 않고 기본 라이브러리를 사용하여 무거운 작업을 수행할 수 있는 경우가 많습니다. 그렇게 하지 않으면 미친 것 같다고 말하고 싶습니다. 코드를 유지 관리하기 쉽고, 줄도 적고, 버그도 적으며, 가장 중요하게는 업계에 도움이 됩니다. 난해한 기술을 아는 사람보다 Python을 아는 사람을 훨씬 더 쉽게 고용할 수 있습니다. 레벨 병렬 언어. 그러면 코드 베이스의 수명이 훨씬 길어집니다.
흥미로운 점은 CPU 집약적인 작업이 표준 알고리즘이 아닐 때입니다. 그런 다음 실제로 직접 구현해야 하며 다시 한 번 사용할 수 있는 최고 수준의 언어를 권장합니다. 여기에는 유지 관리성<->성능 균형에 대한 생각이 포함됩니다. 유지 관리가 용이하고 미래에도 사용할 수 있는 코드를 작성하는 대가로 최고 성능에 도달하지 못하는 것을 받아들일 수도 있습니다. 예를 들어 NumPy를 사용하면 Python 프레임워크에서 약간의 노력으로 상당한 속도 향상을 통해 CUDA 관련 병렬화를 수행할 수 있습니다.
SpaceX에서는 마지막 75%가 코드 개발을 훨씬 더 어렵게 만들고 가장 중요하게는 미래 보장성이 훨씬 떨어지기 때문에 최대 성능의 약 25%를 목표로 합니다. 몇 년마다 새로운 아키텍처를 위해 다시 코딩해야 한다면 추가로 25%를 추가할 가치가 없습니다. 물론 우리는 성능 코드에 Python을 사용하지 않지만 C++에서는 너무 복잡할 수 있는 여러 가지 작업에 Python을 사용합니다.
개발 도구에 관해서는 – 저는 항상 어떤 언어 및/또는 플랫폼이 최고의 진단 도구를 가지고 있는지 살펴봅니다. 디버거, 프로파일러 및 분석을 통해 말 그대로 개발 시간을 50% 절약할 수 있습니다. 그래서 그것과 고급 언어의 조합이 제가 가장 먼저 찾는 것입니다. 아시다시피 저는 Python의 팬이지만 실제로는 사용 사례에 따라 다릅니다. Matlab에는 프레임워크 잠금 기능이 포함되어 있지만 뛰어난 도구도 있습니다.
다른 유형의 언어에 대한 단어입니다. 특히 하스켈(Haskell)이 요즘 많은 관심을 받고 있습니다. 함수형 프로그래밍 언어로서 명령형 언어보다 훨씬 더 자연스럽게 병렬화되며 흥미로워 보입니다. 학계에서는 관심이 많지만 업계에서 사용하기에는 인재 풀이 너무 작다고 생각합니다. 좋은 사람을 고용하는 것은 C는 물론이고 Python에도 충분히 어렵습니다.
나는 그에게 엔지니어링 분석에 여전히 자주 사용되는 언어인 FORTRAN의 미래가 무엇이라고 생각하는지 물었습니다.
스티븐 존스: 컴퓨터의 실행 능력이 떨어지면 사라질 것입니다. 본질적으로 병렬이 아니므로 MPI와 같은 프레임워크를 둘러싸야 합니다. 더 큰(엑사스케일) 컴퓨터는 MPI로 프로그래밍하기가 점점 더 어려워질 것이며 이것이 FORTRAN의 종말을 의미할 것이라고 생각합니다. C와 달리 FORTRAN은 저수준 프로그래밍에 존재하지 않으므로 먼지가 많은 데크가 마침내 다시 작성되면 사라질 것입니다.
내 수정구슬을 들여다보면서 마지막으로 한마디: 프로그래밍의 미래는 소프트웨어-작성-소프트웨어에 달려 있다고 생각합니다. 즉, 나는 나를 위해 프로그램을 작성하는 프로그램을 작성하겠습니다. 컴파일러는 이미 우리를 위해 많은 일을 하고 있습니다. Ruby와 같은 고급 프레임워크는 웹 프로그래밍의 모든 종류의 복잡성을 관리합니다. 자동 병렬화(sic)는 현재 큰 유행어입니다(아직은 아니지만). 컴퓨터는 프로그래밍하기가 점점 더 어려워질 것이며, 우리는 다른 컴퓨터의 도움을 통해서만 프로그래밍을 할 수 있게 될 것입니다…
내가 "진짜 엔지니어"라고 부르고 싶은 사람들과 함께 작업한다는 주제로 넘어가면(공개, 나의 첫 번째 엔지니어링 업무는 선박 수리장에서 이루어졌습니다) Stephen도 똑같이 다가왔습니다.
스티븐 존스: 순수한 기계공학 환경에서 소프트웨어 전문가로 일하는 것은 정말 흥미롭습니다. 컴퓨터는 실험실 장비와 같은 도구이며 누구도 컴퓨터 없이 엔지니어링을 수행하는 것을 상상할 수 없습니다. 그러나 내가 본 모든 엔지니어링 회사의 소프트웨어 엔지니어가 아닌 사람들은 이를 도구처럼 사용합니다(즉, 상당히 소프트웨어가 정교하지 않은 방식으로).
마지막으로, 소프트웨어 엔지니어링과 엔지니어링과의 관계는 제가 정말 관심을 갖는 주제입니다. 나는 이에 대한 스티븐의 생각을 물었다.
스티븐 존스: 이것은 또 다른 거대한 항목입니다. 저는 매일 SpaceX에서 그 격차를 해소하려고 노력하고 있습니다. 저는 몇 달 전 엔지니어링 시뮬레이션에 관한 컨퍼런스에 참석하여 놀랍게도 비슷한 이야기를 하는 XNUMX명의 사람들을 만났습니다. (저도 마찬가지였습니다.) 소프트웨어에 대한 이해 부족이 널리 퍼져 있으며 엔지니어에게는 실질적인 장애가 됩니다. 우리는 컴퓨터를 사용하고 프로그래밍하는 것보다 엔지니어를 훨씬 더 잘 교육해야 합니다. 이는 업무에서 쉽게 사용하는 방법을 배울 수 있는 드릴이나 톱과 같은 것이 아닙니다. 이러한 교육을 제공하는 데 시간을 투자하는 기업은 엔지니어링 혁신과 생산성 측면에서 분명한 이점을 얻습니다. 이는 공학뿐만 ​​아니라 모든 과학에 해당됩니다. NVIDIA의 HPC에서 일하면서 저는 이 엄청나게 복잡한 슈퍼컴퓨터를 사용하여 최첨단 과학을 수행하기 위해 고군분투하고 있는 수많은 훌륭한 물리학자, 화학자, 생물학자를 만났습니다. 가장 성공적인 사람들은 단지 혼란스러워 하는 것이 아니라 적극적으로 프로그래밍을 배운 사람들이었습니다. 많은 경우 경험이 적은 물리학자가 컴퓨터를 더 효과적으로 사용할 수 있기 때문에 더 나은 작업을 수행합니다. 과학과 공학 모두에서 소프트웨어가 "덜 순수하다"는 태도는 부인할 수 없습니다. 하지만 이제 사람들이 어린 시절부터 컴퓨터를 손끝으로 사용하면서 성장함에 따라 이것이 세대 간 연관이 있을 것으로 생각됩니다.
그의 독특한 관점에 대해 Stephen에게 많은 감사를 드립니다. ~에 Rescale, 우리는 과학자와 엔지니어가 필요로 하는 확장 가능한 컴퓨팅 리소스를 제공하여 목표를 달성할 수 있도록 계속 노력할 것입니다.

비슷한 게시물