Design: 임의 레이블 및 고토스를 지원하십시오.

@oridb Wasm은 소비자가 SSA 형식으로 빠르게 변환할 수 있도록 다소 최적화되어 있으며, 여기서 구조가 일반적인 코드 패턴에 도움이 되므로 구조가 반드시 소비자에게 부담이 되는 것은 아닙니다. 나는 '코드 생성의 양쪽이 지정된 형식을 중심으로 작동한다'는 귀하의 주장에 동의하지 않습니다. Wasm은 날씬하고 빠른 소비자에 관한 것입니다. 더 얇고 빠르게 만들기 위한 몇 가지 제안이 있다면 건설적일 수 있습니다.

DAG로 주문할 수 있는 블록은 귀하의 예와 같이 wasm 블록 및 분기로 표현할 수 있습니다. 스위치 루프는 필요할 때 사용되는 스타일이며 아마도 소비자는 여기에서 도움을 주기 위해 점프 스레딩을 수행할 수 있습니다. 아마도 컴파일러 백엔드에 대한 많은 작업을 수행할 수 있는 binaryen을 살펴보십시오.

보다 일반적인 CFG 지원에 대한 다른 요청이 있었고 루프를 사용하는 몇 가지 다른 접근 방식이 언급되었지만 현재 다른 곳에서 초점을 맞추고 있습니다.

인코딩에서 명시적으로 '연속 전달 스타일'을 지원할 계획은 없다고 생각하지만 블록 및 루프에서 인수(람다와 마찬가지로)를 팝핑하고 여러 값(여러 람다 인수)을 지원하고 추가하는 것에 대한 언급이 있었습니다. pick 연산자를 사용하면 정의(람다 인수)를 더 쉽게 참조할 수 있습니다.

구조는 여기에서 일반적인 코드 패턴에 도움이 됩니다.

웹 어셈블리가 적용하는 제한된 루프 및 블록 하위 집합에 비해 임의 레이블에 대한 분기 측면에서 더 쉽게 표현할 수 있는 일반적인 코드 패턴은 보이지 않습니다. 코드를 특정 언어 클래스에 대한 입력 코드와 매우 유사하게 만들려는 시도가 있었다면 약간의 이점을 볼 수 있었지만 그것이 목표인 것 같지는 않습니다.

DAG로 주문할 수 있는 블록은 귀하의 예와 같이 wasm 블록 및 분기로 표현할 수 있습니다.

예, 그럴 수 있습니다. 그러나 나는 어떤 것이 이런 식으로 표현될 수 있는지, 어떤 것이 추가 작업이 필요한지 결정하기 위해 추가 작업을 추가하지 않는 것을 강력히 선호합니다. 현실적으로는 추가 분석을 건너뛰고 항상 스위치 루프 형식을 생성합니다.

다시 말하지만, 내 주장은 루프와 블록이 모든 것을 불가능하게 만든다는 것이 아닙니다. 그들이 할 수 있는 모든 것은 기계가 goto, goto_if 및 임의의 구조화되지 않은 레이블로 작성하는 것이 더 간단하고 쉽다는 것입니다.

아마도 컴파일러 백엔드에 대한 많은 작업을 수행할 수 있는 binaryen을 살펴보십시오.

나는 이미 상당히 만족하는 서비스 가능한 백엔드를 가지고 있으며 내 언어로 전체 컴파일러를 완전히 부트스트랩할 계획입니다. 루프/블록을 강제로 사용하는 문제를 해결하기 위해 다소 큰 추가 종속성을 추가하지 않는 것이 좋습니다. 단순히 스위치 루프를 사용하는 경우 코드를 내보내는 것은 매우 간단합니다. 웹 어셈블리에 있는 기능을 실제로 사용하려고 하면 존재하지 않는 척 하는 것보다 훨씬 더 불쾌하게 됩니다.

더 일반적인 CFG 지원에 대한 다른 요청이 있었고 루프를 사용하는 몇 가지 다른 접근 방식이 언급되었지만 아마도 현재 다른 곳에 있을 것입니다.

나는 여전히 루프가 어떤 이점이 있는지 확신하지 못합니다. 루프로 표현할 수 있는 모든 것은 goto와 레이블로 표현할 수 있으며, 플랫 명령 목록에서 SSA로 빠르고 잘 알려진 변환이 있습니다.

CPS가 진행되는 한 나는 명시적인 지원이 필요하다고 생각하지 않습니다. FP 서클에서 인기가 있습니다. 어셈블리로 직접 변환하기가 상당히 쉽고 추론 측면에서 SSA와 유사한 이점을 제공하기 때문입니다(http:// mlton.org/pipermail/mlton/2003-January/023054.html); 다시 말하지만, 나는 그것에 대한 전문가는 아니지만 내가 기억하는 바에 따르면 호출 연속성은 레이블, 몇 번의 이동 및 고토로 낮아졌습니다.

@oridb '플랫 명령 목록에서 SSA로의 빠르고 잘 알려진 변환이 있습니다'

그들이 wasm SSA 디코더와 어떻게 비교되는지 아는 것이 흥미로울 것입니다. 그것이 중요한 질문입니까?

Wasm은 현재 값 스택을 사용하고 있으며 구조 없이는 일부 이점이 사라지고 디코더 성능이 저하될 수 있습니다. 값 스택이 없으면 SSA 디코딩도 더 많은 작업을 수행해야 하므로 레지스터 기본 코드를 시도했지만 디코딩이 더 느렸습니다(얼마나 중요한지 확실하지 않음).

값 스택을 유지하시겠습니까, 아니면 레지스터 기반 디자인을 사용하시겠습니까? 값 스택을 유지하면 CIL 복제가 될 수 있고 wasm 성능을 CIL과 비교할 수 있다면 실제로 이것을 확인하는 사람이 있습니까?

값 스택을 유지하시겠습니까, 아니면 레지스터 기반 디자인을 사용하시겠습니까?

저는 사실 그런 부분에 대해 강한 감정을 가지고 있지 않습니다. 인코딩의 간결함이 가장 큰 문제 중 하나가 될 것이라고 생각합니다. 레지스터 디자인은 거기에서 잘 작동하지 않을 수 있습니다. 또는 gzip을 통해 환상적으로 압축되는 것으로 판명될 수 있습니다. 사실 머리로는 잘 모르겠습니다.

성능은 또 다른 문제이지만 바이너리 출력을 캐시하는 기능과 다운로드 시간이 디코딩보다 훨씬 더 중요할 수 있다는 사실을 감안할 때 성능이 덜 중요할 수 있다고 생각합니다.

그들이 wasm SSA 디코더와 어떻게 비교되는지 아는 것이 흥미로울 것입니다. 그것이 중요한 질문입니까?

SSA로 디코딩하는 경우 적절한 양의 최적화도 수행하고 있음을 의미합니다. 우선 디코딩 성능이 얼마나 중요한지 벤치마킹하고 싶습니다. 하지만 네, 확실히 좋은 질문입니다.

질문과 우려에 감사드립니다.

많은 디자이너와 구현자가
WebAssembly는 고성능, 산업용 JIT뿐만 아니라
JavaScript(V8, SpiderMonkey, Chakra, JavaScriptCore) 뿐만 아니라
LLVM 및 기타 컴파일러. 개인적으로 Java용 JIT 2개를 구현했습니다.
바이트코드이고 무제한 goto가 있는 스택 머신이 있음을 증명할 수 있습니다.
디코딩, 확인 및 구성에 상당한 복잡성이 도입됩니다.
컴파일러 IR. 사실 자바로 표현할 수 있는 패턴은 많다
C1과 C2를 모두 포함하여 고성능 JIT를 발생시키는 바이트코드
HotSpot은 단순히 포기하고 코드를 다음에서만 실행되도록 강등합니다.
통역사. 대조적으로 다음과 같은 것으로부터 컴파일러 IR을 구성합니다.
JavaScript나 다른 언어의 AST도 제가 한 일입니다. 그만큼
AST의 추가 구조는 이 작업의 일부를 훨씬 간단하게 만듭니다.

WebAssembly의 제어 흐름 구조의 설계는 다음을 통해 소비자를 단순화합니다.
빠르고 간단한 검증, 손쉬운, SSA 양식으로의 원패스 변환 가능
(심지어 그래프 IR), 효과적인 단일 패스 JIT 및 (후불 주문 및
스택 머신) 비교적 간단한 제자리 해석. 구조화
제어는 환원 불가능한 제어 흐름 그래프를 불가능하게 만듭니다.
디코더와 컴파일러에 대한 모든 종류의 불쾌한 코너 케이스. 또한
WASM 바이트코드에서 예외 처리를 위한 단계를 멋지게 설정합니다.
이미 생산과 함께 프로토타입을 개발 중입니다.
구현.

우리는 이 문제에 대해 회원들 사이에서 많은 내부 토론을 했습니다.
바이트코드의 경우 주제와 가장 다른 것 중 하나이기 때문에
다른 기계 수준 목표. 하지만 타겟팅과 다르지 않습니다.
JavaScript(요즘 많은 컴파일러가 사용하는)와 같은 소스 언어 및
구조를 달성하기 위해 블록을 약간만 재구성하면 됩니다. 거기
이를 수행하는 알려진 알고리즘과 도구가 있습니다. 우리는 일부를 제공하고 싶습니다
임의의 CFG로 시작하는 생산자를 위한 더 나은 지침
이것을 더 잘 전달하십시오. AST에서 직접 WASM을 대상으로 하는 언어의 경우
(실제로 V8이 현재 asm.js 코드에 대해 수행하는 작업입니다.
JavaScript AST를 WASM 바이트코드로 변환), 구조 조정이 없습니다.
필요한 단계. 우리는 이것이 많은 언어 도구의 경우일 것으로 예상합니다.
내부에 정교한 IR이 없는 스펙트럼 전반에 걸쳐.

2016년 9월 8일 목요일 오전 9시 53분, Ori Bernstein [email protected]
썼다:

값 스택을 유지하시겠습니까, 아니면 레지스터 기반 디자인을 사용하시겠습니까?

저는 사실 그런 부분에 대해 강한 감정을 가지고 있지 않습니다. 나는 상상할 것이다
인코딩의 압축이 가장 큰 문제 중 하나가 될 것입니다. 당신처럼
언급된 성능은 또 다른 것입니다.

그들이 wasm SSA 디코더와 어떻게 비교되는지 아는 것이 흥미로울 것입니다.
중요한 질문입니까?

SSA로 디코딩하는 경우
합리적인 양의 최적화. 벤치마킹 방법이 궁금합니다.
중요한 디코딩 성능이 우선입니다. 하지만, 네, 그건
확실히 좋은 질문입니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/WebAssembly/design/issues/796#issuecomment -245521009,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ALnq1Iz1nn4--NL32R9ev0JPKfEnDyvqks5qn77cgaJpZM4J3ofA
.

@titzer님 감사합니다. Wasm의 구조가 asm.js와의 유사성 이상의 목적을 가지고 있다는 의심을 키우고 있었습니다. 그래도 궁금합니다. Java 바이트코드(및 CIL)는 CFG 또는 값 스택을 직접 모델링하지 않으며 JIT에서 추론해야 합니다. 그러나 Wasm에서(특히 블록 서명이 추가된 경우) JIT는 값 스택 및 제어 흐름에서 무슨 일이 일어나고 있는지 쉽게 파악할 수 있으므로 CFG(또는 구체적으로 환원 불가능한 제어 흐름)가 루프 및 블록처럼 명시적으로 모델링되었는지 궁금합니다. 그것이 당신이 생각하고 있는 불쾌한 코너 케이스의 대부분을 피할 수 있을까요?

분기 예측을 개선하기 위해 환원 불가능한 제어 흐름에 의존하는 인터프리터가 사용하는 이 깔끔한 최적화가 있습니다...

@oridb

더 평평하고 goto 기반 형식이 다음과 같이 훨씬 더 유용하다고 주장하고 싶습니다.
컴파일러 개발자 대상

goto가 많은 컴파일러에 매우 유용하다는 데 동의합니다. 그렇기 때문에 Binaryen과 같은 도구를 사용하면 gotos 를 사용 생성 할 수 있으며 이를 매우 빠르고 효율적으로 WebAssembly로 변환할 수 있습니다.

WebAssembly를 브라우저가 소비하도록 최적화된 것으로 생각하는 것이 도움이 될 수 있습니다( @titzer가 지적한 대로). 대부분의 컴파일러는 WebAssembly를 직접 생성하지 않고 오히려 Binaryen과 같은 도구를 사용하여 goto를 내보내고 많은 최적화를 무료로 얻을 수 있으며 WebAssembly의 저수준 바이너리 형식 세부 사항에 대해 생각할 필요가 없습니다. 간단한 API를 사용하여 IR을 방출합니다).

당신이 언급한 while-switch 패턴을 사용한 폴리필링과 관련하여: emscripten에서 우리는 루프를 재생성하는 "relooper" 방법을 개발하기 전에 그런 식으로 시작했습니다. while-switch 패턴은 평균적으로 약 4배 더 느립니다(그러나 어떤 경우에는 훨씬 적거나 더 많습니다. 예를 들어 작은 루프가 더 민감합니다). 이론적으로 점프 스레딩 최적화가 속도를 높일 수 있다는 점에 동의하지만 일부 VM이 다른 VM보다 더 잘 수행하므로 성능을 예측할 수 없습니다. 또한 코드 크기 측면에서 훨씬 더 큽니다.

WebAssembly를 브라우저가 소비하도록 최적화된 것으로 생각하는 것이 도움이 될 수 있습니다( @titzer가 지적한 대로). 대부분의 컴파일러는 WebAssembly를 직접 생성하지 않고 Binaryen과 같은 도구를 사용해야 합니다...

나는 여전히 이 측면이 그렇게 중요할 것이라고 확신하지 못합니다. 다시 말하지만, 바이트코드를 가져오는 비용이 사용자가 보는 지연을 지배할 것이라고 생각합니다. 두 번째로 큰 비용은 구문 분석 및 유효성 검사가 아니라 최적화를 수행하는 것입니다. . 나는 또한 바이트코드가 버려지고 컴파일된 출력이 캐시될 것이라고 가정/희망하여 컴파일을 효과적으로 일회성 비용으로 만듭니다.

그러나 웹 브라우저 소비를 위해 최적화하고 있다면 웹 어셈블리를 SSA로 정의하는 것이 어떻습니까? 이는 내가 예상하는 것과 더 일치하고 SSA로 '변환'하는 데 드는 노력이 덜한 것처럼 보입니다.

다운로드하는 동안 구문 분석 및 컴파일을 시작할 수 있으며 일부 VM은 전체 컴파일을 미리 수행하지 않을 수 있습니다(예를 들어 단순한 기준선을 사용할 수 있음). 따라서 다운로드 및 컴파일 시간은 예상보다 짧을 수 있으며 결과적으로 구문 분석 및 유효성 검사가 사용자에게 표시되는 총 지연 시간의 중요한 요소가 될 수 있습니다.

SSA 표현과 관련하여 코드 크기가 큰 경향이 있습니다. SSA는 코드 최적화에는 적합하지만 코드를 간결하게 직렬화하는 데에는 적합하지 않습니다.

@oridb '..., 간단한 검증, 쉽게, 하나의 패스 변환 SSA에 양식 빠른 가능하게함으로써 WebAssembly의 제어 흐름 구조 단순화 소비자의 디자인'@titzer으로 코멘트를 참조하십시오 - 그것은 한 번에 _verified_ SSA를 생성 할 수 있습니다. wasm이 인코딩에 SSA를 사용하더라도 wasm 제어 흐름 제한으로 쉽게 도미네이터 구조를 계산하고 확인해야 하는 부담이 있습니다.

wasm의 인코딩 효율성의 대부분은 정의가 스택 순서로 사용되는 단일 용도를 갖는 공통 코드 패턴에 대해 최적화된 것으로 보입니다. SSA 인코딩도 그렇게 할 수 있기 때문에 비슷한 인코딩 효율성을 가질 수 있을 것으로 기대합니다. 다이아몬드 패턴에 대한 if_else 같은 연산자도 많은 도움이 됩니다. 그러나 wasm 구조가 없으면 모든 기본 블록이 레지스터에서 정의를 읽고 결과를 레지스터에 써야 하는 것처럼 보이며 그렇게 효율적이지 않을 수 있습니다. 예를 들어, wasm은 스택의 위쪽과 기본 블록 경계를 넘어 범위가 지정된 스택 값을 참조할 수 있는 pick 연산자를 사용하여 훨씬 더 나은 작업을 수행할 수 있다고 생각합니다.

나는 was가 SSA 스타일로 대부분의 코드를 인코딩할 수 있는 것과 그리 멀지 않다고 생각합니다. 정의가 기본 블록 출력으로 범위 트리 위로 전달되면 완료될 수 있습니다. SSA 인코딩이 CFG 문제와 직교할 수 있습니다. 예를 들어 wasm CFG 제한이 있는 SSA 인코딩이 있을 수 있고 CFG 제한이 있는 레지스터 기반 VM이 있을 수 있습니다.

wasm의 목표는 최적화 부담을 런타임 소비자 밖으로 옮기는 것입니다. 공격 표면을 증가시키기 때문에 런타임 컴파일러에 복잡성을 추가하는 것에 대한 강한 저항이 있습니다. 설계상의 문제 중 많은 부분이 성능 저하 없이 런타임 컴파일러를 단순화하기 위해 무엇을 할 수 있는지 묻는 것이며 많은 토론이 필요합니다!

글쎄, 지금은 너무 늦었을지 모르지만, 리루퍼 알고리즘 또는 그 변형이 모든 경우에 "충분히 좋은" 결과를 생성할 수 있다는 아이디어에 의문을 제기하고 싶습니다. 대부분의 소스 코드에는 처음부터 환원 불가능한 제어 흐름이 포함되어 있지 않기 때문에 대부분의 경우에 분명히 할 수 있습니다. 최적화는 일반적으로 일을 너무 복잡하게 만들지 않으며, 예를 들어 중복 블록 병합의 일부로 그렇게 한다면 아마도 가르칠 수 있을 것입니다. 하지 않습니다. 그러나 병리학 적 사례는 어떻습니까? 예를 들어 컴파일러가 다음 의사 C와 같은 구조를 가진 일반 함수로 변환한 코루틴이 있다면 어떻게 될까요?

void transformed_coroutine(struct autogenerated_context_struct *ctx) {
    int arg1, arg2; // function args
    int var1, var2, var3, …; // all vars used by the function
    switch (ctx->current_label) { // restore state
    case 0:
        // initial state, load function args caller supplied and proceed to start
        arg1 = ctx->arg1;
        arg2 = ctx->arg2;
        break;
    case 1: 
        // restore all vars which are live at label 1, then jump there
        var2 = ctx->var2; 
        var3 = ctx->var3;
        goto resume_1;
    [more cases…]
    }

    [main body goes here...]
    [somewhere deep in nested control flow:]
        // originally a yield/await/etc.
        ctx->var2 = var2;
        ctx->var3 = var3;
        ctx->current_label = 1;
        return;
        resume_1:
        // continue on
}

따라서 대부분 정상적인 제어 흐름을 가지지만 그 중간에 일부 goto가 있습니다. 이것이 대략 LLVM 코루틴이 작동하는 방식 입니다.

'정상' 제어 흐름이 충분히 복잡하다면 이와 같은 것을 다시 반복하는 좋은 방법이 없다고 생각합니다. (틀릴 수 있습니다.) 함수의 방대한 부분을 복제하여 잠재적으로 모든 양보점에 대해 별도의 사본이 필요하거나 전체를 거대한 스위치로 바꾸 거나 @kripken에 따르면 일반적인 코드에서 relooper보다 4배 느립니다( 그 자체는 아마도 relooper가 전혀 필요하지 않은 것보다 다소 느릴 것입니다).

VM은 점프 스레딩 최적화로 거대한 스위치의 오버헤드를 줄일 수 있지만 분명히 명시적 goto를 수락하는 것보다 코드가 goto로 감소하는 방법을 기본적으로 추측하여 VM이 이러한 최적화를 수행하는 것이 더 비쌉니다. @kripken이 말했듯이 예측 가능성도 낮습니다.

그런 종류의 변환을 시작하는 것은 나쁜 생각일 수 있습니다. 왜냐하면 이후에는 아무 것도 지배하지 않으므로 SSA 기반 최적화는 많은 작업을 수행할 수 없기 때문입니다. 어셈블리 수준에서 수행하는 것이 더 나을 수도 있습니다. 아마도 wasm은 결국 기본 코루틴 지원을 받아야 할까요? 그러나 컴파일러는 변환을 수행 하기 전에 대부분의 최적화

어쨌든 코루틴은 하나의 예일 뿐입니다. 내가 생각할 수 있는 또 다른 예는 VM 내 VM을 구현하는 것입니다. JIT의 더 일반적인 기능은 goto가 필요하지 않은 side exit 이지만, side entry 가 필요한 상황이 있습니다. 다시, goto가 루프의 중간에 있어야 하는 경우입니다. 다른 하나는 최적화된 인터프리터일 것입니다. wasm을 대상으로 하는 인터프리터가 네이티브 코드를 대상으로 하는 인터프리터와 실제로 일치할 수 있다는 것은 아닙니다. 최소한 계산된 goto로 성능을 향상하고 더 많은 것을 위해 어셈블리에 들어갈 수 있지만... 계산된 goto의 동기 중 일부는 더 잘 활용하는 것입니다. 각 사례에 자체 점프 명령을 제공하여 분기 예측자를 사용하므로 사례가 모두 goto인 각 opcode 처리기 뒤에 별도의 스위치를 사용하여 일부 효과를 복제할 수 있습니다. 또는 현재 명령 다음에 일반적으로 오는 특정 명령을 확인하기 위해 적어도 하나 또는 두 가지가 있습니다. 구조화된 제어 흐름으로 표현할 수 있는 패턴의 몇 가지 특별한 경우가 있지만 일반적인 경우는 아닙니다. 등등…

VM이 많은 작업을 수행하지 않고 임의의 제어 흐름을 허용하는 방법이 분명히 있습니다. 막연한 아이디어는 깨질 수 있습니다. 하위 범위로의 점프가 허용되는 체계를 가질 수 있지만, 입력해야 하는 범위의 수가 대상 블록에 정의된 제한보다 적은 경우에만 가능합니다. 제한은 기본적으로 0(상위 범위에서 점프 없음)으로 설정되어 현재 의미 체계를 유지하고 블록의 제한은 상위 블록의 제한 + 1(확인하기 쉬움)보다 클 수 없습니다. 그리고 VM은 우성 휴리스틱을 "X가 Y의 부모인 경우 Y를 지배합니다"에서 "Y의 자식 점프 제한보다 거리가 더 큰 Y의 부모인 경우 X가 Y를 지배합니다"로 변경합니다. (이것은 정확한 지배자 집합을 나타내는 것이 보장되지 않는 보수적인 근사치이지만 기존 휴리스틱의 경우에도 마찬가지입니다. 내부 블록이 외부 블록의 아래쪽 절반을 지배하는 것이 가능합니다.) 환원할 수 없는 제어 흐름이 있는 코드만 제한을 지정해야 하지만 일반적인 경우에는 코드 크기가 증가하지 않습니다.

편집: 흥미롭게도 이는 기본적으로 블록 구조를 지배 트리의 표현으로 만듭니다. 나는 그것을 직접적으로 표현하는 것이 훨씬 더 간단할 것이라고 생각합니다. 기본 블록의 트리입니다. 여기서 블록은 형제, 조상 또는 직계 자식 블록으로 점프할 수 있지만 더 이상의 후손으로는 점프할 수 없습니다. "블록"이 하위 루프가 있는 여러 기본 블록으로 구성될 수 있는 기존 범위 구조에 가장 잘 매핑되는 방법을 모르겠습니다.

FWIW: Wasm은 "중첩 제한으로 인해 루프 외부에서 루프 중간으로 분기하는 것이 불가능하다는 점을 제외하고" 몇 가지 매우 중요한 단어로 설명되는 특정 디자인이 있습니다.

DAG일 경우 유효성 검사에서 분기가 순방향인지 확인할 수 있지만 루프를 사용하면 루프 외부에서 루프 중간으로 분기할 수 있으므로 중첩 블록 설계가 가능합니다.

CFG는 이 디자인의 일부일 뿐이고 다른 하나는 데이터 흐름이며 값 스택이 있고 블록을 구성하여 값 스택을 풀 수 있어 소비자에게 실시간 범위를 매우 유용하게 전달할 수 있어 SSA로 변환하는 작업을 절약할 수 있습니다. .

wasm을 SSA 인코딩으로 확장하는 것이 가능합니다( pick , 블록이 여러 값을 반환하도록 허용, 루프 항목이 값을 팝하게 함). 따라서 흥미롭게도 효율적인 SSA 디코딩에 필요한 제약 조건이 필요하지 않을 수 있습니다. 이미 SSA로 인코딩되었을 수 있습니다)! 이것은 기능적 언어로 이어집니다(효율성을 위해 스택 스타일 인코딩을 가질 수 있음).

이것이 임의의 CFG를 처리하도록 확장된 경우 다음과 같이 보일 수 있습니다. 이것은 SSA 스타일 인코딩이므로 값은 상수입니다. 그것은 여전히 ​​모든 세부 사항이 확실하지 않은 스택 스타일에 대부분 맞는 것 같습니다. 따라서 blocks 내에서 해당 세트의 다른 레이블이 지정된 블록에 분기를 만들거나 제어를 다른 블록으로 전송하는 데 사용되는 다른 규칙을 만들 수 있습니다. 블록 내의 코드는 스택 상위에 있는 값 스택의 값을 여전히 유용하게 참조하여 모든 값을 전달하지 않아도 됩니다.

(func f1 (arg1)
  (let ((c1 10)) ; Some values up the stack.
    (blocks ((b1 (a1 a2 a3)
                   ... (br b3)
               (br b2 (+ a1 a2 a3 arg1 c1)))
             (b2 (a1)
                 ... (br b1 ...))
             (b3 ()
                 ...))
   .. regular structured wasm ..
   (br b2 ...)
   ....
   (br b3)
    ...
   ))

그러나 웹 브라우저가 이것을 내부적으로 효율적으로 처리할 수 있을까요?

스택 머신에 대한 배경 지식이 있는 사람이 코드 패턴을 인식하고 이를 스택 인코딩과 일치시킬 수 있습니까?

여기 http://bboissin.appspot.com/static/upload/bboissin-thesis-2010-09-22.pdf 에 환원 불가능한 루프에 대한 흥미로운 토론이 있습니다.

나는 그것을 빠른 패스로 따라하지 않았지만 엔트리 노드를 추가하여 환원 불가 루프를 환원 루프로 변환하는 것을 언급합니다. wasm의 경우 현재 솔루션과 유사하지만 이에 대한 정의된 변수가 있는 루프 내에서 디스패치하기 위해 특별히 정의된 입력을 루프에 추가하는 것처럼 들립니다. 위에서 언급한 바와 같이 처리 과정에서 가상화되고 최적화됩니다. 아마도 이와 같은 것이 옵션이 될 수 있습니까?

이것이 곧 가능하고 생산자가 이미 유사한 기술을 사용해야 하지만 지역 변수를 사용해야 하는 경우 일찍 생성된 wasm이 고급 런타임에서 더 빠르게 실행될 수 있도록 지금 고려해 볼 가치가 있습니까? 이것은 또한 이것을 탐색하기 위한 런타임 간의 경쟁에 대한 인센티브를 생성할 수 있습니다.

이것은 정확히 임의의 레이블 및 goto가 아니지만 미래에 효율적으로 컴파일될 가능성이 있는 변환될 수 있는 것입니다.

참고로 저는 이 문제에 대해 @oridb 및 @comex 에 강력히 동의 합니다.
더 늦기 전에 해결해야 할 중요한 문제라고 생각합니다.

WebAssembly의 특성을 감안할 때 지금 하는 모든 실수는 앞으로 수십 년 동안 유지 될 가능성이 높습니다(Javascript를 보세요!). 이것이 문제가 매우 중요한 이유입니다. 이유가 무엇이든 지금 goto를 지원하지 마십시오(예: 최적화를 용이하게 하기 위해 --- 솔직히 말해서 --- 일반적인 것에 대한 특정 구현의 영향, 솔직히 말해서 게으른 것이라고 생각합니다). 그러면 결국 장기적으로 문제.

나는 이미 미래(또는 현재, 그러나 미래에) WebAssembly 구현이 그것들을 적절하게 처리하기 위해 레이블을 구현하기 위해 일반적인 while/switch 패턴을 특별한 경우에 인식하려고 시도하는 것을 볼 수 있습니다. 해킹이야

WebAssembly는 깨끗한 상태이므로 이제 더티 핵(또는 오히려 요구 사항)을 피해야 합니다.

@darkuranium :

현재 지정된 WebAssembly는 이미 브라우저 및 도구 체인에 제공되고 있으며 개발자는 이미 해당 디자인에 배치된 형식을 사용하는 코드를 만들었습니다. 따라서 우리는 획기적인 방식으로 디자인을 변경할 수 없습니다 .

그러나 이전 버전과 호환되는 방식으로 디자인에 추가할 수 있습니다. 관련된 사람들 중 goto 가 쓸모없다고 생각하는 사람은 아무도 없다고 생각합니다. 나는 우리 모두가 문법적인 장난감 매너뿐만 아니라 정기적으로 goto 사용한다고 생각합니다.

이 시점에서 동기가 있는 사람이 타당한 제안을 제시하고 실행해야 합니다. 나는 그것이 확실한 데이터를 제공한다면 그러한 제안이 거부되는 것을 보지 않습니다.

WebAssembly의 특성을 감안할 때 지금 하는 모든 실수는 앞으로 수십 년 동안 유지될 가능성이 높습니다(Javascript를 보세요!). 이것이 문제가 매우 중요한 이유입니다. 이유가 무엇이든 지금 goto를 지원하지 마십시오(예: 최적화를 용이하게 하기 위해 --- 솔직히 말해서 --- 일반적인 것에 대한 특정 구현의 영향, 솔직히 말하면 게으른 것이라고 생각합니다). 그러면 결국 장기적으로 문제.

그래서 나는 당신의 허풍을 부르겠습니다. 나는 당신이 보여주는 동기를 가지고 위에서 자세히 설명하는 것처럼 제안과 구현을 하지 않는 것은 솔직히 게으른 것이라고 생각합니다.

나는 물론 건방진거야. 스레드, GC, SIMD 등을 위해 우리의 문을 두드리는 사람들이 있다는 것을 고려하십시오. 모두 해당 기능이 가장 중요한 이유에 대해 열정적이고 합리적인 주장을 하고 있습니다. 이러한 문제 중 하나를 해결하는 데 도움이 된다면 좋을 것입니다. 내가 언급한 다른 기능을 위해 그렇게 하는 사람들이 있습니다. 지금까지 goto 가 없습니다. 이 그룹의 기여 지침을 숙지 하고 재미에 참여하십시오.

그렇지 않으면 goto 가 훌륭한 미래 기능 이라고 생각

안녕. 웹어셈블리에서 IR로, 다시 웹어셈블리로 번역을 작성하는 중이며 이 주제에 대해 사람들과 토론한 적이 있습니다.

환원 불가능한 제어 흐름은 웹 어셈블리에서 표현하기 어렵다는 점을 지적했습니다. 때때로 축소할 수 없는 제어 흐름을 작성하는 컴파일러를 최적화하는 데 문제가 될 수 있습니다. 이것은 여러 진입점이 있는 루프 아래와 같을 수 있습니다.

if (x) goto inside_loop;
// banana
while(y) {
    // things
    inside_loop:
    // do things
}

EBB 컴파일러는 다음을 생성합니다.

entry:
    cjump x, inside_loop
    // banana
    jump loop

loop:
    cjump y, exit
    // things
    jump inside_loop

inside_loop:
    // do things
    jump loop
exit:
    return

다음으로 이것을 웹어셈블리로 번역합니다. 문제는 우리가 오래 전에 디컴파일러를 알아냈음 에도 불구하고 항상 goto를 환원 불가능한 흐름에 추가할 수 있는 옵션이 있다는 것입니다.

번역되기 전에 컴파일러는 이에 대한 트릭을 수행할 것입니다. 그러나 결국 코드를 ​​스캔하고 구조의 시작과 끝을 배치하게 됩니다. 폴스루 점프를 제거한 후 다음 후보가 됩니다.

<inside_loop, if(x)>
    // banana
<loop °>
<exit if(y)>
    // things
</inside_loop, if(x)>
    // do things
</loop ↑>
</exit>

다음으로 이것들로부터 스택을 구축해야 합니다. 어느 것이 바닥으로 갈까요? '내부 루프'이거나 '루프'입니다. 우리는 이것을 할 수 없으므로 스택을 잘라내고 주변에 복사해야 합니다.

if
    // do things
else
    // banana
end
loop
  br out
    // things
    // do things
end

이제 이것을 웹어셈블리로 번역할 수 있습니다. 실례합니다. 이 루프가 어떻게 구성되는지 아직 잘 모르겠습니다.

오래된 소프트웨어를 생각한다면 이것은 특별한 문제가 아닙니다. 새 소프트웨어가 웹 어셈블리로 번역될 가능성이 높습니다. 그러나 문제는 컴파일러가 작동하는 방식에 있습니다. 그들은 _decades_ 동안 기본 블록으로 제어 흐름을 수행했으며 모든 것이 진행된다고 가정합니다.

기술적으로 언어는 번역된 다음 번역됩니다. 드라마 없이 깔끔하게 경계를 넘어 가치가 흐르도록 하는 메커니즘만 있으면 됩니다. 구조화된 흐름은 코드를 읽으려는 사람들에게만 유용합니다.

그러나 예를 들어 다음과 같이 잘 작동합니다.

    cjump x, label(1)
    // banana
0: label
    cjump y, label(2)
    // things
1: label
    // do things
    jump label(0)
2: label
    // exit as usual, picking the values from the top of the stack.

숫자는 암시적입니다. 즉.. 컴파일러가 '레이블'을 볼 때 새 확장 블록을 시작하고 0에서 증가하기 시작하는 새 인덱스 번호를 제공한다는 것을 알고 있습니다.

정적 스택을 생성하려면 레이블로 점프할 때 스택에 있는 항목 수를 추적할 수 있습니다. 레이블로 점프한 후 일관성 없는 스택이 있으면 프로그램이 유효하지 않습니다.

위의 내용이 잘못된 경우 각 레이블에 명시적인 스택 길이를 추가하고(절대값이 압축에 좋지 않은 경우 마지막 인덱싱된 레이블의 스택 크기로부터의 델타일 수 있음) 각 점프에 대한 마커를 추가할 수 있습니다. 점프하는 동안 스택의 맨 위에서 복사합니다.

나는 당신이 제어 흐름을 표현하는 방법에 의해 어떤 식으로든 gzip을 능가할 수 없다고 장담할 수 있습니다. 그래서 여기에서 가장 힘든 일을 하는 사람들에게 좋은 흐름을 선택할 수 있습니다. (나는 'gzip을 능가하는 것'을 위한 유연한 컴파일러 도구 모음으로 설명할 수 있습니다. 원하는 경우 저에게 메시지를 보내고 데모를 올려 보겠습니다!)

나는 지금 산산조각난 기분이다. WebAssembly 사양을 다시 읽고 환원할 수 없는 제어 흐름이 MVP에서 의도적으로 누락되었음을 알아차렸습니다. 아마도 emscripten이 초기에 문제를 해결해야 했기 때문일 것입니다.

WebAssembly에서 환원 불가능한 제어 흐름을 처리하는 방법에 대한 솔루션은 "Emscripten: An LLVM-to-JavaScript Compiler" 문서에 설명되어 있습니다. relooper는 프로그램을 다음과 같이 재구성합니다.

_b_ = bool(x)
_b_ == 0 if
  // banana
end
block loop
  _b_ if
    // do things
    _b_ = 0
  else
    y br_if 2
    // things
    _b_ = 1
  end
  br 0
end end

합리적인 것은 구조화된 제어 흐름이 소스 코드 덤프를 읽는 데 도움이 되며 폴리필 구현에 도움이 된다고 믿어집니다.

웹 어셈블리에서 컴파일하는 사람들은 아마도 축소된 제어 흐름을 처리하고 분리하는 데 적응할 것입니다.

그래서:

• 언급했듯이 WebAssembly는 이제 안정적이므로 제어 흐름이 표현되는 방식을 완전히 다시 작성할 시간은 지났습니다.
  
  
  
  • 어떤 의미에서는 불행한 일입니다. 왜냐하면 보다 직접적인 SSA 기반 인코딩이 현재 디자인과 동일한 간결함을 달성할 수 있었는지 여부를 실제로 테스트한 사람은 아무도 없었기 때문입니다.
  
  
  • 그러나 goto를 지정하면 작업이 훨씬 쉬워집니다! 블록 기반 명령은 이미 바이크셰딩을 넘어섰고 wasm을 대상으로 하는 프로덕션 컴파일러가 이를 사용하여 축소 가능한 제어 흐름을 표현하는 것을 기대하는 것은 큰 문제가 아닙니다. 알고리즘은 그렇게 어렵지 않습니다. 주요 문제는 성능 비용 없이 제어 흐름의 작은 부분을 사용하여 표현할 수 없다는 것입니다. 새로운 goto 명령어를 추가하여 이 문제를 해결하면 전체 재설계에서와 같이 인코딩 효율성에 대해 거의 걱정할 필요가 없습니다. 물론 goto를 사용하는 코드는 여전히 합리적으로 압축되어야 하지만 압축을 위해 다른 구성과 경쟁할 필요는 없습니다. 그것은 환원 불가능한 제어 흐름만을 위한 것이며 드물게 사용되어야 합니다.
  
  
• 환원성은 특별히 유용하지 않습니다.
  
  
  
  • 대부분의 컴파일러 백엔드는 기본 블록과 그 사이의 분기 그래프를 기반으로 하는 SSA 표현을 사용합니다. 축소성이 보장되는 중첩 루프 구조는 처음에는 거의 버려집니다.
  
  
  • JavaScriptCore, V8 및 SpiderMonkey에서 현재 WebAssembly 구현을 확인했는데 모두 이 패턴을 따르는 것 같습니다. (V8은 기본 블록보다 일종의 "노드의 바다" 표현으로 더 복잡하지만 중첩 구조도 버립니다.)
  
  
  • 예외 : 루프 분석이 유용할 수 있으며 이러한 세 가지 구현은 모두 루프의 시작인 기본 블록에 대한 정보를 IR에 전달합니다. (AOT 컴파일을 위해 설계된 'heavyweight' 백엔드로서 이를 버리고 백엔드에서 다시 계산하는 LLVM과 비교하십시오. 이것은 소스 코드에서 루프처럼 보이지 않는 것을 찾을 수 있기 때문에 더 강력합니다. 많은 최적화 후에, 그러나 더 느립니다.)
  
  
  • 루프 분석은 루프 헤더를 거치지 않는 루프 중간으로 분기하는 것을 금지하는 "자연 루프"에서 작동합니다.
  
  
  • WebAssembly는 loop 블록이 자연스러운 루프임을 계속 보장해야 합니다.
  
  
  • 그러나 루프 분석은 전체 함수를 축소할 수 있어야 하거나 루프 내부도 필요하지 않습니다. 단지 외부에서 내부로의 분기를 금지합니다. 기본 표현은 여전히 ​​임의의 제어 흐름 그래프입니다.
  
  
  • 컴파일러가 relooper 알고리즘 자체를 실행해야 하기 때문에 제어할 수 없는 제어 흐름으로 인해 WebAssembly를 JavaScript(폴리필링)로 컴파일하기가 더 어려워집니다.
  
  
  • 그러나 WebAssembly는 이미 JS로 컴파일하는 접근 방식(정렬되지 않은 메모리 액세스 지원 및 범위를 벗어난 액세스에 대한 트래핑 포함)에 상당한 런타임 오버헤드를 추가하는 여러 결정을 내렸으며 이는 그다지 중요하지 않은 것으로 간주됩니다.
  
  
  • 그에 비해 컴파일러를 조금 더 복잡하게 만드는 것은 큰 문제가 아닙니다.
  
  
  • 따라서 환원 불가능한 제어 흐름에 대한 지원을 추가하지 않을 이유가 없다고 생각합니다.
  
  
• SSA 표현(설계상 한 번에 가능해야 함)을 구축하는 데 필요한 주요 정보는 도미네이터 트리 입니다.
  
  
  
  • 현재 백엔드는 구조화된 제어 흐름을 기반으로 도미넌스를 추정할 수 있습니다. 사양을 올바르게 이해했다면 다음 지침은 기본 블록을 종료합니다.
  
  
  • block :
    
    
    
    
    
    • 블록을 시작하는 BB는 이전 BB가 지배합니다.*
    
    
    
    • 해당 end 다음에 오는 BB는 블록을 시작하는 BB가 지배하지만 end 이전의 BB에 의해 지배되지 않습니다( br 아웃이 있으면 건너뛰기 때문입니다. ).
    
    
    
  
  
  • loop :
    
    
    
    
    
    • 블록을 시작하는 BB는 이전 BB가 지배합니다.
    
    
    
    • end 이후의 BB는 end 이전의 BB에 의해 지배됩니다( end 를 실행하는 것 외에는 end 이후의 명령에 도달할 수 없기 때문입니다).
    
    
    
  
  
  • if :
    
    
    
    
    
    • if 쪽, else 쪽, end 뒤의 BB는 모두 if 앞의 BB가 지배합니다.
    
    
    
  
  
  • br , return , unreachable :
    
    
    
    
    
    • ( br , return 또는 unreachable 바로 뒤의 BB는 연결할 수 없습니다.)
    
    
    
  
  
  • br_if , br_table :
    
    
    
    
    
    • br_if / br_table 앞의 BB가 뒤의 BB를 지배합니다.
    
    
    
  
  
  • 특히 이것은 추정치일 뿐입니다. 구성에 의해 A를 거치지 않고 B에 도달할 수 있는 방법이 없을 때만 그렇게 말하기 때문에 거짓 긍정(A가 실제로 그렇지 않을 때 B를 지배한다고 말함)을 생성할 수 없습니다. 그러나 그것은 거짓 부정을 생성할 수 있고(실제로 그럴 때 A가 B를 지배하지 않는다고 말함), 나는 단일 통과 알고리즘이 그것들을 감지할 수 있다고 생각하지 않습니다(틀릴 수 있음).
  
  
  • 거짓 부정의 예:
    
    ```
    
    $outer 차단
    
    고리
    
    br $외부 ;; 무조건 깨기 때문에 은밀히 끝을 지배한다 BB
    
    끝
    
    끝
  
  
  • 하지만 괜찮아, AFAIK.
    
    
    
    
    
    • 예를 들어 기본 블록 A가 기본 블록 B를 지배한다고 하면 B에 대한 기계어 코드가 A에 설정된 레지스터를 사용할 수 있기 때문에 거짓 긍정은 나쁠 것입니다(그 레지스터를 덮어쓰는 중간 항목이 없는 경우). A가 실제로 B를 지배하지 않으면 레지스터가 쓰레기 값을 가질 수 있습니다.
    
    
    
    • 거짓 부정은 본질적으로 결코 발생하지 않는 유령 가지입니다. 컴파일러는 이러한 분기 가 발생할
    
    
    
  
  
  • 어쨌든 goto 명령어가 도미네이터 트리 측면에서 어떻게 작동해야 하는지 생각해 보십시오. A가 B를 지배하고 C를 지배한다고 가정합니다.
  
  
  • A에서 C로 건너뛸 수는 없습니다. 그렇게 하면 B를 건너뛸 수 있기 때문입니다(지배성 가정 위반). 즉, 직계가 아닌 자손으로 점프할 수 없습니다. (그리고 바이너리 생산자 측에서는 진정한 도미네이터 트리를 계산했다면 그런 점프는 절대 없을 것입니다.)
  
  
  • A에서 B로 안전하게 점프할 수 있지만 직계 자손으로 이동하는 것은 그다지 유용하지 않습니다. 이것은 기본적으로 우리가 이미 할 수 있는 if 또는 switch 문과 동일합니다(바이너리 테스트만 있는 경우 if 명령어를 사용하거나 여러 개인 경우 br_table 사용).
  
  
  • 또한 안전하고 더 흥미로운 것은 형제나 조상의 형제에게 점프하는 것입니다. 우리가 형제자매에게 점프한다면, 우리는 우리 부모가 우리 형제자매를 지배한다는 보장을 보존했습니다. 왜냐하면 여기에 오기 위해 이미 우리 부모를 처형했어야 했기 때문입니다(그것도 우리를 지배하기 때문에). 조상들에게도 마찬가지입니다.
  
  
  • 일반적으로 악성 바이너리는 이러한 방식으로 위음성을 생성할 수 있지만 내가 말했듯이 이는 (a) 이미 가능하고 (b) 허용됩니다.
  
  

• 이를 바탕으로 다음은 스트로우맨 제안입니다.

  • 하나의 새로운 블록 유형 명령어:
  • 라벨은 * 끝 INSTR N을 resulttype
  • 정확히 N개의 직계 자식 명령어가 있어야 합니다. 여기서 "직계 자식"은 블록 유형 명령어( loop , block , 또는 labels )와 그에 상응하는 모든 것을 의미합니다. end 또는 단일 비블록 명령어(스택에 영향을 미치지 않아야 함).
  • labels 는 다른 블록 유형 명령처럼 단일 레이블을 만드는 대신 N+1개의 레이블을 만듭니다. N은 N 자식을 가리키고 하나는 labels 블록의 끝을 가리킵니다. 각 자식에서 레이블 인덱스 0~N-1은 순서대로 자식을 가리키고 레이블 인덱스 N은 끝을 나타냅니다.

  다시 말해서, 당신이 가지고 있다면
  loop ;; outer labels 3 block ;; child 0 br X end nop ;; child 1 nop ;; child 2 end end

  X에 따라 br 는 다음을 참조합니다.

  | 엑스 | 대상 |
  | ---------- | ------ |
  | 0 | block 끝 |
  | 1 | 자식 0( block ) |
  | 2 | 아이 1 (아니오) |
  | 3 | 아이 2 (아니오) |
  | 4 | labels 끝 |
  | 5 | 외부 루프의 시작 |

  • 실행은 첫 번째 자식에서 시작됩니다.

  • 실행이 자식 중 하나의 끝에 도달하면 다음으로 계속됩니다. 마지막 자식의 끝에 도달하면 첫 번째 자식으로 돌아갑니다. (자식의 순서가 중요하지 않기 때문에 이것은 대칭을 위한 것입니다.)

  • 자식 중 하나로 분기하면 labels 시작 부분의 깊이까지 피연산자 스택이 해제됩니다.

  • 끝까지 분기하는 경우도 마찬가지지만 resulttype 이 비어 있지 않은 경우 block 와 유사하게 끝으로 분기하면 피연산자가 나오고 해제 후 푸시됩니다.

  • Dominance: labels 명령 앞의 기본 블록은 각 자식을 지배하고 labels 끝의 BB는 물론입니다. 아이들은 서로를 지배하거나 끝까지 지배하지 않습니다.

  • 디자인 노트:

  • N은 한 번에 코드의 유효성을 검사할 수 있도록 미리 지정됩니다. labels 블록의 끝 부분에 도달해야 하는 것은 이상할 것입니다. 블록 안의 인덱스 대상을 알기 전에 자식 수를 알아야 합니다.

  • 레이블 간에 피연산자 스택에 값을 전달하는 방법이 결국 있어야 하는지 확실하지 않지만 block 또는 loop 값을 전달할 수 없는 것과 유사하게 시작하는 데 지원되지 않을 수 있습니다. 와 함께.

그래도 루프에 뛰어들 수 있다면 정말 좋겠죠? IIUC, 그 경우가 고려된다면 불쾌한 루프 + br_table 콤보가 절대 필요하지 않을 것입니다 ...

편집: 오, labels 에서 위로 점프하여 loop 없이 루프를 만들 수 있습니다. 내가 그것을 놓쳤다는 것을 믿을 수 없다.

주어진 루프가 자연 루프가 아닌 경우 @qwertie의 wasm 타겟팅 컴파일러 사용하여 표현한다 labels 대신 loop . 그것이 당신이 말하는 것이라면 제어 흐름을 표현하기 위해 스위치를 추가할 필요가 전혀 없어야 합니다. (결국 최악의 경우 함수의 모든 기본 블록에 대해 레이블이 있는 하나의 거대한 labels 블록을 사용할 수 있습니다. 이렇게 하면 컴파일러가 우세 및 자연 루프에 대해 알 수 없으므로 놓칠 수 있습니다. 그러나 labels 는 해당 최적화가 적용되지 않는 경우에만 필요합니다 .)

축소성이 보장되는 중첩 루프 구조는 처음에는 거의 버려집니다. [...] JavaScriptCore, V8 및 SpiderMonkey에서 현재 WebAssembly 구현을 확인했는데 모두 이 패턴을 따르는 것 같습니다.

정확하지 않음: 적어도 SM에서 IR 그래프는 완전히 일반적인 그래프가 아닙니다. 우리는 구조화된 소스(JS 또는 wasm)에서 생성되고 종종 알고리즘을 단순화 및/또는 최적화하는 특정 그래프 불변성을 가정합니다. 완전히 일반적인 CFG를 지원하려면 파이프라인의 많은 패스를 감사/변경하여 이러한 불변량을 가정하지 않거나(이를 일반화하거나 환원 불가능한 경우 비관화하여) 그래프를 축소할 수 있도록 미리 노드 분할 복제를 수행해야 합니다. 물론 이것은 가능하지만 이것이 단순히 wasm이 인위적인 병목 현상을 일으키는 문제라는 것은 사실이 아닙니다.

또한 많은 옵션이 있고 다른 엔진이 다른 작업을 수행한다는 사실은 생산자가 환원 불가능성을 미리 처리하도록 하면 환원 불가능한 제어 흐름이 있는 상태에서 다소 더 예측 가능한 성능을 생성할 수 있음을 시사합니다.

과거에 임의의 goto 지원으로 wasm을 확장하기 위한 이전 버전과 호환되는 경로에 대해 논의했을 때 한 가지 큰 질문은 여기서 사용 사례가 무엇인지입니다. "실제로 환원할 수 없는 제어 흐름에 대해 보다 효율적인 코드 생성을 허용"? 전자라면 임의의 레이블/고토를 포함하는 방식을 원할 것입니다. 그것은 단지 비용/편익과 위에서 언급한 문제를 평가하는 문제일 뿐입니다.

그러나 후자의 사용 사례에서 우리가 관찰한 한 가지는 야생에서 Duff의 장치 사례를 가끔 볼 수 있지만(실제로 루프를 풀기 위한 효율적인 방법이 아닙니다...), 종종 성능이 중요한 곳에서 환원성 팝업이 표시되는 곳은 인터프리터 루프입니다. 인터프리터 루프는 또한 계산된 goto가 필요한 간접 스레딩의 이점을 얻습니다. 또한, 오프라인 컴파일러에서도 인터프리터 루프는 최악의 레지스터 할당을 받는 경향이 있습니다. 인터프리터 루프 성능이 매우 중요할 수 있기 때문에 한 가지 질문은 엔진이 간접 스레딩을 수행하고 적절한 재갈록을 수행할 수 있도록 하는 제어 흐름 기본 요소가 실제로 필요한지 여부입니다. (이것은 나에게 열린 질문입니다.)

@lukewagner
어떤 패스가 불변량에 의존하는지 자세히 듣고 싶습니다. 환원 불가능한 흐름을 위한 별도의 구성을 사용하여 내가 제안한 디자인은 LICM과 같은 최적화 단계에서 해당 흐름을 피하는 것이 상대적으로 쉬워야 합니다. 그러나 내가 생각하지 못한 다른 유형의 파손이 있는 경우, 그 특성을 더 잘 이해하여 이러한 파손을 피할 수 있는지 여부와 방법에 대해 더 잘 알고 싶습니다.

과거에 임의의 goto 지원으로 wasm을 확장하기 위한 이전 버전과 호환되는 경로에 대해 논의했을 때 한 가지 큰 질문은 여기서 사용 사례가 무엇인지입니다. "실제로 환원할 수 없는 제어 흐름에 대해 보다 효율적인 코드 생성을 허용"?

저에게는 후자입니다. 내 제안은 생산자가 도미네이터와 자연 루프를 식별하는 백엔드 작업을 저장하기 위해 여전히 리루퍼 유형 알고리즘을 실행하고 필요할 때만 labels 되돌아갈 것으로 기대합니다. 그러나 이것은 여전히 ​​생산자를 더 단순하게 만듭니다. 환원할 수 없는 제어 흐름에 큰 페널티가 있는 경우 이상적인 생산자는 코드를 복제하는 것이 더 효율적인지, 작동할 수 있는 최소한의 복제량 등을 결정하기 위해 휴리스틱을 사용하여 이를 피하기 위해 매우 열심히 노력해야 합니다. 유일한 페널티가 잠재적으로 주는 경우 업 루프 최적화, 이것은 실제로 필요하지 않거나 최소한 일반 기계 코드 백엔드(자체 루프 최적화가 있음)보다 더 필요하지 않습니다.

나는 실제로 환원 불가능한 제어 흐름이 얼마나 일반적인지에 대한 더 많은 데이터를 수집해야 합니다…

그러나 이러한 흐름을 처벌하는 것은 본질적으로 자의적이며 불필요하다고 생각합니다. 대부분의 경우 전체 프로그램 런타임에 미치는 영향은 작아야 합니다. 그러나 핫스팟에 감소할 수 없는 제어 흐름이 포함되는 경우 심각한 패널티가 발생합니다. 미래에는 WebAssembly 최적화 가이드에 이것을 일반적인 문제로 포함하고 이를 식별하고 피하는 방법을 설명할 수 있습니다. 내 믿음이 맞다면 이것은 프로그래머에게 완전히 불필요한 형태의 인지 오버헤드입니다. 그리고 오버헤드가 작더라도 WebAssembly는 이미 네이티브 코드에 비해 오버헤드가 충분하므로 추가를 피해야 합니다.

나는 내 믿음이 틀렸다는 확신을 가질 수 있습니다.

인터프리터 루프 성능이 매우 중요할 수 있기 때문에 한 가지 질문은 엔진이 간접 스레딩을 수행하고 적절한 재갈록을 수행할 수 있도록 하는 제어 흐름 기본 요소가 실제로 필요한지 여부입니다.

흥미롭게 들릴 수 있지만 보다 범용적인 프리미티브로 시작하는 것이 더 나을 것이라고 생각합니다. 결국, 인터프리터를 위해 맞춤화된 기본 요소는 축소할 수 없는 제어 흐름을 처리하기 위해 백엔드가 여전히 필요합니다. 그 총알을 깨물려면 일반적인 경우도 지원할 수 있습니다.

또는 내 제안이 이미 통역사를 위한 적절한 기본 기능을 제공할 수 있습니다. labels 와 br_table 를 결합하면 계산된 goto와 다르지 않은 함수의 임의 지점에서 점프 테이블을 직접 가리킬 수 있습니다. (최소한 초기에 제어 흐름을 스위치 블록 내의 지점으로 지시하는 C 스위치와 대조적으로, 모든 경우가 goto인 경우 컴파일러는 추가 점프를 최적화할 수 있어야 하지만 여러 '중복'을 병합할 수도 있습니다. 명령문을 하나로 전환하면 각 명령 처리기 뒤에 별도의 점프가 있다는 이점이 있습니다.) 레지스터 할당의 문제가 무엇인지 잘 모르겠습니다.

@comex 나는 환원 불가능한 제어 흐름이 있는 상태에서 기능 수준에서 전체 최적화 단계를 간단히 끌 수 있다고 생각합니다(SSA 생성, regalloc 및 기타 몇 가지가 필요하므로 작업이 필요할 수 있음). 그러나 나는 우리가 이전에 구조화된 그래프를 가정했던 각 알고리즘을 감사하는 것과 관련된 환원 불가능한 제어 흐름을 가진 기능에 대한 품질 코드를 실제로 생성하기를 원했습니다.

>

환원성이 보장되는 중첩 루프 구조는
초반에 많이 버렸습니다. [...] 나는 현재를 확인했다
JavaScriptCore, V8 및 SpiderMonkey의 WebAssembly 구현 및
모두 이 패턴을 따르는 것 같습니다.

정확하지 않음: 적어도 SM에서 IR 그래프는 완전히 일반적인 그래프가 아닙니다. 우리
다음에서 생성된 특정 그래프 불변량을 가정합니다.
구조화된 소스(JS 또는 wasm) 및 종종 단순화 및/또는 최적화
알고리즘.

V8에서도 마찬가지입니다. 실제로 두 가지 모두에서 SSA에 대한 나의 주요 불만 중 하나입니다.
거의 정의하지 않는 각각의 문헌 및 구현
"잘 구성된" CFG를 구성하지만 암시적으로 다양한
어쨌든 문서화되지 않은 제약 조건은 일반적으로 건설에 의해 보장됩니다.
언어 프론트엔드. 나는 기존 컴파일러에서 많은/대부분의 최적화가
진정으로 임의의 CFG를 처리할 수 없습니다.

@lukewagner가 말했듯이 환원 불가능한 제어의 주요 사용 사례는 아마도
최적화된 인터프리터를 위한 "스레드 코드". 얼마나 관련성이 있는지 말하기 어렵습니다.
Wasm 도메인에 대한 것이며, 그것의 부재가 실제로 가장 큰지 여부
병목.

많은 사람들과 환원 불가능한 제어 흐름에 대해 논의한 후
컴파일러 IR을 조사할 때 "가장 깨끗한" 솔루션은 아마도
상호 재귀 블록의 개념. 그것은 Wasm에게 맞는 일이 될 것입니다.
구조를 잘 제어합니다.

LLVM의 루프 최적화는 일반적으로 환원 불가능한 제어 흐름을 무시하고 최적화를 시도하지 않습니다. 그들이 기반으로 하는 루프 분석은 자연 루프만 인식하므로 루프로 인식되지 않는 CFG 주기가 있을 수 있다는 점을 알아야 합니다. 물론 다른 최적화는 본질적으로 더 지역적이며 환원 불가능한 CFG에서 잘 작동합니다.

메모리에서, 그리고 아마도 틀릴 수 있지만, SPEC2006은 401.bzip2에 단일 환원 불가 루프를 가지고 있으며 그게 전부입니다. 실제로는 매우 드뭅니다.

Clang은 계산된 goto를 사용하는 함수에서 단일 indirectbr 명령만 내보냅니다. 이것은 스레드 인터프리터를 루프 헤더로 indirectbr 블록을 사용하여 자연스러운 루프로 바꾸는 효과가 있습니다. LLVM IR을 떠난 후 단일 indirectbr 는 코드 생성기에서 꼬리 복제되어 원래 얽힘을 재구성합니다.

감소할 수 없는 제어 흐름에 대한 단일 패스 검증 알고리즘이 없습니다.
내가 알고 있는. 감소 가능한 제어 흐름만을 위한 설계 선택은 다음과 같습니다.
이 요구 사항의 영향을 많이 받습니다.

앞에서 언급했듯이 환원 불가능한 제어 흐름은 적어도 두 가지를 모델링할 수 있습니다.
다른 방법들. switch 문이 있는 루프는 실제로 최적화될 수 있습니다.
간단한 로컬 점프 스레딩을 통해 원래의 환원 불가능한 그래프로
최적화(예: 상수 할당이 있는 패턴을 접음으로써
지역 변수에 대한 분기가 발생하면 다음을 수행하는 조건 분기로 분기됩니다.
즉시 해당 지역 변수를 켭니다).

따라서 환원 불가능한 제어 구조는 전혀 필요하지 않으며,
복구를 위한 단일 컴파일러 백엔드 변환의 문제
원래 기약 그래프 및 최적화(컴파일러가 있는 엔진의 경우
4개의 브라우저 중 어느 것도 하지 않는 환원 불가능한 제어 흐름을 지원합니다.
내가 아는 한).

최상의,
-벤

2017년 4월 20일 목요일 오전 5:20, Jakob Stoklund Olesen <
[email protected]>은 다음과 같이 썼습니다.

LLVM의 루프 최적화는 일반적으로 환원 불가능한 제어 흐름을 무시합니다.
최적화를 시도하지 마십시오. 의지 기반 루프 분석
자연스러운 루프만 인식하므로
루프로 인식되지 않는 CFG 사이클입니다. 물론 다른
최적화는 본질적으로 더 지역적이며 환원 불가능한
CFG.

SPEC2006에는 메모리에서, 아마도 틀릴 수 있는 단일 루프가 있습니다.
401.bzip2 그리고 그게 다야. 실제로는 매우 드뭅니다.

Clang은 다음을 사용하는 함수에서 단일 indirectbr 명령만 내보냅니다
계산된 고토. 이것은 스레드 인터프리터를 다음으로 바꾸는 효과가 있습니다.
루프 헤더로 indirectbr 블록이 있는 자연 루프. 떠난 후
LLVM IR, 단일 간접 BR은 코드 생성기에서 꼬리 중복됩니다.
원래 얽힘을 재구성합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/WebAssembly/design/issues/796#issuecomment-295352983 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ALnq1K99AR5YaQuNOIFIckLLSIZbmbd0ks5rxkJQgaJpZM4J3ofA
.

나는 또한 환원할 수 없는 구성이 추가되어야 한다고 말할 수 있습니다.
WebAssembly에서는 TurboFan(V8의 JIT 최적화)에서 작동하지 않으므로 이러한
함수는 결국 해석(매우 느림)되거나
기준 컴파일러에 의해 컴파일됩니다(다소 느림).
감소할 수 없는 제어 흐름을 지원하도록 TurboFan을 업그레이드하는 데 노력을 투자하십시오.
즉, WebAssembly에서 축소할 수 없는 제어 흐름이 있는 기능은
아마도 훨씬 더 나쁜 성능으로 끝날 것입니다.

물론 다른 옵션은 V8의 WebAssembly 엔진이
TurboFan 축소 가능한 그래프를 제공하는 relooper, 그러나 컴파일이
(그리고 시작이 더 나빠짐). 재루핑은 내 오프라인 절차로 남아 있어야 합니다.
그렇지 않으면 피할 수 없는 엔진 비용으로 끝납니다.

최상의,
-벤

2017년 5월 1일 월요일 오후 12:48 Ben L. Titzer [email protected]에서 다음과 같이 썼습니다.

환원 불가능한 제어를 위한 단일 패스 검증 알고리즘이 없습니다.
내가 알고 있는 흐름. 감소 가능한 제어 흐름만을 위한 설계 선택
이 요구 사항의 영향을 많이 받았습니다.

앞에서 언급했듯이 환원 불가능한 제어 흐름은 적어도 두 가지를 모델링할 수 있습니다.
다른 방법들. switch 문이 있는 루프는 실제로 최적화될 수 있습니다.
간단한 로컬 점프 스레딩을 통해 원래의 환원 불가능한 그래프로
최적화(예: 상수 할당이 있는 패턴을 접음으로써
지역 변수에 대한 분기가 발생하면 다음을 수행하는 조건 분기로 분기됩니다.
즉시 해당 지역 변수를 켭니다).

따라서 환원 불가능한 제어 구조는 전혀 필요하지 않으며,
복구를 위한 단일 컴파일러 백엔드 변환의 문제
원래 기약 그래프 및 최적화(컴파일러가 있는 엔진의 경우
4개의 브라우저 중 어느 것도 하지 않는 환원 불가능한 제어 흐름을 지원합니다.
내가 아는 한).

최상의,
-벤

2017년 4월 20일 목요일 오전 5:20, Jakob Stoklund Olesen <
[email protected]>은 다음과 같이 썼습니다.

LLVM의 루프 최적화는 일반적으로 환원 불가능한 제어 흐름을 무시합니다.
최적화를 시도하지 마십시오. 의지 기반 루프 분석
자연스러운 루프만 인식하므로
루프로 인식되지 않는 CFG 사이클입니다. 물론 다른
최적화는 본질적으로 더 지역적이며 환원 불가능한
CFG.

SPEC2006에는 메모리에서, 아마도 틀릴 수 있는 단일 루프가 있습니다.
401.bzip2에 있고 그게 전부입니다. 실제로는 매우 드뭅니다.

Clang은 다음을 사용하는 함수에서 단일 indirectbr 명령만 내보냅니다
계산된 고토. 이것은 스레드 인터프리터를 다음으로 바꾸는 효과가 있습니다.
루프 헤더로 indirectbr 블록이 있는 자연 루프. 떠난 후
LLVM IR, 단일 간접 BR은 코드 생성기에서 꼬리 중복됩니다.
원래 얽힘을 재구성합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/WebAssembly/design/issues/796#issuecomment-295352983 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ALnq1K99AR5YaQuNOIFIckLLSIZbmbd0ks5rxkJQgaJpZM4J3ofA
.

환원 불가능한 제어 흐름의 선형 시간 검증을 위한 확립된 방법이 있습니다. 주목할만한 예는 JVM입니다. 스택맵을 사용하면 선형 시간 검증이 가능합니다. WebAssembly는 이미 모든 블록과 유사한 구성에 블록 서명을 가지고 있습니다. 여러 제어 흐름 경로가 병합되는 모든 지점에서 명시적 유형 정보를 사용하면 고정 소수점 알고리즘을 사용할 필요가 없습니다.

(참고로, 얼마 전에 나는 가상의 pick 연산자가 임의의 깊이에서 블록 외부를 읽는 것을 허용하지 않는 이유를 물었습니다. 이것은 하나의 대답입니다. 서명이 모든 것을 설명하도록 확장되지 않는 한 pick 읽을 수 있으며, pick 하면 더 많은 정보가 필요합니다.)

스위치가 있는 루프 패턴은 물론 점프 스레드로 제거될 수 있지만 의존하는 것은 실용적이지 않습니다. 엔진이 최적화하지 않으면 파괴적인 수준의 오버헤드가 발생합니다. 대부분의 엔진이 최적화하는 경우 언어 자체에서 축소할 수 없는 제어 흐름을 유지함으로써 무엇을 달성할 수 있는지 명확하지 않습니다.

한숨… 더 일찍 답장을 보내려 했지만 삶에 지장이 생겼습니다.

나는 몇몇 JS 엔진을 샅샅이 뒤져 왔으며, '그냥 작동하는' 환원 불가능한 제어 흐름에 대한 주장을 약화시켜야 한다고 생각합니다. 나는 여전히 그것을 작동하게 하는 것이 그렇게 어려울 것이라고 생각하지 않지만, 실제로 이익을 얻을 수 있는 방식으로 적응하기 어려울 몇 가지 구조가 있습니다…

글쎄요, 논쟁을 위해 최적화 파이프라인이 환원 불가능한 제어 흐름을 적절하게 지원하도록 하는 것이 너무 어렵다고 가정해 봅시다. JS 엔진은 여전히 ​​다음과 같이 해킹 방식으로 쉽게 지원할 수 있습니다.

백엔드 내에서 labels 블록을 마지막 순간까지 루프+스위치인 것처럼 취급합니다. 즉, labels 블록을 볼 때 각 레이블을 가리키는 바깥쪽 가장자리가 있는 루프 헤더로 처리하고 레이블을 대상으로 하는 branch 를 볼 때 다음을 생성합니다. labels 헤더를 가리키는 에지는 실제 대상 레이블이 아니라 어딘가에 별도로 저장되어야 합니다. 실제 루프+스위치와 같이 대상 레이블을 저장하기 위해 실제 변수를 생성할 필요가 없습니다. 분기 명령의 일부 필드에 값을 숨기거나 목적을 위해 별도의 제어 명령을 만드는 것으로 충분해야 합니다. 그런 다음 최적화, 스케줄링, 레지스터 할당까지 모두 두 개의 점프가 있는 것처럼 가장할 수 있습니다. 그러나 실제로 기본 점프 명령을 생성할 때가 되면 해당 필드를 확인하고 대상 레이블로 직접 점프를 생성합니다.

예를 들어 분기를 병합/삭제하는 최적화에 문제가 있을 수 있지만 이를 방지하는 것은 매우 쉽습니다. 세부 사항은 엔진 설계에 따라 다릅니다.

어떤 의미에서 내 제안은 @titzer의 "단순한 로컬 점프 스레딩 최적화"와 같습니다. 나는 '네이티브' 환원 불가능한 제어 흐름을 루프+스위치처럼 보이게 만들 것을 제안하고 있지만, 대안은 실제 루프+스위치를 식별하는 것입니다. 해당 로컬 변수를 즉시 켜는 조건부 분기로 분기"하고 파이프라인 후반에 간접 분기를 제거할 수 있도록 메타데이터를 추가합니다. 이 최적화가 유비쿼터스화되면 명시적 명령에 대한 적절한 대체가 될 수 있습니다.

어느 쪽이든, 해킹 접근 방식의 명백한 단점은 최적화가 실제 제어 흐름 그래프를 이해하지 못한다는 것입니다. 마치 어떤 레이블이 다른 레이블로 건너뛸 수 있는 것처럼 효과적으로 작동합니다. 특히 레지스터 할당은 변수를 모든 레이블에서 라이브로 처리해야 합니다. 예를 들어 다음 의사 코드에서와 같이 항상 특정 레이블로 점프하기 직전에 변수가 할당되더라도 다음과 같습니다.

a:
  control = 1;
  goto x;
b:
  control = 2;
  goto x;
...
x:
  // use control

이는 어떤 경우에 심각하게 차선의 레지스터 사용으로 이어질 수 있습니다. 그러나 나중에 언급하겠지만 JIT가 사용하는 활성 알고리즘은 기본적으로 이 작업을 잘 수행하지 못할 수 있습니다.

어떤 경우이든 최적화를 늦게 하는 것이 전혀 최적화하지 않는 것보다 훨씬 낫습니다. 단일 직접 점프는 점프 + 비교 + 로드 + 간접 점프보다 훨씬 좋습니다. CPU 분기 예측기는 결국 과거 상태를 기반으로 후자의 대상을 예측할 수 있지만 컴파일러만큼은 아닙니다. 그리고 '현재 상태' 변수에 대한 레지스터 및/또는 메모리 소비를 피할 수 있습니다.

표현에 관해서는 명시적( labels 명령어 또는 이와 유사한 것) 또는 암시적(특정 패턴을 따르는 실제 루프+스위치 최적화) 중 어느 것이 더 낫습니까?

암시적 이점:

• 사양을 간결하게 유지합니다.

• 기존 루프+스위치 코드로 이미 작동할 수 있습니다. 그러나 나는 바이너리넨이 충분히 엄격한 패턴을 따르는지 확인하기 위해 생성하는 것들을 보지 않았습니다.

• 축소할 수 없는 제어 흐름을 표현하는 축복된 방법을 해킹처럼 느끼게 만드는 것은 일반적으로 속도가 느리고 가능하면 피해야 한다는 사실을 강조합니다.

암시적 단점:

• 해킹 같은 느낌입니다. 사실, @titzer가 말했듯이 환원 불가능한 제어 흐름을 '적절하게' 지원하는 엔진에 실제로 불리하지 않습니다. 그들은 패턴을 조기에 인식하고 최적화를 수행하기 전에 원래의 환원 불가능한 흐름을 복구할 수 있습니다. 그래도 실제 점프를 허용하는 것이 더 깔끔해 보입니다.

• WebAssembly가 일반적으로 JS와 비교하여 피해야 하는 "최적화 절벽"을 만듭니다. 요약하자면, 최적화할 기본 패턴은 "로컬 변수에 상수를 할당한 다음 해당 로컬 변수를 즉시 켜는 조건 분기로 분기"하는 것입니다. 그러나 예를 들어 그 사이에 다른 명령이 있거나 할당이 실제로 wasm const 명령을 사용하지 않고 최적화로 인해 상수라고 알려진 것을 사용하는 경우에는 어떻게 될까요? 일부 엔진은 이 패턴으로 인식하는 점에서 다른 엔진보다 더 자유로울 수 있지만 이를 활용하는 코드(의도적이든 아니든)는 브라우저 간에 성능이 크게 다릅니다. 더 명시적인 인코딩을 사용하면 기대치가 더 명확해집니다.

• 가상의 후처리 단계에서 wasm을 IR처럼 사용하기 어렵게 만듭니다. wasm-targeting 컴파일러가 정상적인 방식으로 작업을 수행하고 결국 relooper를 실행하고 궁극적으로 wasm을 생성하기 전에 내부 IR을 사용하여 모든 최적화/변환을 처리한다면 매직 명령어 시퀀스의 존재를 신경 쓰지 않을 것입니다. 그러나 프로그램이 wasm 코드 자체에 대한 변환을 실행하려면 해당 시퀀스를 분해하는 것을 피해야 하므로 성가신 일입니다.

어쨌든, 나는 어느 쪽이든 그다지 신경 쓰지 않습니다. 암시적 접근 방식을 결정하는 한 주요 브라우저는 실제로 관련 최적화를 수행하는 데 전념합니다.

…

기본적으로 환원 불가능한 흐름을 지원하는 문제로 돌아가서 - 장애물이 무엇인지, 얼마나 많은 이점이 있는지 - 다음은 이를 지원하기 위해 수정해야 하는 최적화 단계에 대한 IonMonkey의 몇 가지 구체적인 예입니다.

AliasAnalysis.cpp: 역순으로 블록을 반복하고(한 번), 이전에 앨리어싱으로 볼 수 있는 저장소만 보고 명령에 대한 순서 지정 종속성을 생성합니다(InstructionReordering에서 사용됨). 순환 제어 흐름에서는 작동하지 않습니다. 그러나 (명시적으로 표시된) 루프는 동일한 루프의 임의의 이후 저장소에 대해 루프의 명령을 확인하는 두 번째 단계로 특별히 처리됩니다.

-> 그래서 마킹 일부 루프가있을 거라고 labels 블록. 이 경우 전체 labels 블록을 루프로 표시하는 것은 '그냥 작동'할 것이라고 생각합니다(개별 레이블을 특별히 표시하지 않음). 분석이 너무 부정확하여 루프 내의 제어 흐름을 처리할 수 없기 때문입니다.

FlowAliasAnalysis.cpp: 좀 더 똑똑한 대체 알고리즘입니다. 또한 역순으로 블록을 반복하지만 각 블록을 만나면 백 에지를 고려하는 루프 헤더를 제외하고 각 전임자(이미 계산된 것으로 가정)에 대해 계산된 마지막 저장 정보를 병합합니다.

-> Messier는 (a) 개별 기본 블록에 대한 선행 작업이 루프 백에지를 제외하고 항상 그 앞에 나타나고 (b) 루프에 백에지가 하나만 있을 수 있다고 가정하기 때문입니다. 이 문제를 해결할 수 있는 여러 가지 방법이 있지만 labels 의 명시적 처리가 필요할 수 있으며 알고리즘이 선형 상태를 유지하려면 이 경우 일반 AliasAnalysis 처럼 꽤 조잡하게 작동해야 할 것입니다.

BacktrackingAllocator.cpp: 레지스터 할당에 대한 유사한 동작: 명령어 목록을 통해 선형 역방향 전달을 수행하고 루프 백에지를 만날 때를 제외하고 명령어의 모든 사용이 해당 정의 이후에 나타날 것으로 가정합니다(즉, 이전에 처리됨). 루프의 시작 부분에서 라이브는 단순히 전체 루프를 통해 라이브 상태를 유지합니다.

-> 모든 레이블은 루프 헤더처럼 처리되어야 하지만 전체 레이블 블록에 대해 활성이 확장되어야 합니다. 구현하기 어렵지는 않지만 결과는 해킹 방식보다 나을 수 없습니다. 제 생각에는.

@comex 여기서 또 다른 고려 사항은 wasm 엔진이 얼마나 많은 작업을 수행할 것으로 예상되는지입니다. 예를 들어 위에서 Ion의 AliasAnalysis를 언급했지만 이야기의 다른 측면은 적어도 대부분의 프로그램이 선형 메모리를 사용하는 동안에는 WebAssembly 코드에서 별칭 분석이 그다지 중요하지 않다는 것입니다.

Ion의 BacktrackingAllocator.cpp 활성 알고리즘은 약간의 작업이 필요하지만 금지되지는 않습니다. OSR이 루프에 여러 항목을 생성할 수 있기 때문에 대부분의 Ion은 이미 다양한 형태의 환원 불가능한 제어 흐름을 처리합니다.

여기서 더 광범위한 질문은 WebAssembly 엔진이 수행할 최적화 작업입니다. WebAssembly가 생산자/라이브러리가 대부분의 최적화를 수행하는 예측 가능한 성능을 갖춘 어셈블리와 같은 플랫폼이 될 것으로 예상하는 경우 엔진이 상당한 부담을 주는 크고 복잡한 알고리즘이 필요하지 않기 때문에 축소할 수 없는 제어 흐름은 상당히 저렴한 비용이 될 것입니다. . WebAssembly가 더 높은 수준의 최적화를 자동으로 수행하는 더 높은 수준의 바이트코드가 될 것으로 예상하고 엔진이 더 복잡하다면 추가 복잡성을 피하기 위해 축소할 수 없는 제어 흐름을 언어에서 유지하는 것이 더 중요해집니다.

BTW는 또한 이 호에서 언급할 가치가 있는 Braun et al의 on-the-fly SSA 구성 알고리즘 입니다 . 이는 간단하고 빠른 on-the-fly SSA 구성 알고리즘이며 환원 불가능한 제어 흐름을 지원합니다.

WebKit(및 코드 서명을 확인하는 동적 링커)이 메모리를 실행 가능한 것으로 표시할 수 있는 유일한 프로그램인 iOS에서 WebAssembly를 qemu 백엔드로 사용하는 데 관심이 있습니다. Qemu의 codegen은 goto 문이 codegen에 필요한 모든 프로세서의 일부가 될 것이라고 가정하므로 goto가 추가되지 않으면 WebAssembly 백엔드가 거의 불가능합니다.

@tbodt - Binaryen의 relooper를 사용할 수 있습니까? 기본적으로 Wasm-with-goto를 생성한 다음 이를 Wasm에 대한 구조화된 제어 흐름으로 변환할 수 있습니다.

@eholk 그것은 기계 코드를 wasm으로 직접 번역하는 것보다 훨씬 느린 것처럼 들립니다.

@tbodt Binaryen을 사용하면 도중에 추가 IR이 추가되지만 훨씬 느려서는 안 됩니다. 컴파일 속도에 최적화되어 있다고 생각합니다. 또한 선택적으로 Binaryen 최적화 프로그램을 실행할 수 있으므로 gotos 등을 처리하는 것 외에 이점이 있을 수 있습니다. 이 최적화 프로그램은 qemu 최적화 프로그램이 수행하지 않는 작업(wasm 관련 작업)을 수행할 수 있습니다.

사실 저는 당신이 원한다면 그것에 대해 당신과 협력하는 데 매우 관심이 있을 것입니다. :) Qemu를 wasm으로 이식하는 것이 매우 유용할 것이라고 생각합니다.

그래서 다시 생각해보면, goto는 별로 도움이 되지 않을 것입니다. Qemu의 codegen은 기본 블록이 처음 실행될 때 기본 블록에 대한 코드를 생성합니다. 블록이 아직 생성되지 않은 블록으로 점프하면 블록을 생성하고 goto가 있는 이전 블록을 다음 블록으로 패치합니다. 내가 아는 한 동적 코드 로드 및 기존 기능의 패치는 웹 어셈블리에서 수행할 수 있는 작업이 아닙니다.

@kripken 협업에 관심이 있습니다. 채팅하기 가장 좋은 곳은 어디인가요?

기존 기능을 직접 패치할 수는 없지만 call_indirect 및 a WebAssembly.Table 를 사용하여 코드를 지트할 수 있습니다. 생성되지 않은 기본 블록에 대해 JavaScript를 호출하고, WebAssembly 모듈과 인스턴스를 동기적으로 생성하고, 내보낸 함수를 추출하고 테이블의 인덱스 위에 쓸 수 있습니다. 이후 호출은 생성된 함수를 사용합니다.

아직 누군가가 이것을 시도했는지 확실하지 않으므로 많은 거친 가장자리가 있을 수 있습니다.

꼬리 호출이 구현된 경우 작동할 수 있습니다. 그렇지 않으면 스택이 꽤 빨리 오버플로됩니다.

또 다른 문제는 기본 테이블에 공간을 할당하는 것입니다. 주소를 테이블 인덱스에 어떻게 매핑합니까?

또 다른 옵션은 각각의 새로운 기본 블록에서 wasm 함수를 재생성하는 것입니다. 이것은 사용된 블록의 수와 동일한 재컴파일 횟수를 의미하지만 컴파일 후(특히 내부 루프) 코드를 빠르게 실행할 수 있는 유일한 방법이며 전체 코드일 필요가 없습니다. 재컴파일하면 각 기존 블록에 대해 Binaryen IR을 재사용하고 새 블록에 IR을 추가하고 모든 블록에 대해 relooper를 실행할 수 있습니다.

(하지만 qemu가 게으르지 않고 전체 함수를 미리 컴파일하도록 할 수 있습니까?)

Binaryen 과의 협업을 위한 @tbodt, 한 가지 옵션은 작업과 함께 리포지토리를 만드는 것이고(문제를 사용할 수 있음), 다른 옵션은 qemu용 Binaryen에서 특정 문제를 여는 것입니다.

qemu에는 "함수"라는 개념이 없기 때문에 qemu가 한 번에 전체 함수를 컴파일하도록 할 수 없습니다.

블록의 전체 캐시를 다시 컴파일하는 데 시간이 오래 걸릴 수 있습니다. qemu의 내장 프로파일러를 사용하는 방법을 알아낸 다음 binaryen에서 문제를 여겠습니다.

사이드 질문입니다. 내 생각에 WebAssembly를 대상으로 하는 언어는 효율적인 상호 재귀 기능을 제공할 수 있어야 합니다. 유용성에 대한 설명을 보려면 다음을 읽어보시기 바랍니다. http://sharp-gamedev.blogspot.com/2011/08/forgotten-control-flow-construct.html

특히 Cheery 가 표현한 필요성은 상호 재귀 함수로 해결되는 것 같습니다.

꼬리 재귀의 필요성을 이해하지만 기본 기계가 goto를 제공하는지 여부를 제공하지 않는 경우에만 상호 재귀 기능을 구현할 수 있는지 궁금합니다. 그렇게 하면 WebAssembly를 대상으로 하는 데 어려움을 겪을 수 있는 수많은 프로그래밍 언어가 있을 것이기 때문에 나에게 그것은 그들에게 찬성하는 정당한 주장이 될 것입니다. 그렇지 않은 경우 상호 재귀 기능을 지원하는 최소한의 메커니즘만 있으면 됩니다(꼬리 재귀와 함께).

@davidgrenier , Wasm 모듈의 기능은 모두 상호 재귀적입니다. 그들에 대해 비효율적이라고 생각하는 점을 자세히 설명해 주시겠습니까? 꼬리 호출이 없거나 다른 것을 언급하고 있습니까?

일반 테일 콜이 오고 있습니다. 꼬리 재귀(상호 또는 기타)는 특별한 경우입니다.

나는 그들에 대해 어떤 것이 비효율적이라고 말하지 않았습니다. 내 말은, 당신이 그것들을 가지고 있다면, 상호 재귀 함수가 WebAssembly를 목표로 하는 언어 구현자가 필요로 하는 모든 것을 제공하기 때문에 일반적인 goto가 필요하지 않다는 것입니다.

Goto는 시각적 프로그래밍의 다이어그램에서 코드를 생성하는 데 매우 유용합니다. 아마도 지금은 비주얼 프로그래밍이 그다지 인기가 없지만 미래에는 더 많은 사람들을 얻을 수 있고 wass는 이에 대한 준비가 되어 있어야 한다고 생각합니다. 다이어그램 및 goto에서 코드 생성에 대한 추가 정보: http://drakon-editor.sourceforge.net/generation.html

곧 출시될 Go 1.11 릴리스에는 WebAssembly에 대한 실험적 지원이 포함됩니다. 여기에는 고루틴, 채널 등을 포함한 Go의 모든 기능에 대한 완전한 지원이 포함됩니다. 그러나 생성된 WebAssembly의 성능은 현재 그다지 좋지 않습니다.

이것은 주로 누락된 goto 명령 때문입니다. goto 명령어가 없으면 모든 함수에서 최상위 루프와 점프 테이블을 사용해야 했습니다. relooper 알고리즘을 사용하는 것은 우리에게 선택 사항이 아닙니다. 고루틴 간에 전환할 때 함수의 다른 지점에서 실행을 재개할 수 있어야 하기 때문입니다. relooper는 이것을 도울 수 없으며 goto 명령만 할 수 있습니다.

WebAssembly가 Go와 같은 언어를 지원할 수 있는 지경에 이르게 된 것은 굉장합니다. 그러나 진정한 웹 어셈블리가 되려면 WebAssembly가 다른 어셈블리 언어와 동등하게 강력해야 합니다. Go에는 다른 여러 플랫폼에 대해 매우 효율적인 어셈블리를 생성할 수 있는 고급 컴파일러가 있습니다. 이것이 웹을 위한 효율적인 어셈블리를 내보내는 데 이 컴파일러를 사용하는 것이 불가능하다는 것이 주로 WebAssembly의 제한이고 Go 컴파일러의 제한이 아니라고 주장하는 이유입니다.

relooper 알고리즘을 사용하는 것은 우리에게 선택 사항이 아닙니다. 고루틴 간에 전환할 때 함수의 다른 지점에서 실행을 재개할 수 있어야 하기 때문입니다.

명확히하기 위해 일반 goto로는 충분하지 않으며 사용 사례에 계산 된 goto 가 필요합니다. 맞습니까?

성능 면에서 일반 goto로 충분할 것이라고 생각합니다. 기본 블록 사이의 점프는 어쨌든 정적이며 고루틴을 전환하려면 분기에 goto가 있는 br_table 이면 충분합니다. 출력 크기는 다른 질문입니다.

각 기능에 정상적인 제어 흐름이 있는 것처럼 들리지만 고루틴을 재개할 때 "중간"에 있는 기능 항목에서 특정 다른 위치로 점프하는 기능도 필요합니다. 이러한 위치가 몇 개나 될까요? 모든 단일 기본 블록인 경우 리루퍼는 모든 명령이 통과하는 최상위 루프를 강제로 방출해야 하지만, 몇 개일 경우 문제가 되지 않습니다. (그것은 실제로 emscripten에서 setjmp 지원으로 발생하는 일입니다. LLVM의 기본 블록 사이에 추가로 필요한 경로를 만들고 relooper가 정상적으로 처리하도록 합니다.)

다른 함수에 대한 모든 호출은 이러한 위치이며 대부분의 기본 블록에는 적어도 하나의 호출 명령이 있습니다. 우리는 호출 스택을 어느 정도 풀고 복원하고 있습니다.

알겠습니다. 감사합니다. 예, 실용적이려면 정적 goto 또는 호출 스택 복원 지원이 필요하다는 데 동의합니다(이 또한 고려됨).

CPS 스타일로 함수를 호출하거나 WASM에서 call/cc 를 구현할 수 있습니까?

@Heimdell , 구분된 연속 형태(일명 "스택 전환")에 대한 지원이 로드맵에 있으며 거의 ​​모든 흥미로운 제어 추상화에 충분해야 합니다. Wasm 호출 스택은 임베더에 대한 재진입 호출을 포함하여 다른 언어와 임의로 혼합될 수 있고 따라서 복사 가능하거나 이동 가능하다고 가정할 수 없기 때문에 우리는 무제한 연속(즉, 전체 호출/cc)을 지원할 수 없습니다.

이 스레드를 읽으면서 임의의 레이블과 goto가 기능이 되기 전에 큰 장애물이 있다는 인상을 받았습니다.

• 구조화되지 않은 제어 흐름은 환원 불가능한 제어 흐름 그래프를 가능하게 합니다.
• "빠르고 간단한 검증, 쉬운, SSA 양식으로의 원패스 변환" 제거*
• 비선형 성능에 JIT 컴파일러 열기
• 원래 언어 컴파일러가 선행 작업을 수행할 수 있다면 웹 페이지를 탐색하는 사람들이 지연을 겪을 필요가 없습니다.

_* 비록 환원 불가능한 제어 흐름을 처리하는 Braun et al의 즉석 SSA 구성 알고리즘 과 같은 대안이 있을 수 있지만_

우리가 여전히 거기에 갇혀 있다면 _및_ 테일 호출이 계속 진행되고 있을 것입니다. 언어 컴파일러에게 여전히 goto로 번역하도록 요청할 가치가 있지만 WebAssembly 출력 전에 마지막 단계로 "레이블 블록"을 함수로 분할하고, goto를 꼬리 호출로 변환하십시오.

Scheme 디자이너 Guy Steele의 1977년 논문 Lambda: The Ultimate GOTO 에 따르면 변환이 가능해야 하며 꼬리 호출의 성능은 goto와 거의 일치할 수 있어야 합니다.

생각?

우리가 여전히 거기에 갇혀 있다면 _및_ 테일 호출이 계속 진행되고 있을 것입니다. 언어 컴파일러에게 여전히 goto로 번역하도록 요청할 가치가 있지만 WebAssembly 출력 전에 마지막 단계로 "레이블 블록"을 함수로 분할하고, goto를 꼬리 호출로 변환하십시오.

이것은 본질적으로 모든 컴파일러가 수행할 작업입니다. 내가 아는 사람 중 누구도 유형이 지정된 EBB의 그래프에 대해 JVM에서 많은 문제를 일으키는 종류의 관리되지 않는 goto를 옹호하지 않습니다. LLVM, GCC, Cranelift 및 나머지는 모두 내부 표현으로 (환원 불가능한) SSA 형식 CFG를 갖고 Wasm에서 네이티브로의 컴파일러는 동일한 내부 표현을 가지므로 가능한 한 많은 정보를 보존하고 싶습니다. 가능한 한 적은 정보를 재구성하십시오. 로컬은 더 이상 SSA가 아니기 때문에 손실이 발생하고 Wasm의 제어 흐름은 더 이상 임의의 CFG가 아니기 때문에 손실이 발생합니다. Wasm을 포함하는 AFAIK는 세분화된 레지스터 활성 정보가 포함된 무한 레지스터 SSA 레지스터 머신이 아마 codegen에 가장 적합할 것이지만 코드 크기가 부풀려질 것입니다. 임의의 CFG에서 모델링된 제어 흐름이 있는 스택 머신이 아마도 최고의 중간 지점일 것입니다. . 레지스터 기계의 코드 크기에 대해 틀릴 수 있지만 효율적으로 인코딩할 수 있습니다.

환원 불가능한 제어 흐름에 관한 것은 프론트 엔드에서 환원할 수 없는 경우 wasm에서 여전히 환원할 수 없다는 것입니다. relooper/stackifier 변환은 제어 흐름을 환원 가능하게 만들지 않고, 단지 환원 불가능성을 런타임 값에 종속되도록 변환합니다. 이것은 백엔드에 더 적은 정보를 제공하므로 더 나쁜 코드를 생성할 수 있습니다. 현재 환원 불가능한 CFG에 대해 좋은 코드를 생성하는 유일한 방법은 relooper 및 stackifier에서 방출되는 패턴을 감지하고 이를 다시 환원 불가능한 CFG로 변환하는 것입니다. AFAIK가 축소 가능한 제어 흐름만 지원하는 V8을 개발하지 않는 한, 축소 가능한 제어 흐름을 지원하는 것은 순전히 승리입니다. 이는 프론트엔드와 백엔드 모두를 훨씬 더 간단하게 만듭니다(프론트엔드는 내부적으로 저장하는 것과 동일한 형식으로 코드를 내보낼 수 있습니다. 백엔드는 패턴을 감지해야 함) 제어 흐름이 환원될 수 없는 경우 더 나은 출력을 생성하고 제어 흐름이 환원 가능한 일반적인 경우와 같거나 더 나은 출력을 생성합니다.

또한 GCC와 Go가 WebAssembly 생산을 시작할 수 있습니다.

V8이 WebAssembly 에코시스템의 중요한 구성 요소라는 것을 알고 있지만 현재 제어 흐름 상황에서 이점을 얻는 에코시스템의 유일한 부분인 것 같습니다. 다른 모든 백엔드는 어쨌든 CFG로 변환하고 영향을 받지 않습니다. WebAssembly가 환원 불가능한 제어 흐름을 나타낼 수 있는지 여부.

관련 기사: WebAssembly 문제 2부: Relooper 알고리즘이 다시 필요한 이유는 무엇입니까?

v8은 입력 CFG를 수락하기 위해 relooper를 통합할 수 없었습니까? v8의 구현 세부 사항에서 생태계의 큰 덩어리가 차단 된 것 같습니다.

참고로 C++의 switch 문은 was에서 매우 느립니다. 코드를 프로파일링할 때 이미지 처리를 수행하기 위해 훨씬 더 빠르게 작동하는 다른 형식으로 변환해야 했습니다. 그리고 다른 아키텍처에서는 결코 문제가 되지 않았습니다. 성능상의 이유로 정말 가고 싶습니다.

@graph , "switch 문이 느린" 방법에 대한 자세한 정보를 제공할 수 있습니까? 항상 성능을 개선할 수 있는 기회를 찾고 있습니다... (이 스레드를 보고 싶지 않다면 [email protected]으로 직접 이메일을 보내주십시오.)

이것은 모든 브라우저에 적용되므로 여기에 게시하겠습니다. if 문으로 변환할 때 더 빠른 emscripten으로 컴파일할 때 이와 같은 간단한 문.

for(y = ....) {
    for(x = ....) {
        switch(type){
        case IS_RGBA:....
         ....
        case IS_BGRA
        ....
        case IS_RGB
        ....
....

컴파일러가 점프 테이블을 wasm이 지원하는 모든 것으로 변환하고 있다고 가정합니다. 생성된 어셈블리를 살펴보지 않았으므로 확인할 수 없습니다.

웹에서 이미지 처리에 최적화할 수 있는 wassing과 관련이 없는 몇 가지를 알고 있습니다. 이미 파이어폭스의 "피드백" 버튼을 통해 제출했습니다. 관심이 있으시면 알려주시면 문제를 이메일로 보내 드리겠습니다.

@graph 완전한 벤치마크는 여기에서 매우 도움이 될 것입니다. 일반적으로 C의 스위치는 wasm에서 매우 빠른 점프 테이블로 바뀔 수 있지만 아직 제대로 작동하지 않는 코너 케이스가 있어서 LLVM이나 브라우저에서 수정해야 할 수도 있습니다.

특히 emscripten에서는 이전 fastcomp 백엔드와 새로운 upstream 백엔드 사이에서 스위치를 처리하는 방법이 많이 변경되므로 얼마전 또는 최근에 fastcomp를 사용하여 이것을 봤다면 업스트림에서 확인하는 것이 좋습니다.

@graph , @kripken에 동의합니다. 공유할 내용이 있으면 실행 가능한 코드가 여기에서 매우 도움이 될 것입니다.

(v8 또는 jsc에 대해 모르지만 Firefox는 현재 if-then-else 체인을 가능한 스위치로 인식하지 않으므로 일반적으로 긴 if-then-else 체인만큼 스위치를 공개하는 것은 좋은 생각이 아닙니다. 손익분기점은 아마도 2~3번의 비교를 넘지 않을 것입니다.)

@lars-t-hansen @kripken @graph br_table 는 이 교환이 보여주는 것처럼 현재 매우 최적화되지 않은 것일 수 있습니다. https://twitter.com/battagline/status/1168310096515883008

@aardappel , 이상합니다. 어제 실행한 벤치마크에서는 이것을 보여주지 않았습니다. 내 시스템의 파이어폭스에서 손익분기점은 내가 기억하는 약 5건이었고 그 후 br_table이 승자였습니다. 물론 microbenchmark와 조회 키를 균등하게 배포하려는 시도가 있습니다. "if" 네스트가 가장 가능성이 높은 키에 편향되어 있어 두 번 이상의 테스트가 필요하지 않으면 "if" 네스트가 승리합니다.

이를 피하기 위해 스위치 값에 대한 범위 분석을 수행할 수 없는 경우 br_table은 또한 스위치 범위에 대해 적어도 하나의 필터링 테스트를 수행해야 하며 이는 이점도 먹습니다.

@lars-t-hansen 예, 우리는 그의 테스트 케이스를 모릅니다. 이상값이 있었을 수도 있습니다. 어느 쪽이든 Chrome이 Firefox보다 할 일이 더 많은 것 같습니다.

휴가중이라 답변이 부족합니다. 이해 주셔서 감사합니다.

@kripken @lars-t-hansen 몇 가지 테스트를 실행했는데 예, 이제 파이어폭스에서 더 나은 것 같습니다. if-else가 스위치를 능가하는 경우가 여전히 있습니다. 다음은 사례입니다.

#include <stdio.h>

#include <chrono>
#include <random>

class Chronometer {
public:
    Chronometer() {

    }

    void start() {
        mStart = std::chrono::steady_clock::now();
    }

    double seconds() {
        std::chrono::steady_clock::time_point end = std::chrono::steady_clock::now();
        return std::chrono::duration_cast<std::chrono::duration<double>>(end - mStart).count();
    }

private:
    std::chrono::steady_clock::time_point mStart;
};

int main() {
    printf("Starting tests!\n");
    Chronometer timer;
    // we want to prevent optimizations based on known size as most applications
    // do not know the size in advance.
    std::random_device rd;  //Will be used to obtain a seed for the random number engine
    std::mt19937 gen(rd()); //Standard mersenne_twister_engine seeded with rd()
    std::uniform_int_distribution<> dis(100000000, 1000000000);
    std::uniform_int_distribution<> opKind(0, 3);
    int maxFrames = dis(gen);
    int switchSelect = 0;
    constexpr int SW1 = 1;
    constexpr int SW2 = 8;
    constexpr int SW3 = 32;
    constexpr int SW4 = 38;

    switch(opKind(gen)) {
    case 0:
        switchSelect = SW1;
        break;
    case 1:
        switchSelect = SW2; break;
    case 2:
        switchSelect = SW3; break;
    case 4:
        switchSelect = SW4; break;
    }
    printf("timing with SW = %d\n", switchSelect);
    timer.start();
    int accumulator = 0;
    for(int i = 0; i < maxFrames; ++i) {
        switch(switchSelect) {
        case SW1:
            accumulator = accumulator*3 + i; break;
        case SW2:
            accumulator = (accumulator < 3)*i; break;
        case SW3:
            accumulator = (accumulator&0xFF)*i + accumulator; break;
        case SW4:
            accumulator = (accumulator*accumulator) - accumulator + i; break;
        }
    }
    printf("switch time = %lf seconds\n", timer.seconds());
    printf("accumulated value: %d\n", accumulator);
    timer.start();
    accumulator = 0;
    for(int i = 0; i < maxFrames; ++i) {
        if(switchSelect == SW1)
            accumulator = accumulator*3 + i;
        else if(switchSelect == SW2)
            accumulator = (accumulator < 3)*i;
        else if(switchSelect == SW3)
            accumulator = (accumulator&0xFF)*i + accumulator;
        else if(switchSelect == SW4)
            accumulator = (accumulator*accumulator) - accumulator + i;
    }
    printf("if-else time = %lf seconds\n", timer.seconds());
    printf("accumulated value: %d\n", accumulator);

    return 0;
}

switchSelect의 값에 따라 다릅니다. if-else가 성능을 능가합니다. 출력 예:

Starting tests!
timing with SW = 32
switch time = 2.049000 seconds
accumulated value: 0
if-else time = 0.401000 seconds
accumulated value: 0

switchSelect = 32 if-else에서 볼 수 있듯이 훨씬 빠릅니다. 다른 경우에는 if-else가 조금 더 빠릅니다. switchSelect = 1 & 0인 경우 switch 문이 더 빠릅니다.

Test in Firefox 69.0.3 (64-bit)
compiled using: emcc -O3 -std=c++17 main.cpp -o main.html
emcc version: emcc (Emscripten gcc/clang-like replacement) 1.39.0 (commit e047fe4c1ecfae6ba471ca43f2f630b79516706b)

2019년 10월 20일 현재 안정적인 최신 emscripen 사용. 새로 설치 ./emcc activate latest .

위에서 오타가 있음을 알아차렸지만 동일한 명령을 실행하기 때문에 if-else가 더 빠른 SW3 경우에 영향을 미치지 않아야 합니다.

다시 5의 손익분기점을 넘어섰습니다. 이 경우 switchSelect=32의 경우 속도가 if-else와 비슷하다는 점이 흥미롭습니다. 1003 if-else에서 볼 수 있듯이 약간 더 빠릅니다. 이 경우 스위치가 승리해야 합니다.

Starting tests!
timing with SW = 1003
switch time = 2.253000 seconds
accumulated value: 1903939380
if-else time = 2.197000 seconds
accumulated value: 1903939380

#include <stdio.h>

#include <chrono>
#include <random>

class Chronometer {
public:
    Chronometer() {

    }

    void start() {
        mStart = std::chrono::steady_clock::now();
    }

    double seconds() {
        std::chrono::steady_clock::time_point end = std::chrono::steady_clock::now();
        return std::chrono::duration_cast<std::chrono::duration<double>>(end - mStart).count();
    }

private:
    std::chrono::steady_clock::time_point mStart;
};

int main() {
    printf("Starting tests!\n");
    Chronometer timer;
    // we want to prevent optimizations based on known size as most applications
    // do not know the size in advance.
    std::random_device rd;  //Will be used to obtain a seed for the random number engine
    std::mt19937 gen(rd()); //Standard mersenne_twister_engine seeded with rd()
    std::uniform_int_distribution<> dis(100000000, 1000000000);
    std::uniform_int_distribution<> opKind(0, 8);
    int maxFrames = dis(gen);
    int switchSelect = 0;
    constexpr int SW1 = 1;
    constexpr int SW2 = 8;
    constexpr int SW3 = 32;
    constexpr int SW4 = 38;
    constexpr int SW5 = 64;
    constexpr int SW6 = 67;
    constexpr int SW7 = 1003;
    constexpr int SW8 = 256;

    switch(opKind(gen)) {
    case 0:
        switchSelect = SW1;
        break;
    case 1:
        switchSelect = SW2; break;
    case 2:
        switchSelect = SW3; break;
    case 3:
        switchSelect = SW4; break;
    case 4:
        switchSelect = SW5; break;
    case 5:
        switchSelect = SW6; break;
    case 6:
        switchSelect = SW7; break;
    case 7:
        switchSelect = SW8; break;
    }
    printf("timing with SW = %d\n", switchSelect);
    timer.start();
    int accumulator = 0;
    for(int i = 0; i < maxFrames; ++i) {
        switch(switchSelect) {
        case SW1:
            accumulator = accumulator*3 + i; break;
        case SW2:
            accumulator = (accumulator < 3)*i; break;
        case SW3:
            accumulator = (accumulator&0xFF)*i + accumulator; break;
        case SW4:
            accumulator = (accumulator*accumulator) - accumulator + i; break;
        case SW5:
            accumulator = (accumulator << 3) - accumulator + i; break;
        case SW6:
            accumulator = (i - accumulator) & 0xFF; break;
        case SW7:
            accumulator = i*i + accumulator; break;
        }
    }
    printf("switch time = %lf seconds\n", timer.seconds());
    printf("accumulated value: %d\n", accumulator);
    timer.start();
    accumulator = 0;
    for(int i = 0; i < maxFrames; ++i) {
        if(switchSelect == SW1)
            accumulator = accumulator*3 + i;
        else if(switchSelect == SW2)
            accumulator = (accumulator < 3)*i;
        else if(switchSelect == SW3)
            accumulator = (accumulator&0xFF)*i + accumulator;
        else if(switchSelect == SW4)
            accumulator = (accumulator*accumulator) - accumulator + i;
        else if(switchSelect == SW5)
            accumulator = (accumulator << 3) - accumulator + i;
        else if(switchSelect == SW6)
            accumulator = (i - accumulator) & 0xFF;
        else if(switchSelect == SW7)
            accumulator = i*i + accumulator;

    }
    printf("if-else time = %lf seconds\n", timer.seconds());
    printf("accumulated value: %d\n", accumulator);

    return 0;
}

이 테스트 케이스를 살펴봐 주셔서 감사합니다.

그것은 매우 희박한 switch 입니다. LLVM은 어쨌든 if-then 세트와 동등한 것으로 변환해야 하지만 분명히 수동 if-then보다 덜 효율적인 방식으로 변환해야 합니다. 이 두 루프가 코드에서 어떻게 다른지 보기 위해 wasm2wat를 실행해 보셨습니까?

이것은 또한 각 반복에서 동일한 값을 사용하는 이 테스트에 크게 의존합니다. 이 테스트는 모든 값을 순환하거나 값에서 무작위로 선택하는 것이 좋습니다(저렴하게 수행할 수 있는 경우).

더 좋은 점은 사람들이 성능을 위해 스위치를 사용하는 진짜 이유는 범위가 조밀하기 때문입니다. 따라서 실제로 아래에서 br_table 사용하고 있음을 보장할 수 있습니다. br_table 가 if 보다 빠른 경우가 몇 개인지 확인하는 것이 가장 유용한 정보입니다.

빡빡한 루프의 스위치는 성능보다 코드가 더 깔끔했기 때문에 사용되었습니다. 그러나 wass의 경우 성능 영향이 너무 커서 더 못생긴 if 문으로 변환되었습니다. 많은 사용 사례에서 이미지 처리를 위해 스위치에서 더 많은 성능을 원하면 스위치를 루프 외부로 이동하고 각 경우에 대한 루프 사본을 가지기만 하면 됩니다. 일반적으로 전환은 픽셀 형식, 색상 형식, 인코딩 등의 일부 형식 간에 전환하는 것입니다. 그리고 많은 경우 상수는 선형이 아닌 정의 또는 열거형을 통해 계산됩니다. 이제 내 문제가 goto 디자인과 관련이 없다는 것을 알았습니다. 나는 내 switch 문에 대해 무슨 일이 일어나고 있는지 불완전하게 이해하고 있었습니다. 내 노트가 이 경우 이미지 처리를 위해 wasm을 최적화하기 위해 이 글을 읽는 브라우저 개발자에게 유용하기를 바랍니다. 감사합니다.

goto가 이렇게 열띤 토론을 할 수 있을 줄은 상상도 못했습니다 😮 . 나는 모든 언어의 보트에 goto가 있어야합니다 😁 . goto를 추가하는 또 다른 이유는 컴파일러가 wasm으로 컴파일하는 복잡성을 줄이기 때문입니다. 나는 그것이 어딘가에 위에서 언급했다고 확신합니다. 이제 불평할 것이 없습니다 😞 .

더 이상의 진전이 있습니까?

열띤 토론으로 인해 일부 브라우저는 goto에 대한 지원을 비표준 바이트코드 확장으로 추가할 것이라고 가정합니다. 그러면 GCC가 비표준 버전을 지원하는 것으로 게임에 들어갈 수 있습니다. 전반적으로 좋지 않다고 생각하지만 더 많은 컴파일러 경쟁을 허용합니다. 이것이 고려되었습니까?

최근에 많은 진전이 없었지만 funclets 제안 을 살펴보고 싶을 수도 있습니다.

@graph 나에게 당신의 제안은 "모든 것을 부수고 더 나은 것을 바라자"처럼 들립니다.
그런 식으로 작동하지 않습니다. 현재 WebAssembly 구조에는 많은 이점이 있습니다(불행히도 명확하지 않음). wass의 철학에 더 깊이 빠져보십시오.

"임의의 레이블 및 고토스"를 허용하면 검증할 수 없는 바이트코드의 (고대) 시대로 돌아가게 됩니다. 모든 컴파일러는 "올바른 작업" 대신 작업을 "게으른 방법"으로 전환합니다.

현재 상태의 wasm에는 몇 가지 중요한 누락이 있음이 분명합니다. 사람들은 ( @binji가 언급한 것과 같은) 공백을 메우기 위해 노력하고 있지만 "글로벌 wasm 구조"를 다시 작업할 필요 는 없다고 생각합니다. 그냥 제 소박한 생각입니다.

@vshymanskyy 임의의 레이블 및 goto와 동일한 기능을 제공하는 funclet 제안은 선형 시간에서 완전히 검증 가능합니다.

나는 또한 우리의 선형 시간 Wasm 컴파일러, 우리는 내부적으로 funclets 같은 표현, 난에 대한 정보가에 모든 Wasm 제어 흐름을 컴파일 언급해야 이 블록의 게시물에 구현되며이 내부 표현 Wasm 제어 흐름의 변환을 여기 . 컴파일러는 이 funclet과 같은 표현에서 모든 유형 정보를 가져오므로 선형 시간에 유형 안전성을 확인하는 것이 간단하다고 말하는 것으로 충분합니다.

환원 불가능한 제어 흐름을 선형 시간으로 검증할 수 없다는 이러한 오해는 환원 불가능한 제어 흐름이 컴파일되는 대신 인터프리터를 사용하여 실행되어야 하는 JVM에서 비롯된 것이라고 생각합니다. 이는 JVM이 환원 불가능한 제어 흐름에 대한 유형 메타데이터를 표현할 방법이 없어 스택 머신에서 레지스터 머신으로의 변환을 수행할 수 없기 때문이다. "임의 gotos"(즉, 바이트/명령어 X로 점프)는 전혀 확인할 수 없지만 함수를 유형이 지정된 블록으로 분리한 다음 임의의 순서로 건너뛸 수 있는 것은 모듈을 유형이 지정된 함수로 분리하는 것보다 검증하기 어렵지 않습니다. , 그런 다음 임의의 순서로 건너뛸 수 있습니다. GCC 및 LLVM과 같은 컴파일러에서 내보내는 유용한 패턴을 구현하기 위해 jump-to-byte-X-style untyped goto가 필요하지 않습니다.

나는 여기의 과정을 좋아합니다. A면은 특정 애플리케이션에서 이것이 필요한 이유를 설명합니다. B측은 그들이 잘못하고 있다고 말하지만 해당 애플리케이션에 대한 지원은 제공하지 않습니다. A면은 B의 실용적인 주장 중 어느 것도 타당하지 않은 이유를 설명합니다. B 측은 A 측이 잘못하고 있다고 생각하기 때문에 처리하기를 원하지 않습니다. 사이드 A는 목표를 달성하기 위해 노력하고 있습니다. 사이드 B는 그것을 게으르거나 야만적이라고 부르는 잘못된 목표라고 말합니다. 더 깊은 철학적 의미는 A면에서 손실됩니다. 실용적인 의미는 B면에서 손실됩니다. 왜냐하면 그들은 일종의 더 높은 도덕적 기반을 가지고 있다고 주장하기 때문입니다. A측은 이것을 비도덕적인 기계론적 작업으로 보고 있습니다. 궁극적으로 측면 B는 일반적으로 더 좋거나 나쁘게 사양을 제어하고 있으며 상대적인 순도에 따라 엄청난 양의 작업을 수행했습니다.

솔직히 말해서, 몇 년 전 저는 TinyCC 포트를 WASM으로 만들려고 했기 때문에 ESP8266을 대상으로 하는 ESP8266에서 개발 환경을 실행할 수 있었습니다. ~4MB의 저장 공간만 있으므로 재루퍼 및 AST로의 전환 및 기타 많은 변경 사항을 포함하는 것은 불가능합니다. (참고: relooper가 relooper와 같은 유일한 방법은 무엇입니까? 정말 끔찍하고 아무도 In C에서 그 빨판을 다시 작성하지 않았습니다!?) 이 시점에서 가능하더라도 TinyCC 대상을 작성할지 모르겠습니다. 나에게 더 이상 흥미롭지 않기 때문에 WASM에.

그래도 이 스레드. 이 실은 나에게 많은 실존적 기쁨을 가져다주었다. 인류의 분열을 지켜보는 것은 민주주의자나 공화주의자, 종교보다 더 깊습니다. 이 문제가 해결될 수 있을까 하는 생각이 듭니다. A가 B의 세계에서 살 수 있게 되거나 B가 절차적 프로그래밍이 그 자리를 차지한다는 A의 주장을 입증한다면... 저는 우리가 세계 평화를 해결할 수 있을 것 같습니다.

V8 담당자가 이 스레드에서 환원 불가능한 제어 흐름에 대한 반대가 V8의 현재 구현에 영향을 받지 않는다는 것을 확인할 수 있습니까?

이것이 가장 나를 괴롭히는 것이기 때문에 나는 묻는다. 나에게 이것은 이 기능의 장단점에 대한 사양 수준에 대한 토론이어야 하는 것 같습니다. 특정 구현이 현재 어떻게 설계되었는지에 의해 전혀 영향을 받아서는 안 됩니다. 그러나 V8의 구현이 이에 영향을 미치고 있다고 믿게 만드는 진술이 있었습니다. 내가 틀렸을 수도 있습니다. 공개 진술이 도움이 될 수 있습니다.

글쎄요, 불행한 만큼, 현재까지 존재하는 현재 구현은 너무 중요해서 미래(과거보다 더 길었을 것)는 그렇게 중요하지 않습니다. 나는 #1202에서 일관성이 몇 가지 구현보다 더 중요하다고 설명하려고했지만 망상 인 것 같습니다. 일부 프로젝트의 일부 개발 결정이 보편적인 진실을 구성하지 않거나 기본적으로 올바른 것으로 가정해야 한다고 설명하는 행운을 빕니다.

이 스레드는 W3C 탄광에 있는 하나의 카나리아입니다. 저는 많은 W3C 개인을 존경하지만 W3C가 아닌 Ecma International에 JavaScript를 위임하기로 한 결정이 편견 없이 이루어진 것은 아닙니다.

@cnlohr 처럼, 나는 TCC wasm 포트에 대한 희망을 가지고 있었고, 그럴만한 이유가 있었습니다.

"Wasm은 프로그래밍 언어를 위한 이식 가능한 컴파일 대상으로 설계되어 클라이언트 및 서버 응용 프로그램을 위해 웹에 배포할 수 있습니다." - webassembly.org

물론, 누구나 goto 가 [INSERT JARGON]인 이유를 장담할 수 있지만 의견보다 표준을 선호하는 것은 어떻습니까? 우리 모두는 POSIX C가 좋은 기본 타겟이라는 데 동의할 수 있습니다. 특히 오늘날의 lang이 C에서 만들어지거나 C에 대해 벤치마킹되고 WASM의 홈페이지 헤드라인이 자체적으로 lang에 대한 이식 가능한 컴파일 타겟을 선전하고 있다는 점을 감안할 때 그렇습니다. 물론 일부 기능은 스레드 및 simd와 같이 로드맵됩니다. 그러나 goto 와 같은 근본적인 것을 완전히 무시하고 로드맵의 품위조차 부여하지 않는 것은 WASM의 명시된 목적과 <marquee> 를 승인한 표준화 기구의 입장과 일치하지 않습니다. 창백하지 않습니다.

SEI CERT C Coding Standard Rec. "리소스를 사용하고 해제할 때 오류에 함수를 남길 때 goto 체인 사용을 고려하십시오" ;

많은 기능을 사용하려면 여러 리소스를 할당해야 합니다. 할당된 모든 리소스를 해제하지 않고 이 함수의 중간 어딘가에서 실패하고 반환하면 메모리 누수가 발생할 수 있습니다. 이런 방식으로 리소스 중 하나(또는 전체)를 해제하는 것을 잊는 것은 일반적인 오류이므로 goto 체인은 해제된 리소스의 순서를 유지하면서 종료를 구성하는 가장 간단하고 깔끔한 방법입니다.

그런 다음 권장 사항은 goto 사용하는 선호하는 POSIX C 솔루션의 예를 제공합니다. 반대론자들은 goto 가 여전히 해로운 것으로 간주 된다는 점을 지적할

결론적으로 "CSS 지역" 또는 goto 를 유해한 것으로 간주하는 것은 그러한 기능이 사용되는 문제에 대한 제안된 솔루션과 함께 고려되어야 합니다. 해당 "유해한" 기능을 제거하는 것이 대안 없이 합리적인 사용 사례를 제거하는 것과 같다면 이는 솔루션이 아니며 실제로 해당 언어 사용자에게 해로운 것입니다.

함수는 C에서도 비용이 0이 아닙니다. 누군가 gotos 및 레이블에 대한 대체품을 제공한다면 canihaz 부탁합니다! 누군가가 나에게 필요하지 않다고 말하면 어떻게 알 수 있습니까? 성능과 관련하여 goto 는 언어의 여명기부터 존재했던 성능이 뛰어나고 사용하기 쉬운 기능이 필요하지 않다고 엔지니어에게 주장하기 어려운 약간의 추가 기능을 제공할 수 있습니다.

goto 를 지원할 계획이 없다면 WASM은 장난감 컴파일 대상이고 괜찮습니다. W3C가 웹을 보는 방식일 수도 있습니다. WASM이 32비트 주소 공간을 넘어 더 높이 올라가 컴파일 경쟁에 뛰어들기를 바랍니다. 엔지니어링 담론이 "불가능..."에서 벗어나 WASM이 굉장해야 하기 때문에 Labels as Values 와 같은 GCC C 확장을 빠르게 추적할 수 있기를 바랍니다. 개인적으로 TCC는 힙스터 랜딩 페이지와 반짝이는 로고가 없는 이 시점에서 훨씬 더 인상적이고 유용합니다.

@d4tocchini :

SEI CERT C Coding Standard Rec. "리소스를 사용하고 해제할 때 오류에 함수를 남길 때 goto 체인 사용을 고려하십시오" ;

많은 기능을 사용하려면 여러 리소스를 할당해야 합니다. 할당된 모든 리소스를 해제하지 않고 이 함수의 중간 어딘가에서 실패하고 반환하면 메모리 누수가 발생할 수 있습니다. 이런 방식으로 리소스 중 하나(또는 전체)를 해제하는 것을 잊는 것은 일반적인 오류이므로 goto 체인은 해제된 리소스의 순서를 유지하면서 종료를 구성하는 가장 간단하고 깔끔한 방법입니다.

그런 다음 권장 사항은 goto 사용하는 선호하는 POSIX C 솔루션의 예를 제공합니다. 반대론자들은 goto 가 여전히 해로운 것으로 간주 된다는 점을 지적할

해당 권장 사항에 제공된 예제는 Wasm에서 사용할 수 있는 레이블이 지정된 중단으로 직접 표현할 수 있습니다. 임의 goto의 추가 기능이 필요하지 않습니다. (C는 레이블이 붙은 break and continue를 제공하지 않으므로 필요한 것보다 더 자주 goto로 폴백해야 합니다.)

@rossberg , 해당 예에서 레이블이 지정된 중단에 대한 좋은 점이지만 C가 "폴백"해야 한다는 질적 가정에 동의하지 않습니다. goto는 레이블이 지정된 중단보다 더 풍부한 구성입니다. C가 이식 가능한 컴파일 대상에 포함되어야 하고 C가 레이블이 지정된 중단을 지원하지 않는다면 이는 오히려 음소거 지점입니다. Java는 break/continues라는 레이블을 지정했지만 Python 은 제안된 기능을 거부했으며 Sun JVM과 기본 CPython이 모두 C로 작성되었음을 고려할 때 지원되는 언어로 C가 우선 순위 목록에서 더 높아야 한다는 데 동의하지 않습니까?

goto 가 고려 대상에서 쉽게 제외 된다면 emscripten의 소스 내 에서

C로 쓸 수 없는 언어가 있나요? 언어로서의 C는 WASM의 기능을 알려야 합니다. 오늘날의 WASM으로는 POSIX C가 불가능하다면 적절한 로드맵이 있습니다.

논쟁의 주제에 관한 것은 아니지만 일반적으로 논쟁의 여기저기에 도사리고 있는 무작위적인 실수를 숨기지 않기 위해:

Python에는 레이블이 지정된 휴식 시간이 있습니다.

자세히 알려주실 수 있나요? (일명: Python에는 레이블이 지정된 중단이 없습니다.)

@pfalcon , 예, 내 잘못입니다. Python이 레이블이 지정된 중단/계속을 제안하고 거부했습니다.

goto가 고려 대상에서 쉽게 제외된다면 emscripten의 소스 내에서 수백 가지의 goto 사용도 재고해야 합니까?

1) 그 중 얼마나 많은 것이 emscripten에 직접 존재하지 않고 musl libc에 존재하는지 주목하십시오. (두 번째로 많이 사용되는 것은 tests/third_party입니다)
2) 소스 레벨 구성은 바이트코드 명령어와 동일하지 않습니다.
3) Emscripten은 wasm 표준과 같은 추상화 수준이 아니므로 이를 기준으로 재고하지 않아야 합니다.

특히, 오늘날 libc에서 gotos를 다시 작성하는 것이 유용할 수 있습니다. 그러면 결과 cfg를 잘 처리하기 위해 relooper/cfgstackify를 신뢰하는 것보다 결과 cfg를 더 많이 제어할 수 있기 때문입니다. 업스트림 musl에서 엄청나게 다양한 코드로 마무리하는 것은 사소하지 않은 양의 작업이기 때문에 그렇지 않습니다.

Emscripten 개발자(내가 마지막으로 확인함)는 goto와 같은 구조가 정말 좋을 것이라고 생각하는 경향이 있습니다. 이러한 명백한 이유 때문에 수용 가능한 타협에 도달하는 데 몇 년이 걸리더라도 고려 대상에서 제외하지 않을 것입니다.

<marquee> 를 승인한 표준화 기구의 입장은 창백하지 않습니다.

이것은 특히 asinine 진술입니다.

1) 더 광범위한 인터넷은 그러한 결정을 내리기까지 10년 이상 남았습니다.
2) We-the-wasm-CG는 해당 태그와 완전히(거의?) 별개의 사람들 그룹이며, 명백한 과거 실수로 인해 개별적으로도 짜증이 날 것입니다.

힙스터 랜딩 페이지와 반짝이는 로고도 낭비하지 않고요.

이것은 톤 문제가 발생하지 않고 "나는 좌절합니다"로 다시 말했을 수 있습니다.

이 스레드에서 알 수 있듯이 이러한 대화는 그 자체로 충분히 어렵습니다.

사용 환경이 지원을 위해 추가 단계를 거쳐야 하기 때문에 완전히 새로운 기능에 대해 깊이 신뢰하고 이해하는 기능 집합을 다시 작성하려는 경우에 대해 깊이 우려하는 새로운 수준이 있습니다. (하나의 특정 컴파일러만 사용하는 것에 얽매이는 것을 싫어하기 때문에 나는 여전히 확고한 please-add-goto 캠프에 있지만)

제 생각에는 이 쓰레드가 생산적이지 못한 방향으로 나아갔다고 생각합니다. 이 쓰레드는 4년 넘게 실행되어 왔으며 임의의 goto 에 대한 모든 가능한 주장이 여기에 사용된 것 같습니다. 또한 이러한 주장 중 어느 것도 특별히 새로운 것은 아니라는 점에 유의해야 합니다. ;)

임의의 점프 레이블을 사용하지 않도록 선택한 관리되는 런타임이 있습니다. 또한 임의 점프가 허용되는 프로그래밍 시스템이 있으며 잘 수행되고 있습니다. 결국, 프로그래밍 시스템의 작성자는 디자인 선택을 하고 그 선택이 성공적인지 아닌지는 오직 시간만이 실제로 보여줍니다.

임의의 점프를 금지하는 Wasm 디자인 선택은 철학의 핵심입니다. 순수한 간접 점프를 지원하지 않는 것과 같은 이유로 funclet과 같은 것이 없이 goto 지원할 수 있을 것 같지 않습니다.

임의의 점프를 금지하는 Wasm 디자인 선택은 철학의 핵심입니다. 순수한 간접 점프를 지원하지 않는 것과 같은 이유로 funclet과 같은 것이 없이 goto를 지원할 수 있을 것 같지 않습니다.

@penzn funclets 제안 이 왜 멈췄습니까? 2018년 10월부터 존재하며 아직 0단계에 있습니다.

우리가 평범한 오픈 소스 프로젝트에 대해 논의하고 있었다면 포크하고 끝냈을 것입니다. 여기서 우리는 광범위한 독점 표준에 대해 이야기하고 있습니다. 우리가 관심을 갖고 있기 때문에 활발한 커뮤니티 반응이 배양되어야 합니다.

@J0eCool

1. 그 중 얼마나 많은 것이 emscripten에 직접 존재하지 않고 musl libc에 존재하는지 주목하십시오. (두 번째로 많이 사용되는 것은 tests/third_party입니다)

예, 일반적으로 C에서 얼마나 많이 사용되는지에 대한 고개를 끄덕였습니다.

1. 소스 수준 구성은 바이트 코드 명령어와 동일하지 않습니다.

물론, 우리가 논의하고 있는 것은 소스 수준 구성에 영향을 미치는 내부 문제입니다. 그것이 좌절의 일부이며, 블랙박스는 그 우려를 누설해서는 안됩니다.

1. Emscripten은 wasm 표준과 같은 추상화 수준이 아니므로 이를 기반으로 재고해서는 안 됩니다.

요점은 WebAssembly 도구 체인 내에서도 대부분의 상당한 C 프로젝트에서 goto 찾을 수 있다는 것입니다. 자체 컴파일러를 대상으로 하기에 충분히 표현력이 없는 일반적으로 언어에 대한 이식 가능한 컴파일러 대상은 우리 기업의 특성과 정확히 일치하지 않습니다.

특히, 오늘날 libc에서 gotos를 다시 작성하는 것이 유용할 수 있습니다. 그러면 결과 cfg를 잘 처리하기 위해 relooper/cfgstackify를 신뢰하는 것보다 결과 cfg를 더 많이 제어할 수 있기 때문입니다.

이것은 원형입니다. 위의 많은 사람들이 그러한 요구 사항의 무오성에 대해 답이 없는 심각한 질문을 제기했습니다.

업스트림 musl에서 엄청나게 다양한 코드로 마무리하는 것은 사소하지 않은 양의 작업이기 때문에 그렇지 않습니다.

당신이 말했듯이 gotos를 제거하는 것이 가능합니다. 그것은 사소한 일이

Emscripten 개발자(내가 마지막으로 확인함)는 goto와 같은 구조가 정말 좋을 것이라고 생각하는 경향이 있습니다. 이러한 명백한 이유 때문에 수용 가능한 타협에 도달하는 데 몇 년이 걸리더라도 고려 대상에서 제외하지 않을 것입니다.

한 줄기 희망! 몇 년이 지났더라도 goto/label 지원이 로드맵 항목 + 공을 움직이게 하는 공식 초청으로 진지하게 받아들여진다면 만족할 것입니다.

이것은 특히 asinine 진술입니다.

네가 옳아. 과장된 표현을 용서하십시오. 저는 약간 실망스럽습니다. 나는 was를 좋아하고 자주 사용하지만 포트 TCC와 같이 주목할만한 것을하고 싶다면 궁극적으로 내 앞에 고통의 길이 보입니다. 모든 댓글과 기사를 읽은 후에도 반대가 기술적인지, 철학적인지, 정치적인 것인지 알 수 없습니다. @neelance가 표현했듯이,

“V8 담당자가 이 스레드에서 환원 불가능한 제어 흐름에 대한 반대가 V8의 현재 구현에 영향을 받지 않는다는 것을 확인할 수 있습니까?

이것이 가장 나를 괴롭히는 것이기 때문에 나는 묻는다. [...]

사용 중이시라면 Go 1.11에 대한 @neelance의 피드백을 마음에 새기십시오. 그것은 논쟁하기 어렵습니다. 물론, 우리는 모두 goto의 사소한 더스팅을 수행할 수 있지만, 그럼에도 불구하고 goto 명령으로만 고칠 수 있는 심각한 성능 적중을 받습니다.

다시 한 번 제 좌절감을 용서해 주십시오. 하지만 이 문제가 적절한 주소 없이 종료된다면 이러한 종류의 커뮤니티 응답을 화나게 할 뿐 아니라 우리의 가장 큰 표준 노력 중 하나에 적합하지 않은 잘못된 종류의 신호를 보낼 것입니다. 들. 내가 이 팀의 모든 이들의 열렬한 팬이자 지지자라는 것은 말할 필요도 없습니다. 감사합니다!

다음은 goto/funclets 누락으로 인해 발생하는 또 다른 실제 문제입니다. https://github.com/golang/go/issues/42979

이 프로그램의 경우 Go 컴파일러는 현재 18,000개의 중첩된 block 있는 wasm 바이너리를 생성합니다. wasm 바이너리 자체의 크기는 2.7MB이지만 wasm2wat 통해 실행하면 4.7GB .wat 파일이 생성됩니다. 🤯

Go 컴파일러에 약간의 경험적 방법을 제공하여 하나의 거대한 점프 테이블 대신 일종의 이진 트리를 만든 다음 점프 대상 변수를 여러 번 볼 수 있도록 할 수 있습니다. 그러나 이것이 정말로 wasm과 함께 있어야 하는 방식입니까?

단일 컴파일러(Emscripten[1])만 WebAssembly를 현실적으로 지원할 수 있다면 사람들이 완벽하게 괜찮다고 생각하는 것이 이상하다는 점을 덧붙이고 싶습니다.
libopus 상황(저작권이 있는 코드에 규범적으로 의존하는 표준)이 생각납니다.

나는 또한 WebAssembly 개발자가 이것에 대해 그렇게 격렬하게 반대하는 것처럼 보이는 것이 이상하다고 생각합니다. 컴파일러 쪽의 거의 모든 사람들이 이것이 필요하다고 말하고 있음에도 불구하고. 기억하십시오: WebAssembly는 선언문이 아니라 표준입니다. 그리고 사실, 대부분의 최신 컴파일러는 명시적 루프[2]의 개념이 없는 일부 형태의 SSA + 기본 블록을 내부적으로(또는 동일한 속성을 가진 거의 동등한 것) 사용합니다. JIT조차도 비슷한 것을 사용하므로 일반적입니다.
"그냥 goto 사용"이라는 탈출구 없이 재루핑이 발생하기 위한 절대적인 요구 사항은 내가 아는 한[3] 언어 대 언어 번역가 외에는 전례가 없는 일입니다. goto가 없는 언어를 대상으로 합니다. 특히 WebAssembly 이외의 모든 종류의 IR 또는 바이트 코드에 대해 이 작업을 수행해야 한다는 이야기를 들어본 적이 없습니다.

아마도 WebAssembly의 이름을 WebEmscripten(WebScripten?)으로 변경할 때일 것입니다.

@d4tocchini가 말했듯이 WebAssembly의 (표준화 상황으로 인해 필요한) 독점 상태가 아니었다면 지금쯤이면 컴파일러 개발자가 지원해야 한다고 이미 알고 있는 것을 합리적으로 지원할 수 있는 것으로 분기되었을 것입니다.
그리고 아니오, "그냥 emscripten 사용"은 표준을 단일 컴파일러 공급업체에 의존하게 만들기 때문에 유효한 반론이 아닙니다. 그게 왜 나쁜지 말할 필요가 없기를 바랍니다.

편집: 한 가지를 추가하는 것을 잊었습니다.
문제가 기술적인지, 철학적인지, 정치적인 것인지 아직 명확히 하지 않았습니다. 나는 후자를 의심하지만 기꺼이 틀린 것으로 판명될 것입니다(기술적, 철학적 문제는 정치적인 문제보다 훨씬 쉽게 고칠 수 있기 때문입니다).

goto/funclets 누락으로 인해 발생하는 또 다른 실제 문제는 다음과 같습니다. golang/go#42979

이 프로그램의 경우 Go 컴파일러는 현재 18,000개의 중첩된 block 있는 wasm 바이너리를 생성합니다. wasm 바이너리 자체의 크기는 2.7MB이지만 wasm2wat 통해 실행하면 4.7GB .wat 파일이 생성됩니다. 🤯

Go 컴파일러에 약간의 경험적 방법을 제공하여 하나의 거대한 점프 테이블 대신 일종의 이진 트리를 만든 다음 점프 대상 변수를 여러 번 볼 수 있도록 할 수 있습니다. 그러나 이것이 정말로 wasm과 함께 있어야 하는 방식입니까?

이 예는 정말 흥미롭습니다. 그러한 간단한 직선 프로그램이 어떻게 이 코드를 생성합니까? 배열 요소의 수와 블록의 수 사이의 관계는 무엇입니까? 특히, 이것을 각 배열 요소 액세스에 _multiple_ 블록이 충실하게 컴파일되어야 한다는 의미로 해석해야 합니까?

그리고 아니요, "그냥 emscripten을 사용하십시오"는 유효한 반론이 아닙니다.

이 맥락에서 실제 반론은 Wasm을 대상으로 하려는 다른 컴파일러가 자체 relooper와 같은 알고리즘을 구현할 수/반드시 구현해야 한다는 것입니다. 개인적으로, 나는 Wasm이 결국 goto 대한 자연스러운 목표인 multi-body loop (Funclet에 가깝다) 또는 이와 유사한 것을 가져야 한다고 생각합니다.

@conrad-watt 각 할당이 CFG의 여러 기본 블록을 사용하도록 하는 몇 가지 요인이 있습니다. 그 중 하나는 컴파일 시간에 길이를 알 수 없기 때문에 슬라이스에 길이 검사가 있다는 것입니다. 일반적으로 컴파일러는 기본 블록을 비교적 저렴한 구성으로 간주하지만 wasm을 사용하면 특히 이 특정 경우에 다소 비용이 많이 듭니다.

코드가 여러 기능으로 분할된 수정된 예제의 @neelance 에서 (런타임/컴파일) 메모리 오버헤드가 훨씬 낮은 것으로 표시됩니다. 이 경우 더 적은 수의 블록이 생성됩니까? 아니면 별도의 기능으로 인해 엔진 GC가 더 세분화될 수 있다는 의미입니까?

@conrad-watt 메모리를 사용하는 것은 Go 코드도 아니고 WebAssembly 호스트입니다. Chrome 86으로 wasm 바이너리를 인스턴스화하면 CPU가 2분 동안 100%가 되고 탭의 메모리 사용량이 최고점에 도달합니다. 11.3GB. 이것은 wasm 바이너리 / Go 코드가 실행 되기 전 입니다. 문제를 일으키는 것은 wass 바이너리의 모양입니다.

그것은 이미 나의 이해였다. 많은 수의 블록/유형 주석으로 인해 특히 컴파일/인스턴스화 중에 메모리 오버헤드가 발생할 것으로 예상합니다.

이전 질문을 명확하게 하기 위해 - 코드의 분할 버전이 더 적은 수의 블록으로 Wasm으로 컴파일되면(일부 리루퍼 특성으로 인해) 메모리 오버헤드 감소에 대한 한 가지 설명이 될 것이며 더 일반적인 추가를 위한 좋은 동기가 될 것입니다. Wasm으로의 흐름을 제어합니다.

또는 분할 코드가 (대략) 동일한 총 블록 수를 생성할 수 있지만 각 기능이 별도로 JIT 컴파일되기 때문에 각 기능을 컴파일하는 데 사용되는 메타데이터/IR은 Wasm 엔진에 의해 더 열성적으로 GC 처리될 수 있습니다. . 큰 asm.js 함수를 구문 분석/컴파일할 때 비슷한 문제가 V8년 전에 발생했습니다. 이 경우 Wasm에 보다 일반적인 제어 흐름을 도입해도 문제가 해결되지 않습니다.

먼저 Go 컴파일러는 relooper 알고리즘을 사용하지 않습니다. 왜냐하면 그것은 본질적으로 고루틴 전환의 개념과 호환되지 않기 때문입니다. 모든 기본 블록은 가능한 경우 약간의 폴스루가 있는 점프 테이블을 통해 표현됩니다.

중첩된 block 의 깊이와 관련하여 Chrome의 wasm 런타임에 기하급수적인 복잡성 증가가 있다고 생각합니다. 분할 버전은 블록 수는 같지만 최대 깊이는 더 작습니다.

이 경우 Wasm에 보다 일반적인 제어 흐름을 도입해도 문제가 해결되지 않습니다.

나는 이 복잡성 문제가 아마도 Chrome의 끝에서 해결될 수 있다는 데 동의합니다. 하지만 저는 항상 "왜 이 문제가 처음에 존재했을까?"라는 질문을 하고 싶습니다. 보다 일반적인 제어 흐름이 있었다면 이 문제가 존재하지 않았을 것이라고 주장합니다. 또한 모든 기본 블록이 점프 테이블로 표현되기 때문에 여전히 상당한 일반 성능 오버헤드가 있는데, 이는 최적화로 사라질 것 같지 않습니다.

중첩 블록의 깊이와 관련하여 Chrome의 wasm 런타임에 기하급수적으로 복잡성이 증가하는 것 같습니다. 분할 버전은 블록 수는 같지만 최대 깊이는 더 작습니다.

이것은 N 배열 액세스가 있는 직선 함수에서 최종 배열 액세스가 N 블록 깊이 중첩(일부 상수 요소)된다는 것을 의미합니까? 그렇다면 오류 처리 코드를 다르게 인수분해하여 이를 줄일 수 있는 방법이 있습니까? 컴파일러가 3000개의 중첩 루프를 분석해야 하는 경우(매우 대략적인 유추) 예상할 수 있으므로 의미론적 이유로 피할 수 없는 경우 이는 보다 일반적인 제어 흐름에 대한 인수이기도 합니다.

중첩 차이가 그보다 덜 극명하다면 V8은 단일 Wasm 함수를 컴파일하는 동안 메타데이터의 GC를 거의 수행하지 않으므로 처음부터 언어에서 약간의 funclets 제안과 같은 것을 가지고 있더라도 , 흥미로운 GC 최적화를 수행하지 않고도 동일한 오버헤드가 계속 표시됩니다.

또한 모든 기본 블록이 점프 테이블로 표현되기 때문에 여전히 상당한 일반 성능 오버헤드가 있는데, 이는 최적화로 사라질 것 같지 않습니다.

여기에 더 자연스러운 대상을 갖는 것이 (순전히 기술적인 관점에서) 분명히 바람직하다는 데 동의합니다.

이것은 N 배열 액세스가 있는 직선 함수에서 최종 배열 액세스가 N 블록 깊이 중첩(일부 상수 요소)된다는 것을 의미합니까? 그렇다면 오류 처리 코드를 다르게 인수분해하여 이를 줄일 수 있는 방법이 있습니까? 컴파일러가 3000개의 중첩 루프를 분석해야 하는 경우(매우 대략적인 유추) 예상할 수 있으므로 의미론적 이유로 피할 수 없는 경우 이는 보다 일반적인 제어 흐름에 대한 인수이기도 합니다.

다른 방법으로: 첫 번째 할당은 마지막이 아닌 깊이 중첩됩니다. 중첩된 block 와 상단의 단일 br_table 는 전통적인 switch 문이 wasm으로 표현되는 방식입니다. 이것은 내가 언급한 점프 테이블입니다. 3000개의 중첩 루프가 없습니다.

내포 차이가 그것보다 덜 극명하다면, 내 직감은 V8이 단일 Wasm 함수를 컴파일하는 동안 메타데이터의 GC를 거의 수행하지 않는다는 것입니다. , 흥미로운 GC 최적화를 수행하지 않고도 동일한 오버헤드가 계속 표시됩니다.

예, 기본 블록의 수와 관련하여 기하급수적으로 복잡한 구현이 있을 수도 있습니다. 그러나 많은 양의 컴파일러가 하루 종일 하는 일은 기본 블록을 처리하는 것입니다. 예를 들어 Go 컴파일러 자체는 여러 최적화 단계에 의해 처리되더라도 컴파일하는 동안 이 수의 기본 블록을 쉽게 처리합니다.

예, 기본 블록의 수와 관련하여 기하급수적으로 복잡한 구현이 있을 수도 있습니다. 그러나 많은 양의 컴파일러가 하루 종일 하는 일은 기본 블록을 처리하는 것입니다. 예를 들어 Go 컴파일러 자체는 여러 최적화 단계에 의해 처리되더라도 컴파일하는 동안 이 수의 기본 블록을 쉽게 처리합니다.

물론, 하지만 여기서 성능 문제는 이러한 기본 블록 간의 제어 흐름이 원래 소스 언어로 표현되는 방식과 직교합니다(즉, Wasm에서 보다 일반적인 제어 흐름에 대한 동기가 아님). 여기서 V8이 특히 나쁜지 확인하려면 FireFox/SpiderMonkey 또는 Lucet/Cranelift가 동일한 컴파일 오버헤드를 나타내는지 확인할 수 있습니다.

몇 가지 테스트를 더 했습니다. Firefox와 Safari는 전혀 문제가 없습니다. 흥미롭게도 Chrome은 집중 프로세스가 완료되기 전에 코드를 실행할 수도 있으므로 wasm 바이너리를 실행하는 데 꼭 필요하지 않은 일부 작업에 복잡성 문제가 있는 것 같습니다.

물론, 하지만 여기서 성능 문제는 기본 블록 간의 제어 흐름이 원래 소스 언어로 표현되는 방식과 직교합니다.

너의 의도를 알 겠어.

나는 여전히 점프 명령어가 아닌 점프 변수와 거대한 점프 테이블/중첩 블록을 통해 기본 블록을 표현하는 것이 기본 블록의 단순한 개념을 상당히 복잡한 방식으로 표현한다고 믿습니다. 이것은 성능 오버헤드와 여기에서 본 것과 같은 복잡성 문제의 위험으로 이어집니다. 나는 단순한 시스템이 복잡한 시스템보다 더 훌륭하고 강력하다고 믿습니다. 나는 더 단순한 시스템이 나쁜 선택이라는 것을 확신시키는 주장을 아직 보지 못했다. 나는 V8이 임의의 제어 흐름을 구현하는 데 어려움을 겪을 것이라고 들었고 이 진술이 틀렸음을 알려주는 공개 질문(https://github.com/WebAssembly/design/issues/796#issuecomment-623431527)이 없습니다. 아직 답변이 되었습니다.

@neelance

Chrome은 집중 프로세스가 완료되기 전에 코드를 실행할 수도 있습니다.

베이스라인 컴파일러 Liftoff가 괜찮은 것처럼 들리고 문제는 최적화 컴파일러 TurboFan에 있습니다. 문제를 제출하거나 테스트 케이스를 제공하면 원하는 경우 하나를 제출할 수 있습니다.

더 일반적으로: was stack 스위칭 계획이 Go의 고루틴 구현 문제를 해결할 수 있다고 생각하십니까? 이것이 내가 찾을 수 있는 최고의 링크이지만 격주 모임과 작업에 동기를 부여하는 몇 가지 강력한 사용 사례로 인해 현재 매우 활성화되어 있습니다. Go가 큰 스위치 패턴을 피하기 위해 wasm 코루틴을 사용할 수 있다면 임의의 goto가 필요하지 않을 것이라고 생각합니다.

Go 컴파일러는 본질적으로 고루틴 전환 개념과 호환되지 않기 때문에 리루퍼 알고리즘을 사용하지 않습니다.

자체적으로 적용할 수 없는 것이 사실입니다. 그러나 우리는 구조화된 제어 흐름 + Asyncify 를 사용하여 좋은 결과를

관심이 있으시면 Go에서 실험해 보겠습니다. 이것은 분명히 wasm의 내장 스택 스위칭 지원만큼 좋지는 않지만 이미 큰 스위치 패턴보다 나을 수 있습니다. 그리고 나중에 내장 스택 스위칭 지원으로 전환하는 것이 더 쉬울 것입니다. 구체적으로, 이 실험이 작동하는 방법은 스택 전환에 대해 전혀 걱정하지 않고 Go가 정상적으로 구조화된 코드를 내보내도록 하고 적절한 지점에서 특별한 maybe_switch_goroutine 함수에 대한 호출을 내보내는 것입니다. Asyncify 변환은 기본적으로 나머지 모든 것을 처리합니다.

저는 qemu와 같은 동적 재컴파일 에뮬레이터를 위한 gotos에 관심이 있습니다. 다른 컴파일러와 달리 qemu는 프로그램 제어 흐름 구조에 대한 지식이 없으므로 goto가 유일한 합리적인 대상입니다. Tailcall은 각 블록을 함수로 컴파일하고 각 goto를 tailcall로 컴파일하여 이 문제를 해결할 수 있습니다.

@kripken 매우 유용한 게시물에 감사드립니다.

베이스라인 컴파일러 Liftoff가 괜찮은 것처럼 들리고 문제는 최적화 컴파일러 TurboFan에 있습니다. 문제를 제출하거나 테스트 케이스를 제공하면 원하는 경우 하나를 제출할 수 있습니다.

여기의 wasm 바이너리 당신이 실행할 수 wasm_exec.html은 .

wasm 스택 전환 계획이 Go의 고루틴 구현 문제를 해결할 수 있다고 생각하십니까?

네, 언뜻 보기에 도움이 될 것 같습니다.

그러나 우리는 구조화된 제어 흐름 + Asyncify를 사용하여 좋은 결과를 얻었습니다.

이것도 유망해 보입니다. Go에서 relooper를 구현해야 하지만 괜찮습니다. 한 가지 작은 단점은 wasm 바이너리를 생성하기 위해 바이너리에 종속성을 추가한다는 것입니다. 아마 곧 제안서를 작성할 것입니다.

LLVM의 stackifier 알고리즘이 더 쉽고 더 낫다고 생각합니다. 이를 구현하려는 경우: https://medium.com/leaningtech/solve-the-structured-control-flow-problem-once-and-for-all-5123117b1ee2

Go 프로젝트에 대한 제안서를 제출했습니다: https://github.com/golang/go/issues/43033

@neelance , @kripken 의 제안이 golang + wasm에 약간 도움이 되는 것을 보니 반갑습니다. 이 문제가 스택 전환이 아닌 goto/labels 중 하나라고 생각하고 Asyncify가 스택 전환이 릴리스될 때까지 Asyncify를 사용하여 새로운 deps/특수 케이스 빌드를 도입한다는 점을 감안할 때 이 문제를 솔루션으로 특성화하시겠습니까 아니면 최적 완화 미만으로 특성화하시겠습니까? goto 지침을 사용할 수 있는 경우 예상 이점과 비교하면 어떻습니까?

연결 목록에 대한 Linus Torvalds의 "Good Taste" 주장이 유일한 특별한 경우의 분기 문을 제거하는 우아함에 근거한다면 이러한 종류의 특별한 경우의 체조를 승리로 보거나 올바른 방향으로 나아가는 단계라고 보기 어렵습니다. 개인적으로 C에서 비동기식 API에 goto를 사용하여 goto 명령이 모든 종류의 냄새를 유발하기 전에 스택 전환에 대해 이야기했습니다.

내가 잘못 읽고 있다면 정정해 주십시오. 그러나 제기된 몇 가지 질문에 대한 미미한 특수성에 초점을 맞춘 임시방편처럼 보이는 응답을 제외하고 여기 유지 관리자는 당면한 문제에 대해 명확성을 제공하지 않았으며 어려운 질문에 답변하지도 않은 것 같습니다. 모든 정당한 존경과 함께, 이 느린 골화는 굳은살이 기업 정치의 특징이 아닙니까? 이 경우라면 그 상황을 이해합니다... ANSI C만 호환 리트머스 테스트였다면 Wasm의 브랜드가 지원을 자랑할 수 있었던 모든 언어/컴파일러를 상상해 보십시오!

@neelance @darkuranium @d4tocchini 모든 Wasm 기고자들이 goto의 부족이 옳은 것이라고 생각하는 것은 아닙니다. 사실 저는 개인적으로 그것을 Wasm의 #1 디자인 실수로 평가하고 싶습니다. 나는 그것을 추가하는 것에 절대적으로 찬성합니다(펀클릿으로 또는 직접적으로).

그러나 이 스레드에 대해 토론한다고 해서 goto가 발생하지도 않고, Wasm에 관련된 모든 사람이 마술처럼 확신을 갖고 작업을 수행하지도 않을 것입니다. 취해야 할 단계는 다음과 같습니다.

1. Wasm CG에 가입하세요.
2. 누군가 goto 제안의 챔피언이 되기 위해 시간을 투자합니다. 이미 @sunfishcode에 의해 잘 생각하고있다으로 나는, 기존 funclets 제안에서 시작하는 것이 좋습니다로는 원시보다 성공할 확률이 더 높다 있도록 블록 구조에 의존하는 현재의 엔진 및 도구에 "적어도 방해"가 이동.
3. 4가지 제안 단계를 거치도록 도와주세요. 여기에는 단계를 통과할 때 과반수 표를 얻을 수 있도록 충분한 사람들을 기쁘게 하는 것을 목표로 하는 모든 반대 의견에 대해 좋은 디자인을 만들고 토론을 시작하는 것이 포함됩니다.

@d4tocchini 솔직히 말해서, 저는 현재 제안된 솔루션을 "변경할 수 없는 상황에서 가장 좋은 방법" 즉 "해결 방법"으로 보고 있습니다. 나는 여전히 jump/goto 명령어(또는 funclets)를 더 간단한 방법으로 생각하고 따라서 더 선호합니다. (여전히 대안을 제안해 준 @kripken 에게 감사드립니다.)

@aardappel 내가 아는 한, @sunfishcode 는 funclet 제안을 푸시하려고 했지만 실패했습니다. 왜 나와 다를까요?

@neelance 저는 @sunfishcode 가 제안을 초기 생성 이상으로 밀어붙일 시간이 많지 않았기 때문에 "실패"가 아니라 "중단" 상태라고 생각합니다. 제가 말하려고 했던 것처럼, 제안이 파이프라인을 통해 끝까지 전달되려면 챔피언이 지속적인 작업을 해야 합니다.

@neelance

테스트 케이스 주셔서 감사합니다! 동일한 문제를 현지에서 확인할 수 있습니다. https://bugs.chromium.org/p/v8/issues/detail?id=11237을 제출했습니다.

Go에서 리루퍼를 구현해야 합니다. [..] 한 가지 작은 단점은 wasm 바이너리를 생성하기 위해 바이너리에 종속성을 추가한다는 것입니다.

Btw, 도움이 된다면 이진 라이브러리 빌드를 단일 C 파일로 만들 수 있습니다. 통합이 더 쉬울까요?

또한 Binaryen을 사용하면 거기에 있는 Relooper 구현

@taralx

LLVM의 stackifier 알고리즘이 더 쉽고 더 낫다고 생각합니다.

링크는 업스트림 LLVM에 관한 것이 아니라 Cheerp 컴파일러(LLVM의 포크)에 관한 것입니다. Stackifier는 LLVM과 이름이 비슷하지만 다릅니다.

또한 Cheerp 게시물은 2011년의 원래 알고리즘을 참조합니다. 최신 relooper 구현 (앞서 언급한 대로)에는 수년 동안 언급한 문제가 없었습니다. Cheerp와 다른 사람들이 하는 것과 매우 유사한 일반적인 접근 방식에 대한 더 간단하거나 더 나은 대안을 알지 못합니다. 이는 테마의 변형입니다.

@kripken 문제를

Btw, 도움이 된다면 이진 라이브러리 빌드를 단일 C 파일로 만들 수 있습니다. 통합이 더 쉬울까요?

할 것 같지 않은. Go 컴파일러 자체는 얼마 전에 순수 Go로 변환되었으며 다른 C 종속성을 사용하지 않습니다. 나는 이것이 예외가 될 것이라고 생각하지 않는다.

funclet 제안의 현재 상태는 다음과 같습니다. 프로세스 의 다음 단계는 1단계에 진입하기 위해 CG 투표를 요청하는 것입니다.

나 자신은 현재 WebAssembly의 다른 영역에 집중하고 있으며 funclet을 앞으로 푸시할 대역폭이 없습니다. 누군가가 funclet의 챔피언 역할을 인수하는 데 관심이 있다면 기꺼이 넘겨드리겠습니다.

할 것 같지 않은. Go 컴파일러 자체는 얼마 전에 순수 Go로 변환되었으며 다른 C 종속성을 사용하지 않습니다. 나는 이것이 예외가 될 것이라고 생각하지 않는다.

게다가 이것은 WebAssembly 런타임에서 심각한 성능 절벽을 일으키는 relooper의 광범위한 사용 문제를 해결하지 못합니다.

@부리히

나는 그것이 wasm에 gotos를 추가하는 가장 좋은 경우일 수 있다고 생각하지만 누군가는 심각한 성능 절벽을 보여주는 실제 코드에서 매력적인 데이터를 수집해야 할 것입니다. 나는 그런 데이터를 직접 본 적이 없다. "Not So Fast: Analyzing Performance of WebAssembly vs. Native Code"(2019) 와 같은 wasm perf 적자를 분석하는 작업은 중요한 요소인 제어 흐름도 지원하지 않습니다(더 많은 양의 분기 명령을 기록하지만 그렇지 않습니다. 구조화된 제어 흐름으로 인해 - 오히려 안전 점검 때문입니다).

@kripken 그러한 데이터를 수집할 수 있는 방법에 대한 제안 사항이 있습니까? 성능 부족이 구조화된 제어 흐름으로 인한 것임을 어떻게 나타낼 수 있습니까?

여기에 불만의 일부인 컴파일 단계의 성능을 분석하는 작업이 많지 않을 것입니다.

나는 우리가 아직 switch case 구조를 가지고 있지 않다는 것에 다소 놀랐지만 funclet은 그것을 포함합니다.

@neelance

구체적인 원인을 파악하기가 쉽지 않죠. 예를 들어 경계 검사의 경우 VM에서 비활성화하고 측정할 수 있지만 슬프게도 goto에 대해 동일한 작업을 수행하는 간단한 방법은 없습니다.

한 가지 옵션은 방출된 기계어 코드를 손으로 비교하는 것인데, 이는 링크된 문서에서 수행한 작업입니다.

또 다른 옵션은 제어 흐름을 최적으로 처리할 수 있다고 믿는 것으로 wasm을 컴파일하는 것입니다. 즉, 구조화를 "실행 취소"합니다. LLVM은 그렇게 할 수 있어야 하므로 LLVM(WAVM 또는 wasmer와 같은)을 사용하는 VM에서 또는 WasmBoxC를 통해 wasm을 실행하는 것이 흥미로울 수 있습니다. LLVM에서 CFG 최적화를 비활성화하고 이것이 얼마나 중요한지 확인할 수 있습니다.

@taralx

흥미롭네요. 컴파일 시간이나 메모리 사용량에 대해 놓친 부분이 있습니까? 구조화된 제어 흐름은 실제로 거기에서 더 좋아야 합니다. 예를 들어 일반 CFG에서와 비교할 때 SSA 형식으로 이동하는 것이 매우 간단합니다. 이것은 사실 처음부터 구조화된 제어 흐름을 사용했던 이유 중 하나였습니다. 또한 웹에서 로드 시간에 영향을 미치기 때문에 매우 신중하게 측정됩니다.

(또는 개발자의 컴퓨터에서 컴파일러 성능을 의미합니까? wasm이 클라이언트에서 더 많은 작업을 수행하고 더 적은 작업을 수행하는 방향으로 기울어지는 것이 사실입니다.)

나는 임베더에서 컴파일 성능을 의미했지만 그것이 반드시 순수한 성능 문제가 아닌 버그 로 취급되는 것 같습니다.

@taralx

예, 버그라고 생각합니다. 한 VM의 한 계층에서만 발생합니다. 그리고 그것에 대한 근본적인 이유는 없습니다. 구조화된 제어 흐름은 더 많은 리소스를 필요로 하지 않으며 더 적은 리소스를 필요로 합니다. 즉, was에 goto가 있는 경우 이러한 성능 버그가 발생할 가능성이 더 높을 것입니다.

@kripken

구조화된 제어 흐름은 실제로 거기에서 더 좋아야 합니다. 예를 들어 일반 CFG에서와 비교할 때 SSA 형식으로 이동하는 것이 매우 간단합니다. 이것은 사실 처음부터 구조화된 제어 흐름을 사용했던 이유 중 하나였습니다. 또한 웹에서 로드 시간에 영향을 미치기 때문에 매우 신중하게 측정됩니다.

만일을 대비하여 매우 구체적인 질문: "구조화된 제어 흐름"에서 SSA 형식으로 "매우 간단"하게 수행하는 Wasm 컴파일러를 알고 있습니까? 간단히 살펴보면 Wasm의 제어 흐름은 (완전히/궁극적으로) 구조화되어 있지 않기 때문입니다. 형식적으로 구조화된 제어는 break s, continue s, return s(대략 call/cc와 같은 마법이 없는 Scheme의 프로그래밍 모델)가 없는 제어입니다. 그것들이 존재할 때, 그러한 제어 흐름은 대략 "반구조적"이라고 부를 수 있습니다.

완전히 구조화된 제어 흐름을 위한 잘 알려진 SSA 알고리즘이 있습니다. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.4503 . 반구조화된 제어 흐름에 대해 다음과 같이 설명합니다.

구조화된 명령문의 경우 구문 분석 중 단일 패스에서 SSA 형식과 도미네이터 트리를 모두 생성하는 방법을 보여주었습니다. 다음 섹션에서는 임의의 지점에서 제어 구조를 종료할 수 있는 특정 클래스의 비정형 명령문(LOOP/EXIT 및 RETURN)으로 메서드를 확장하는 것이 가능하다는 것을 보여줍니다. 그러나 그러한 종료는 일종의 (규율된) goto이므로 구조화된 명령문보다 처리하기가 훨씬 더 어렵다는 것은 놀라운 일이 아닙니다.

OTOH, 잘 알려진 또 다른 알고리즘인 https://pp.info.uni-karlsruhe.de/uploads/publikationen/braun13cc.pdf 가 있습니다. 이 알고리즘은 단일 패스이기도 하지만 구조화되지 않은 제어에만 문제가 없습니다. 흐름, 그러나 환원할 수 없는 제어 흐름이 있는 경우에도(최적의 결과를 생성하지는 않지만).

따라서 문제는 일부 프로젝트가 실제로 Brandis/Mössenböck 알고리즘을 확장하는 문제를 겪었고 Braun et al과 비교하여 해당 경로에서 실질적인 이점을 얻었다는 것을 알고 있는지 여부입니다. 알고리즘(참고로 내 직관적 직감은 Braun algo가 정확히 그런 "상한" 확장입니다. 하지만 형식적 증거에 대해 말하지 않고 직관적으로 증명하기에는 너무 멍청하기 때문에 그게 다입니다. - 직관적 직감 ).

그리고 질문의 일반적인 주제는 Wasm이 임의적인 goto 지원을 거부한 궁극적인 이유를 확립하는 것입니다("유지"라고 말하고 싶습니다). 이 스레드를 몇 년 동안 관찰하면서 내가 구축한 멘탈 모델은 환원 불가능한 CFG에 직면하는 것을 피하기 위해 수행되었다는 것입니다. 그리고 실제로 격차는 축소 가능한 CFG와 할 수 없는 CFG 사이에 있으며 많은 최적화 알고리즘이 축소 가능한 CFG에 대해 훨씬 더 쉽고 이것이 많은 옵티마이저가 코딩한 것입니다. Wasm의 (반)구조화된 제어 흐름은 보장하는 저렴한 방법일 뿐입니다. 환원성.

구조화된 CFG(그리고 Wasm CFG는 실제로 형식적인 의미에서 구조화되지 않은 것 같습니다)에 대한 SSA 생산의 특별한 용이성에 대해 언급하면 ​​위의 명확한 그림이 흐려집니다. 그래서 SSA 구성이 Wasm CFG 형식으로 실질적으로 도움이 된다는 구체적인 언급이 있는지 묻고 있습니다.

감사 해요.

@kripken 저는 지금 약간 혼란스럽고 배우고 싶어합니다. 나는 상황을보고 있으며 현재 다음을보고 있습니다.

프로그램 소스에는 특정 제어 흐름이 있습니다. 이 CFG는 축소 가능하거나 축소할 수 없습니다(예: goto가 소스 언어에서 사용되었는지 여부). 이 사실을 바꿀 방법은 없습니다. 이 CFG는 예를 들어 Go 컴파일러가 기본적으로 하는 것처럼 기계어로 변환될 수 있습니다.

CFG가 이미 축소 가능하면 모든 것이 잘되고 wasm VM이 빠르게 로드할 수 있습니다. 모든 번역 패스는 이것이 간단한 경우임을 감지하고 빠른 작업을 수행할 수 있어야 합니다. 환원 불가능한 CFG를 허용하는 것은 이 경우를 늦추지 않아야 합니다.

CFG를 축소할 수 없는 경우 두 가지 옵션이 있습니다.

• 컴파일러는 예를 들어 점프 테이블을 도입하여 축소 가능하게 만듭니다. 이 단계에서 정보가 손실됩니다. 바이너리를 생성한 컴파일러에 특정한 분석 없이 원래 CFG를 복원하는 것은 어렵습니다. 이러한 정보 손실로 인해 생성된 모든 기계어 코드는 초기 CFG에서 생성된 코드보다 다소 느립니다. 단일 패스 알고리즘으로 이 기계어 코드를 생성할 수는 있지만 정보 손실이 발생합니다. [1]

• 컴파일러가 환원 불가능한 CFG를 방출하도록 허용합니다. VM은 이를 축소 가능하게 만들어야 할 수 있습니다. 이렇게 하면 로드 시간이 느려지지만 CFG가 실제로 감소할 수 없는 경우에만 가능합니다. 컴파일러에는 로드 시간 성능 또는 런타임 성능에 대한 최적화 중에서 선택할 수 있는 옵션이 있습니다.

[1] 조작을 되돌릴 수 있는 방법이 여전히 있다면 정보 손실이 아니라는 것을 알고 있지만 더 잘 설명할 수는 없습니다.

내 생각의 결함은 어디에 있습니까?

@팔콘

"구조화된 제어 흐름"에서 SSA 형식으로 "매우 간단"하게 수행하는 Wasm 컴파일러를 알고 있습니까?

VM 정보: 직접적으로는 모릅니다. 그러나 IIRC는 @titzer 와 @lukewagner 가 그런 방식으로 구현하는 것이 편리하다고 말했습니다. 아마도 그들 중 하나가 정교하게 만들 수 있을 것입니다. 환원 가능성이 전체 문제인지 아닌지는 확실하지 않습니다. 그리고 그들이 당신이 언급한 알고리즘을 구현했는지 여부는 확실하지 않습니다.

VM 이외의 정보: Binaryen 옵티마이저는 wasm의 구조화된 제어 흐름의 이점을 확실히 누릴 뿐만 아니라 축소 가능합니다. 예를 들어 wasm에서 주석이 달린 루프 헤더가 어디에 있는지 항상 알고 있기 때문에 다양한 최적화가 더 간단합니다. (OTOH 다른 최적화는 수행하기가 더 어려우며 우리는 일반 CFG IR도 가지고 있습니다...)

@neelance

CFG가 이미 축소 가능하면 모든 것이 잘되고 wasm VM이 빠르게 로드할 수 있습니다. 모든 번역 패스는 이것이 간단한 경우임을 감지하고 빠른 작업을 수행할 수 있어야 합니다. 환원 불가능한 CFG를 허용하는 것은 이 경우를 늦추지 않아야 합니다.

어쩌면 내가 당신을 완전히 이해하지 못하고 있을지도 모릅니다. 그러나 wasm VM이 코드를 빠르게 로드할 수 있는지 여부는 축소 가능 여부뿐만 아니라 인코딩 방식에 따라 다릅니다. 특히 일반적인 CFG 형식을 상상할 수 있으며 VM은 축소 가능한지 확인하는 작업을 수행해야 합니다. Wasm은 그 작업을 피하도록 선택했습니다. 인코딩은 반드시 축소 가능합니다(즉, wasm을 읽고 사소한 유효성 검사를 수행할 때 추가 작업 없이 축소 가능함을 증명하는 것입니다).

게다가, wasm의 인코딩은 그것을 검증할 필요 없이 축소성을 보장하는 것만은 아닙니다. 또한 루프 헤더, if 및 기타 유용한 것들에 주석을 답니다(이 주석의 앞부분에서 별도로 언급한 것처럼). 프로덕션 VM이 이를 통해 얼마나 많은 이점을 얻을 수 있는지는 확실하지 않지만 기대합니다. (아마도 특히 베이스라인 컴파일러에서?)

전반적으로 나는 환원 불가능한 CFG를 허용하면 환원 불가능한 CFG가 별도의 방식으로 인코딩되지 않는 한 빠른 경우를 늦출 수 있다고 생각합니다(예: funclet이 제안됨).

@kripken

설명해주셔서 감사합니다.

예, 이것이 바로 제가 만들려고 하는 차별화입니다. 축소 가능한 CFG의 경우 구조화된 표기법/인코딩의 이점을 봅니다. 그러나 환원 불가능한 CFG의 표기를 허용하고 환원 가능한 소스 CFG의 경우 기존 장점을 유지하는 일부 구성을 추가하는 것은 어렵지 않아야 합니다(예를 들어, 이 새로운 구성을 사용하지 않으면 CFG가 보장됩니다. 축소 가능).

결론적으로 나는 순전히 환원 가능한 표기법이 더 빠르다고 주장할 수 있는 방법을 알지 못합니다. 축소 가능한 소스 CFG 의 경우 똑같이 빠릅니다. 그리고 환원 불가능한 소스 CFG 의 경우 기껏해야 크게 느리지 않다고 주장할 수 있지만 몇 가지 실제 사례는 이미 일반적으로 그럴 가능성이 없음을 보여주었습니다.

요컨대, 성능 고려 사항이 환원 불가능한 제어 흐름을 방지하는 주장이 될 수 있고 다음 단계가 성능 데이터를 수집해야 하는 이유에 대해 의문을 제기하는 방법을 알 수 없습니다.

@neelance

예, 나는 우리가 funclet과 같은 새로운 구조를 추가할 수 있다는 것에 동의합니다. 그리고 그것을 사용하지 않으면 기존 사례가 느려지지 않을 것입니다.

그러나 was에 복잡성을 추가하기 때문에 새로운 구성을 추가하는 데에는 단점이 있습니다. 특히 VM에서 더 큰 표면적을 의미하므로 더 많은 버그와 보안 문제가 발생할 수 있습니다. Wasm은 VM의 복잡성을 줄이기 위해 가능한 한 개발자 측에 많은 복잡성을 가하는 쪽으로 기울었습니다.

일부 wasm 제안은 GC(JS로 주기 수집을 허용함)와 같이 속도에 관한 것이 아닙니다. 그러나 funclet과 같이 속도에 관한 제안의 경우 속도가 복잡성을 정당화한다는 것을 보여줄 필요가 있습니다. 우리는 속도에 관한 SIMD에 대해 토론했고 실제 코드에서 매우 큰 속도 향상(2배 이상)을 안정적으로 달성할 수 있다는 것을 보았기 때문에 가치가 있다고 결정했습니다.

(일반 CFG를 허용하는 속도 외에 다른 이점이 있습니다. 컴파일러가 wasm을 대상으로 하는 것이 더 쉬워진다는 점에 동의합니다. 하지만 wasm VM에 복잡성을 추가하지 않고도 이 문제를 해결할 수 있습니다. 우리는 이미 LLVM 및 Binaryen에서 임의의 CFG에 대한 지원을 제공합니다. , 컴파일러가 CFG를 내보내고 구조화된 제어 흐름에 대해 걱정하지 않도록 합니다. 그것이 충분하지 않다면 저를 포함한 도구 사람들이 더 많은 일을 해야 합니다.)

Funclet은 중요한 제어 흐름이 있는 언어가 WebAssembly로 컴파일되도록 허용하는 것만큼 속도에 관한 것이 아닙니다. C 및 Go가 가장 분명하지만 비동기/대기가 있는 모든 언어에 적용됩니다. 또한 계층적 제어 흐름을 선택하면 V8 이외의 모든 Wasm 컴파일러가 계층적 제어 흐름을 CFG로 분해한다는 사실에서 알 수 있듯이 실제로 VM에서 _더 많은_ 버그가 발생합니다. CFG의 EBB는 Wasm 등의 여러 제어 흐름 구성을 나타낼 수 있으며 컴파일할 단일 구성을 사용하면 다양한 용도로 여러 종류를 사용하는 것보다 훨씬 적은 수의 버그가 발생합니다.

매우 단순한 스트리밍 컴파일러인 Lightbeam도 CFG에 제어 흐름을 분해하는 추가 번역 단계를 추가한 후 잘못된 컴파일 버그가 크게 감소했습니다. 이것은 이 프로세스의 다른 측면에서 두 배로 진행됩니다. Relooper는 funclet을 내보내는 것보다 훨씬 더 오류가 발생하기 쉽습니다. 저는 LLVM용 Wasm 백엔드 및 구현될 funclet인 다른 컴파일러에서 작업하는 개발자로부터 모든 것을 방출할 것이라고 들었습니다. codegen의 신뢰성과 단순성을 향상시키기 위해 funclet만을 사용하여 함수를 만듭니다. Wasm을 생성하는 모든 컴파일러는 EBB를 사용하지만 Wasm을 사용하는 컴파일러 중 하나를 제외하고 모두 EBB를 사용합니다. 이러한 funclet 구현을 거부하거나 CFG를 나타내는 다른 방법을 거부하는 것은 V8 팀 이외의 관련된 모든 당사자에게 해를 입히는 손실 단계를 중간에 추가하는 것입니다. .

"유해한 것으로 간주되는 환원 불가능한 제어 흐름"은 단순히 요점일 뿐이며, funclet의 제어 흐름을 축소할 수 있다는 제한을 쉽게 추가할 수 있으며, 미래에 환원 불가능한 제어 흐름을 허용하려면 축소 가능한 제어 흐름을 가진 기존의 모든 Wasm 모듈이 수정되지 않고 작동할 것입니다. 환원 불가능한 제어 흐름을 추가로 지원하는 엔진에서. 유효성 검사기에서 축소성 검사를 제거하는 경우일 뿐입니다.

@부리히

funclet의 제어 흐름을 축소할 수 있다는 제한을 쉽게 추가할 수 있습니다.

할 수 있지만 사소한 일은 아닙니다. VM에서 이를 확인해야 합니다. 단일 선형 패스에서는 이것이 가능하지 않다고 생각합니다. 이는 현재 대부분의 VM에 있는 기준 컴파일러에 문제가 될 것입니다. (사실, 루프 백 에지를 찾는 것 - 이것은 더 간단한 문제이고 다른 이유로도 필요합니다 - 단일 정방향 패스에서 수행될 수 없습니까?)

V8 이외의 모든 Wasm 컴파일러는 어쨌든 계층적 제어 흐름을 CFG로 분해합니다.

TurboFan이 사용하는 "노드의 바다" 접근 방식을 말씀하시는 건가요? 나는 그것에 대해 전문가가 아니므로 답변은 다른 사람들에게 맡기겠습니다.

그러나 더 일반적으로 컴파일러를 최적화하기 위해 위의 인수를 구입하지 않더라도 앞에서 언급한 것처럼 기준 컴파일러에 대해서는 훨씬 더 직접적인 사실입니다.

Funclet은 속도에 관한 것이 아니라 중요하지 않은 제어 흐름이 있는 언어를 WebAssembly로 컴파일하도록 허용하는 것과 관련이 있습니다. [..] Relooper는 funclet을 내보내는 것보다 오류가 발생하기 쉽습니다.

도구 측면에서 100% 동의합니다. 대부분의 컴파일러에서 구조화된 코드를 내보내는 것이 더 어렵습니다! 그러나 요점은 VM 측에서 더 간단하게 만들고 wasm이 선택한 것입니다. 그러나 다시 말하지만, 여기에는 귀하가 언급한 단점을 포함하여 절충점이 있다는 데 동의합니다.

2015년에 was가 이것을 잘못 이해했나요? 있을 수있다. 디버깅 가능성 및 스택 머신으로의 늦은 전환과 같은 몇 가지 문제가 있는 것 같습니다. 그러나 돌이켜보면 고칠 수 없고 새로운 것을 추가하는 것, 특히 겹치는 것에는 높은 기준이 있습니다.

이 모든 것을 감안할 때 건설적인 노력을 기울이면서 도구 측면에서 기존 문제를 수정해야 한다고 생각합니다. 도구 변경에 대한 훨씬 낮은 막대가 있습니다. 두 가지 가능한 제안:

• Go 컴파일러에 도움이 된다면 Binaryen CFG 코드를 Go로 이식하는 방법을 살펴볼 수 있습니다. - @neelance ?
• 우리는 순전히 도구 측면에서 funclet 또는 이와 유사한 것을 구현할 수 있습니다. 즉, 우리는 오늘 이를 위한 라이브러리 코드를 제공하지만 바이너리 형식을 추가할 수도 있습니다. (wasm 오브젝트 파일에서 도구 측에서 wasm 바이너리 형식을 추가하는 선례가 이미 있습니다.)

우리는 순전히 도구 측면에서 funclet 또는 이와 유사한 것을 구현할 수 있습니다. 즉, 우리는 오늘 이를 위한 라이브러리 코드를 제공하지만 바이너리 형식을 추가할 수도 있습니다. (wasm 오브젝트 파일에서 도구 측에서 wasm 바이너리 형식을 추가하는 선례가 이미 있습니다.)

이에 대한 구체적인 작업이 있는 경우 (AFAIU) 이것을 Wasm에 추가하는 가장 작은 관용적 방법( @rossberg가 언급한 대로 )은 블록 명령을 도입하는 것입니다.

다중 루프 (t <sub>in</sub> ) <sup>_n_</sup> t <sub>out</sub> (_instr_* end ) <sup>_n_</sup>

이는 n개의 레이블이 지정된 본문을 정의합니다(n개의 입력 유형 주석이 앞으로 선언됨). 그런 다음 명령의 br 계열은 일반화되어 다중 루프에 의해 정의된 모든 레이블이 각 본문 내에서 순서대로 범위 내에 있습니다(즉, 모든 본문이 다른 본문 내에서 분기될 수 있음). 멀티루프 본문이 분기되면 실행은 본문의 _start_로 점프합니다(일반 Wasm 루프처럼). 실행이 다른 본문으로 분기하지 않고 본문 끝에 도달하면 전체 구문이 반환됩니다(폴스루 없음).

각 바디의 유형 주석을 효율적으로 표현하는 방법에 대해 수행해야 하는 약간의 바이크쉐딩이 있을 것입니다(위의 공식에서 n개의 바디는 n개의 다른 입력 유형을 가질 수 있지만 모두 동일한 출력 유형을 가져야 하므로 직접 사용할 수 없습니다. 불필요한 느낌의 LUB 계산을 요구하지 않는 일반 다중 값 _blocktype_ 인덱스) 및 실행할 초기 본문을 선택하는 방법(항상 첫 번째 또는 정적 매개변수가 있어야 합니까?).

이것은 funclet과 같은 수준의 표현력을 갖지만 제어 명령의 새로운 공간을 도입할 필요가 없습니다. 사실 funclet이 더 반복되었다면 다음과 같이 변했을 것이라고 생각합니다.

편집: 폴 스루(fall-through) 동작을 갖도록 이것을 조정하면 형식 의미가 약간 복잡해질 수 있지만

엔진을 더 간단하고 빠르게 만들기 위해 작업을 도구로 오프로딩하는 Wasm 설계 원칙은 매우 중요하며 계속해서 매우 유용할 것입니다.

즉, 사소하지 않은 모든 것과 마찬가지로 흑백이 아닌 절충안입니다. 여기에 생산자의 고통이 엔진의 고통과 비례하지 않는 경우가 있다고 생각합니다. 우리가 Wasm에 가져오고 싶은 대부분의 컴파일러는 내부적으로 임의의 CFG 구조(SSA)를 사용하거나 goto(CPU)에 신경 쓰지 않는 대상을 대상으로 사용됩니다. 우리는 많은 이득을 얻지 못한 채 세상을 뛰어넘게 만들고 있습니다.

funclet(또는 multiloop)과 같은 것은 모듈식이기 때문에 좋습니다. 생산자가 필요하지 않으면 이전과 같이 작동합니다. 엔진이 임의의 CFG를 실제로 처리할 수 없는 경우 잠시 동안은 마치 loop + br_table 종류의 구성인 것처럼 방출할 수 있으며 이를 사용하는 사람만 대가를 지불합니다. . 그런 다음 "시장이 결정"하고 엔진에 더 나은 코드를 내보내야 한다는 압력이 있는지 확인합니다. funclet에 의존하는 Wasm 코드가 많이 있을 경우 일부 사람들이 생각하는 것처럼 엔진이 좋은 코드를 내보내는 것은 큰 재앙이 되지 않을 것이라고 뭔가가 말해줍니다.

할 수 있지만 사소한 일은 아닙니다. VM에서 이를 확인해야 합니다. 단일 선형 패스에서는 이것이 가능하지 않다고 생각합니다. 이는 현재 대부분의 VM에 있는 기준 컴파일러에 문제가 될 것입니다.

어쩌면 내가 기준 컴파일러에 대한 기대치를 오해하고 있을지도 모르지만 그들이 왜 신경을 쓰겠습니까? goto가 보이면 점프 명령을 삽입하십시오.

도구 측면에서 100% 동의합니다. 대부분의 컴파일러에서 구조화된 코드를 내보내는 것이 더 어렵습니다! 그러나 요점은 VM 측에서 더 간단하게 만들고 wasm이 선택한 것입니다. 그러나 다시 말하지만, 여기에는 귀하가 언급한 단점을 포함하여 절충점이 있다는 데 동의합니다.

아니요, 원래 의견에서 여러 번 말했듯이 VM 측에서 작업을 더 쉽게 만들지 _않습니다_. 나는 1년 넘게 베이스라인 컴파일러에서 일했고 Wasm의 제어 흐름을 CFG로 변환하는 중간 단계를 추가한 후 내 삶이 더 쉬워지고 방출된 코드가 더 빨라졌습니다.

할 수 있지만 사소한 일은 아닙니다. VM에서 이를 확인해야 합니다. 단일 선형 패스에서는 이것이 가능하지 않다고 생각합니다. 이는 현재 대부분의 VM에 있는 기준 컴파일러에 문제가 될 것입니다. (사실, 루프 백 에지를 찾는 것 - 이것은 더 간단한 문제이고 다른 이유로도 필요합니다 - 단일 정방향 패스에서 수행될 수 없습니까?)

자, 여기 문제가 있습니다. 컴파일러에서 사용되는 알고리즘에 대한 제 지식은 스트리밍 컴파일러에서 환원 불가능한 제어 흐름을 감지할 수 있거나 감지할 수 없다는 절대적인 확신을 가질 만큼 강력하지 않지만, 그럴 필요가 없다는 것입니다. 검증은 컴파일과 함께 발생할 수 있습니다. 스트리밍 알고리즘이 존재하지 않는 경우(귀하와 본인 모두 알지 못하는) 기능이 완전히 수신되면 비 스트리밍 알고리즘을 사용할 수 있습니다. (어떤 이유로) 축소할 수 없는 제어 흐름이 무한 루프와 같이 정말 나쁜 것으로 이어지는 경우, 단순히 컴파일 시간을 초과하거나 컴파일 스레드를 취소할 수 있습니다. 그러나 이것이 사실일 것이라고 믿을 이유가 없습니다.

어쩌면 내가 기준 컴파일러에 대한 기대치를 오해하고 있을지도 모르지만 그들이 왜 신경을 쓰겠습니까? goto가 보이면 점프 명령을 삽입하십시오.

Wasm의 무한 레지스터 기계(아니요, 스택 기계가 아님)를 물리적 하드웨어의 유한 레지스터에 매핑해야 하기 때문에 그렇게 간단

내가 작업한 스트리밍 컴파일러는 임의의 - 심지어 환원 불가능한 - CFG를 잘 컴파일할 수 있습니다. 특별히 특별한 일을 하는 것은 아닙니다. 처음으로 점프해야 할 때 각 블록에 "호출 규칙"(기본적으로 해당 블록의 범위 내 값이 있어야 하는 위치)을 할당하고 조건부로 두 블록으로 분기해야 하는 지점에 도달한 경우 호환되지 않는 "호출 규칙"이 있는 더 많은 대상에서 "어댑터" 블록을 대기열로 푸시하고 다음 가능한 지점에서 방출합니다. 이것은 축소 및 축소 제어 흐름 모두에서 발생할 수 있으며 두 경우 모두 거의 필요하지 않습니다. 앞서 말했듯이 "유해한 제어 흐름으로 간주되는 환원 불가능한 제어 흐름"은 기술적인 주장이 아니라 화두입니다. 제어 흐름을 CFG로 나타내면 스트리밍 컴파일러를 훨씬 더 쉽게 작성할 수 있으며, 여러 번 말했듯이 광범위한 개인 경험을 통해 이를 알고 있습니다.

환원할 수 없는 제어 흐름이 구현을 작성하기 어렵게 만드는 모든 경우(그 중 아무 것도 생각할 수 없음)는 스터브 처리되어 오류를 반환할 수 있습니다. 흐름은 축소할 수 없으므로(따라서 축소할 수 없는 제어 흐름을 실수로 수락하지 않음) 기준 컴파일러 자체와 별도로 실행할 수 있습니다. 상대적으로 간단한 스트리밍 알고리즘이 존재한다고 믿을만한 이유가 있는 누군가가 그 주제에 대한 권위를 가지고 있다는 말을 들었습니다. CFG의 환원 가능성을 감지하기 위한 것이지만 이것이 사실이라고 직접 말할 수는 없습니다.

@oridb

어쩌면 내가 기준 컴파일러에 대한 기대치를 오해하고 있을지도 모르지만 그들이 왜 신경을 쓰겠습니까? goto가 보이면 점프 명령을 삽입하십시오.

기준 컴파일러는 여전히 루프 백에지에 추가 검사를 삽입하는 것과 같은 작업을 수행해야 하므로(웹에서 매달린 페이지가 결국 느린 스크립트 대화를 표시하는 방식입니다), 그런 것을 식별해야 합니다. 또한 그들은 합리적으로 효율적인 레지스터 할당을 시도합니다(기준 컴파일러는 종종 최적화 컴파일러의 약 1/2 속도로 실행됩니다. 이는 단일 패스를 감안할 때 매우 인상적입니다!). 조인과 분할을 포함한 제어 흐름의 구조를 가지면 훨씬 쉬워집니다.

@gwvo

즉, 사소하지 않은 모든 것과 마찬가지로 흑백이 아닌 절충안입니다. [..] 우리는 많은 이득을 얻지 못한 채 세상을 뛰어넘게 만들고 있습니다.

그것이 절충점이라는 데 전적으로 동의합니다. 그리고 아마도 wasm도 그 당시에는 틀렸을 것입니다. 그러나 도구 측면에서 이러한 고리를 수정하는 것이 훨씬 더 실용적이라고 생각합니다.

그런 다음 "시장이 결정"하고 엔진에 더 나은 코드를 내보내야 한다는 압력이 있는지 확인합니다.

이것은 실제로 우리가 지금까지 피했던 것입니다. 우리는 가상 머신에서 wasm을 가능한 한 간단하게 만들려고 노력했습니다. 그래서 복잡한 최적화가 필요하지 않습니다. 목표는 VM이 ​​더 잘하도록 압력을 가하는 것이 아니라 도구 측면에서 열심히 일하는 것입니다.

@부리히

나는 1년 넘게 베이스라인 컴파일러에서 일했고 Wasm의 제어 흐름을 CFG로 변환하는 중간 단계를 추가한 후 내 삶이 더 쉬워지고 방출된 코드가 더 빨라졌습니다.

매우 흥미로운! 어떤 VM이었습니까?

또한 싱글 패스/스트리밍인지 아닌지(만약 그렇다면 루프 백에지 계측을 어떻게 처리했습니까?), 그리고 어떻게 레지스터 할당을 수행하는지 궁금합니다.

원칙적으로 루프 백에지와 레지스터 할당은 모두 선형 명령 순서를 기반으로 처리될 수 있으며, 기본 블록은 엄격하게 요구하지 않고도 합리적인 topsort와 같은 순서로 배치될 것으로 예상 됩니다.

For 루프 backedges: backedge를 명령어 스트림에서 이전으로 점프하는 명령어로 정의합니다. 최악의 경우 블록이 거꾸로 배치되면 엄격하게 필요한 것보다 더 많은 백에지 검사를 받게 됩니다.

레지스터 할당의 경우: 이것은 표준 선형 스캔 레지스터 할당 입니다. 레지스터 할당을 위한 변수의 수명은 그 사이에 선형으로 있는 모든 블록을 포함하여 변수의 첫 번째 언급부터 마지막 ​​언급까지입니다. 최악의 경우 블록이 섞이면 필요한 것보다 더 긴 수명을 갖게 되어 불필요하게 스택에 물건을 쏟아 붓게 됩니다. 유일한 추가 비용은 단일 선형 스캔으로 모든 변수에 대해 수행할 수 있는 각 변수의 첫 번째 및 마지막 언급을 추적하는 것입니다. (wasm의 경우 "변수"가 로컬 또는 스택 슬롯이라고 가정합니다.)

@kripken

Go 컴파일러에 도움이 된다면 Binaryen CFG 코드를 Go로 이식하는 방법을 살펴볼 수 있습니다. - @neelance ?

Asyncify를 통합하려면? 제안 에 말씀해 주십시오.

@comex

좋은 점!

유일한 추가 비용은 각 변수의 처음 언급과 마지막 언급을 추적하는 것입니다.

네, 상당한 차이가 있다고 생각합니다. 선형 스캔 레지스터 할당은 실제로 빠른 스트리밍 방식으로 컴파일하기 때문에 현재 wasm 기준 컴파일러 가 수행하는 것보다 낫습니다(하지만 수행하는 데 느림). 즉, 각 변수의 마지막 언급을 찾는 초기 단계가 없습니다. 단일 패스로 컴파일하고 나중에 wasm 함수에서 코드를 보지 않고 코드를 내보내고 구조의 도움을 받아 간단하게 만듭니다. 그들이가는대로 선택 ( "바보"해당 게시물에서 사용되는 단어입니다).

레지스터 할당에 대한 V8의 스트리밍 접근 방식은 블록이 처리하는 유일한 수명이기 때문에 블록이 상호 재귀적으로 허용되는 경우(https://github.com/WebAssembly/design/issues/796#issuecomment-742690194에서와 같이) 잘 작동해야 합니다. 단일 블록(스택) 내에서 바인딩되거나 기능 전체(로컬)로 간주됩니다.

IIUC( @titzer 의 의견 참조) V8의 주요 문제는 Turbofan이 최적화할 수 있는 CFG의 종류에 있습니다.

@kripken

복잡한 최적화가 필요하지 않도록 VM에서 wasm을 가능한 한 간단하게 만들려고 했습니다.

이것은 "복잡한 최적화"가 아닙니다. goto는 많은 시스템에서 믿을 수 없을 정도로 기본적이고 자연스럽습니다. 나는 이것을 비용 없이 추가할 수 있는 많은 엔진이 있을 것이라고 확신합니다. 어떤 이유로든 구조화된 CFG 모델을 유지하려는 엔진이 있다면 그렇게 할 수 있습니다.

예를 들어, 저는 LLVM(현재 우리의 1위 Wasm 생산자)이 주요 엔진에서 성능 저하가 아니라는 확신이 있을 때까지 funclet 사용으로 전환하지 않을 것이라고 확신합니다.

@kripken Wasmtime 의 일부입니다. 예, 스트리밍이고 O(N) 복잡성을 의도했지만 완전히 실현되기 전에 새 회사로 옮겼으므로 "O(N)-ish"입니다. https://github.com/bytecodealliance/wasmtime/tree/main/crates/lightbeam

감사합니다 @Vurich , 흥미롭습니다. 특히 시작뿐만 아니라 처리량에 대해서도 사용할 수 있는 경우 성능 수치를 확인하는 것이 좋습니다. 귀하의 접근 방식은 V8 및 SpiderMonkey 엔지니어가 취한 접근 방식보다 컴파일 속도가 더 느리면서 더 빠른 코드를 생성할 것이라고 생각합니다. 따라서 이 공간에서는 다른 절충안입니다. 당신의 접근 방식이 당신이 말했듯이 wasm의 구조화된 제어 흐름의 이점을 얻지 못하는 반면 그들의 접근 방식은 그럴듯해 보입니다.

아니요, 스트리밍 컴파일러이고 두 엔진 중 하나보다 더 빠르게 코드를 내보냅니다(비록 내가 프로젝트를 떠났을 때 수정되지 않은 퇴화 사례가 있긴 하지만). 빠른 코드를 내보내기 위해 최선을 다했지만 주로 출력의 효율성이 부차적인 관심사인 코드를 빠르게 내보내도록 설계되었습니다. 내가 아는 한 시작 비용은 모든 데이터 구조가 초기화되지 않고 시작되고 컴파일이 명령어별로 수행되기 때문에 0(백엔드 간에 공유되는 Wasmtime의 고유 비용 이상)입니다. V8 또는 SpiderMonkey와 비교할 수 있는 숫자는 없지만 Cranelift(wasmtime의 기본 엔진)와 비교할 숫자는 있습니다. 이 시점에서 몇 개월이 지났지만 Cranelift보다 더 빠르게 코드를 생성할 뿐만 아니라 Cranelift보다 더 빠른 코드를 생성한다는 것을 알 수 있습니다. 그 당시에는 SpiderMonkey보다 더 빠른 코드도 내보냈지만, 내 말을 믿어야 하므로 내 말을 믿지 않는다고 해서 당신을 비난하지는 않을 것입니다. 최신 수치는 없지만 현재 상태는 Cranelift와 SpiderMonkey가 Lightbeam과 비교할 때 이러한 마이크로벤치마크에서 낮은 성능의 출력의 주요 원인이었던 소수의 버그를 수정한 상태라고 생각합니다. 하지만 컴파일 속도 차이는 내가 프로젝트에 있는 내내 변하지 않았습니다. 왜냐하면 각 컴파일러는 여전히 기본적으로 동일하게 설계되어 있고 서로 다른 수준의 성능을 이끌어내는 것은 각각의 아키텍처이기 때문입니다. 나는 당신의 추측에 감사하지만 내가 설명한 방법이 더 느릴 것이라는 당신의 가정이 어디에서 오는지 모르겠습니다.

다음은 벤치마크입니다. ::compile 벤치마크는 컴파일 속도에 대한 것이고 ::run 벤치마크는 기계 코드 출력의 실행 속도에 대한 것입니다. https://gist.github.com/Vurich/8696e67180aa3c93b4548fb1f298c29e

방법론이 있습니다. 이를 복제하고 벤치마크를 다시 실행하여 결과를 직접 확인할 수 있지만 PR은 최신 버전의 wasmtime과 호환되지 않을 수 있으므로 마지막으로 업데이트한 시점의 성능 비교만 표시합니다. 홍보 https://github.com/bytecodealliance/wasmtime/pull/1660

즉, 내 주장은 CFG가 스트리밍 컴파일러의 성능에 대한 유용한 내부 표현이라는 _아닙니다_. 내 주장은 CFG가 모든 컴파일러의 성능에 부정적인 영향을 미치지 않으며 GCC 및 Go 팀이 WebAssembly를 생산하지 못하도록 완전히 잠그는 것을 정당화할 수준이 아니라는 것입니다. 이 스레드에서 funclets 또는 wasm에 대한 유사한 확장에 대해 논쟁하는 사람은 거의 아무도 이 제안에 의해 부정적인 영향을 받을 것이라고 주장하는 프로젝트에서 실제로 작업하지 않았습니다. 이 주제에 대해 논평하기 위해 직접 경험이 필요하다는 것은 아니지만 모든 사람이 어느 정도 가치 있는 정보를 가지고 있다고 생각하지만 자전거 보관소의 색상에 대해 다른 의견을 갖는 것과 자전거를 만드는 것 사이에는 선이 있습니다. 유휴 추측에 근거한 주장.

@부리히

아니요, 스트리밍 컴파일러이고 두 엔진 중 하나보다 더 빠르게 코드를 내보냅니다(비록 내가 프로젝트를 떠났기 때문에 수정되지 않은 퇴화 사례가 있긴 하지만).

이전에 충분히 명확하지 않았다면 죄송합니다. 우리가 같은 것에 대해 이야기하고 있는지 확인하기 위해 해당 엔진의 기본 컴파일러를 의미했습니다. 그리고 V8과 SpiderMonkey가 이 용어를 사용한다는 의미에서 기준 컴파일러의 요점인 컴파일 시간에 대해 이야기하고 있습니다.

내가 V8 및 SpiderMonkey 기준 컴파일 시간을 능가할 수 있다고 회의적인 이유는 이전에 제공 한 링크 에서와 같이 두 기준 컴파일러가 컴파일 시간에 대해 엄청나게 조정되었기 때문입니다. 특히 내부 IR을 생성하지 않고 wasm에서 기계 코드로 바로 이동합니다. 컴파일러가 내부 IR(CFG의 경우)을 내보낸다고 말씀하셨습니다. - 그 때문에(더 많은 분기, 메모리 대역폭 등으로 인해) 컴파일 시간이 느려질 것으로 예상합니다.

그러나 이러한 기준 컴파일러에 대해 벤치마킹하십시오! 내 추측이 틀렸음을 보여주는 데이터를 보고 싶습니다. V8 및 SpiderMonkey 엔지니어도 마찬가지일 것입니다. 그것은 그들이 채택을 고려해야 할 더 나은 디자인을 발견했음을 의미합니다.

V8에 대해 테스트하려면 d8 --liftoff --no-wasm-tier-up 를 실행할 수 있고 SpiderMonkey의 경우 sm --wasm-compiler=baseline 실행할 수 있습니다.

(Cranelift와 비교하기 위한 지침에 감사하지만 Cranelift는 기준 컴파일러가 아니므로 컴파일 시간을 이와 비교하는 것은 이 컨텍스트에서 관련이 없습니다. 그렇지 않으면 매우 흥미롭지만 동의합니다.)

내 직관은 베이스라인 컴파일러가 어쨌든 의미 있는 블록 간 최적화를 시도하지 않기 때문에 funclet/ multiloop 를 지원하기 위해 컴파일 전략을 크게 변경할 필요가 없다는 것입니다. @kripken 이 참조 하는 "조인 및 분할을 포함한 제어 흐름의 구조"에 의존하는 것은 상호 재귀 블록 컬렉션에 대한 모든 입력 유형이 전방으로 선언되도록 요구함으로써 충족됩니다(어쨌든 스트리밍 유효성 검사를 위한 자연스러운 선택인 것 같습니다) . Lightbeam/Wasmtime이 엔진 기준 컴파일러를 능가할 수 있는지 여부는 이를 고려하지 않습니다. 중요한 점은 엔진 기준 컴파일러가 지금처럼 빠르게 유지될 수 있는지 여부입니다.

FWIW, 저는 이 기능이 향후 CG 회의에서 논의되는 것을 보고 싶습니다. 저는 엔진 담당자가 구현할 준비가 되어 있지 않으면 스스로 반대할 수 있다는 @Vurich의 의견에 대체로 동의합니다. 즉, 우리는 그러한 반대를 진지하게 받아들여야 합니다(이 기능을 추구할 때 JavaScript Proper Tail Calls saga 의 WebAssembly 버전을 피해야 한다고 이전에 직접 회의에서 의견을 나눴습니다). 나는 (현재 매우 늦은) 논문 제출을 마치면 새해에 그러한 CG 토론을 먼저 시작하게 되어 기쁩니다.

@kripken

네, 상당한 차이가 있다고 생각합니다. 선형 스캔 레지스터 할당은 실제로 빠른 스트리밍 방식으로 컴파일하기 때문에 현재 wasm 기준 컴파일러 가 수행하는 것보다 낫습니다(하지만 수행하는 데 느림). 즉, 각 변수의 마지막 언급을 찾는 초기 단계가 없습니다. 단일 패스로 컴파일하고 나중에 wasm 함수에서 코드를 보지 않고 코드를 내보내고 구조의 도움을 받아 간단하게 만듭니다. 그들이가는대로 선택 ( "바보"해당 게시물에서 사용되는 단어입니다).

와, 정말 간단합니다.

반면에... 그 특정 알고리즘은 구조화된 제어 흐름의 깊은 속성에 의존하지 않을 정도로 간단합니다. 구조화된 제어 흐름의 얕은 속성에도 거의 의존하지 않습니다.

블로그 게시물에서 언급했듯이 SpiderMonkey의 wasm 기준 컴파일러는 고정 ABI를 사용하거나 wasm 스택에서 기본 스택 및 레지스터로 매핑하는 대신 "제어 흐름 조인"(즉, 여러 선행 작업이 있는 기본 블록)을 통해 레지스터 할당자 상태를 유지하지 않습니다. . 테스트를 통해 대부분의 경우 제어 흐름 조인이 아니더라도 블록을 입력할 때 고정 ABI도 사용한다는 것을 발견했습니다!

고정 ABI는 다음과 같습니다(x86에서).

• 매개변수의 수가 0이 아닌 경우 (블록에 들어갈 때) 또는 반환할 때(블록을 나갈 때), wasm 스택의 맨 위는 rax 에 들어가고 나머지 wasm 스택은 x86에 해당합니다. 스택.
• 그렇지 않으면 전체 wasm 스택이 x86 스택에 해당합니다.

이것이 왜 중요합니까?

이 알고리즘은 훨씬 적은 정보로 거의 동일한 방식으로 작동할 수 있기 때문입니다. 사고 실험으로 기본 어셈블리와 유사한 구조화된 제어 흐름 지침이 없고 점프 지침만 있는 대체 우주 버전의 WebAssembly를 상상해 보십시오. 어떤 명령이 점프의 대상인지 알려주는 한 가지 추가 정보로 보강되어야 합니다.

그러면 알고리즘은 다음과 같을 것입니다. 명령을 선형으로 진행합니다. 점프 및 점프 대상 전에 레지스터를 고정 ABI로 플러시합니다.

한 가지 차이점은 고정 ABI가 두 개가 아니라 한 개여야 한다는 것입니다. 스택 상단 값이 의미상 점프의 '결과'인 것과 외부 블록에서 스택에 남아 있는 것을 구별할 수 없습니다. 따라서 무조건 rax 최상위 스택을 넣어야 합니다.

그러나 이것이 성능에 대한 측정 가능한 비용이 될 것인지 의심스럽습니다. 무엇이든 개선이 될 수 있습니다.

(검증도 다르지만 여전히 단일 패스입니다.)

좋아요, 사전 주의사항:

1. 이것은 대체 우주가 아닙니다. 우리는 기존 WebAssembly에 이전 버전과 호환되는 확장을 만드는 데 어려움을 겪고 있습니다.
2. SpiderMonkey의 기준 컴파일러는 단지 하나의 구현일 뿐이며 레지스터 할당과 관련하여 차선책일 가능성 이 있습니다. 즉, 조금만 더 똑똑했다면 런타임 이점이 컴파일 시간 비용보다 클 것입니다.
3. 기준 컴파일러에 추가 정보가 필요하지 않더라도 최적화 컴파일러는 빠른 SSA 구성을 위해 추가 정보가 필요할 수 있습니다.

이를 염두에 두고 위의 사고 실험은 기준 컴파일러가 구조화된 제어 흐름을 필요로 하지 않는다는 나의 믿음을 강화합니다. 우리가 얼마나 낮은 수준의 구성을 추가했는지에 관계없이, 어떤 명령어가 점프 대상인지와 같은 기본 정보가 포함되어 있는 한, 베이스라인 컴파일러는 사소한 변경만으로 이를 처리할 수 있습니다. 또는 적어도 이것은 할 수 있습니다.

@ conrad -watt

아주 좋은 점들입니다! 베이스라인 컴파일러에 대한 나의 직관은 잘못된 것일 수 있습니다.

그리고 @comex - 예, 당신이 말했듯이 이 논의는 SSA가 구조의 이점을 얻을 수 있는 최적화 컴파일러와 별개입니다. 이전 링크 중 하나에서 약간 인용할 가치가 있습니다.

설계상 WebAssembly 코드를 TurboFan의 IR(SSA 구성 포함)로 간단한 단일 패스로 변환하는 것은 부분적으로 WebAssembly의 구조화된 제어 흐름으로 인해 매우 효율적입니다.

@conrad-watt 저는 우리가 VM 사람들로부터 직접적인 피드백을 받고 열린 마음을 유지해야 한다는 데 동의합니다. 분명히 말해서, 여기서 내 목표는 아무것도 막는 것이 아닙니다. 여러 의견이 wasm의 구조화된 제어 흐름이 명백한 실수이거나 funclets/multiloop으로 분명히 수정되어야 하는 오류라고 생각하는 것 같았기 때문에 여기에 길게 설명했습니다. 저는 단지 여기에 생각의 역사를 제시하고 싶었고 강력한 이유가 있다고 말했습니다. 현재 모델의 경우 개선이 쉽지 않을 수 있습니다.

나는 이 대화를 읽는 것을 정말로 즐겼다. 나는 (양방향에서 오는) 이러한 질문을 많이 궁금해했고 이러한 생각 중 많은 부분을 (다시 양방향에서) 공유했으며 토론은 많은 유용한 통찰력과 경험을 제공했습니다. 아직 확고한 의견이 있는지는 모르겠지만, 각 방향에 기여하고 싶다는 생각이 있습니다.

"for" 측면에서, 어떤 블록에 backedge가 있는지 미리 아는 것이 유용합니다. 스트리밍 컴파일러 WebAssembly 유형의 시스템 (예 : 로컬에서 인덱스 자명하지 않은 특성을 추적 할 수 i 로컬에서 상기 어레이의 경계 내에 arr ). 앞으로 점프할 때 해당 지점에서 어떤 속성이 유지되는지 대상에 주석을 추가하는 것이 유용할 수 있습니다. 그렇게 하면 레이블에 도달할 때 모든 인-에지에서 유지되는 속성을 사용하여 해당 블록을 컴파일하여 배열 경계 검사를 제거할 수 있습니다. 그러나 레이블에 잠재적으로 알려지지 않은 backedge가 있을 수 있는 경우 해당 블록은 이 지식으로 컴파일할 수 없습니다. 물론 비 스트리밍 컴파일러는 더 중요한 루프 불변 분석을 수행할 수 있지만 스트리밍 컴파일러의 경우 앞으로 일어날 일에 대해 걱정할 필요가 없는 것이 유용합니다. ( 부수적 생각:

"반대" 측면에서 지금까지 논의는 국지적 통제에만 초점을 맞추었습니다. C에서는 괜찮지만 C++ 또는 유사한 예외가 있는 다양한 다른 언어의 경우는 어떻습니까? 다른 형태의 비-로컬 컨트롤이 있는 언어는 어떻습니까? 동적 범위가 있는 것들은 본질적으로 구조화되어 있는 경우가 많습니다(또는 적어도 상호 재귀적 동적 범위의 예는 모릅니다). 이러한 고려 사항을 해결할 수 있다고 생각하지만 이러한 설정에서 결과를 사용할 수 있으려면 염두에 두고 무언가를 설계해야 합니다. 이것은 내가 숙고해 왔던 것이며, 진행 중인 내 생각(@conrad-watt의 다중 루프의 확장처럼 보임)을 관심 있는 사람과 공유하게 되어 기쁩니다(여기서는 주제가 아닌 것 같지만). 나는 적어도 염두에 두어야 할 로컬 제어 흐름 이상의 것이 있다는 점을 미리 알려드리고 싶었습니다.

(나는 @kripken 이 고려 사항을 대표하는 훌륭한 일을 했다고 생각하지만 VM 사람들의

내가 Lightbeam이 내부 IR을 생성한다고 말할 때, 그것은 정말 오해의 소지가 있고 분명히 했어야 했습니다. 나는 잠시 동안 프로젝트에 참여하고 있었고 때때로 터널 비전을 얻을 수 있습니다. 기본적으로 Lightbeam은 명령어별로 입력 명령어를 사용하며(실제로 최대 1개의 명령어 미리보기가 있지만 특별히 중요하지 않음) 각 명령어에 대해 일정한 공간에서 지연되고 일정한 공간에서 여러 내부 IR 명령어를 생성합니다. Wasm 명령어당 최대 명령어 수는 일정하고 작습니다. 예를 들어 6과 같습니다. 전체 기능에 대한 IR 명령어 버퍼를 만들고 작업하는 것이 아닙니다. 그런 다음 해당 IR 명령을 하나씩 읽습니다. 각 Wasm 명령을 구현하는 보다 일반적인 도우미 함수 라이브러리가 있는 것으로 생각할 수 있습니다. 제어 흐름 등에 대한 다른 모델이 있는 방법을 설명하는 데 도움이 되기 때문에 그냥 IR이라고 부릅니다. 아마도 V8이나 SpiderMonkey의 기준 컴파일러만큼 빠르게 코드를 생성하지 않을 것입니다. 하지만 이는 완전히 최적화되지 않았기 때문이요 구조적으로 부족하기 때문이 아닙니다. 내 요점은 LLVM 또는 Cranelift가 수행하는 방식으로 실제로 메모리에 IR 버퍼를 생성하는 대신 Wasm의 계층적 제어 흐름을 마치 CFG인 것처럼 내부적으로 모델링한다는 것입니다.

또 다른 옵션은 제어 흐름을 최적으로 처리할 수 있다고 믿는 것으로 wasm을 컴파일하는 것입니다. 즉, 구조화를 "실행 취소"합니다. LLVM은 그렇게 할 수 있어야 하므로 LLVM(WAVM 또는 wasmer와 같은)을 사용하는 VM에서 또는 WasmBoxC를 통해 wasm을 실행하는 것이 흥미로울 수 있습니다.

@kripken 불행히도 LLVM은 아직 구조화를 취소할 수 없는 것 같습니다. 점프 스레딩 최적화 단계에서 이를 수행할 수 있어야 하지만 아직 이 패턴을 인식하지 못합니다. 다음은 relooper 알고리즘이 CFG를 루프+스위치로 변환하는 방법을 모방하는 일부 C++ 코드를 보여주는 예입니다. GCC는 "deloop"을 관리하지만 clang은 그렇지 않습니다. https://godbolt.org/z/GGM9rP

@AndrewScheidecker 흥미

@comex

SpiderMonkey의 기준 컴파일러는 단지 하나의 구현일 뿐이며 레지스터 할당과 관련하여 차선책일 가능성이 있습니다. 즉, 조금만 더 똑똑했다면 런타임 이점이 컴파일 시간 비용보다 클 것입니다.

레지스터 할당에 대해 분명히 더 똑똑할 수 있습니다. 제어 흐름 포크, 조인 및 호출 전에서 무분별하게 유출되고 레지스터 상태에 대한 추가 정보를 유지하고 레지스터에 값을 더 오래 유지하려고 시도할 수 있습니다/죽을 때까지. 블록의 값 결과에 대해 rax보다 더 나은 레지스터를 선택하거나 고정 레지스터를 사용하지 않는 것이 좋습니다. 지역 변수를 보유하기 위해 두 개의 레지스터를 정적으로 전용할 수 있습니다. 내가 한 말뭉치 분석에 따르면 소수의 정수와 FP 레지스터가 대부분의 기능에 충분할 것이라고 제안했습니다. 일반적으로 흘리는 것이 더 현명할 수 있습니다. 있는 그대로 레지스터가 부족할 때 모든 것을 공황 상태로 빠뜨립니다.

이것의 컴파일 시간 비용은 주로 각 제어 흐름 에지와 관련하여 일정하지 않은 양의 정보(레지스터 상태)를 갖게 되며 이는 기본 컴파일러가 가지고 있는 동적 저장소 할당의 더 널리 퍼진 사용으로 이어질 수 있습니다. 멀리 피했다. 물론 각 조인(및 기타 위치)에서 가변 크기 정보를 처리하는 데 드는 비용이 있습니다. 그러나 스필 코드를 생성하기 위해 레지스터 상태를 통과해야 하기 때문에 일정하지 않은 비용이 이미 존재하고 대체로 라이브 값이 거의 없을 수 있으므로 이것이 괜찮을 수도 있고 아닐 수도 있습니다. 물론 regalloc을 사용하여 더 똑똑해지는 것은 빠른 캐시와 ooo 실행으로 최신 칩에서 성과를 낼 수도 있고 그렇지 않을 수도 있습니다...

더 미묘한 비용은 컴파일러의 유지 관리 가능성입니다... 이미 상당히 복잡하고 원 패스이며 IR 그래프를 작성하거나 동적 메모리를 전혀 사용하지 않기 때문에 계층화 및 추상화에 저항합니다.

@RossTate

Re funclet / gotos, 나는 요전에 funclet 사양을 훑어보았고 언뜻 보기에 1 패스 컴파일러는 단순한 regalloc 체계가 아닌 실제로 문제가 없어야 하는 것처럼 보이지 않았습니다. 그러나 더 나은 체계를 사용하더라도 괜찮을 수 있습니다. 결합 지점에 도달하는 첫 번째 가장자리는 레지스터 할당이 무엇인지 결정하고 다른 가장자리는 일치해야 합니다.

@conrad-watt CG 회의에서 방금 언급했듯이 다중 루프가 어떻게 생겼는지에 대한 세부 정보를 보는 데 매우 관심이 있을 것입니다.

@aardappel 예, 인생이 빨리 찾아왔지만 다음 회의에서는 이것을 해야 합니다. @rossberg가 원래

유익할 수 있는 참조 중 하나는 일종의 구식이지만 DJ 그래프를 사용하여 환원 불가능한 루프를 처리하기 위해 익숙한 루프 개념을 일반화

우리는 CG에서 이에 대해 몇 차례 토론 세션을 가졌으며 요약 및 후속 문서를 작성했습니다. 길이 때문에 나는 그것을 별도의 요점으로 만들었습니다.

https://gist.github.com/conrad-watt/6a620cb8b7d8f0191296e3eb24dffdef

즉시 실행 가능한 두 가지 질문은 다음과 같습니다(자세한 내용은 후속 섹션 참조).

• 현재 어려움을 겪고 있고 성능 면에서 multiloop 도움이 되는 "야생" 프로그램을 찾을 수 있습니까? 이는 LLVM 변환이 소스 프로그램에 존재하지 않더라도 환원 불가능한 제어 흐름을 도입하는 프로그램일 수 있습니다.
• multiloop 가 "웹" Wasm에 대한 링크/번역 배포 계층과 함께 생산자 측에서 먼저 구현되는 세상이 있습니까?

내가 후속 문서에서 논의하는 예외 처리 문제의 결과에 대해 더 자유로운 토론이 있을 것이며, 물론 우리가 구체적인 내용으로 나아가면 의미론적 세부 사항에 대한 표준 자전거 공유가 있을 것입니다.

이러한 논의는 다소 분기될 수 있으므로, 그 중 일부를 funclet 저장소의 문제로

이 문제에 대한 진전을 보게 되어 매우 기쁩니다. 관련된 모든 분들께 큰 "고맙습니다!"

현재 어려움을 겪고 있고 멀티루프에서 성능면에서 이점이 있는 "야생" 프로그램을 찾을 수 있습니까? 이는 LLVM 변환이 소스 프로그램에 존재하지 않더라도 환원 불가능한 제어 흐름을 도입하는 프로그램일 수 있습니다.

순환 추론에 대해 약간 주의하고 싶습니다. 현재 성능이 좋지 않은 프로그램은 바로 이러한 이유로 "야생에서" 발생할 가능성이 적습니다.

나는 대부분의 바둑 프로그램이 많은 이점을 얻을 것이라고 생각합니다. Go 컴파일러는 Go의 고루틴을 지원하는 효율적인 코드를 내보내려면 WebAssembly 코루틴 또는 multiloop 가 필요합니다.

미리 컴파일된 정규식 매처는 다른 미리 컴파일된 상태 시스템과 함께 제어 흐름을 축소할 수 있는 결과를 낳습니다. 인터페이스 유형에 대한 "융합" 알고리즘이 제어 흐름을 감소시킬 수 있는지 여부를 말하기는 어렵습니다.

• 이 토론을 funclets(또는 새) 리포지토리의 문제로 옮겨야 한다는 데 동의합니다.
• LLVM(및 Go 및 기타)이 실제로 가장 최적의 제어 흐름(환원 불가능할 수 있음)을 방출하지 않고는 이를 통해 이익을 얻을 수 있는 프로그램을 찾는 것이 정량화하기 어렵다는 데 동의합니다. FixIrreducibleControlFlow 및 친구로 인해 발생하는 비효율성은 대규모 바이너리에서 "1000 컷으로 사망" 문제일 수 있습니다.
• 나는 이 논의에서 나오는 절대적인 최소 진행으로 도구 전용 구현을 환영하지만, 생산자는 이제 편리함을 위해 이 기능을 사용하는 어려운 선택을 하기 때문에 여전히 최적이 아닐 것입니다(그러나 예측할 수 없는 성능 회귀/ 절벽), 또는 예측 가능한 결과를 얻기 위해 출력을 표준 wasm으로 랭글링하기 위해 열심히 노력하십시오.
• "gotos"가 기껏해야 도구 전용 기능이라고 결정되면 멀티루프보다 훨씬 더 간단한 기능으로 벗어날 수 있다고 주장합니다. 절대적으로 최소한 goto <function_byte_offset> 는 WABT 또는 Binaryen이 합법적인 Wasm으로 변환할 수 있도록 일반 Wasm 함수 본체에 삽입해야 하는 유일한 것입니다. 유형 서명과 같은 것은 엔진이 다중 루프를 빠르게 확인해야 하는 경우에 유용하지만, 편리한 도구인 경우 방출하는 것이 최대한 편리할 수 있습니다.

LLVM(및 Go 및 기타)이 실제로 가장 최적의 제어 흐름(환원 불가능할 수 있음)을 방출하지 않고는 이를 통해 이익을 얻을 수 있는 프로그램을 찾는 것이 정량화하기 어렵다는 데 동의합니다.

수정된 도구 체인 + VM에서 테스트하는 것이 최적이라는 데 동의합니다. 그러나 현재 wasm 빌드를 최적의 제어 흐름을 가진 기본 빌드와 비교할 수 있습니다. Not So Fast 와 다른 사람들은 이를 다양한 방식(성능 카운터, 직접 조사)으로 살펴보았지만 환원할 수 없는 제어 흐름이 중요한 요소라는 것을 발견하지 못했습니다.

더 구체적으로 말하면 C/C++에서 중요한 요소로 인식되지 않았습니다. 이는 환원 불가능한 제어 흐름의 성능보다 C/C++와 더 관련이 있을 수 있습니다. (솔직히 잘 모르겠습니다.) @neelance 가 Go에서도 마찬가지가 아닐 것이라고 믿을 만한 이유가 있는 것 같습니다.

내 생각에 이 문제에는 여러 측면이 있으며 여러 방향을 통해 문제를 해결하는 것이 좋습니다.

첫째, WebAssembly의 생성 가능성에 일반적인 문제가 있는 것처럼 들립니다. 그 대부분은 효율적인 유형 검사 및 스트리밍 컴파일을 포함하는 컴팩트 바이너리를 갖는 WebAssembly의 제약으로 인해 발생합니다. 생성하기 더 쉽지만 "진정한" WebAssembly로의 번역이 보장되는 표준화된 "사전"-WebAssembly를 개발함으로써 이 문제를 적어도 부분적으로 해결할 수 있습니다. 그러한 번역을 제공하는 적어도 일부 도구와 함께.

둘째, "진정한" WebAssembly에 직접 통합할 가치가 있는 "pre"-WebAssembly의 기능을 고려할 수 있습니다. "진정한" WebAssembly 모듈로 변형 되기 전에 분석할 수 있는 "사전"-WebAssembly 모듈이 있기 때문에 정보에 입각한 방식으로 이 작업을 수행할 수 있습니다.

몇 년 전에 동적 언어(https://github.com/ciao-lang/ciao)에 대한 특정 바이트 코드 에뮬레이터를 웹 어셈블리로 컴파일하려고 시도했지만 성능이 최적이 아니었습니다(때로는 기본 버전보다 10배 느림). 주 실행 루프에는 큰 바이트코드 디스패치 스위치가 포함되어 있으며 엔진은 실제 하드웨어에서 실행되도록 수십 년 동안 미세 조정되었으며 레이블과 goto를 많이 사용합니다. 이러한 종류의 소프트웨어가 환원 불가능한 제어 흐름을 지원함으로써 이점을 얻을 수 있는지 아니면 문제가 다른 문제인지 궁금합니다. 추가 조사를 할 시간이 없었지만 상황이 개선된 것으로 알려지면 다시 시도하고 싶습니다. 물론 다른 언어 VM을 wasm으로 컴파일하는 것이 주요 사용 사례가 아니라는 점을 이해하지만, 특히 어디서나 효율적으로 실행되는 범용 바이너리가 약속된 이점 중 하나이기 때문에 이것이 결국 실현 가능한지 알고 싶습니다. wasm. (이 특정 주제가 다른 문제에서 논의된 경우 감사합니다.)

@jfmc 내 이해는 프로그램이 현실적이고(즉, 병리학적이 되기 위해 고안된 것이 아님) 성능에 관심이 있다면 완벽하게 유효한 사용 사례라는 것입니다. WebAssembly는 좋은 범용 타겟을 목표로 합니다. 따라서 왜 그렇게 심각한 둔화가 발생했는지 이해하는 것이 좋을 것입니다. 그것이 제어 흐름에 대한 제한으로 인해 발생하는 경우 이 논의에서 아는 것이 매우 유용할 것입니다. 다른 문제로 인해 발생하는 경우 일반적으로 WebAssembly를 개선하는 방법을 아는 것이 여전히 유용합니다.