클리프 클릭 — Cratus(프로세스 개선을 위한 IoT 센서)의 CTO이자 여러 스타트업(Rocket Realtime School, Neurensic 및 H2O.ai 포함)의 창립자이자 공동 창립자로서 여러 차례 성공적으로 종료했습니다. Cliff는 15세에 첫 번째 컴파일러(TRS Z-80용 Pascal)를 작성했습니다! 그는 Java(Sea of ​​​​Nodes IR)의 C2 작업으로 가장 잘 알려져 있습니다. 이 컴파일러는 JIT가 고품질 코드를 생성할 수 있다는 사실을 세상에 보여주었습니다. 이는 Java가 주요 현대 소프트웨어 플랫폼 중 하나로 등장한 요인 중 하나였습니다. 그런 다음 Cliff는 Azul Systems가 864밀리초 이내에 500GB 힙에서 GC 일시 중지를 지원하는 순수 Java 소프트웨어로 10코어 메인프레임을 구축하도록 도왔습니다. 일반적으로 Cliff는 JVM의 모든 측면을 작업했습니다.

 
이 habrapost는 Cliff와의 훌륭한 인터뷰입니다. 우리는 다음 주제에 관해 이야기할 것입니다:

• 낮은 수준의 최적화로 전환
• 대규모 리팩토링을 수행하는 방법
• 비용 모델
• 낮은 수준의 최적화 교육
• 성능 향상의 실제 사례
• 자신만의 프로그래밍 언어를 만드는 이유
• 성능 엔지니어 경력
• 기술적 과제
• 레지스터 할당과 멀티 코어에 대해 조금
• 인생의 가장 큰 도전

인터뷰는 다음과 같이 진행됩니다.

• 안드레이 사타린 아마존 웹 서비스에서. 그의 경력에서 그는 완전히 다른 프로젝트에 참여했습니다. 그는 Yandex의 NewSQL 분산 데이터베이스, Kaspersky Lab의 클라우드 감지 시스템, Mail.ru의 멀티 플레이어 게임, Deutsche Bank의 외환 가격 계산 서비스를 테스트했습니다. 대규모 백엔드 및 분산 시스템 테스트에 관심이 있습니다.
• 블라디미르 시트니코프 넷크래커에서. 통신 사업자가 네트워크 및 네트워크 장비 관리 프로세스를 자동화하기 위해 사용하는 소프트웨어인 NetCracker OS의 성능과 확장성에 대해 XNUMX년 동안 연구했습니다. Java 및 Oracle 데이터베이스 성능 문제에 관심이 있습니다. 공식 PostgreSQL JDBC 드라이버에서 XNUMX개 이상의 성능 개선을 이룬 저자입니다.

낮은 수준의 최적화로 전환

앤드류: 당신은 JIT 컴파일, Java 및 성능 작업 전반에 걸쳐 큰 이름을 갖고 있는 사람이죠? 

낭떠러지: 그런거구나!

앤드류: 퍼포먼스 작업에 대한 몇 가지 일반적인 질문부터 시작하겠습니다. CPU 수준에서 작업하는 것과 같이 높은 수준 최적화와 낮은 수준 최적화 사이의 선택에 대해 어떻게 생각하시나요?

낭떠러지: 네, 여기서는 모든 것이 간단합니다. 가장 빠른 코드는 결코 실행되지 않는 코드입니다. 따라서 항상 높은 수준에서 시작하여 알고리즘 작업을 수행해야 합니다. 충분히 큰 상수가 개입하지 않는 한 더 나은 O 표기법이 더 나쁜 O 표기법을 능가합니다. 낮은 수준의 일은 마지막에 진행됩니다. 일반적으로 스택의 나머지 부분을 충분히 최적화했지만 여전히 흥미로운 내용이 남아 있다면 이는 낮은 수준입니다. 하지만 높은 수준에서 시작하는 방법은 무엇입니까? 높은 수준의 작업이 충분히 완료되었는지 어떻게 알 수 있나요? 글쎄... 절대 안돼. 준비된 레시피가 없습니다. 문제를 이해하고 무엇을 할 것인지 결정한 다음(미래에 불필요한 조치를 취하지 않도록) 유용한 정보를 제공할 수 있는 프로파일러를 발견할 수 있습니다. 어느 시점에서 당신은 불필요한 것들을 제거했고 이제 낮은 수준의 미세 조정을 해야 할 때라는 것을 스스로 깨닫습니다. 이것은 확실히 특별한 종류의 예술이다. 불필요한 일을 하고 있지만 너무 빨리 움직여서 생산성에 대해 걱정할 여유가 없는 사람들이 많습니다. 그러나 이것은 질문이 퉁명스럽게 나타날 때까지입니다. 보통 99%의 시간은 아무도 내가 하는 일에 관심을 두지 않는다. 아무도 관심을 두지 않는 결정적인 길에서 중요한 일이 일어나는 순간까지 말이다. 그런데 여기서 다들 “왜 처음부터 완벽하게 안 됐냐”고 잔소리를 하기 시작한다. 일반적으로 성능에는 항상 개선할 부분이 있습니다. 하지만 99%의 경우 단서가 없습니다! 당신은 단지 무언가를 작동시키려고 노력하고 있으며 그 과정에서 무엇이 중요한지 파악하고 있습니다. 이 작품이 완벽해야 한다는 것을 미리 알 수 없기 때문에 사실 모든 면에서 완벽해야 합니다. 하지만 이것은 불가능하고 당신은 그렇게 하지 않습니다. 항상 고쳐야 할 부분이 많이 있으며 이는 완전히 정상적인 현상입니다.

대규모 리팩토링을 수행하는 방법

앤드류: 공연 작업은 어떻게 진행되나요? 이것은 교차 문제입니다. 예를 들어, 기존의 많은 기능이 교차하면서 발생하는 문제를 해결해야 했던 적이 있습니까?

낭떠러지: 나는 그것을 피하려고 노력한다. 성능이 문제가 될 것이라는 것을 안다면 코딩을 시작하기 전에 특히 데이터 구조에 대해 생각해 봅니다. 그러나 종종 이 모든 것을 아주 나중에 발견하게 됩니다. 그런 다음 극단적인 조치를 취하고 제가 "다시 작성하여 정복"이라고 부르는 작업을 수행해야 합니다. 충분히 큰 조각을 확보해야 합니다. 일부 코드는 성능 문제 등으로 인해 다시 작성해야 합니다. 코드를 다시 작성하는 이유가 무엇이든, 작은 부분보다 큰 부분을 다시 작성하는 것이 거의 항상 더 좋습니다. 이 순간, 모두가 두려움에 떨기 시작합니다. “맙소사, 그렇게 많은 코드를 만질 수는 없잖아!” 그러나 실제로는 이 접근 방식이 거의 항상 훨씬 더 효과적입니다. 즉시 큰 문제를 해결하고 그 주위에 큰 원을 그리고 다음과 같이 말해야 합니다. 원 안의 모든 것을 다시 쓰겠습니다. 테두리는 교체해야 하는 내부 콘텐츠보다 훨씬 작습니다. 그리고 그러한 경계 묘사를 통해 내부 작업을 완벽하게 수행할 수 있다면 손이 자유롭고 원하는 것을 할 수 있습니다. 문제를 이해하고 나면 다시 작성하는 과정이 훨씬 쉬워지므로 크게 시도해 보세요!
동시에 대규모 재작성을 수행하고 성능이 문제가 될 것이라는 사실을 깨닫게 되면 즉시 이에 대해 걱정할 수 있습니다. 이것은 일반적으로 "데이터를 복사하지 말고, 데이터를 가능한 한 간단하게 관리하고, 작게 만드십시오"와 같은 간단한 것으로 변합니다. 대규모 재작성에는 성능을 향상시키는 표준 방법이 있습니다. 그리고 거의 항상 데이터를 중심으로 이루어집니다.

비용 모델

앤드류: 팟캐스트 중 하나에서 생산성 측면의 비용 모델에 대해 이야기하셨습니다. 이게 무슨 뜻인지 설명해 주실 수 있나요?

낭떠러지: 틀림없이. 나는 프로세서 성능이 매우 중요했던 시대에 태어났다. 그리고 이 시대가 다시 돌아옵니다. 운명에는 아이러니가 없지 않습니다. 나는 256비트 컴퓨터 시대에 살기 시작했고 나의 첫 번째 컴퓨터는 XNUMX바이트로 작동했습니다. 정확히 바이트입니다. 모든 것이 매우 작았습니다. 명령은 계산되어야 했고 프로그래밍 언어 스택이 올라가기 시작하면서 언어가 점점 더 많아졌습니다. Assembler, Basic, C가 있었고 C는 레지스터 할당 및 명령어 선택과 같은 많은 세부 사항을 처리했습니다. 그러나 거기에서는 모든 것이 매우 명확했으며 변수의 인스턴스에 대한 포인터를 만들면 로드가 발생하고 이 명령의 비용이 알려졌습니다. 하드웨어는 일정한 수의 기계 주기를 생성하므로 실행하려는 모든 명령을 합산하여 다양한 작업의 실행 속도를 간단히 계산할 수 있습니다. 각 비교/테스트/분기/호출/로드/저장을 합산하여 말할 수 있습니다. 이것이 바로 실행 시간입니다. 성능 향상을 위해 작업할 때 작은 핫 사이클에 해당하는 숫자가 무엇인지 확실히 주의를 기울일 것입니다. 
그러나 Java, Python 및 이와 유사한 것으로 전환하자마자 하위 수준 하드웨어에서 매우 빠르게 벗어나게 됩니다. Java에서 getter를 호출하는 데 드는 비용은 얼마입니까? HotSpot의 JIT가 올바른 경우 인라인, 로드되지만 로드되지 않은 경우 함수 호출이 됩니다. 호출이 핫 루프에 있으므로 해당 루프의 다른 모든 최적화가 무시됩니다. 따라서 실제 비용은 훨씬 더 높을 것입니다. 그리고 코드 조각을 보고 프로세서 클럭 속도, 메모리 및 사용된 캐시 측면에서 코드를 실행해야 한다는 사실을 이해하는 능력을 즉시 잃게 됩니다. 이 모든 것은 실제로 공연에 참여하는 경우에만 흥미로워집니다.
이제 우리는 지난 XNUMX년 동안 프로세서 속도가 거의 증가하지 않은 상황에 처해 있습니다. 옛날이 돌아왔다! 더 이상 우수한 단일 스레드 성능을 기대할 수 없습니다. 하지만 갑자기 병렬 컴퓨팅에 빠지면 엄청나게 어렵습니다. 모두가 당신을 제임스 본드처럼 바라볼 것입니다. 여기서 XNUMX배 가속은 일반적으로 누군가가 뭔가를 엉망으로 만든 곳에서 발생합니다. 동시성에는 많은 작업이 필요합니다. XNUMX배의 속도 향상을 얻으려면 비용 모델을 이해해야 합니다. 비용은 얼마이며 비용은 얼마입니까? 이를 위해서는 혀가 기본 하드웨어에 어떻게 맞는지 이해해야 합니다.
마틴 톰슨(Martin Thompson)은 자신의 블로그에 좋은 단어를 선택했습니다 기계적 동정! 하드웨어가 무엇을 할 것인지, 정확히 어떻게 할 것인지, 애초에 하드웨어가 그 일을 하는 이유를 이해해야 합니다. 이를 사용하면 명령 계산을 시작하고 실행 시간이 어디로 가는지 파악하는 것이 매우 쉽습니다. 적절한 훈련이 없으면 어두운 방에서 검은 고양이를 찾을 뿐입니다. 나는 사람들이 도대체 무엇을 하고 있는지 전혀 모르는 채 항상 성능을 최적화하는 것을 봅니다. 그들은 많은 고통을 겪고 있으며 많은 진전을 이루지 못하고 있습니다. 그리고 동일한 코드 조각을 사용하여 몇 가지 작은 해킹을 적용하여 XNUMX배 또는 XNUMX배의 속도 향상을 얻으면 다음과 같습니다. 음, 그건 불공평합니다. 우리는 이미 당신이 더 낫다는 것을 알고 있습니다. 놀라운. 내가 말하는 것은... 비용 모델은 어떤 종류의 코드를 작성하고 큰 그림에서 평균적으로 얼마나 빠르게 실행되는지에 관한 것입니다.

앤드류: 그리고 어떻게 그런 볼륨을 머릿속에 유지할 수 있습니까? 이것은 더 많은 경험을 통해 달성됩니까, 아니면? 그러한 경험은 어디에서 오는가?

낭떠러지: 글쎄, 나는 가장 쉬운 방법으로 경험을 얻지 못했습니다. 나는 모든 지침을 이해할 수 있었던 시절에 어셈블리로 프로그래밍했습니다. 어리석게 들리겠지만, 그 이후로 Z80 명령어 세트는 항상 내 머릿속, 기억 속에 남아 있었습니다. 말을 하면 40분 안에 사람 이름은 기억나지 않지만, XNUMX년 전에 작성된 코드는 기억난다. 웃긴데 증후군인 것 같다"바보 과학자".

낮은 수준의 최적화 교육

앤드류: 더 쉽게 들어갈 수 있는 방법이 있나요?

낭떠러지: 예, 아니오. 우리 모두가 사용하는 하드웨어는 시간이 지나도 크게 변하지 않았습니다. Arm 스마트폰을 제외하고 모두가 x86을 사용합니다. 일종의 하드코어 임베딩을 수행하지 않는 경우에도 동일한 작업을 수행하는 것입니다. 알았어, 다음. 지침도 수세기 동안 변경되지 않았습니다. 가서 어셈블리에 뭔가를 작성해야 합니다. 많지는 않지만 이해하기에는 충분합니다. 당신은 웃고 있지만 나는 완전히 진지하게 말하고 있습니다. 언어와 하드웨어 간의 대응 관계를 이해해야 합니다. 그 후에는 가서 약간의 글을 작성하고 작은 장난감 언어를 위한 작은 장난감 컴파일러를 만들어야 합니다. 장난감 같다는 것은 합리적인 시간 내에 만들어져야 함을 의미합니다. 매우 간단할 수 있지만 지침을 생성해야 합니다. 명령어를 생성하는 행위는 모든 사람이 작성하는 고급 코드와 하드웨어에서 실행되는 기계어 코드 사이를 연결하는 비용 모델을 이해하는 데 도움이 됩니다. 이 서신은 컴파일러가 작성될 때 두뇌에 새겨질 것입니다. 심지어 가장 간단한 컴파일러도 마찬가지입니다. 그 후에는 Java를 살펴보기 시작할 수 있으며 Java의 의미론적 틈이 훨씬 더 깊고 Java를 연결하는 것이 훨씬 더 어렵다는 사실을 알 수 있습니다. Java에서는 우리의 브리지가 좋은지 나쁜지, 무엇이 무너지게 만들고 무엇이 무너지지 않을지를 이해하는 것이 훨씬 더 어렵습니다. 하지만 코드를 보고 "예, 이 getter는 매번 인라인되어야 합니다."라는 것을 이해할 수 있는 일종의 시작점이 필요합니다. 그리고 메소드가 너무 커지고 JIT가 모든 것을 인라인하기 시작하는 상황을 제외하고는 때때로 이런 일이 발생하는 것으로 나타났습니다. 그러한 장소의 성능은 즉시 예측할 수 있습니다. 일반적으로 getter는 잘 작동하지만 대규모 핫 루프를 살펴보면 자신이 수행하는 작업을 모르는 일부 함수 호출이 주위에 떠 있다는 것을 알게 됩니다. 이것이 게터의 광범위한 사용에 따른 문제이며, 인라인되지 않은 이유는 게터인지 여부가 명확하지 않기 때문입니다. 매우 작은 코드 기반이 있는 경우 간단히 기억하고 다음과 같이 말할 수 있습니다. 이것은 getter이고 이것은 setter입니다. 대규모 코드 베이스에서 각 함수는 일반적으로 누구에게도 알려지지 않은 고유한 기록을 유지합니다. 프로파일러는 우리가 일부 루프에서 24%의 시간을 잃었다고 말하고 이 루프가 수행하는 작업을 이해하려면 내부의 각 함수를 살펴봐야 합니다. 기능을 공부하지 않고는 이것을 이해하는 것이 불가능하며, 이로 인해 이해 과정이 심각하게 느려집니다. 그래서 나는 getter와 setter를 사용하지 않고 새로운 수준에 도달했습니다!
비용 모델은 어디서 구할 수 있나요? 물론 뭔가를 읽을 수도 있겠지만... 하지만 가장 좋은 방법은 행동하는 것이라고 생각합니다. 작은 컴파일러를 만드는 것이 비용 모델을 이해하고 이를 자신의 머리에 맞추는 가장 좋은 방법이 될 것입니다. 전자레인지 프로그래밍에 적합한 작은 컴파일러는 초보자를 위한 작업입니다. 글쎄, 내 말은, 이미 프로그래밍 기술을 갖고 있다면 그것만으로도 충분하다는 뜻이다. 일종의 대수식으로 가지고 있는 문자열을 구문 분석하고, 거기에서 올바른 순서로 수학 연산에 대한 지침을 추출하고, 레지스터에서 올바른 값을 가져오는 등 이 모든 작업이 한 번에 수행됩니다. 그리고 그렇게 하는 동안 그것은 뇌에 각인될 것입니다. 나는 모두가 컴파일러가 무엇을 하는지 알고 있다고 생각합니다. 그리고 이를 통해 비용 모델을 이해할 수 있습니다.

성능 향상의 실제 사례

앤드류: 생산성을 위해 작업할 때 또 어떤 점에 주의해야 할까요?

낭떠러지: 데이터 구조. 그건 그렇고, 네, 저는 이 수업을 오랫동안 가르치지 않았습니다... 로켓스쿨. 즐거웠지만 많은 노력이 필요했고 나에게도 인생이 있습니다! 좋아요. 그래서 크고 흥미로운 수업 중 하나인 "당신의 성과는 어디로 가는가"에서 학생들에게 예를 들었습니다. 70GB의 핀테크 데이터를 CSV 파일에서 읽은 다음 판매된 제품 수를 계산해야 했습니다. . 일반 진드기 시장 데이터. 1년대 이후 UDP 패킷이 텍스트 형식으로 변환되었습니다. Chicago Mercantile Exchange - 버터, 옥수수, 대두 등 모든 종류의 물건. 이러한 제품, 거래 수, 자금 및 상품의 평균 이동량 등을 계산해야했습니다. 이는 매우 간단한 거래 수학입니다. 제품 코드(해시 테이블에서 2-XNUMX자)를 찾고, 금액을 얻고, 거래 세트 중 하나에 추가하고, 거래량을 추가하고, 가치를 추가하는 등 몇 가지 다른 작업을 수행합니다. 매우 간단한 수학. 장난감 구현은 매우 간단했습니다. 모든 것이 파일에 있고 파일을 읽고 이동하며 개별 레코드를 Java 문자열로 나누고 그 안에서 필요한 항목을 찾아 위에 설명된 수학에 따라 추가합니다. 그리고 그것은 약간 낮은 속도로 작동합니다.

이 접근 방식을 사용하면 무슨 일이 일어나고 있는지 분명하며 병렬 컴퓨팅은 도움이 되지 않습니다. 그렇죠? 올바른 데이터 구조를 선택하기만 하면 성능이 XNUMX배 향상될 수 있는 것으로 나타났습니다. 그리고 이것은 숙련된 프로그래머들조차 놀라게 합니다! 내 특별한 경우에는 핫 루프에서 메모리 할당을 해서는 안 된다는 것이 비결이었습니다. 글쎄, 이것이 전체 진실은 아니지만 일반적으로 X가 충분히 클 때 "X에 한 번"을 강조 표시해서는 안됩니다. X가 XNUMXGB인 경우 "문자당 한 번", "라인당 한 번", "필드당 한 번" 등을 할당해서는 안 됩니다. 이것은 시간이 소비되는 곳입니다. 이것은 어떻게 작동합니까? 내가 전화를 한다고 상상해 보세요 String.split() 또는 BufferedReader.readLine(). Readline 수억 개의 라인 각각에 대해 각 라인에 대해 한 번씩 네트워크를 통해 제공된 바이트 세트에서 문자열을 만듭니다. 나는 이 줄을 가져다가 분석하고 버립니다. 왜 버리는 걸까요? 이미 처리했으니 그게 다입니다. 따라서 이 2.7G에서 읽은 각 바이트에 대해 두 문자, 즉 이미 5.4G가 줄에 기록되며 더 이상 필요하지 않으므로 버려집니다. 메모리 대역폭을 살펴보면 프로세서의 메모리와 메모리 버스를 통과하는 2.7G를 로드한 다음 메모리에 있는 라인에 두 배의 양이 전송되고, 새로운 라인이 생성될 때마다 이 모든 것이 닳아 없어집니다. 하지만 읽어야 합니다. 나중에 모든 것이 닳더라도 하드웨어는 그것을 읽습니다. 그리고 라인을 하나 만들었더니 캐시가 꽉 차서 적어야 합니다. 캐시가 2.7G를 수용할 수 없습니다. 따라서 내가 읽는 모든 바이트에 대해 4바이트를 더 읽고 1바이트를 더 쓰게 되며 결국 XNUMX:XNUMX 비율이 됩니다. 이 비율에서는 메모리 대역폭을 낭비하고 있습니다. 그리고 내가 그렇게 하면 String.split() – 이번이 마지막이 아닙니다. 내부에 6~7개의 필드가 더 있을 수 있습니다. 따라서 CSV를 읽은 다음 문자열을 구문 분석하는 고전적인 코드는 실제로 원하는 메모리 대역폭에 비해 약 14:1의 메모리 대역폭 낭비를 초래합니다. 이러한 선택 사항을 버리면 속도가 XNUMX배 향상될 수 있습니다.

그리고 그렇게 어렵지도 않습니다. 코드를 올바른 각도에서 보면 문제를 깨닫고 나면 모든 것이 매우 간단해집니다. 메모리 할당을 완전히 중단해서는 안 됩니다. 유일한 문제는 무언가를 할당하면 즉시 종료되고 그 과정에서 중요한 리소스(이 경우 메모리 대역폭)가 소모된다는 것입니다. 그리고 이 모든 것이 생산성 저하로 이어집니다. x86에서는 일반적으로 프로세서 주기를 적극적으로 소모해야 하지만 여기서는 훨씬 더 일찍 모든 메모리를 소모합니다. 해결책은 방전량을 줄이는 것입니다. 
문제의 또 다른 부분은 메모리 스트라이프가 부족할 때 프로파일러를 실행하면 일반적으로 캐시가 방금 생성한 모든 라인으로 가득 차 있기 때문에 캐시가 다시 돌아올 때까지 기다리고 있다는 것입니다. 따라서 모든 로드 또는 저장 작업은 캐시 누락으로 이어지기 때문에 느려집니다. 전체 캐시가 느려지고 쓰레기가 떠날 때까지 기다리게 됩니다. 따라서 프로파일러는 전체 루프에 걸쳐 따뜻한 무작위 노이즈가 번진 것으로 표시합니다. 코드에 별도의 핫 명령어나 위치가 없습니다. 소음 만. 그리고 GC 주기를 살펴보면 모두 Young Generation이며 초고속(최대 마이크로초 또는 밀리초)입니다. 결국, 이 모든 기억은 즉시 사라집니다. 수십억 기가바이트를 할당하면 그는 자르고 자르고 또 자르고. 이 모든 일은 매우 빠르게 일어납니다. 저렴한 GC 주기, 전체 주기에 걸쳐 따뜻한 노이즈가 있는 것으로 밝혀졌지만 우리는 5배의 속도 향상을 원합니다. 이 순간 머릿속에서 무언가가 닫히고 소리가 들릴 것입니다. "이게 왜?!" 메모리 스트립 오버플로는 클래식 디버거에 표시되지 않으므로 하드웨어 성능 카운터 디버거를 실행하여 직접 확인해야 합니다. 그러나 이 세 가지 증상만으로는 이를 직접적으로 의심할 수는 없습니다. 세 번째 증상은 강조 표시한 내용을 보고 프로파일러에게 물어보면 "당신은 수십억 개의 행을 만들었지만 GC는 무료로 작동했습니다."라고 대답하는 것입니다. 이런 일이 발생하자마자 당신은 너무 많은 객체를 생성했고 전체 메모리 레인을 태워버렸다는 것을 깨닫게 됩니다. 이를 알아낼 수 있는 방법이 있지만 명확하지는 않습니다. 

문제는 데이터 구조에 있습니다. 발생하는 모든 일의 기반이 되는 기본 구조는 너무 크고 디스크의 용량은 2.7G이므로 이 복사본을 만드는 것은 매우 바람직하지 않습니다. 네트워크 바이트 버퍼에서 즉시 로드하려고 합니다. 라인을 다섯 번 앞뒤로 읽고 쓰지 않도록 레지스터에 넣습니다. 불행하게도 Java는 기본적으로 JDK의 일부로 이러한 라이브러리를 제공하지 않습니다. 하지만 이건 사소한 일이잖아요? 기본적으로 이는 기본 바이트 버퍼 주위의 래퍼 역할을 하면서 문자열 클래스의 동작을 반복하는 자체 버퍼링된 문자열 로더를 구현하는 데 사용되는 5~10줄의 코드입니다. 결과적으로 거의 문자열을 사용하는 것처럼 작업하고 있지만 실제로는 버퍼에 대한 포인터가 그곳으로 이동하고 원시 바이트가 어디에도 복사되지 않으므로 동일한 버퍼가 계속해서 재사용됩니다. 운영 체제는 이러한 바이트 버퍼의 숨겨진 이중 버퍼링과 같이 설계된 작업을 스스로 수행하므로 더 이상 불필요한 데이터의 끝없는 스트림을 헤쳐 나가지 않아도 됩니다. 그런데 GC로 작업할 때 마지막 GC 주기 이후 각 메모리 할당이 프로세서에 표시되지 않는다는 것이 보장된다는 점을 이해하시나요? 따라서 이 모든 것이 캐시에 있을 수 없으며 100% 보장된 누락이 발생합니다. x86에서 포인터로 작업할 때 메모리에서 레지스터를 빼는 데는 1-2 클럭 사이클이 걸리고, 이 일이 발생하자마자 메모리가 모두 켜져 있기 때문에 지불하고 지불하고 지불합니다. XNUMX개의 캐시 – 이것이 메모리 할당 비용입니다. 실제 가치.

즉, 데이터 구조는 변경하기 가장 어려운 것입니다. 그리고 나중에 성능을 저하시킬 잘못된 데이터 구조를 선택했다는 사실을 깨닫고 나면 일반적으로 수행해야 할 작업이 많지만 그렇지 않으면 상황이 더욱 악화됩니다. 우선, 데이터 구조에 대해 생각해야 합니다. 이것이 중요합니다. 여기서 주요 비용은 "Y의 모양이 더 좋기 때문에 데이터 구조 X를 데이터 구조 Y에 복사했습니다."라는 스타일로 사용되기 시작한 뚱뚱한 데이터 구조에 있습니다. 그러나 복사 작업(저렴해 보이는)은 실제로 메모리 대역폭을 낭비하며 낭비되는 실행 시간이 모두 여기에 묻혀 있습니다. 거대한 JSON 문자열이 있고 이를 POJO 등의 구조화된 DOM 트리로 변환하려는 경우 해당 문자열을 구문 분석하고 POJO를 빌드한 다음 나중에 다시 POJO에 액세스하는 작업은 불필요한 비용을 초래합니다. 저렴하지 않습니다. POJO를 문자열 주위에서 실행하는 것보다 훨씬 더 자주 실행하는 경우는 제외됩니다. 대신 POJO로 변환하지 않고 문자열을 해독하고 거기에서 필요한 것만 추출할 수 있습니다. 이 모든 것이 최대 성능이 필요한 경로에서 발생하고 POJO가 없으면 어떻게든 직접 라인을 파헤쳐야 합니다.

자신만의 프로그래밍 언어를 만드는 이유

앤드류: 비용 모델을 이해하려면 자신만의 작은 언어를 작성해야 한다고 하셨는데…

낭떠러지: 언어가 아니라 컴파일러입니다. 언어와 컴파일러는 서로 다른 것입니다. 가장 중요한 차이점은 머리에 있습니다. 

앤드류: 그런데 제가 아는 한, 당신은 자신만의 언어를 만드는 실험을 하고 있는 것으로 알고 있습니다. 무엇을 위해?

낭떠러지: 할 수 있으니까! 나는 반쯤 은퇴했기 때문에 이것이 내 취미입니다. 나는 평생 동안 다른 사람의 언어를 구현해 왔습니다. 나는 또한 내 코딩 스타일에 많은 노력을 기울였습니다. 또한 다른 언어에도 문제가 있기 때문입니다. 익숙한 일을 하는 데 더 좋은 방법이 있다는 것을 알았습니다. 그리고 나는 그것을 사용할 것입니다. 나는 자바, 파이썬, 다른 언어에서 나 자신의 문제를 보는 것에 지쳤습니다. 이제는 은퇴가 아닌 활발한 활동을 위한 취미로 React Native, JavaScript, Elm으로 글을 쓰고 있습니다. 나는 또한 Python으로 글을 쓰고 있으며 아마도 Java 백엔드를 위한 기계 학습 작업을 계속할 것입니다. 널리 사용되는 언어가 많이 있으며 모두 흥미로운 기능을 가지고 있습니다. 모든 사람은 각자의 방식으로 훌륭하며 이러한 모든 기능을 하나로 통합하려고 노력할 수 있습니다. 그래서 저는 관심 있는 것, 즉 언어의 행동을 연구하고 합리적인 의미론을 찾아내려고 노력하고 있습니다. 그리고 지금까지 나는 성공하고 있습니다! 현재 저는 메모리 의미론에 어려움을 겪고 있습니다. C와 Java처럼 메모리 의미론을 갖고 로드와 저장을 위한 강력한 메모리 모델과 메모리 의미론을 얻고 싶기 때문입니다. 동시에 Haskell처럼 자동 유형 추론도 가능합니다. 여기서는 Haskell과 유사한 유형 추론을 C와 Java의 메모리 작업과 혼합하려고 합니다. 예를 들어 이것이 제가 지난 2~3개월 동안 해온 일입니다.

앤드류: 당신이 다른 언어의 더 나은 측면을 취하는 언어를 만든다면, 누군가는 그 반대의 일을 할 것이라고 생각합니까? 즉, 당신의 아이디어를 취하고 그것을 사용할 것입니까?

낭떠러지: 이것이 바로 새로운 언어가 나타나는 방식입니다! Java가 C와 유사한 이유는 무엇입니까? C에는 모두가 이해할 수 있는 좋은 구문이 있었고 Java는 이 구문에서 영감을 받아 유형 안전성, 배열 범위 검사, GC를 추가했으며 C에서 몇 가지 사항도 개선했습니다. 그들은 자신의 것을 추가했습니다. 하지만 그들은 꽤 많은 영감을 받았죠? 모두가 당신보다 먼저 온 거인의 어깨 위에 서 있습니다. 그것이 발전이 이루어지는 방식입니다.

앤드류: 내가 이해하는 바에 따르면, 귀하의 언어는 메모리에 안전할 것입니다. Rust의 빌림 검사기와 같은 것을 구현하는 것에 대해 생각해 보셨나요? 그를 보셨나요? 그에 대해 어떻게 생각하시나요?

낭떠러지: 글쎄요, 저는 이 모든 malloc과 무료를 포함하고 수명을 수동으로 관리하면서 오랫동안 C를 작성해 왔습니다. 수동으로 제어되는 수명의 90~95%는 동일한 구조를 가지고 있습니다. 그리고 수동으로 수행하는 것은 매우 고통스럽습니다. 나는 컴파일러가 거기에서 무슨 일이 일어나고 있는지, 그리고 당신의 행동으로 무엇을 성취했는지 간단히 말해 주기를 바랍니다. 어떤 경우에는 빌림 검사기가 이 작업을 즉시 수행합니다. 그리고 자동으로 정보를 표시하고, 모든 것을 이해해야 하며, 이러한 이해를 제시하는 데 부담을 주지도 않아야 합니다. 최소한 로컬 이스케이프 분석을 수행해야 하며, 실패한 경우에만 수명을 설명하는 유형 주석을 추가해야 합니다. 이러한 체계는 빌림 검사기나 실제로 기존 메모리 검사기보다 훨씬 더 복잡합니다. "모든 것이 괜찮아요"와 "아무것도 이해가 안 돼요" 사이의 선택 - 아니, 더 나은 것이 있어야합니다. 
그래서 C로 많은 코드를 작성해 본 사람으로서 자동 수명 제어 기능을 지원하는 것이 가장 중요하다고 생각합니다. 나는 또한 Java가 메모리를 얼마나 많이 사용하는지에 질려 있고 주요 불만 사항은 GC입니다. Java에서 메모리를 할당하면 마지막 GC 주기에 로컬이었던 메모리를 다시 가져오지 않습니다. 보다 정확한 메모리 관리 기능을 갖춘 언어에서는 그렇지 않습니다. malloc을 호출하면 평소 방금 사용했던 메모리를 즉시 얻게 된다. 일반적으로 메모리를 사용하여 일시적인 작업을 수행하고 즉시 다시 반환합니다. 그리고 즉시 malloc 풀로 돌아가고, 다음 malloc 주기에서 다시 꺼내옵니다. 따라서 실제 메모리 사용량은 특정 시간에 살아있는 개체 집합과 누수로 줄어듭니다. 그리고 모든 것이 완전히 외설적인 방식으로 누출되지 않으면 대부분의 메모리가 캐시와 프로세서에 들어가고 빠르게 작동합니다. 그러나 올바른 위치에서 올바른 순서로 호출되는 malloc 및 free를 사용하여 많은 수동 메모리 관리가 필요합니다. Rust는 이를 자체적으로 적절하게 처리할 수 있으며, 많은 경우에 훨씬 더 나은 성능을 제공합니다. 메모리 소비가 메모리를 확보하기 위해 다음 GC 주기를 기다리는 것과는 반대로 현재 계산으로만 좁혀지기 때문입니다. 그 결과 우리는 성능을 향상시킬 수 있는 매우 흥미로운 방법을 얻었습니다. 그리고 매우 강력합니다. 핀테크를 위한 데이터를 처리할 때 이러한 작업을 수행했고 이로 인해 약 XNUMX배의 속도 향상을 얻을 수 있었습니다. 이는 특히 프로세서가 더 빨라지지 않고 여전히 개선을 기다리고 있는 세상에서 매우 큰 향상입니다.

성능 엔지니어 경력

앤드류: 전반적인 직업에 대해서도 여쭤보고 싶습니다. HotSpot에서 JIT 작업으로 두각을 나타낸 후 JVM 회사인 Azul로 옮겼습니다. 하지만 우리는 이미 소프트웨어보다 하드웨어에 더 많은 노력을 기울이고 있었습니다. 그러다가 갑자기 빅데이터와 머신러닝으로 전환했다가 사기 탐지로 전환했습니다. 어떻게 이런일이 일어 났습니까? 이들은 매우 다른 개발 영역입니다.

낭떠러지: 저는 꽤 오랫동안 프로그래밍을 해왔고 다양한 수업을 많이 들어왔습니다. 그리고 사람들이 "아, 당신이 Java용 JIT를 한 사람이군요!"라고 말하면 항상 웃깁니다. 하지만 그 전에 저는 Apple이 한때 레이저 프린터에 사용했던 언어인 PostScript 복제 작업을 하고 있었습니다. 그리고 그 전에 저는 Forth 언어를 구현했습니다. 저의 공통 주제는 도구 개발이라고 생각합니다. 나는 평생 동안 다른 사람들이 멋진 프로그램을 작성하는 데 사용할 수 있는 도구를 만들어 왔습니다. 하지만 저는 운영 체제, 드라이버, 커널 수준 디버거, OS 개발용 언어 개발에도 참여했는데, 처음에는 사소한 일이었지만 시간이 지나면서 점점 더 복잡해졌습니다. 그러나 주요 주제는 여전히 도구 개발입니다. 내 인생의 큰 부분이 Azul과 Sun 사이를 오갔고, 그것은 Java에 관한 것이었습니다. 하지만 빅데이터와 머신러닝에 입문했을 때 저는 다시 멋진 모자를 쓰고 이렇게 말했습니다. "아, 이제 우리에게는 사소한 문제가 생겼는데, 흥미로운 일이 많이 일어나고 사람들이 일을 하고 있습니다." 이는 훌륭한 개발 경로입니다.

네, 저는 분산 컴퓨팅을 정말 좋아합니다. 나의 첫 번째 직업은 광고 프로젝트에서 C를 공부하는 학생이었습니다. 이는 실제 아날로그 분석기로 생성된 아날로그 OCR용 데이터를 수집한 Zilog Z80 칩의 분산 컴퓨팅이었습니다. 그것은 시원하고 완전히 미친 주제였습니다. 하지만 문제가 있었고, 어떤 부분이 제대로 인식되지 않아서 사진을 꺼내서 이미 눈으로 읽고 내용을 보고할 수 있는 사람에게 보여줘야 했기 때문에 데이터가 있는 직업이 있었고, 이런 직업이 있었습니다. 그들만의 언어가 있었다. 이 모든 것을 처리하는 백엔드가 있었습니다. vt80 터미널이 병렬로 실행되는 Z100은 80인당 하나씩 실행되었으며 Z80에는 병렬 프로그래밍 모델이 있었습니다. 스타 구성 내의 모든 Z80이 공유하는 일부 공통 메모리 조각입니다. 백플레인도 공유되었으며 RAM의 절반은 네트워크 내에서 공유되었고 나머지 절반은 개인용이거나 다른 곳으로 이동했습니다. 공유된 반공유 메모리를 갖춘 의미있고 복잡한 병렬 분산 시스템입니다. 이게 언제였는지... 기억도 안나는데 XNUMX년대 중반쯤이었나. 꽤 오래 전입니다. 
네, 30년이 꽤 오래 전 일이라고 가정해 봅시다. 분산 컴퓨팅과 관련된 문제는 꽤 오랫동안 존재해 왔습니다. 베오울프-클러스터. 이러한 클러스터는 다음과 같습니다... 예를 들어 이더넷이 있고 빠른 x86이 이 이더넷에 연결되어 있는데 이제 가짜 공유 메모리를 얻으려고 합니다. 그 당시에는 누구도 분산 컴퓨팅 코딩을 할 수 없었기 때문에 너무 어려웠기 때문에 거기에 있었습니다. x86의 보호 메모리 페이지가 있는 가짜 공유 메모리였으며, 만약 당신이 이 페이지에 썼다면 우리는 다른 프로세서에게 그들이 동일한 공유 메모리에 접근한다면 당신에게서 로드되어야 한다고 말했고, 따라서 지원을 위한 프로토콜과 같은 것입니다. 캐시 일관성이 나타나고 이를 위한 소프트웨어가 등장했습니다. 흥미로운 개념. 물론 진짜 문제는 다른 데 있었습니다. 이 모든 것이 효과가 있었지만 어느 누구도 충분히 좋은 수준의 성능 모델(어떤 메모리 액세스 패턴이 있었는지, 노드가 끝없이 서로 핑하지 않았는지 확인하는 방법 등)을 이해하지 못했기 때문에 빨리 성능 문제가 발생했습니다.

제가 H2O에서 생각해낸 것은 병렬성이 숨겨져 있는 곳과 그렇지 않은 곳을 결정하는 책임은 개발자 자신이라는 것입니다. 나는 고성능 코드를 쉽고 간단하게 작성할 수 있는 코딩 모델을 생각해냈습니다. 하지만 느리게 실행되는 코드를 작성하는 것은 어렵습니다. 보기에도 좋지 않을 것입니다. 느린 코드를 작성하려면 진지하게 노력해야 하며, 비표준 방법을 사용해야 합니다. 제동 코드는 한눈에 보입니다. 결과적으로 일반적으로 빠르게 실행되는 코드를 작성하지만 공유 메모리의 경우 어떻게 해야 할지 파악해야 합니다. 이 모든 것은 대규모 배열과 연결되어 있으며 동작은 병렬 Java의 비휘발성 대규모 배열과 유사합니다. 내 말은, 두 개의 스레드가 병렬 배열에 기록하고 그 중 하나가 승리하고 다른 스레드가 그에 따라 패배하며 어느 것이 어느 것인지 알 수 없다고 상상해보십시오. 휘발성이 아니라면 원하는 대로 순서를 정할 수 있으며 이는 정말 잘 작동합니다. 사람들은 작업 순서에 큰 관심을 갖고 휘발성을 올바른 위치에 배치하며 메모리 관련 성능 문제를 올바른 위치에 기대합니다. 그렇지 않으면 모든 복잡한 사례가 자동으로 병렬화되기를 바라면서 1에서 N까지의 루프 형태로 코드를 작성할 것입니다. 여기서는 작동하지 않습니다. 그러나 H2O에서는 이는 Java도 아니고 Scala도 아니며 원하는 경우 "Java 마이너스 마이너스"라고 생각할 수 있습니다. 이는 매우 명확한 프로그래밍 스타일이며 루프와 배열을 사용하여 간단한 C 또는 Java 코드를 작성하는 것과 유사합니다. 그러나 동시에 메모리는 테라바이트 단위로 처리될 수 있습니다. 나는 아직도 H2O를 사용한다. 나는 때때로 다른 프로젝트에서 그것을 사용합니다. 그리고 그것은 여전히 ​​​​가장 빠른 것입니다. 경쟁사보다 수십 배 빠릅니다. 컬럼형 데이터로 빅데이터를 수행하는 경우 H2O를 이기기가 매우 어렵습니다.

기술적 과제

앤드류: 당신의 경력 전체에서 가장 큰 도전은 무엇이었나요?

낭떠러지: 문제의 기술적인 부분을 논의하고 있나요, 아니면 비기술적인 부분을 논의하고 있나요? 가장 큰 과제는 기술적 문제가 아니라고 말하고 싶습니다. 
기술적 과제에 관해서는. 나는 단지 그들을 이겼을 뿐입니다. 가장 큰 것이 무엇인지조차 모르겠지만, 꽤 시간이 걸리고 정신적 어려움을 겪는 꽤 흥미로운 것들이 있었습니다. Sun에 갔을 때 나는 빠른 컴파일러를 만들 것이라고 확신했고, 많은 선배들은 결코 성공하지 못할 것이라고 대답했습니다. 하지만 저는 이 경로를 따라 레지스터 할당자에 컴파일러를 작성했는데 꽤 빨랐습니다. 최신 C1만큼 빠르지만 할당자는 그 당시 훨씬 느렸고 돌이켜보면 큰 데이터 구조 문제였습니다. 그래픽 레지스터 할당자를 작성하는 데 필요했고 그 시대에 존재했고 매우 중요했던 코드 표현성과 속도 사이의 딜레마를 이해하지 못했습니다. 데이터 구조는 일반적으로 당시 x86의 캐시 크기를 초과하므로 처음에 레지스터 할당자가 총 지터 시간의 5-10%를 처리할 것이라고 가정했다면 실제로는 다음과 같은 것으로 나타났습니다. 50퍼센트.

시간이 지남에 따라 컴파일러는 더 깨끗해지고 효율적이게 되었으며 더 이상 끔찍한 코드 생성이 중단되었으며 성능은 점차 C 컴파일러가 생성하는 것과 비슷해졌습니다. 물론 C조차도 속도를 높이지 못하는 쓰레기를 작성하지 않는 한 말이죠. . C와 같은 코드를 작성하면 더 많은 경우에 C와 같은 성능을 얻을 수 있습니다. 그리고 더 나아갈수록, 레벨 C와 점근적으로 일치하는 코드를 더 자주 얻게 되고, 레지스터 할당자는 코드가 빠르게 실행되는지 느리게 실행되는지에 관계없이 완전한 것으로 보이기 시작했습니다. 나는 더 나은 선택을 만들기 위해 할당자 작업을 계속했습니다. 그는 점점 더 느려졌지만, 누구도 감당할 수 없는 상황에서는 점점 더 좋은 성과를 냈다. 레지스터 할당자로 들어가서 거기에 한 달 간의 작업을 묻어두면 갑자기 전체 코드가 5% 더 빠르게 실행되기 시작할 수 있습니다. 이런 일이 계속해서 발생했고 레지스터 할당자는 일종의 예술 작품이 되었습니다. 모두가 그것을 좋아하거나 싫어했고, 아카데미 사람들은 "모든 것이 왜 이런 식으로 수행되는지"라는 주제에 대해 질문했습니다. 라인 스캔, 그리고 차이점은 무엇입니까? 대답은 여전히 ​​동일합니다. 그래프 색상에 기반한 할당자와 버퍼 코드에 대한 매우 세심한 작업은 누구도 이길 수 없는 최고의 조합인 승리의 무기와 같습니다. 그리고 이것은 다소 분명하지 않은 것입니다. 컴파일러가 수행하는 다른 모든 작업은 상당히 잘 연구되었지만 예술 수준까지 올라갔습니다. 나는 항상 컴파일러를 예술 작품으로 만드는 일을 했습니다. 그러나 레지스터 할당자를 제외하고는 이 중 어느 것도 특별한 것이 아닙니다. 비결은 조심하는 것 줄이다 부하가 걸리고 이런 일이 발생하면(관심이 있으면 더 자세히 설명할 수 있음) 이는 성능 일정에 문제가 생길 위험 없이 더 적극적으로 인라인할 수 있음을 의미합니다. 그 당시에는 레지스터 할당자가 있고 장신구와 휘파람 소리를 내는 본격적인 컴파일러가 많이 있었지만 다른 누구도 그것을 할 수 없었습니다.

문제는 인라인 처리되는 메소드를 추가하고 인라인 영역을 늘리고 늘리면 사용되는 값 집합이 즉시 레지스터 수를 뛰어넘어 잘라야 한다는 점이다. 임계 수준은 일반적으로 할당자가 포기하고 유출에 대한 좋은 후보 하나가 다른 가치가 있을 때 발생합니다. 일반적으로 야생 물건을 판매하게 됩니다. 여기서 인라인 처리의 가치는 오버헤드의 일부, 호출 및 저장에 대한 오버헤드가 손실되고, 내부 값을 볼 수 있으며 이를 더욱 최적화할 수 있다는 것입니다. 인라인 처리의 비용은 수많은 라이브 값이 형성된다는 점이며, 레지스터 할당자가 필요 이상으로 소진되면 즉시 손실을 입게 됩니다. 따라서 대부분의 할당자에게는 문제가 있습니다. 인라인이 특정 선을 넘으면 세상의 모든 것이 축소되기 시작하고 생산성이 변기에서 쏟아져 나올 수 있습니다. 컴파일러를 구현하는 사람들은 몇 가지 경험적 방법을 추가합니다. 예를 들어 할당으로 인해 모든 것이 망가질 수 있으므로 인라인을 중지하고 충분히 큰 크기로 시작하는 것입니다. 이것이 성능 그래프의 꼬임이 형성되는 방식입니다. 인라인, 인라인, 성능이 천천히 증가한 다음 폭발합니다! – 줄을 너무 많이 쳐서 스위프트 잭처럼 떨어집니다. 이것이 Java가 출현하기 전에 모든 것이 작동했던 방식이었습니다. Java에는 훨씬 더 많은 인라인이 필요하므로 할당자를 훨씬 더 공격적으로 만들어 충돌이 발생하지 않고 수평을 유지하도록 해야 했습니다. 너무 많이 인라인하면 유출되기 시작하지만 "더 이상 유출이 없는" 순간은 여전히 ​​옵니다. 이것은 흥미로운 관찰이며 갑자기 나에게 나타났습니다. 명확하지는 않지만 좋은 성과를 거두었습니다. 저는 공격적인 인라인을 채택했고 이를 통해 Java와 C 성능이 나란히 작동하는 곳으로 이동했습니다. 그들은 정말 가깝습니다. C 코드보다 훨씬 빠른 Java 코드를 작성할 수 있지만 평균적으로 큰 그림에서는 거의 비슷합니다. 내 생각에 이 장점의 일부는 레지스터 할당자인데, 이를 통해 가능한 한 멍청하게 인라인을 수행할 수 있습니다. 나는 내가 보는 모든 것을 인라인합니다. 여기서 질문은 할당자가 잘 작동하는지, 결과가 지능적으로 작동하는 코드인지 여부입니다. 이 모든 것을 이해하고 실행하는 것은 큰 도전이었습니다.

레지스터 할당과 멀티 코어에 대해 조금

블라디미르: 레지스터 할당과 같은 문제는 일종의 영원하고 끝없는 주제처럼 보입니다. 유망해 보였지만 실제로는 실패한 아이디어가 있었는지 궁금합니다.

낭떠러지: 틀림없이! 레지스터 할당은 NP-완전 문제를 해결하기 위해 몇 가지 경험적 방법을 찾으려는 영역입니다. 그리고 결코 완벽한 솔루션을 얻을 수는 없습니다. 그렇죠? 이것은 단순히 불가능합니다. 보세요, Ahead of Time 컴파일도 제대로 작동하지 않습니다. 여기의 대화는 몇 가지 일반적인 경우에 관한 것입니다. 일반적인 성능에 대해, 좋은 일반적인 성능이라고 생각되는 것을 측정할 수 있습니다. 결국 이를 개선하기 위해 노력하고 있는 것입니다! 레지스터 할당은 성능에 관한 모든 주제입니다. 첫 번째 프로토타입이 완성되면 작동하고 필요한 것을 칠한 후 성능 작업이 시작됩니다. 잘 측정하는 법을 배워야합니다. 왜 중요 함? 명확한 데이터가 있다면 다양한 영역을 살펴보고 확인할 수 있습니다. 예, 여기서는 도움이 되었지만 모든 것이 깨졌습니다! 좋은 아이디어가 떠오르고 새로운 경험적 방법을 추가하면 갑자기 모든 것이 평균적으로 조금 더 잘 작동하기 시작합니다. 아니면 시작되지 않습니다. 이전 할당자와 개발을 차별화하는 XNUMX% 성능을 위해 싸우는 경우가 많이 있었습니다. 그리고 매번 다음과 같이 보입니다. 당신이 승리하는 곳과 패배하는 곳. 좋은 성과 분석 도구가 있다면 잃어버린 아이디어를 찾고 그것이 실패한 이유를 이해할 수 있습니다. 어쩌면 모든 것을 그대로 두는 것이 가치가 있을 수도 있고, 미세 조정에 좀 더 진지하게 접근하거나, 나가서 다른 것을 고치는 것이 가치가 있을 수도 있습니다. 그것은 많은 것들입니다! 저는 이 멋진 꿀팁을 만들었지만 이것도 필요합니다. 이 것, 이것, 그리고 이것이 필요합니다. 그리고 그것들의 총체적인 조합은 약간의 개선을 제공합니다. 그리고 외톨이는 실패할 수도 있습니다. 이것이 NP-완전 문제에 대한 수행 작업의 특성입니다.

블라디미르: 할당자에 그림을 그리는 것과 같은 문제는 이미 해결된 문제라는 느낌을 받습니다. 글쎄요, 당신이 말하는 대로 판단하면 그것은 당신을 위해 결정된 것입니다. 그렇다면 그럴만한 가치가 있습니까?

낭떠러지: 그 자체로는 해결되지 않습니다. 그것을 '해결'로 바꿔야 하는 사람은 바로 당신입니다. 어려운 문제가 있고 해결해야 합니다. 이 작업이 완료되면 생산성을 높이기 위해 작업할 시간입니다. 이에 따라 이 작업에 접근해야 합니다. 벤치마크를 수행하고, 지표를 수집하고, 이전 버전으로 롤백할 때 이전 해킹이 다시 작동하기 시작하거나 그 반대의 경우 상황을 설명합니다. 그리고 뭔가를 이룰 때까지 포기하지 마세요. 이미 말했듯이, 효과가 없는 멋진 아이디어가 있지만 아이디어 레지스터 할당 분야에서는 거의 끝이 없습니다. 예를 들어 과학 출판물을 읽을 수 있습니다. 이제 이 영역은 젊었을 때보다 훨씬 더 느리게 움직이기 시작했고 더 명확해졌습니다. 하지만 이 분야에는 셀 수 없이 많은 사람들이 일하고 있으며 그들의 모든 아이디어는 시도해 볼 가치가 있으며 모두가 기다리고 있습니다. 그리고 시도해 보지 않으면 그것이 얼마나 좋은지 알 수 없습니다. 할당자는 많은 일을 수행하고 일부 아이디어는 특정 할당자에서는 작동하지 않지만 다른 할당자에서는 쉽게 작동하기 때문에 할당자의 다른 모든 것과 얼마나 잘 통합됩니까? 할당자가 승리하는 주요 방법은 느린 항목을 기본 경로 외부로 끌어와 느린 경로의 경계를 따라 강제로 분할하는 것입니다. 따라서 GC를 실행하고 느린 경로를 택하고, 최적화를 취소하고, 예외를 발생시키는 등의 모든 작업을 수행하려는 경우 이러한 작업이 상대적으로 드물다는 것을 알고 있습니다. 그리고 그런 경우는 정말 드물다고 확인해 봤습니다. 추가 작업을 수행하면 이러한 느린 경로에 대한 많은 제한이 제거되지만 속도가 느리고 거의 이동하지 않기 때문에 실제로 중요하지 않습니다. 예를 들어, 널 포인터는 절대 발생하지 않습니다. 그렇죠? 다양한 작업을 수행하려면 여러 경로가 필요하지만 주요 경로를 방해해서는 안 됩니다. 

블라디미르: 수천 개의 코어가 동시에 존재하는 멀티 코어에 대해 어떻게 생각하시나요? 이것이 유용한 것입니까?

낭떠러지: GPU의 성공은 그것이 매우 유용하다는 것을 보여줍니다!

블라디미르: 상당히 전문적입니다. 범용 프로세서는 어떻습니까?

낭떠러지: 그게 바로 Azul의 비즈니스 모델이었죠. 사람들이 예측 가능한 성능을 정말 좋아하던 시대에 그 대답이 돌아왔습니다. 그 당시에는 병렬 코드를 작성하는 것이 어려웠습니다. H2O 코딩 모델은 확장성이 뛰어나지만 범용 모델은 아닙니다. 아마도 GPU를 사용할 때보다 조금 더 일반적일 것입니다. 그런 것을 개발하는 것의 복잡성이나 그것을 사용하는 것의 복잡성에 대해 이야기하고 있습니까? 예를 들어 Azul은 나에게 다소 명확하지 않은 흥미로운 교훈을 가르쳐주었습니다. 작은 캐시는 정상입니다. 

인생의 가장 큰 도전

블라디미르: 기술적이지 않은 과제는 어떻습니까?

낭떠러지: 가장 큰 도전은... 사람들에게 친절하고 친절하게 대하는 것이 아니었습니다. 그 결과 나는 극도의 갈등 상황에 끊임없이 직면했습니다. 일이 잘못되고 있다는 것을 알았지만 그 문제를 어떻게 해결해야 할지 모르고 처리할 수 없었던 사람들이었습니다. 수십 년 동안 지속된 많은 장기적인 문제가 이런 식으로 발생했습니다. Java에 C1 및 C2 컴파일러가 있다는 사실은 이에 따른 직접적인 결과입니다. 자바에서 XNUMX년 연속 다단계 컴파일이 없었다는 것도 직접적인 결과다. 그러한 시스템이 필요하다는 것은 분명하지만 왜 존재하지 않았는지는 분명하지 않습니다. 엔지니어 한 명이나 엔지니어 그룹과 문제가 있었습니다. 옛날 옛적에 Sun에서 일을 시작했을 때 나는... 알았어, 그때뿐만 아니라 나는 일반적으로 모든 것에 대해 항상 내 의견을 가지고 있었습니다. 그리고 나는 당신이 이 진실을 받아들이고 정면으로 말할 수 있다는 것이 사실이라고 생각했습니다. 특히 나는 대부분의 경우 놀랍게도 옳았 기 때문에 더욱 그렇습니다. 그리고 만약 당신이 이 접근 방식을 좋아하지 않는다면... 특히 당신이 분명히 틀렸고 말도 안되는 일을 하고 있다면... 일반적으로 이런 형태의 의사소통을 용인할 수 있는 사람은 거의 없습니다. 나처럼 일부는 그럴 수 있지만. 나는 내 인생 전체를 능력주의 원칙 위에 세워왔습니다. 당신이 나에게 잘못된 것을 보여 주면 나는 즉시 돌아 서서 말할 것입니다 : 당신은 말도 안되는 말을했습니다. 동시에 사과드리며, 장점이 있다면 지적하고 다른 올바른 조치를 취하겠습니다. 반면에, 전체 시간의 놀랍게도 큰 비율에 대해서는 내 말이 옳습니다. 그리고 사람들과의 관계에서는 잘 작동하지 않습니다. 친절하게 대할 생각은 없지만 직설적으로 질문드립니다. "이건 절대 안 될 것 같아요. 하나, 둘, 셋이니까요." 그리고 그들은 "오!"라고 말했습니다. 무시하는 것이 더 나은 다른 결과도 있었습니다. 예를 들어, 아내와의 이혼으로 이어졌고 그 후 XNUMX년 동안 우울증을 겪게 된 결과가 있습니다.

도전은 당신이 할 수 있는 것과 할 수 없는 것, 중요한 것과 그렇지 않은 것에 대한 사람들의 인식과의 투쟁입니다. 코딩 스타일에 대한 어려움이 많았습니다. 나는 아직도 코드를 많이 작성하는데, 그 당시에는 하나에 집중하기보다 병렬 작업을 너무 많이 하고 제대로 수행하지 못해서 속도를 늦춰야 하기도 했습니다. 되돌아보면 Java JIT 명령인 C2 명령에 대한 코드의 절반을 작성했습니다. 그 다음으로 빠른 코더는 절반은 느리게, 그 다음 절반은 느리게 작성했는데, 이는 기하급수적으로 감소했습니다. 이 줄의 일곱 번째 사람은 매우 느렸습니다. 항상 그런 일이 일어났습니다! 코드를 많이 만졌습니다. 나는 누가 무엇을 썼는지 살펴보았는데, 예외 없이 그들의 코드를 쳐다보고, 각각의 코드를 검토했으며, 여전히 그들 중 누구보다 더 많은 것을 직접 작성했습니다. 이 접근 방식은 사람들에게는 잘 작동하지 않습니다. 어떤 사람들은 이것을 좋아하지 않습니다. 그리고 이를 감당하지 못하면 온갖 불만이 터지기 시작한다. 예를 들어, 코드를 너무 많이 작성하면 팀이 위험해진다는 이유로 코딩을 중단하라는 말을 들었습니다. 이 모든 것이 나에게는 농담처럼 들렸습니다. 친구, 나머지 팀원이 사라지고 계속 코드를 작성하면 절반만 팀을 잃게 됩니다. 반면에 내가 계속해서 코드를 작성했는데 팀의 절반을 잃게 된다면 관리가 매우 나쁜 것처럼 들립니다. 그것에 대해 깊이 생각해 본 적도 없고, 이야기한 적도 없지만, 그 생각은 여전히 ​​내 머릿속 어딘가에 남아 있었습니다. 내 마음 한구석에는 “농담하는 거야?”라는 생각이 맴돌았습니다. 그래서 가장 큰 문제는 나와 사람들과의 관계였습니다. 이제 나는 내 자신을 훨씬 더 잘 이해하고 오랫동안 프로그래머의 팀 리더였으며 이제는 사람들에게 직접 말합니다. 알다시피 나는 나이고 당신은 나를 상대해야 할 것입니다. 내가 서 있어도 괜찮습니까? 여기? 그리고 그들이 그것을 다루기 시작했을 때 모든 것이 잘 작동했습니다. 사실 나는 나쁘지도 착하지도 않고, 나쁜 의도나 이기적인 열망도 없고, 그것은 단지 나의 본질이고, 어떻게든 살아가야 합니다.

앤드류: 최근에 모두가 내성적인 사람의 자기 인식과 일반적인 소프트 스킬에 대해 이야기하기 시작했습니다. 이것에 대해 무엇을 말할 수 있습니까?

낭떠러지: 네, 그게 제가 아내와의 이혼을 통해 배운 통찰이자 교훈이었습니다. 이혼을 통해 배운 것은 나 자신을 이해하는 것이었다. 이것이 제가 다른 사람들을 이해하기 시작한 방법입니다. 이 상호 작용이 어떻게 작동하는지 이해하십시오. 이것이 잇따라 발견으로 이어졌습니다. 내가 누구인지, 내가 무엇을 대표하는지에 대한 인식이 있었습니다. 내가 무엇을 하고 있는지: 나는 일에 몰두하고 있거나 갈등을 피하고 있거나 다른 일을 하고 있습니다. 이러한 수준의 자기 인식은 나 자신을 통제하는 데 실제로 도움이 됩니다. 그 후에는 모든 것이 훨씬 쉬워집니다. 나 자신뿐만 아니라 다른 프로그래머에게서도 내가 발견한 한 가지는 감정적 스트레스 상태에 있을 때 생각을 말로 표현할 수 없다는 것입니다. 예를 들어, 당신이 거기 앉아서 몰입한 상태로 코딩을 하고 있는데, 그들이 당신에게 달려와 뭔가가 망가졌다고 히스테리하게 비명을 지르기 시작하면 이제 당신에게 극단적인 조치가 취해질 것입니다. 그리고 감정적으로 스트레스를 받은 상태라 한마디도 할 수 없습니다. 습득한 지식을 통해 이 순간을 준비하고, 생존하고, 퇴각 계획으로 넘어간 후 뭔가를 할 수 있습니다. 그렇습니다. 모든 것이 어떻게 작동하는지 깨닫기 시작하면 인생을 바꾸는 엄청난 사건이 됩니다. 
나 자신도 올바른 단어를 찾을 수 없었지만 일련의 행동을 기억했습니다. 요점은 이 반응이 언어적 반응만큼이나 육체적이므로 공간이 필요하다는 것입니다. 젠(Zen)의 의미에서 그런 공간. 이것이 바로 설명되어야 할 사항이며, 즉시 물러나십시오. 순전히 물리적으로 물러나십시오. 말로 침묵하면 감정적으로 상황을 처리할 수 있다. 아드레날린이 두뇌에 도달하면 전투 또는 비행 모드로 전환되고 더 이상 아무 말도 할 수 없습니다. 이제 당신은 바보이고 채찍질하는 엔지니어이며 적절한 대응도 불가능하고 공격을 중지할 수도 없으며 공격자는 자유로워집니다. 계속해서 공격합니다. 당신은 먼저 다시 당신 자신이 되어야 하고, 통제력을 회복하고, "투쟁 또는 도피" 모드에서 벗어나야 합니다.

이를 위해서는 언어적 공간이 필요합니다. 그냥 여유 공간. 당신이 무엇이든 말한다면, 당신은 정확히 그렇게 말하고 가서 정말로 자신을 위한 "공간"을 찾을 수 있습니다. 공원에서 산책을 하고, 샤워실에 몸을 가두십시오. 그것은 중요하지 않습니다. 가장 중요한 것은 해당 상황에서 일시적으로 연결을 끊는 것입니다. 최소한 몇 초 동안 스위치를 끄자마자 제어력이 회복되고 냉정하게 생각하기 시작합니다. "알겠습니다. 저는 바보가 아닙니다. 저는 어리석은 짓을 하지 않습니다. 저는 꽤 유용한 사람입니다." 자신을 설득할 수 있게 되면 이제 다음 단계인 무슨 일이 일어났는지 이해하는 단계로 넘어갈 시간입니다. 당신은 공격을 받았습니다. 공격은 당신이 예상하지 못한 곳에서 일어났습니다. 그것은 부정직하고 사악한 매복이었습니다. 이것은 나쁘다. 다음 단계는 공격자에게 이것이 왜 필요한지 이해하는 것입니다. 정말 왜? 어쩌면 그 자신이 분노했기 때문일까요? 왜 화가 났나요? 예를 들어, 그가 자신을 망쳤고 책임을 질 수 없어서? 이것이 전체 상황을 신중하게 처리하는 방법입니다. 그러나 이를 위해서는 기동할 공간, 언어적 공간이 필요합니다. 첫 번째 단계는 언어적 접촉을 끊는 것입니다. 말로 토론하지 마십시오. 취소하고 최대한 빨리 떠나세요. 전화 통화라면 그냥 끊으세요. 이것은 전처와 대화하면서 배운 기술입니다. 대화가 잘 진행되지 않으면 "안녕"이라고 말하고 전화를 끊으세요. 전화기 반대편에서 "어쩌고 저쩌고"라고 말하면 "그래, 안녕!"이라고 대답합니다. 그리고 끊으세요. 그냥 대화를 끝내시면 됩니다. XNUMX분 후 현명하게 사고할 수 있는 능력이 돌아오면 조금 식어지고 모든 것에 대해, 무슨 일이 일어났고, 다음에 무슨 일이 일어날 것인지 생각하는 것이 가능해집니다. 그리고 단지 감정적으로 반응하기보다는 사려 깊은 반응을 공식화하기 시작하십시오. 나에게 있어서 자기 인식의 돌파구는 바로 감정적 스트레스가 있을 경우 말을 할 수 없다는 사실이었다. 이 상태에서 벗어나 문제에 대응하고 보상하는 방법을 생각하고 계획하는 것이 말을 할 수 없는 경우의 올바른 단계입니다. 가장 쉬운 방법은 정서적 스트레스가 나타나는 상황에서 벗어나 단순히 이러한 스트레스에 참여하는 것을 중단하는 것입니다. 그 후에는 생각할 수 있게 되고, 생각할 수 있게 되면 말할 수도 있게 됩니다.

그건 그렇고, 법정에서 상대방 변호사가 당신에게 이런 일을 시도합니다. 이제 그 이유가 분명해졌습니다. 예를 들어 그는 당신이 당신의 이름조차 발음할 수 없을 정도로 당신을 억압하는 능력을 가지고 있기 때문입니다. 실제로는 말을 할 수 없게 됩니다. 이런 일이 발생하고 법원과 같이 언어 싸움이 격렬한 곳에서 자신을 발견하게 될 것이라는 것을 알고 있다면 변호사와 함께 오십시오. 변호사가 당신을 대신해 폭언을 멈추고, 완전히 합법적인 방법으로 처리해 줄 것이며, 잃어버린 선(禪) 공간이 당신에게 돌아올 것입니다. 예를 들어 가족들에게 몇 번이나 전화를 해야 했는데 판사는 이에 대해 상당히 친절했는데, 상대 변호사가 저에게 소리를 지르고 소리를 지르는 바람에 저는 한 마디도 들을 수 없었습니다. 이런 경우에는 중재자를 이용하는 것이 나에게 가장 적합합니다. 중재자는 연속적인 흐름으로 당신에게 쏟아지는 이 모든 압력을 멈추고, 당신은 필요한 선(禪) 공간을 찾고, 이를 통해 말하는 능력이 돌아옵니다. 이것은 공부할 것이 많고 스스로 발견할 것이 많은 지식의 전체 분야이며, 이 모든 것이 사람마다 다른 높은 수준의 전략적 결정으로 전환됩니다. 위에서 설명한 문제가 없는 사람도 있지만, 일반적으로 전문 영업사원인 경우에는 이러한 문제가 없습니다. 유명한 가수, 시인, 종교 지도자, 정치인 등 말로 생계를 유지하는 사람들은 항상 할 말이 있습니다. 그들에게는 그런 문제가 없지만 나는 있습니다.

앤드류: 그건... 예상치 못한 일이었어. 좋아요, 우리는 이미 많은 이야기를 나눴고 이제 이 인터뷰를 마무리할 시간입니다. 우리는 반드시 회의에서 만날 것이며 이 대화를 계속할 수 있을 것입니다. 히드라에서 만나보세요!

2019년 11월 12~2019일 상트페테르부르크에서 개최되는 Hydra XNUMX 컨퍼런스에서 Cliff와의 대화를 계속하실 수 있습니다. 그는 보고서를 가지고 올 것이다 "Azul 하드웨어 트랜잭션 메모리 경험". 티켓 구매 가능 공식 웹 사이트.

출처 : habr.com