Design: 제안: 언어 간 유형 바인딩 추가

이것은 정말 흥미 롭습니다! 나는 빨리 읽었을 뿐이며 몇 가지 초기 생각이 있지만 가장 중요한 질문은 대부분의 언어가 이미 제공/사용하는 기존 FFI 메커니즘이 WebAssembly에 충분하지 않은 이유를 묻는 것입니다. 내가 친숙한 거의 모든 언어에는 C FFI 형식이 있으므로 오늘날에도 이미 상호 운용할 수 있습니다. 이러한 언어 중 상당수는 이러한 바인딩을 기반으로 정적 유형 검사도 수행할 수 있습니다. 게다가 이미 이러한 인터페이스에 대한 많은 도구가 있습니다(예: Rust의 경우 bindgen crate, Erlang/BEAM의 경우 erl_nif 등). C FFI는 이미 가장 중요한 요구 사항을 다루고 있으며 이미 입증되고 실제로 널리 사용되는 주요 이점이 있습니다.

5 - 메모리 레이아웃 간의 브리지

이상적인 유형 시스템은 의미론적 유형을 표현해야 하며 언어가 메모리에서 이를 해석하는 방법을 결정하도록 해야 합니다. 메모리 레이아웃이 호환되지 않는 언어 간에 데이터를 전달하면 항상 약간의 오버헤드가 발생하지만 유사한 언어 간에 데이터를 전달하는 것은 이상적으로 저렴해야 합니다(예: memcpy가 동일한 작업을 수행할 수 있는 경우 임베더는 직렬화-역직렬화 단계를 피해야 합니다).

의미 유형이 호환되는 한 두 모듈 간에 데이터를 전달할 때 변환 작업은 개발자에게 투명해야 합니다.

FFI 장벽을 통해 데이터를 전달할 때 한 레이아웃을 다른 레이아웃으로 투명하게 변환하는 것은 실제로 컴파일러 백엔드 또는 언어 런타임을 위한 작업처럼 보이며 C/C++/Rust/등과 같은 성능에 민감한 언어에서는 전혀 바람직하지 않을 수 있습니다. 특히, FFI를 통해 주고받을 계획인 경우 번역 비용이 너무 많이 들 수 있으므로 어떤 종류의 번역보다 공통 ABI를 사용하는 것이 항상 더 나은 것 같습니다. 플랫폼의 공통 ABI 이외의 레이아웃을 선택하는 이점은 그만한 가치가 없을 것 같지만 대체 레이아웃이 의미하는 바를 오해할 수 있음을 쉽게 인정합니다.

제쳐두고, 컴파일러/런타임에 견고한 FFI 도구의 부담을 가하는 것은 추가적인 이점이 있습니다. 모든 개선 사항은 다른 플랫폼에 적용 가능하고 반대의 경우도 마찬가지입니다. 저는 주장이 근본적으로 처음부터 시작하여 새로운 FFI 메커니즘을 구축하기 위해 정말 설득력이 있어야 한다고 생각합니다.

제안의 목적을 잘못 이해했거나 위에서 언급한 것처럼 중요한 것을 놓쳤다면 사과드립니다. 다시 한 번 더 자세히 읽어야 하지만 시간이 있는 동안 초기 질문을 제기해야 할 것 같았습니다.

Apache Arrow 도 이를 위해 존재하지만 고성능 애플리케이션에 더 중점을 둡니다.

나는 여기의 일반적인 동기에 동의하고 기본적으로 미래에 Web IDL 바인딩 을 일반화할 수 있는 방법에 대해 논의한 내용과 일치한다고 생각합니다. 실제로, 설명자의 초기 초안에는 이 언어 간 사용 사례를 언급하는 FAQ 항목이 포함되어 있습니다.

내 주요 관심사(그리고 그 FAQ 항목을 생략한 이유)는 범위입니다. N개 언어를 바인딩하는 일반적인 문제는 특히 아무도 이미 하고 있지 않다는 점을 감안할 때 많은 개방형(그리고 아마도 비종료형) 토론을 생성할 가능성이 있는 것 같습니다( 물론 닭과 달걀의 문제입니다.) 대조적으로, Web IDL Bindings에 의해 해결된 문제는 오늘날 Rust/C++에서 상당히 구체적이고 쉽게 입증되어 우리가 (사소하지 않은) 노력을 표준화/구현하고 제안된 솔루션의 프로토타입/검증에 대한 동기를 부여할 수 있습니다.

그러나 내 희망은 Web IDL 바인딩을 통해 우리가 이 닭과 달걀의 문제를 해결하고 Web IDL에 국한되지 않는 새로운 확장이나 바랍니다 . (현재 제안된 대로 호환 가능한 Web IDL 바인딩을 사용하는 두 개의 wasm 모듈이 서로를 호출하는 경우, Cap'n Proto의 완전한 표현 없이도 최적화 impl이 여기에서 언급한 최적화를 수행할 수 있습니다.)

나는 아직 그 제안을 완전히 받아들일 시간이 없었다는 것을 미리 말해야 합니다.
그 이유는 그 일이 불가능하다고 생각하기 때문입니다. 여기에는 두 가지 근본적인 이유가 있습니다.
NS. 다른 언어에는 유형 주석에서 반드시 캡처되지 않는 다른 의미 체계가 있습니다. 예를 들어, Prolog의 평가는 C++의 평가와 근본적으로 다릅니다. (Prolog의 경우 다른 여러 언어로 대체 가능)

NS. 정의에 따라 유형 시스템의 LCD는 지정된 언어의 모든 유형 언어를 캡처할 수 있다고 보장되지 않습니다. 이는 언어 구현자에게 매우 불편한 선택을 남깁니다. 자신의 언어를 지원하거나 해당 언어의 유형 시스템의 이점을 포기하는 것입니다. 사례: Haskell에는 '유형 클래스'가 있습니다. 유형 클래스를 지원하지 않는 것과 관련된 Haskell의 구현은 효과적으로 이를 내장하고 사용할 수 없게 만듭니다.
또 다른 예: C++에서 제네릭을 지원하려면 컴파일 타임에 제네릭을 제거해야 합니다. 반면에 ML, Java(및 기타 여러 언어)는 범용 표현 형식을 사용합니다. 이는 C++에서 사용하는 접근 방식과 호환되지 않습니다.

다른 한편으로 내보낸/가져온 유형의 두 표현식을 갖는 것은 자체 문제를 제기하는 것 같습니다. 언어 시스템은 두 표현식이 어떤 의미에서 일관성이 있는지 확인해야 합니까? 이 일을 하는 것은 누구의 책임입니까?

@lukewagner 링크 주셔서 감사합니다! 확실히 그 문서를 읽을 기회가 생겨서 기쁩니다!

이 특정 토론에는 두 가지가 혼합되어 있는 것 같습니다. 아래 내용 중 일부는 내가 이해한 내용을 다시 확인할 수 있도록 작성되었으므로 내가 오해하거나 놓친 부분이 있으면 자유롭게 지적해 주십시오.

1. 효율적인 호스트 바인딩
   
   
   
   • 기본적으로 WebIDL은 적어도 브라우저 환경에 대해 해결하기 위한 것입니다. 모듈->호스트 및 호스트->모듈에서 매핑되는 인터페이스 설명은 기본적으로 하나에서 다른 것으로 번역 작업을 호스트 엔진으로 위임합니다. 이 번역이 반드시 이상적이거나 최적화된 것은 아니지만 최적화 엔진에서 이를 사용할 수 있습니다. 그러나 최적화된 경우에도 번역은 여전히 ​​어느 정도 수행되지만 대안은 여전히 ​​번역이고 속도가 느리기 때문에 허용됩니다.
   
   
2. 효율적인 이기종 모듈 간 바인딩.
   
   
   
   • 즉, source 작성된 모듈과 dest 작성된 두 모듈이 주어지면 소스->dest 및/또는 dest->source에서 호출하여 서로 유형을 공유합니다.
   
   
   • 공통 FFI를 사용할 수 없고 WebIDL과 같은 것이 주어지면(예: source type -> common type -> dest type 언어 장벽을 넘어 호출할 때 호스트 환경에서 제공하는 일부 공통 분모 유형을 통해 최적화되지 않은 경로가 제공됩니다. .
     
     
     
     
     
     • 최적화 엔진은 이론적으로 이 번역을 중개 없이 source 에서 dest 로 직접 만들 수 있지만 여전히 번역 오버헤드를 부과합니다.
     
     
     
   
   
   • 공통 FFI를 사용할 수 있는 경우(예: source 및 dest 가 ABI(예: C ABI)를 공유하면 source 및 dest 가 다음을 사용하여 서로 직접 호출할 수 있습니다. FFI를 통해 오버헤드가 전혀 없습니다. 이것은 아마도 실제로 가장 가능성이 높은 시나리오일 것입니다.
   
   

따라서 내 생각은 WebIDL 또는 이와 유사한 것(즉, 광범위한 호스트 API/환경 세트를 지원하는 상위 세트)을 활용하면 확실히 이점이 있지만 실제로는 1에 설명된 문제에 대한 솔루션일 뿐이며 하위 집합입니다. FFI를 사용할 수 없는 언어 간 바인딩을 처리하는 2개 중. FFI를 사용할 수 있는 2의 하위 집합은 그 자체로 오버헤드가 발생하지 않기 때문에 대안보다 분명히 선호됩니다.

FFI가 옵션인 경우에도 IDL을 사용해야 하는 타당한 이유가 있습니까? 분명히 말해서, 나는 언급된 다른 사용 사례에 대해 IDL을 사용하는 데 확실히 동의하지만 특히 호스트 바인딩이 아니라 언어 상호 운용성의 맥락에서 묻고 있습니다.

C FFI(예: 가장 일반적이기 때문에)와 IDL이 동시에 사용/존재하는 경우 몇 가지 추가 질문이 있습니다.

• source 및 dest 언어가 공통 ABI에 따라 동일한 기본 메모리 내 표현을 사용하여 공유 유형에 대해 다른 유형 정의를 제공하는 경우(예: 가변 길이 배열에 대한 공통 표현 ) - 호스트 엔진이 표준 FFI를 사용하여 서로 안전하게 호출할 수 있음에도 불구하고 IDL 지시문이 있다는 이유만으로 이러한 유형 간에 변환을 수행하려고 합니까?
  
  
  
  • 그렇지 않고 옵트인인 경우 FFI가 없는 언어와의 상호 운용성을 지원하는 IDL을 추가하는 동시에 FFI가 있는 언어를 지원할 수 있기 때문에 이상적인 시나리오처럼 보입니다. 호스트 엔진이 어떻게 작동하는지 잘 모르겠습니다. 완전히 생각하지 않았기 때문에 아마도 뭔가를 놓치고있을 것입니다.
  
  
  • 그렇다면 호스트 엔진은 유형을 어떻게 통합합니까?:
    
    
    
    
    
    • 엔진이 레이아웃에만 관심이 있는 경우 호출자가 호출 수신자에게 잘못된 인수 유형을 제공할 때 정적 분석이 어떻게 감지할 수 있습니까? 그런 종류의 분석이 목표가 아니라면 IDL은 실제로 호스트 바인딩에 이상적으로 적합하고 언어 간에는 덜 적합합니다.
    
    
    
    • 엔진이 레이아웃보다 더 많은 것을 고려한다면, 다시 말해서 유형 시스템은 명목상 및 구조적 호환성을 모두 필요로 합니다.
      
      
      
      
      
      
      
      • 일부 기능에 대한 권한 유형을 정의하는 사람은 누구입니까? 일부 언어에서 권위 있는 유형을 어떻게 참조합니까? 예를 들어, add/2 함수를 정의하는 다른 언어로 작성된 공유 라이브러리를 호출하고 있고 add/2 size_t 유형의 두 인수를 예상한다고 가정해 보겠습니다. 내 언어는 명목상 size_t 에 대해 반드시 알지는 못하지만, 기계 너비의 부호 없는 정수에 대한 자체 ABI 호환 표현인 usize 가 있으므로 내 언어의 해당 기능에 대한 FFI 바인딩은 내 언어를 사용합니다. 언어 유형. 이를 감안할 때 내 컴파일러는 usize 를 size_t 매핑하는 IDL을 생성하는 방법을 알 수 있습니다.
      
      
      
      
    
    
    
  
  
• FFI를 사용할 수 있지만 IDL 설명 인터페이스를 위해 명시적으로 사용하지 않는 프로그램의 모듈 간에 호출하는 데 사용되는 IDL 인터페이스의 예가 있습니까? 특히 WebAssembly가 아닌 것으로, 이러한 경우의 이점을 연구하는 데 주로 관심이 있습니다.

나는 여전히 WebIDL과 그 전임자의 전체 세부 사항을 파헤치려고 노력하고 있음을 인정할 것입니다. 이 모든 것이 다른 호스트(브라우저 대 비 브라우저)에 어떻게 들어맞는지 등입니다. 내가 간과했다면 확실히 알려주십시오. 무엇.

@bitwalker

이것은 정말 흥미 롭습니다!

네가 좋다 니 기쁘다!

그러나 제 첫 번째이자 가장 중요한 질문은 대부분의 언어가 이미 제공/사용하는 기존 FFI 메커니즘이 WebAssembly에 충분하지 않은 이유를 묻는 것입니다.

C 유형 시스템은 언어 간 IDL로 몇 가지 문제가 있습니다.

• WebAssembly에서 안전하지 않고 의도적으로 보유하지 않는 공유 주소 공간을 가정하여 작동합니다. (JS-to-C FFI에 대한 내 자신의 경험에 따르면 구현은 속도와 안전을 거래하는 경향이 있음)

• 동적 길이 배열, 태그가 지정된 공용체, 기본값, 제네릭 등에 대한 기본 지원이 없습니다.

• 참조 유형에 직접적으로 해당하는 것은 없습니다.

C++는 이러한 문제 중 일부(가장 큰 문제인 공유 주소 공간이 아님)를 해결하지만 IPC에서 실제로 유용하지 않은 많은 개념을 추가합니다. 물론, 항상 C의 상위 집합이나 C++의 하위 집합을 IDL로 사용하고 이에 대한 바인딩 규칙을 고안할 수 있지만 그 시점에서 기존 코드의 이점을 거의 얻지 못하므로 기존 코드를 사용할 수도 있습니다. IDL.

특히 FFI에서 앞뒤로 전달할 계획인 경우

나는 당신이 그것을 의미하는 방법이 정확하지 않지만 명확하게: 나는 모듈 사이에서 변경 가능한 데이터를 앞뒤로 전달하는 것이 일반적인 경우에 가능하다고 생각하지 않습니다. 이 제안은 다른 모듈이 데이터를 저장하는 방법에 대한 정보가 없는 모듈 간에 변경할 수 없는 데이터를 보내고 그 대가로 변경할 수 없는 데이터를 얻는 방법을 설명하려고 합니다.

플랫폼의 공통 ABI 이외의 레이아웃을 선택하는 이점은 그만한 가치가 없을 것 같지만 대체 레이아웃이 의미하는 바를 오해할 수 있음을 쉽게 인정합니다.

문제는 현재 일반적인 ABI가 선형 메모리에 저장된 바이트 조각이라는 것입니다. 그러나 미래에 GC 제안이 구현되면 일부 언어(Java, C#, Python)는 선형 메모리에 거의 저장하지 않거나 전혀 저장하지 않을 것입니다. 대신 모든 데이터를 GC 구조에 저장합니다. 이러한 언어 중 2개가 통신을 시도하는 경우 이러한 구조를 바이트 스트림으로 직렬화하여 즉시 역직렬화하는 것은 불필요한 오버헤드가 될 것입니다.

@KronicDeth 감사합니다. 조사하겠습니다.

문서 훑어보기에서 이것은 특히 성능 향상을 위한 Flatbuffer의 상위 집합인 것처럼 보입니다. 어느 쪽이든, Flatbuffers 또는 Capnproto와 비교하여 WebAssembly 모듈 상호 운용성을 고유하게 도울 수 있는 특성은 무엇입니까?

@lukewagner

그러나 제 희망은 Web IDL 바인딩을 통해 우리가 이 닭과 계란의 문제를 해결하고 Web IDL에 국한되지 않고 새로운 확장의 물결을 일으킬 수 있는 언어 간 바인딩에 대한 경험을 얻을 수 있다는 것입니다.

동의. 이 제안을 작성할 때의 가정은 모든 capnproto 바인딩 구현이 WebIDL 제안 구현의 피드백을 기반으로 한다는 것이었습니다.

내 주요 관심사(그리고 그 FAQ 항목을 생략한 이유)는 범위입니다. N개 언어를 바인딩하는 일반적인 문제는 특히 아무도 이미 하고 있지 않다는 점을 감안할 때 많은 개방형(그리고 아마도 비종료형) 토론을 생성할 가능성이 있는 것 같습니다( 물론 닭과 달걀의 문제입니다.)

저는 capnproto 구현에 대해 논의하는 것이 이 초기에도 가치가 있다고 생각합니다.

특히 구현이 충족해야 하거나 시도할 수 있는 요구 사항을 간략하게 설명하려고 했습니다. 언어 간 유형 시스템이 해결하려고 할 수 있는 일반적인 사용 사례를 나열하는 것도 유용할 것이라고 생각합니다.

N-to-N 문제와 관련하여 다음 솔루션에 중점을 두고 있습니다.

• RPC 스타일 데이터 전송에 대해서만 걱정하십시오. "벡터에는 'x', 'y' 및 'z'라는 세 개의 필드가 있으며 모두 부동 소수점입니다.

• 언어 및 사용 사례를 데이터 처리 전략의 "클러스터"로 그룹화하십시오. 이러한 클러스터의 중심에 전략을 수립합니다. 언어 컴파일러는 주어진 전략에 바인딩하고 인터프리터는 나머지 NxN 작업을 수행합니다.

@fgmccabe

그 이유는 그 일이 불가능하다고 생각하기 때문입니다. 여기에는 두 가지 근본적인 이유가 있습니다.
NS. 다른 언어에는 유형 주석에서 반드시 캡처되지 않는 다른 의미 체계가 있습니다. 예를 들어, Prolog의 평가는 C++의 평가와 근본적으로 다릅니다. (Prolog의 경우 다른 여러 언어로 대체 가능)

유형 클래스를 지원하지 않는 것과 관련된 Haskell의 구현은 효과적으로 이를 내장하고 사용할 수 없게 만듭니다.

예, 아이디어는 완벽한 "모든 언어와 쉽게 호환되는" 추상화를 정의하는 것이 아닙니다.

즉, 대부분의 언어는 데이터를 구조화하는 방식에서 약간의 유사점이 있다고 생각합니다(예: "모든 사람에게는 이름, 이메일 및 나이가 있습니다" 또는 "모든 그룹에는 사람 목록이 있습니다. 임의의 크기").

이러한 유사성을 활용하여 모듈 간의 마찰을 크게 줄이는 것이 가능하다고 생각합니다. (lukewagner에 대한 내 대답도 참조하십시오)

NS. 정의에 따라 유형 시스템의 LCD는 지정된 언어의 모든 유형 언어를 캡처할 수 있다고 보장되지 않습니다. 이는 언어 구현자에게 매우 불편한 선택을 남깁니다. 자신의 언어를 지원하거나 해당 언어의 유형 시스템의 이점을 포기하는 것입니다.

응. 여기에서 경험적 규칙은 "공유 라이브러리 경계인 경우 capnproto 유형으로 만들고 그렇지 않으면 기본 유형을 사용하십시오"라고 생각합니다.

다른 한편으로 내보낸/가져온 유형의 두 표현식을 갖는 것은 자체 문제를 제기하는 것 같습니다. 언어 시스템은 두 표현식이 어떤 의미에서 일관성이 있는지 확인해야 합니까? 이 일을 하는 것은 누구의 책임입니까?

예, 처음에는 불변 검사에 대한 섹션과 유형 호환성에 대한 섹션을 포함하고 싶었지만 용기를 잃었습니다.

"누구의 책임인지"에 대한 대답은 일반적으로 "수신자"입니다(그들은 수신한 모든 데이터가 의심스러운 것으로 가정해야 하기 때문에). 그러나 인터프리터가 호출자가 유형 불변성을 존중한다는 것을 증명할 수 있는 경우 검사를 생략할 수 있습니다.

C형 시스템은 언어간 IDL로서 몇 가지 문제가 있습니다.

분명히 하기 위해 IDL로 제안하지 않습니다. 오히려 저는 바이너리 인터페이스(C ABI)가 이미 존재하고, 잘 정의되어 있으며, 이미 광범위한 언어 지원을 가지고 있다고 제안하고 있습니다. 그렇다면 해결되는 문제가 언어 간 상호 운용성을 넘어서지 않는 한 WebAssembly가 다른 솔루션을 제공할 필요가 없다는 의미입니다.

WebAssembly에서 안전하지 않고 의도적으로 보유하지 않는 공유 주소 공간을 가정하여 작동합니다.

그래서 저는 여기서 오해의 일부를 본 것 같아요. 여기서 말하는 FFI에는 두 가지 클래스가 있습니다. 하나는 선형 메모리를 공유하는 것(보다 전통적인 공유 메모리 FFI)이고 다른 하나는 그렇지 않습니다(보다 전통적인 IPC/RPC). 나는 전자에 대해 이야기했고, 나는 당신이 후자에 더 초점을 맞춘다고 생각합니다.

모듈을 제어할 때 모듈 간에 메모리를 공유하는 것이(전체 애플리케이션의 일부로 여러 독립 모듈을 함께 연결하는 경우와 같이) 효율성을 위해서는 바람직하지만 보안이 희생됩니다. 반면에 FFI를 위해 특별히 지정된 선형 메모리를 공유하는 것이 가능하지만 오늘날 기본 도구로 얼마나 실용적인지는 모르겠습니다.

공유 메모리 FFI, 즉 IPC/RPC를 _사용하지 않는_ 모듈 간 상호 운용성은 WebIDL, capnproto 또는 그 맥락에서 다른 제안 중 하나와 확실히 잘 맞는 것처럼 보입니다. 왜냐하면 그것이 그들의 빵과 버터이기 때문입니다.

내가 확신할 수 없는 부분은 어느 쪽의 이점도 희생하지 않는 방식으로 두 범주를 혼합하는 방법입니다. 한 쪽 또는 다른 쪽을 선택하는 것은 사용 사례에 크게 의존하기 때문입니다. 적어도 명시된 바와 같이 우리는 둘 중 하나만 가질 수 있는 것 같습니다. 둘 다 지원할 수 있다면 이상적일 것이라고 생각합니다.

동적 길이 배열, 태그가 지정된 공용체, 기본값, 제네릭 등에 대한 기본 지원이 없습니다.

나는 이것이 아마도 우리가 두 가지 다른 것에 대해 이야기하고 있다는 것을 깨달았기 때문에 관련이 없다고 생각하지만, 후손을 위해: ABI에는 확실히 가변 길이 배열과 태그가 있는 공용체에 대한 _representation_이 있지만 C에는 다음이 있습니다. 약한 유형 시스템, 그러나 그것은 실제로 요점이 아닙니다. 언어는 C 유형 시스템에 대해 C FFI를 대상으로 하지 않습니다. C ABI가 유용한 이유는 언어가 상호 작용하는 유형 시스템에 대한 개념이 없는 다른 언어와 통신하는 데 사용할 수 있는 공통 분모를 제공하기 때문입니다. 더 높은 수준의 유형 시스템 기능의 부족은 이상적이지 않으며 FFI를 통해 표현할 수 있는 것의 종류를 제한하지만 제한은 또한 그것이 하는 일에서 매우 성공적인 이유의 일부이기도 합니다. 거의 모든 언어가 방법을 찾을 수 있습니다. 해당 인터페이스를 통해 노출된 것을 나타내거나 그 반대의 경우도 마찬가지입니다.

C++는 이러한 문제 중 일부(가장 큰 문제인 공유 주소 공간이 아님)를 해결하지만 IPC에서 실제로 유용하지 않은 많은 개념을 추가합니다. 물론, 항상 C의 상위 집합이나 C++의 하위 집합을 IDL로 사용하고 이에 대한 바인딩 규칙을 고안할 수 있지만 그 시점에서 기존 코드의 이점을 거의 얻지 못하므로 기존 코드를 사용할 수도 있습니다. IDL.

동의합니다. IPC/RPC의 경우 C는 인터페이스를 정의하는 데 끔찍한 언어입니다.

문제는 현재 일반적인 ABI가 선형 메모리에 저장된 바이트 조각이라는 것입니다.

그것은 확실히 우리가 작업하고 있는 원시적이지만 C ABI는 그 위에 많은 것을 정의합니다.

그러나 미래에 GC 제안이 구현되면 일부 언어(Java, C#, Python)는 선형 메모리에 거의 저장하지 않거나 전혀 저장하지 않을 것입니다. 대신 모든 데이터를 GC 구조에 저장합니다. 이러한 언어 중 2개가 통신을 시도하는 경우 이러한 구조를 바이트 스트림으로 직렬화하여 즉시 역직렬화하는 것은 불필요한 오버헤드가 될 것입니다.

나는 그 언어들이 GC를 호스트로 미루는 것을 뛰어넘을 것이라고 확신하지 못하지만 그것은 단지 내 추측일 뿐입니다. 어쨌든 호스트 GC 관리 구조를 이해하는 언어는 capnproto를 사용하여 표현할 수 있는 것처럼 쉽게 CA ABI를 사용하여 해당 구조에 대한 공통 표현을 결정할 수 있습니다. 유일한 차이점은 해당 표현의 사양이 어디에 있는지입니다. 그렇긴 하지만, 나는 GC 제안의 세부 사항과 그것이 호스트 바인딩 제안과 어떻게 연결되는지에 대해 아주 미약하게 이해하고 있습니다. 따라서 여기에서 내가 과도하게 벗어나더라도 자유롭게 무시해도 됩니다.

TL;DR: 공유 선형 메모리가 작동하지 않는 모듈 상호 운용성에 대해 동의한다고 생각합니다. 하지만 공유 메모리는 지원하는 _is_ 중요하다고 생각하고 C ABI는 기존 언어 지원으로 인해 해당 사용 사례에 가장 합리적인 선택입니다. 이 제안이 발전함에 따라 두 가지 모두를 지원할 수 있기를 바랍니다.

우리에게 필요한 것은 단순히 바이트 버퍼를 교환하는 최대한 효율적인 방법과 언어가 형식에 동의하는 방법입니다. 이것을 특정 직렬화 시스템에 고칠 필요는 없습니다. Cap'n Proto가 이 목적에 가장 적합하다면 wasm에 의해 위임되지 않고 유기적으로 공통 기본값으로 발생할 수 있습니다.

Cap'n Proto와 효율성이 비슷하지만 더 유연하고 더 널리 지원되는 FlatBuffers를 만들었

주어진 특정 사용 사례에서 이 두 가지 형식보다 선호될 수 있는 다른 형식이 많이 있습니다.

Cap'n Proto와 FlatBuffers는 모두 복사가 없고 임의 액세스가 가능하며 중첩 형식에서 효율적입니다(다른 형식으로 래핑된 형식이 래핑되지 않은 것보다 덜 효율적이지 않음을 의미함). 이는 언어 간을 위해 고려해야 할 실제 속성입니다. 의사 소통. "다음 바이트는 Cap'n Proto schema X"를 포함하여 버퍼에 대해 매우 정확한 바이트 레이아웃을 지정할 수 있는 IDL을 상상할 수 있습니다.

내가 미묘하게 자기 홍보를 하는 동안 스키마가 없는 FlatBuffers와 같은 FlexBuffers 에서 사람들을

@aardappel

우리에게 필요한 것은 단순히 바이트 버퍼를 교환하는 최대한 효율적인 방법과 언어가 형식에 동의하는 방법입니다. 이것을 특정 직렬화 시스템에 고칠 필요는 없습니다. Cap'n Proto가 이 목적에 가장 적합하다면 wasm에 의해 위임되지 않고 유기적으로 공통 기본값으로 발생할 수 있습니다.

나는 wasm이 다른 경쟁자들에게 하나의 표준을 부과하는 방법으로 사용되어서는 안 된다는 암시적인 요점을 이해하고, IDL이 선택되는 것에 개인적으로 무관심합니다.

즉, 모든 것이 끝나고 완료되면 고무는 어느 시점에서 도로를 만날 필요가 있습니다. wasm이 언어 간 통신을 용이하게 하려면(물론 모든 사람이 공유하는 가정은 아닙니다) "이 바이트가 숫자를 구성합니다" 이상을 표현할 수 있는 표준 형식이 필요합니다. 그 형식은 capnproto, C 구조, 플랫 버퍼 또는 wasm에 특정한 것이 될 수 있지만 @fgmccabe에 설명된 이유 때문에 동시에 이들 모두의 하위 집합이 될 수는 없습니다.

내가 미묘하게 자기 홍보를 하는 동안 스키마가 없는 FlatBuffers와 같은 FlexBuffers에서 사람들을 가리킬 수 있습니다. 그것은 동일한 바람직한 제로 카피, 랜덤 액세스 및 저렴한 중첩 속성을 가지고 있지만 JSON이 사용되는 방식과 유사하게 codegen을 수행하지 않고 스키마에 동의하지 않고도 언어가 통신할 수 있도록 합니다.

호소력이 있습니다. 라이브러리를 작성할 때 이것이 대부분의 시간 동안 원하는 것이 아니라고 생각합니다. (끔찍한 구문 분석 시간을 제외하고) JSON의 문제는 코드의 어딘가에 JSON 개체를 가져올 때 작성하면 데이터를 사용하기 전에 많은 살균 코드를 작성하게 된다는 것입니다. 예:

assert(myObj.foo);
assert(isJsonObject(myObj.foo));
assert(myObj.foo.bar);
assert(isString(myObj.foo.bar));
loadUrl(myObj.foo.bar);

그렇지 않으면 잠재적인 보안 취약점이 있습니다.

위의 6 - 컴파일 타임 오류 처리 도 참조하십시오.

@bitwalker

맞습니다. 공유 선형 메모리의 가능성을 고려하지 않았습니다. 저보다 웹어셈블리 디자인에 더 익숙한 사람( @lukewagner ?)이 얼마나 실현 가능한지, 그리고 이것이 모듈 간 호출을 달성하는 좋은 방법인지 논의하기 위해 필요합니다. 그것은 또한 wasm의 메모리 레이아웃에 의해 무효화되는 FFI가 의존하는 가정의 수에 달려 있습니다.

예를 들어, FFI는 호스트 언어가 C 라이브러리를 사용하고 네이티브 라이브러리에 malloc 함수에 대한 직접 액세스 권한을 부여한다는 사실에 자주 의존합니다. 두 개의 상호 의심스러운 모듈의 맥락에서 그 전략을 was로 얼마나 잘 번역할 수 있습니까?

Cap'n Proto의 창시자로서 이 스레드에 대해 말해야 할 것 같지만 이상하게도 제 의견이 별로 없다는 것을 발견했습니다. 흥미롭거나 그렇지 않을 수 있는 몇 가지 인접한 생각을 표현해 보겠습니다.

저는 JavaScript와 WASM을 실행하는 "서버리스" 환경인 Cloudflare Workers의 기술 책임자이기도 합니다.

우리는 작업자들이 서로 대화할 수 있는 프로토콜로 Cap'n Proto RPC 지원을 고려하고 있습니다. 현재 HTTP로 제한되어 있어 기준이 상당히 낮게 설정되어 있습니다. :)

워커에서 한 워커가 다른 워커를 호출할 때 동일한 프로세스에서도 동일한 시스템에서 둘 다 실행되는 경우가 매우 일반적입니다. 이러한 이유로 Cap'n Proto와 같은 무복사 직렬화는 이론적으로 물리적으로 공유될 수 있는 선형 메모리에서 작동하기 때문에 특히 WASM 작업자에게 많은 의미가 있습니다.

이것이 적합하다고 생각하는 잘 알려지지 않은 두 번째 이유는 RPC 시스템입니다. Cap'n Proto는 CapTP를 모델로 한 Promise 파이프라이닝이 포함된 전체 개체 기능 RPC 프로토콜을 제공합니다. 이를 통해 안전하고 성능이 뛰어난 방식으로 풍부한 개체 지향 상호 작용을 쉽게 표현할 수 있습니다. Cap'n Proto RPC는 단순한 지점 간 프로토콜이 아니라 네트워크로 연결된 여러 당사자 간의 상호 작용을 모델링하며 이는 꽤 큰 문제가 될 것입니다.

한편 WASM 랜드에서는 WASI가 기능 기반 API를 도입하고 있다. 여기에 흥미로운 "시너지"가 있을 수 있을 것 같습니다.

그렇긴 해도 Cap'n Proto의 몇 가지 설계 목표는 FFI의 특정 사용 사례에 적합하지 않을 수 있습니다.

• Cap'n Proto 메시지는 주소 공간 간에 전송 및 공유될 수 있도록 위치 독립적이고 연속되도록 설계되었습니다. 포인터는 상대적이며 메시지의 모든 개체는 연속 메모리 또는 최소한 적은 수의 세그먼트에 할당되어야 합니다. 이것은 네이티브 개체에 비해 사용 모델을 상당히 복잡하게 만듭니다. 동일한 선형 메모리 공간 내에서 FFI를 사용할 때 느슨한 힙 개체에 네이티브 포인터를 전달할 수 있으므로 이 오버헤드가 낭비됩니다.
• Cap'n Proto 메시지는 스키마를 몰라도 무손실로 개체와 하위 트리를 복사하는 기능을 포함하여 스키마 버전 간에 앞뒤로 호환되도록 설계되었습니다. 이를 위해서는 일부 라이트 유형 정보가 콘텐츠에 직접 저장되어야 하며, Cap'n Proto는 이를 모든 포인터에서 메타데이터로 인코딩합니다. FFI를 통해 통신하는 두 개의 모듈이 동시에 컴파일되면 이 메타데이터가 필요하지 않습니다.
• Cap'n Proto RPC의 약속 파이프라이닝, 경로 단축 및 순서 보장은 호출자와 호출 수신자 사이에 무시할 수 없는 대기 시간이 있을 때 의미가 있습니다. 단일 CPU의 FFI에는 이러한 대기 시간이 없습니다. 이 경우 약속 파이프라이닝 기계는 사이클을 낭비할 수 있습니다.

요컨대, 개별 샌드박스에 독립적으로 배포된 모듈이 서로 통신할 때 Cap'n Proto가 의미가 있다고 생각합니다. 그러나 단일 샌드박스에 동시에 배포된 모듈의 경우 이는 아마도 과잉입니다.

피드백을 주셔서 감사합니다!

포인터는 상대적이며 메시지의 모든 개체는 연속 메모리 또는 최소한 적은 수의 세그먼트에 할당되어야 합니다. 이것은 네이티브 개체에 비해 사용 모델을 상당히 복잡하게 만듭니다. 동일한 선형 메모리 공간 내에서 FFI를 사용할 때 느슨한 힙 개체에 네이티브 포인터를 전달할 수 있으므로 이 오버헤드가 낭비됩니다.

공유 선형 메모리 접근 방식이 wasm에 얼마나 실현 가능한지 모르겠습니다(위 참조).

즉, 어느 쪽이든 상대 포인터의 오버헤드가 그렇게 나쁘지 않을 것이라고 생각합니다. WebAssembly는 이미 선형 메모리 시작과 관련된 오프셋을 사용하고 구현에는 대부분의 경우 ADD 명령어를 최적화하는 트릭이 있으므로(내 생각에) 상대 포인터를 사용하는 오버헤드도 최적화될 수 있습니다.

Cap'n Proto 메시지는 스키마를 몰라도 무손실로 개체와 하위 트리를 복사하는 기능을 포함하여 스키마 버전 간에 앞뒤로 호환되도록 설계되었습니다. [...] FFI를 통해 통신하는 두 개의 모듈이 동시에 컴파일되면 이 메타데이터가 필요하지 않습니다.

나는 그것이 사실이 아니라고 생각합니다. 모듈이 경계에서 이전 버전과 호환되는 유형을 정의하는 방법을 사용하면 wasm이 종속성 트리 모델을 사용할 수 있으며 대부분 Haskell의 종속성 다이아몬드 문제를 피할 수 있습니다.

무의미한 오버헤드의 더 큰 원인은 capnproto xor 가 기본값에 대해 변수를 사용하는 방식입니다. 이는 0바이트가 압축될 때 유용하지만 제로 복사 워크플로에서는 비생산적입니다.

공유 선형 메모리 접근 방식이 wasm에 얼마나 실현 가능한지 모르겠습니다(위 참조).

아, TBH 토론의 그 부분을 따를 충분한 맥락이 없다고 생각합니다. 공유 주소 공간이 없다면 예, Cap'n Proto가 많은 의미를 갖기 시작합니다.

이와 같은 형식을 디자인하는 방법에 대한 조언을 제공하게 되어 기쁩니다. FWIW 오늘날 이미 존재하는 앱과의 호환성에 대해 신경 쓰지 않는다면 Cap'n Proto에서 변경할 몇 가지 사항이 있습니다. 하지만 대부분은 낮은 수준의 포인터 인코딩 세부 정보와 같습니다.

무의미한 오버헤드의 더 큰 원인은 capnproto가 기본값에 대해 변수를 xor하는 방식입니다. 이는 0바이트가 압축될 때 유용하지만 제로 복사 워크플로에서는 비생산적입니다.

주제에서 조금 벗어나지만 XOR은 복사가 없는 경우에도 오버헤드가 아니라 최적화입니다. 그것은 모든 구조가 0으로 초기화된다는 것을 보장합니다. 즉, 버퍼가 이미 0인 경우(종종 어쨌든 그럴 수 있음) 객체 할당에 대한 초기화를 수행할 필요가 없습니다. 컴파일 시간 상수에 대한 XOR은 아마도 1사이클의 비용이 들지만 모든 종류의 메모리 액세스는 훨씬 더 많은 비용이 듭니다.

@lukewagner "선형 메모리 공유" 부분에 대한 생각이

선형 메모리를 공유하거나 공유하지 않는 경우 모두 사용 사례가 있으며 궁극적으로 도구는 다음 두 가지를 모두 지원해야 한다고 생각합니다.

오늘날 기본 앱이 정적 또는 동적 연결을 사용하는 경우 공유는 의미가 있습니다. 결합되는 모든 코드가 완전히 신뢰할 수 있고 해당 조합이 모두 동일한 도구 체인을 사용하거나 엄격하게 정의된 ABI를 사용하는 경우입니다. 그러나 더 취약한 소프트웨어 구성 모델입니다.

메모리를 공유하지 않는 것은 고전적인 Unix 스타일 디자인이 코드를 파이프로 연결된 별도의 프로세스에 넣는 보다 느슨하게 결합된 모듈 컬렉션에 적합합니다. 개인적으로 저는 이것이 보다 구성적인 소프트웨어 생태계를 위한 더 흥미롭고 미래 지향적인 방향이라고 생각하므로 이것이 ESM 통합을 통해

마침내 이 내용을 다 읽고 나면 이 부분에 대한 내 생각과 매우 흡사하게 들립니다(이 주석 상자가 너무 짧아 담기에는 어떤 것이 있습니까?).

특히 모듈 간 통신 문제에 대해 스키마로 가장 잘 설명할 수 있다고 생각했습니다. 즉, Cap'nProto 직렬화 형식이 필요하지 않으며 스키마만 사용할 수 있습니다. 저는 현재 Cap'nProto의 스키마 언어에 대해 특별히 의견이 없습니다.

WASI/ESM+npm 관점에서 이 형식의 솔루션이 가장 의미가 있습니다. 공유 ABI에 의존하지 않고 ABI에 대한 추상화입니다. 기본적으로 schema-lang API로 인터페이스를 설명하고 양쪽 끝에서 네이티브처럼 보이는 ABI를 사용하여 이러한 언어 경계를 넘어 호출하여 호스트가 번역을 처리할 수 있도록 합니다.

특히, 이것은 다른 모듈과 더 많은 조정을 위한 사용 사례를 포함하지 않습니다. ABI를 공유할 수 있다는 것을 확실히 알고 있다면 실제로 ABI, C 또는 Haskell이든 관계없이 모든 ABI를 사용할 수 있습니다. 문제의 모든 wasm을 제어하고 컴파일하면 훨씬 더 쉽게 해결할 수 있습니다. 알 수 없는 임의의 코드를 로드하고 소스 언어를 모르는 npm의 경우에만 모듈 간에 스키마 수준 상호 운용성을 갖는 것과 같은 것이 매우 매력적입니다. 왜냐하면 우리는 wasm 자체의 LCD를 사용할 수 있기 때문입니다. 이는 네이티브 라이브러리와 유사한 호를 따를 것으로 예상하고 C ABI를 사용하거나 스키마 언어로 인코딩된 언어의 LCD를 사용할 수 있기 때문입니다. 그리고 스키마는 요구 사항 2)를 소프트 요구 사항으로 만들어 더 유연할 수 있습니다. 예를 들어 C에서 Rust로, Nim으로 효율적으로 변환할 수 있어야 하지만 C에서 Haskell로 더 많은 오버헤드가 있는 것은 문제가 되지 않습니다.

특히 모듈 간 통신 문제에 대해 스키마로 가장 잘 설명할 수 있다고 생각했습니다. 즉, 직렬화 형식이 필요하지 않으며 스키마만 사용할 수 있습니다.

나는 전자에 동의하는 경향이 있지만 후자가 따를지는 잘 모르겠습니다. 누가 스키마를 구현합니까? 호스트가 전송을 수행하더라도 어느 시점에서 Wasm 값/바이트가 실제로 양쪽 끝에서 소비/생성되는지 정의해야 하고 각 모듈은 호스트가 이해할 수 있는 형식으로 자체 데이터를 가져와야 합니다. 여러 형식을 사용할 수도 있지만 여전히 직렬화 형식과 다르지 않고 약간 더 높은 수준입니다.

C에서 Rust로, Nim으로 효율적으로 변환할 수 있어야 합니다.

아닐 수도 있지만 그 의미를 알고 있어야 합니다. C 유사 언어에 대한 권한을 부여한다는 것은 오버헤드가 유발되기 때문에 Haskell이 Haskell 모듈에 대해 이 추상화를 사용하지 않는다는 것을 의미합니다. 이는 차례로 자체 라이브러리에 대해 동일한 "npm" 생태계에 참여하지 않는다는 것을 의미합니다.

그리고 여기에서 "Haskell"은 거의 모든 고급 언어의 대명사입니다. 대부분의 언어는 C와 유사하지 않습니다.

더 나은 솔루션이 있다고 주장하지는 않지만 단일 ABI 또는 스키마 추상화가 일반적인 FFI 스타일의 단방향 상호 운용성을 넘어서 얼마나 효율적이고 매력적일 수 있는지에 대해 현실성을 유지해야 한다고 생각합니다. 특히 범언어적 패키지 생태계가 지나치게 현실적인 결과라고 확신하지 않습니다.

C 유사 언어에 대한 권한을 부여한다는 것은 오버헤드가 유발되기 때문에 Haskell이 Haskell 모듈에 대해 이 추상화를 사용하지 않는다는 것을 의미합니다. 이는 차례로 자체 라이브러리에 대해 동일한 "npm" 생태계에 참여하지 않는다는 것을 의미합니다.

그리고 여기에서 "Haskell"은 거의 모든 고급 언어의 대명사입니다. 대부분의 언어는 C와 유사하지 않습니다.

특정 사용 사례를 제공할 수 있습니까? 이상적으로는 직렬화 스키마로 변환하기 어려운 Haskell 또는 다른 언어의 기존 라이브러리가 있습니까?

나는 그것이 주로 유틸리티 라이브러리 대 비즈니스 라이브러리로 귀결 될 것이라고 생각합니다. 예를 들어 컨테이너, 정렬 알고리즘 및 언어의 제네릭에 의존하는 기타 유틸리티는 wasm으로 잘 변환되지 않지만 파서, GUI 위젯 및 파일 시스템 도구는 변환됩니다.

@PoignardAzur , 번역하는 것은 어렵지 않지만 각 교차 모듈 호출의 양쪽 끝에 있는 모든 인수/결과를 복사(직렬화/역직렬화)해야 합니다. 분명히, 모든 언어 내부 라이브러리 호출에 대해 그 비용을 지불하고 싶지는 않습니다.

특히 Haskell에서는 복사가 게으름의 의미와 호환되지 않는다는 추가 문제가 있습니다. 다른 언어에서는 상태 저장 데이터와 호환되지 않을 수 있습니다.

누가 스키마를 구현합니까? 호스트가 전송을 수행하더라도 어느 시점에서 Wasm 값/바이트가 실제로 양쪽 끝에서 소비/생성되는지 정의해야 하고 각 모듈은 호스트가 이해할 수 있는 형식으로 자체 데이터를 가져와야 합니다. 여러 형식을 사용할 수도 있지만 여전히 직렬화 형식과 다르지 않고 약간 더 높은 수준입니다.

호스트는 스키마를 구현합니다. 스키마는 바이트를 전혀 설명하지 않으며 구현 세부 사항이 되도록 합니다. 이것은 흥미로운 부분이 C 구조체에서 WebIDL 유형으로의 변환에 있는 WebIDL 바인딩 제안의 디자인에서 차용한 것입니다. 이러한 종류의 디자인은 WebIDL 유형 대신 Wasm 추상 인터페이스 유형(약어: WAIT)을 사용합니다. WebIDL 제안에서 우리는 "WebIDL로 변환"되었을 때 데이터의 이진 표현을 요구하거나 요구하지 않습니다. 왜냐하면 우리는 중간에 중단 없이 wasm에서 브라우저 API로 바로 이동할 수 있기를 원하기 때문입니다.

C 유사 언어에 대한 권한을 부여한다는 것은 오버헤드가 유발되기 때문에 Haskell이 Haskell 모듈에 대해 이 추상화를 사용하지 않는다는 것을 의미합니다.

아, 100% 동의합니다. 더 명확하게 하기 위해 예제를 완료했어야 했습니다. 한편, Haskell에서 Elm에서 C#으로 변환하는 것도 유사하게 효율적일 수 있지만(wasm gc 유형을 사용한다고 가정할 때), C#에서 Rust로 변환하는 데 오버헤드가 있을 수 있습니다. 언어 패러다임을 뛰어 넘을 때 오버 헤드를 피할 수있는 방법이 없다고 생각합니다.

우리가 주어진 언어에 대해 충분히 인체공학적 + 성능에 실패하면 인터페이스 사용에서 많은 가치를 보지 못하여 생태계에 참여하지 않기 때문에 언어에 대한 특권을 피하려고 시도해야 한다는 귀하의 관찰이 옳다고 생각합니다. .

유형을 추상화하고 유선 형식을 지정하지 않음으로써 호스트가 최적화할 수 있는 여지를 훨씬 더 많이 줄 수 있다고 생각합니다. "C 스타일 문자열이 효율적"이라고 말하는 것이 목표가 아닌 것 같지만 "C 스타일 문자열에 대해 추론하고 싶은 언어가 그렇게 효율적으로 할 수 있다"라고 말하는 것이 목표입니다. 또는 어떤 형식도 축복을 받아서는 안 되지만 특정 호환 가능한 호출 체인이 효율적이어야 하고 모든 호출 체인이 가능해야 합니다.

콜 체인이란 다음을 의미합니다.

1. C -> Rust -> Zig -> Fortran, 효율적
2. Haskell -> C# -> Haskell, 효율적
3. C -> Haskell -> Rust -> Scheme, 비효율적
4. 자바 -> 러스트, 비효율적

그리고 여기에서 "Haskell"은 거의 모든 고급 언어의 대명사입니다. 대부분의 언어는 C와 유사하지 않습니다.

네, 이것이 Haskell을 구체적인 언어로 사용하려는 의도였습니다. (Nim은 GC도 많이 사용하기 때문에 C와 같은 언어의 나쁜 예일 수 있지만)

--

내가 추상 유형에 대해 생각해 온 또 다른 방법은 IR입니다. LLVM이 다대일 관계(많은 언어 -> 하나의 IR -> 많은 대상)를 설명하는 것과 같은 방식으로 wasm 추상 유형은 언어+호스트의 다대다 매핑을 중재할 수 있습니다. 언어+호스트. 이 디자인 공간의 어떤 것이 N^2 매핑 문제를 가져와 N+N 문제로 바꿉니다.

호스트는 스키마를 구현합니다.

글쎄요, 그것만으로는 충분하지 않습니다. 각 모듈은 호스트가 데이터를 찾을 수 있도록 뭔가 를 구현해야 합니다. 호스트가 C 레이아웃을 기대한다면 이 C 레이아웃을 정의해야 하고 모든 클라이언트는 내부적으로 마샬링/마샬링 해제해야 합니다. 직렬화 형식과 크게 다르지 않습니다.

그렇게 하더라도 직렬화 형식을 정의하는 것은 여전히 ​​유용합니다(예: 네트워킹 또는 파일 기반 지속성을 통해 단일 엔진 간에 데이터를 전송해야 하는 응용 프로그램의 경우).

글쎄요, 그것만으로는 충분하지 않습니다. 각 모듈은 호스트가 데이터를 찾을 수 있도록 뭔가를 구현해야 합니다. 호스트가 C 레이아웃을 예상하는 경우 이 C 레이아웃을 정의해야 합니다.

호스트는 아무것도 기대하지해야하지만, 필요에 모든 것을 지원합니다. 좀 더 구체적으로 설명 하면 webidl-bindings 제안을 사용하여 각각 i32 (ptr) 및 i32 (ptr), i32 (len) utf8-cstr 및 utf8-str 가 있습니다. 사양에서 "호스트가 내부적으로 이것을 C-문자열로 나타냄"을 지정하여 둘 사이를 구체적으로 매핑할 수 있도록 할 필요는 없습니다.
따라서 각 모듈은 무언가를 구현하지만 데이터의 표현은 추상 데이터/스키마 계층에서 표현될 필요가 없습니다. 이것이 우리에게 해당 데이터 레이아웃에 대한 추상화 속성을 제공하는 방법입니다.
또한 이것은 구체적인 wasm 유형과 추상 중간 유형을 매핑하는 바인딩 레이어에서 확장할 수 있습니다. Haskell 지원(문자열을 단점 목록과 문자 배열로 모델링)을 추가하기 위해 utf8-cons-str 및 utf8-array-str 바인딩을 추가할 수 있습니다. gc 제안 구문) (type $haskellString (struct (field i8) (field (ref $haskellString)))) 및 (type $haskellText (array i8)) .

즉, 각 모듈은 데이터가 생성되는 방식을 결정합니다. 추상 유형 + 바인딩은 모듈이 동일한 데이터를 보는 방식 간의 변환을 허용하며, 단일 표현이 어떻게든 표준이 되는 것을 축복하지 않습니다.

추상 유형(일부 하위 집합)에 대한 직렬화 형식은 유용하지만 스키마 형식의 소비자로 구현할 수 있으며 직교 문제라고 생각합니다. FIDL에는 네트워크를 통해 전송할 수 있는 유형의 하위 집합에 대한 직렬화 형식이 있으며 불투명 핸들의 구체화를 허용하지 않는 반면 시스템 내에서 전송되는 불투명 핸들을 허용합니다(IPC 예, RPC 아니요).

당신이 설명하고 있는 것은 내가 염두에 두었던 것과 매우 비슷하지만 한 가지 큰 주의 사항이 있습니다. 스키마에는 가능한 적은 수의 고정된 표현이 있어야 합니다. 서로 다른 표현 사이를 연결하는 것은 N*N 문제입니다. 즉, VM 작성자에게 과부하가 걸리지 않도록 표현 수를 작게 유지해야 합니다.

따라서 Haskell 지원을 추가하려면 사용자 지정 바인딩을 추가하지 않고 기존 바인딩을 사용해야 합니다.

몇 가지 가능한 표현:

• C 스타일 구조체와 포인터.
• 실제 capnproto 바이트.
• GC 수업.
• getter 및 setter 역할을 하는 클로저.
• 파이썬 스타일의 사전.

각 언어가 다르고 일부 극단적인 이상값이 있지만 상당히 적은 수의 범주에 상당히 많은 수의 언어를 맞출 수 있다는 아이디어입니다.

따라서 Haskell 지원을 추가하려면 사용자 지정 바인딩을 추가하지 않고 기존 바인딩을 사용해야 합니다.

생각하고 있는 기존 바인딩의 세분성 수준에 따라 다릅니다. 가능한 각 바인딩을 인코딩하는 N<->N 언어는 2*N*N이지만 N<->IR은 2*N이며 N<->[공통 바인딩 스타일]<->IR이라고 하면 여기서 숫자 일반적인 형식은 k이며, 여기서 k < N인 2*k를 말하는 것입니다.

특히, 내가 설명하는 구성표를 사용하면 Scheme을 무료로 얻을 수 있습니다( utf8-cons-str 재사용). Java가 문자열을 char 배열로도 모델링하는 경우 이는 utf8-array-str 바인딩입니다. Nim이 내부적으로 string_views를 사용하는 경우 utf8-str . Zig가 C ABI를 준수하는 경우 utf8-cstr . (저는 Java/Nim/Zig의 ABI를 몰라서 앞에서 구체적인 예로 언급하지 않았습니다.)

따라서 가능한 각 언어에 대한 바인딩을 추가하고 싶지는 않지만 IR 유형별로 몇 가지 바인딩을 추가하여 대부분의 언어를 포괄할 수 있습니다. 여기에서 동의하지 않을 수 있는 여지가 있다고 생각합니다. 바인딩이 "몇 개"인지, 스위트 스폿이 무엇인지, 언어의 ABI를 지원하는지 여부에 대한 기준은 얼마나 엄격해야 할까요?
이 질문에 대한 구체적인 답변은 없습니다. 디자인 공간을 더 잘 설명하기 위해 많은 구체적인 예를 제공하려고 합니다.

또한 한 가지 스타일의 데이터에 대한 특권을 피하기 위해 추상 유형별로 여러 바인딩을 지정하기를 절대적으로 원한다고 주장합니다. Strings에 노출하는 유일한 바인딩이 utf8-cstr 인 경우 C-ABI가 아닌 모든 언어는 해당 불일치를 처리해야 합니다. VM 작성 복잡성을 증가시키는 것은 괜찮습니다.
생태계의 총 작업은 O(VM 작업 + 언어 구현 작업)이며 두 용어 모두 N=언어 수와 함께 어떤 식으로든 확장됩니다. M = 임베더 수, k = 바인딩 수, a = 주어진 언어가 구현해야 하는 평균 바인딩 수를 a<=k로 지정합니다. 최소한 M+N개의 별도 wasm 구현이 있습니다.
모든 N 언어가 독립적으로 다른 모든 N 언어와 함께 ABI FFI를 구현하는 순진한 접근 방식은 O(M + N*N)입니다. 이것은 우리가 네이티브 시스템에 대해 가지고 있는 것인데, 이는 모든 O(N*N)이 네이티브 시스템과 다르지 않은 결과로 이어질 것이라는 강력한 신호입니다.
모든 VM이 모든 N*N 바인딩을 구현해야 하는 두 번째 순진한 접근 방식: O(M*N*N + N), 이는 분명히 훨씬 더 나쁩니다.
우리가 제안하려고 하는 것은 추상 언어 사이에 매핑되는 k 바인딩이 있고 모든 언어에 다시 매핑된다는 것입니다. 이는 각 VM에 대해 k 작업을 의미합니다. 각 언어에 대해 바인딩의 하위 집합만 구현하면 됩니다. 총 작업은 M*k + N*a이며 O(M*k + N*k)입니다. k=N인 경우 VM 측이 "유일한" M*N이므로 주어진 VM에 대해 언어 수에서 "유일한" 선형입니다. 분명히 우리는 k << N을 원하지만, 그렇지 않으면 여전히 O(N*N)이므로 첫 번째 솔루션보다 낫지 않습니다.
그래도 O(M*k + N*k)가 훨씬 더 맛있습니다. k가 O(1)이면 전체 생태계를 구현 횟수에서 선형으로 만들며, 이는 관련된 노력의 양에 대한 하한선입니다. 더 가능성이 있는 경계는 k가 O(log(N))이고 나는 여전히 꽤 만족합니다.

긴 말이지만 저는 이 기능에 대한 VM 복잡성을 일정한 요소로 증가시키는 데 완전히 문제가 없습니다.

IR 유형별로 몇 가지 바인딩을 추가하여 대부분의 언어를 다룰 수 있습니다.

이것은 내가 단순히 사실이 아니라고 믿는 결정적인 기본 가정입니다. 내 경험에 따르면 (적어도!) 언어 구현만큼 많은 표현 선택이 있습니다. 그리고 그것들은 임의로 복잡할 수 있습니다.

다른 인코딩, 이종 로프 등을 포함하여 문자열에 대해 수십(!)개의 표현이 있는 V8을 예로 들어 보겠습니다.

Haskell의 경우는 설명하는 것보다 훨씬 더 복잡합니다. Haskell의 목록은 게으르므로 문자열의 모든 단일 문자에 대해 썽크를 호출해야 할 수도 있습니다.

다른 언어는 문자열 길이에 대해 재미있는 표현을 사용하거나 명시적으로 저장하지 않지만 계산을 요구합니다.

이 두 가지 예는 이미 선언적 데이터 레이아웃이 잘리지 않는다는 것을 보여줍니다. 런타임 코드를 호출할 수 있어야 하는 경우가 많으며, 런타임 코드에는 고유한 호출 규칙이 있을 수 있습니다.

그리고 그것은 개념적으로 상당히 단순한 데이터 유형인 문자열일 뿐입니다. 언어가 제품 유형(튜플/구조체/객체)을 나타내는 무한한 방법에 대해 생각하고 싶지도 않습니다.

그리고 수신측이 있습니다. 여기에서 이러한 모든 데이터 구조를 생성 할 수 있어야 합니다!

따라서 "대부분의 언어"를 지원하는 데 아주 조금이라도 가까워진다는 것은 완전히 비현실적이라고 생각합니다. 대신, 우리는 이미 임의적인 것들의 큰 동물원을 성장시키면서 소수의 특권을 누리기 시작할 것입니다. 그것은 여러 수준에서 치명적으로 보입니다.

내 경험에 따르면 (적어도!) 언어 구현만큼 많은 표현 선택이 있습니다. 그리고 그것들은 임의로 복잡할 수 있습니다.

완전히 동의 해. 대부분의 언어의 데이터 내부 표현을 어떻게든 다룰 수 있는 유형을 설계하는 것은 다루기 힘들고 생태계를 지나치게 복잡하게 만들 것이라고 생각합니다.

결국 데이터와 관련하여 언어 간에 가장 낮은 공통 분모는 "버퍼"뿐입니다. 모든 언어는 이것을 읽고 구성할 수 있습니다. 효율적이고 간단합니다. 네, 그들은 내용을 직접 다룰 수 있는 언어를 선호합니다. 그러나 나는 그것이 (게으른) 죄수 세포를 같은 수준의 지원으로 승격함으로써 해결되는 불평등이라고 생각하지 않습니다.

사실, 포인터 + len 쌍이라는 단일 데이터 유형으로 매우 멀리 갈 수 있습니다. 그런 다음 해당 바이트에 있는 내용을 나타내는 "스키마"가 필요합니다. UTF-8 준수를 약속합니까? 마지막 바이트는 항상 0으로 보장됩니까? 처음 4/8바이트 길이/용량 필드입니까? 이 모든 바이트가 WebGL로 바로 보낼 수 있는 리틀 엔디안 부동 소수점입니까? 이 바이트가 기존 직렬화 형식의 스키마 X입니까? 등?

나는 이러한 모든 질문에 답할 수 있는 매우 간단한 스키마 사양을 제안합니다(기존 직렬화 형식이 아니라 더 낮은 수준, 단순하고 wasm에 특정한 것). 그런 다음 지정된 형식으로 이러한 버퍼를 효율적으로 읽고 쓰는 것이 각 언어의 부담이 됩니다. 그런 다음 그 사이에 있는 레이어는 복사 또는 가능한 경우 참조/보기를 통해 처리하지 않고 버퍼 주위를 맹목적으로 전달할 수 있습니다.

이것은 내가 단순히 사실이 아니라고 믿는 결정적인 기본 가정입니다. 내 경험에 따르면 (적어도!) 언어 구현만큼 많은 표현 선택이 있습니다. 그리고 그것들은 임의로 복잡할 수 있습니다.

나는 이것이 중요한 기본 가정이라는 데 동의합니다. 나는 그것이 사실이 아니라는 데 동의하지 않지만, 의미론적 뉘앙스 때문에 내가 분명히 하지 않았다고 생각합니다.

바인딩은 모든 언어 표현에 완벽하게 매핑되는 것이 아니라 모든 언어에

이것은 인코딩에 관계없이 이것을 전혀 다루기 어렵게 만드는 중요한 기본 가정입니다. @aardappel 이 다른 방향으로 나아가 실제로 바이트를 디코딩 가능한 버퍼로 구체화한다는 제안은 주어진 프로그램 의미의 손실 인코딩이며 다른 것보다 손실이 더 많다는 가정에 기반합니다.

Haskell의 경우는 설명하는 것보다 훨씬 더 복잡합니다. Haskell의 목록은 게으르므로 문자열의 모든 단일 문자에 대해 썽크를 호출해야 할 수도 있습니다.

사실 잊고 있었는데 그게 중요한 건 아닌 것 같아요. 목표는 모듈 경계에서 의미론적 뉘앙스를 모두 유지하면서 Haskell 문자열을 표현하는 것이 아닙니다. 목표는 값에 따라 Haskell 문자열을 IR 문자열로 변환하는 것입니다. 이것은 필연적으로 전체 문자열을 계산하는 것을 포함합니다.

이 두 가지 예는 이미 선언적 데이터 레이아웃이 잘리지 않는다는 것을 보여줍니다. 런타임 코드를 호출할 수 있어야 하는 경우가 많으며, 런타임 코드에는 고유한 호출 규칙이 있을 수 있습니다.

바인딩을 지정하는 방법(또는 바인딩에 대해 무엇이든 지정하는 경우)에 관계없이 이를 모델링하는 방법은 사용자 영역에서 처리하는 것입니다. 언어의 형식 표현이 바인딩에 직접 매핑되지 않는 경우 매핑하는 표현으로 변환해야 합니다. 예를 들어 Haskell의 문자열이 실제로 (type $haskellString (struct (field i8) (field (func (result (ref $haskellString)))))) 로 표현된다면 엄격한 문자열로 변환하고 Scheme과 유사한 바인딩을 사용하거나 Text 배열로 변환하고 Java와 같은 바인딩을 사용해야 합니다. CFFIString을 사용하고 C와 같은 바인딩을 사용합니다. 불완전한 바인딩 유형이 여러 개 있다는 가치 제안은 그 중 일부가 다른 것보다 Haskell에 덜 어색하고 컴파일러를 수정할 필요 없이 Wasm-FFI 유형을 구성할 수 있다는 것입니다.

그리고 그것은 개념적으로 상당히 단순한 데이터 유형인 문자열일 뿐입니다. 언어가 제품 유형(튜플/구조체/객체)을 나타내는 무한한 방법에 대해 생각하고 싶지도 않습니다.
그리고 수신측에서 이러한 모든 데이터 구조를 생성할 수 있어야 합니다!

혼란스럽습니다. "언어 간의 바인딩은 완전히 불가능하므로 전혀 시도해서는 안 됩니다."라고 말하지만 귀하가 말한 내용은 "나는 믿지 않습니다. 여기에 설명된 접근 방식은 다루기 쉽습니다." 훨씬 더 합리적으로 보입니다. 특히 이 논증에 대한 나의 반대는 그것이 앞으로 나아갈 길을 설명하지 않는다는 것입니다. 이 문제가 "매우 어렵다"는 점을 감안할 때 우리는 무엇을 해야 합니까?

대신, 우리는 몇 가지 특권을 시작합니다

거의 확실합니다. 문제는 최적으로 지원되는 소수의 언어가 어느 정도 특권을 누리는가 하는 것입니다. 소외된 언어가 인체공학적 솔루션을 찾는 데 얼마나 여유가 있습니까?

이미 임의적인 것들의 큰 동물원을 성장시키는 동안.

무슨 말씀이신지 모르겠습니다. 임의적인 것에 대한 나의 해석은 "우리는 어떤 언어를 지원합니까?"이지만 이는 이중으로 계산되는 "몇 가지 권한 부여"와 동일합니다. 따라서 이것은 여러 수준이 아닌 한 수준에서만 치명적인 결함이 있습니다. D

@aardappel 짧은 버전은 선언적 추상 접근 방식이 실패할 경우 내 백업 계획입니다. 완전히 반대 방향으로 이동하여 직렬화 형식을 설명합니다. 웹 자체는 매우 낮은 공통 분모이기 때문에 거의 전적으로 텍스트를 기반으로 구축된다는 관찰이 이루어집니다. 텍스트는 모든 도구에서 쉽게 이해할 수 있으므로 웹과 같은 것이 그 위에 가능합니다.

그 접근 방식을 다루기 어렵게 만들 수 있는 버퍼 내 데이터에 대한 가장 큰 우려는 참조 유형을 처리하는 방법입니다. 내가 가진 가장 좋은 아이디어는 테이블을 공유하고 인덱스를 직렬화하는 것이지만 실제로 얼마나 잘 작동하는지에 대한 완전한 그림은 없습니다.

@jgravelle-google 참조 유형을 별도로 유지해야 합니까? 따라서 주어진 함수의 원시 서명은 ref ref i32 i32 i32 i32 이는 실제로 2개의 anyref 뒤에 특정 유형의 2개의 버퍼가 있습니다(위의 가상 스키마에 지정됨).

(여담으로, 나는 하스켈에 익숙 해요,하지만 문자열의 아이디어는 문자의 게으른 목록은 내 마음을 날려한다. 지금까지 무엇이든 할 수있는 가장 효율적인 또는 편리한 방법을 바이트의 목록을 연결하면? 내가 하스켈가 모든 것을 필요로 얻을 변경 불가능하고 연결 목록은 저렴한 추가를 허용하지만 연결 목록을 사용하지 않고 불변 문자열을 가져오고 조작할 수 있습니다.)

그 접근 방식을 다루기 어렵게 만들 수 있는 버퍼 내 데이터에 대한 가장 큰 우려는 참조 유형을 처리하는 방법입니다. 내가 가진 가장 좋은 아이디어는 테이블을 공유하고 인덱스를 직렬화하는 것이지만 실제로 얼마나 잘 작동하는지에 대한 완전한 그림은 없습니다.

그것이 내가 capnproto를 인코딩으로 제안한 이유 중 하나입니다. 참조 테이블은 다소 내장되어 있습니다.

어쨌든 우리는 데이터 그래프의 어느 곳에나 배치할 수 있는 1급 시민으로 참조 유형을 갖도록 선택한 모든 형식을 원합니다. (예: 선택 사항, 배열, 변형 등)

의견을 보내주신 모든 분들께 감사드립니다.

나는 우리가 거의 변동 없이 동일한 주장을 다시 읽는 지점에 도달하기 시작했다고 생각합니다. 그래서 제안을 업데이트하고 모든 사람의 우려를 해결하려고 노력할 것입니다. 업데이트된 제안서 작성을 마치면 새 문제로 다시 시작할 것입니다.

지금까지의 피드백을 요약하자면:

• 직렬화 형식이 있는 경우 wasm에 가장 적합한 형식에 대한 합의는 거의 없습니다. 대안에는 FlatBuffers, 원시 포인터가 있는 C ABI 구조 그래프, 맞춤형 wasm IDL 형식 또는 위의 일부 조합이 포함됩니다.

• 제안에는 더 강력한 부정적인 공간이 필요합니다. 제안의 범위와 용이하게 하려는 사용 사례(정적 대 동적 연결, 모듈 대 호스트 대 호스트 대 호스트, 변경 가능한 데이터 공유 대 변경할 수 없는 메시지 전달)에 대해 혼란스러워하는 여러 독자.

• @lukewagner 는 ESM 통합과 결합될 때 상호 신뢰하지 않는 모듈을 연결하는 모듈 시스템의 잠재력에 대해 약간의 열의를 표했습니다. 제안의 다음 반복은 그 잠재력을 확장해야 합니다. 특히, 이전 버전과 호환되는 유형 시스템을 사용하면 wasm이 npm과 같은 종속성 트리 모델을 사용할 수 있게 되면서 종속성 다이아몬드 문제의 정면승부를 피할 수 있다고 믿습니다.

• 기능 주제, 즉 반환 및 전달할 수 있지만 원시 데이터에서 생성할 수 없는 불투명한 값에 대한 피드백은 거의 없습니다. 나는 그것을 다음 반복이 그것들에 훨씬 더 중점을 두어야 한다는 신호로 받아들입니다.

• 몇몇 독자들은 언어 간 유형 시스템의 실행 가능성에 대해 우려를 표명했습니다. 이러한 우려는 부분적으로 주제가 매우 추상적이기 때문에 부분적으로는 다소 모호하고 정의하기 어렵습니다. 부분적으로는 지금까지 제안 자체가 @lukewagner 의 닭과 달걀 문제를 반영하는 매우 모호하기 때문입니다. 특정 오류 상태는 다음과 같습니다.

  • 눈에 잘 띄는 언어에 너무 많은 초점을 맞추고 더 많은 틈새 언어를 뒤에 남겨둡니다.
  • 너무 일반적이려고 하지만 누구의 사용 사례를 편리하거나 효율적으로 다루지 않는 누수 추상화를 가집니다.
  • 너무 많은 경우를 다루면서 여전히 위의 문제로 고통받는 부풀려진 N*N 구현을 만듭니다.

다음 제안 반복에서는 어떤 식으로든 이러한 문제를 해결해야 합니다.

특히, 토론은 몇 가지 엉뚱한 예에서 추론하는 데 많은 도움이 될 것이라고 생각합니다. 이러한 예에는 n*n 문제를 설명하기 위해 서로 다른 데이터 레이아웃(예: C++ 및 Java)을 사용하여 서로 다른 언어로 작성된 최소 두 개의 라이브러리가 포함되며 서로 다른 언어(예: Rust 및 Python)의 최소 두 개 이상의 프로그램에서 사용됩니다. 해결하기 위한 전략입니다.

또한 독자들이 지적했듯이 이 제안은 현재 유형 스키마의 개념과 그 표현의 개념을 얽혀 있습니다. 제안서가 표현 형식의 요구 사항을 적절하게 배치하는 동안 추상 유형 스키마의 요구 사항을 먼저 배치해야 합니다.

어쨌든 지금까지 이 토론에 참여해 주신 모든 분들께 다시 한 번 감사드립니다. 최대한 빠른 시일 내에 보다 철저한 제안을 드릴 수 있도록 노력하겠습니다. 여기 있는 누군가가 제가 작성하는 데 도움이 된다면 저에게 이메일을 보내주세요!

@jgravelle-google:

바인딩을 지정하는 방법(또는 바인딩에 대해 무엇이든 지정하는 경우)에 관계없이 이를 모델링하는 방법은 사용자 영역에서 처리하는 것입니다.

네, 저도 동의합니다. 제 주장은 @aardappel 과 비슷합니다. 그것이 우리가 일반적으로 해야 하는 일이라면 그냥 받아들여야 하고 이상한 경우를 개선하기 위해 임시로 시도하지 않아야 합니다. Userland는 Wasm의 다른 모든 것의 정신으로 전환이 속하는 곳입니다.

혼란스러워서 "언어 간의 바인딩은 완전히 불가능하므로 전혀 시도하지 않아야합니다."

언어 간의 데이터 상호 운용성을 위해 DDL(유형 체계)을 정의하는 것이 완전히 바람직하다고 생각합니다. 나는 Wasm으로의 변환을 구축하는 것이 다루기 힘들다고 생각하지 않습니다. 변환은 사용자 영역에서 구현해야 합니다. 바인딩 레이어는 사용자 코드가 생성/소비해야 하는 형식을 규정합니다.

이미 임의적인 것들의 큰 동물원을 성장시키는 동안.
무슨 말씀이신지 모르겠습니다. 임의적인 것에 대한 나의 해석은 "우리는 어떤 언어를 지원합니까?"이지만 이는 이중으로 계산되는 "몇 가지 권한 부여"와 동일합니다.

죄송합니다. 저는 이러한 변환에 대해 매우 표준적인 것은 없을 것이라고 생각합니다. 따라서 선택은 "임의"와 개별 의미입니다.

참조 유형을 어떻게 처리할 수 있습니까?

아, 좋은 질문이네요. FWIW, 우리는 Dfinity 플랫폼을 위한 IDL/DDL에 대해 바로 이 문제를 해결하려고 노력하고 있습니다. anyref만 있는 한 솔루션은 매우 간단합니다. 직렬화 형식은 투명한 데이터를 투영하는 메모리 슬라이스와 포함된 참조를 투영하는 테이블 슬라이스의 두 부분을 정의합니다. 여러 참조 유형에는 그에 따라 여러 테이블 조각이 필요합니다. 까다로운 질문은 ref 유형 세트가 더 이상 유한하지 않은 경우(예: 유형이 지정된 함수 참조의 경우) 수행할 작업입니다.

GC 유형이 있으면 GC 값으로 데이터를 제공하는 대체 방법이 있어야 합니다. 이 경우 참조는 자유롭게 혼합될 수 있으므로 문제가 되지 않습니다.

@PoignardAzur :

여담으로 저는 Haskell에 익숙하지 않지만 문자열을 게으른 문자 목록으로 생각하면 마음이 흔들립니다.

네, 요즘은 그것이 실수로 널리 간주되고 있다고 생각합니다. 그러나 "단순한" 데이터 유형에 대해서도 얼마나 많은 다양성이 있는지 보여줍니다.

@rossberg

언어 간의 데이터 상호 운용성을 위해 DDL(유형 체계)을 정의하는 것이 완전히 바람직하다고 생각합니다. 나는 Wasm으로의 변환을 구축하는 것이 다루기 힘들다고 생각하지 않습니다. 변환은 사용자 영역에서 구현해야 합니다.

동의합니다. 그리고 덧붙이자면: 저는 wasm이 다른 플랫폼보다 언어 간 솔루션이 더 필요 하다고 생각하지 않기 때문에 wasm 사양에 무언가를 추가하는 것에 회의적입니다. 그리고 wasm도 그렇게 생각하지 않습니다 다른 플랫폼보다 이러한 솔루션을 구현할 수 있는 능력이 뛰어납니다 . 여기서 was에 대해 나에게 명백하게 특별한 것은 없습니다. 그래서 우리가 @aardappel이 언급한 버퍼와 같이 이 영역에서 표준 솔루션보다 더 나은 이유를

적어도 웹에서 wasm이 가진 한 가지 특별한 것은 문자열 및 배열 등에 대한 JavaScript/Web API 유형입니다. 그들과 상호 작용할 수 있다는 것은 분명히 중요합니다.

나는 wasm이 다른 플랫폼보다 언어 간 솔루션이 더 필요하다고 생각하지 않습니다.

제 생각에는 그렇습니다. 기본적으로 웹에서 사용된다는 것은 코드가 다른 컨텍스트에서 실행될 수 있고 실행될 것임을 의미합니다. <script src="http://some.other.site/jquery.js"> 와 같은 방식으로 나는 사람들이 cross-origin 방식으로 wasm 라이브러리를 결합하는 것을 보고 싶습니다. 웹이 제공하는 임시성과 구성성 속성으로 인해 외부 모듈과 인터페이스할 수 있는 부가가치는 네이티브 시스템에서 그 어느 때보다 높습니다.

그리고 나는 wasm이 다른 플랫폼보다 그러한 솔루션을 구현하는 능력이 더 뛰어나다고 생각하지 않습니다.

그리고 그렇게 생각합니다. wasm은 임베더에 의해 / 호스트에서 실행되기 때문에 코드 생성은 효과적으로 추상화됩니다. 그 때문에 VM은 네이티브 시스템에서는 불가능한 더 높은 수준의 구성을 지원할 수 있는 훨씬 더 많은 도구와 여유를 가지고 있습니다.

그래서 저는 이 공간의 어떤 것이 다른 시스템보다 더 가치 있고 더 가능성이 있다고 생각합니다. 그래서 wasm이 이 맥락에서 특별한 이유입니다. 나에게 JS interop은 wasm 모듈이 세계에 대한 매우 다른 관점을 가진 외부 사물과 대화할 수 있어야 한다는 보다 일반적인 개념의 특별한 경우입니다.

이를 위한 경로는 현재로서는 이것을 완전히 도구 수준 상호 운용성으로 밀어넣고 승리한 형식이 나올 때까지 표준화를 연기하는 것입니다. 따라서 목표가 주어진 인터페이스 형식을 사용하여 wasm 패키지 관리자의 에코시스템을 지배하는 것이라면(그리고 NPM 또는 WAPM 또는 아직 생성되지 않은 패키지 관리자인가요?) 표준화와 독립적으로 발생할 수 있습니다. 이론적으로 우리는 더 나은 성능을 얻기 위해 사람들이 이미 하고 있는 일을 표준화할 수 있지만 인체 공학은 사용자 영역에서 구현될 수 있습니다. 우승한 언어 간 형식이 최적화에 적합하지 않아 사실상 차선의 표준이 되는 위험이 있습니다. 나중에 표준화할 의도로 형식을 디자인할 수 있다면(사용자 정의 섹션의 선언적 스타일이 대부분 충분합니까?) 이러한 위험은 제거하지만 성능 향상도 지연됩니다. 나에게 성능은 이런 종류의 것을 갖게 하는 덜 흥미로운 동기 중 하나이므로 다른 사람들은 동의하지 않을 수 있지만 나는 그것에 대해 꽤 괜찮습니다.

(그리고 NPM이나 WAPM 또는 아직 생성되지 않은 패키지 관리자입니까?)

WAPM이 실행 가능한 패키지 관리자가 되기에는 너무 이르다고 생각합니다. wasm 패키지 관리자가 실현 가능하게 되기 전에 표준화할 ESM 통합, WASI 및 일부 형태의 언어 간 바인딩과 같은 기능이 필요합니다.

있는 그대로 WAPM에 종속성 관리 기능이 없다고 생각합니다.

나는 wasm이 다른 플랫폼보다 언어 간 솔루션이 더 필요하다고 생각하지 않습니다.

제 생각에는 그렇습니다. 기본적으로 웹에서 사용된다는 것은 코드가 다른 컨텍스트에서 실행될 수 있고 실행될 것임을 의미합니다. 같은 방법으로

변환은 사용자 영역에서 구현해야 합니다. 바인딩 레이어는 사용자 코드가 생성/소비해야 하는 형식을 규정합니다.

그것은 나에게 좋은 요약입니다.

새 초안을 작성하는 동안 이 스레드의 모든 사람에게 열려 있는 질문이 있습니다.

WebAssembly로 컴파일된 경우 모든 언어에서 사용할 수 있는 기존 라이브러리가 있습니까?

저는 본질적으로 디자인의 기반이 될 잠재적인 사용 사례를 찾고 있습니다. 저만의 것(특히 React, Bullet 엔진 및 플러그인 시스템)이 있지만 작업할 예제가 더 필요합니다.

@PoignardAzur C의 많은 언어는 동일한 Perl 호환 정규식(PCRE) 라이브러리를 사용하지만 브라우저 임베딩에서는 JS의 Regex API를 사용해야 합니다.

@PoignardAzur BoringSSL과 libsodium이

또한 Cap'n Proto RPC 구현도 있지만 이것은 이상한 것입니다. Cap'n Proto의 _serialization_ 레이어는 대부분이 관용적이고 인라인이어야 하는 넓고 얕은 API 레이어이기 때문에 현실적으로 각 언어에서 독립적으로 구현되어야 합니다. -친숙한. RPC 계층인 OTOH는 좁지만 깊습니다. 원칙적으로 FFI 경계를 넘어 capnp로 인코딩된 바이트 배열 참조를 전달하여 임의의 언어의 직렬화 구현 뒤에서 C++ RPC 구현을 사용할 수 있어야 합니다...

제 생각에는 궁극적으로 제안된 작업을 수행하려면 이미 존재하는 웹 어셈블리 자체에 대해 상당히 침입적인 변경이 필요하지만 그만한 가치가 있을 수 있습니다.

SmallTalk 세계는 모든 유형의 크기를 다소 효율적으로 나타낼 수 있는 효율적인 직렬화 프로토콜인 상태 복제 프로토콜(SRP) 개발에 도움이 될 수 있는 그러한 노력에 대해 긍정적인 경험을 가지고 있음을 알려드립니다. VM 또는 FPGA를 위한 기본 메모리 레이아웃으로 만드는 것을 고려했지만 시도하지 않았습니다. 나는 그것이 좋은 결과와 함께 적어도 하나의 다른 언어인 Squeak으로 이식되었다는 것을 알고 있습니다. 확실히 이 제안의 문제, 도전 과제 및 경험과 크게 겹치는 부분을 읽을 수 있습니다.

Web IDL이 바인딩 언어로서의 기본 제안인 이유를 이해합니다. Web IDL은 웹을 위한 역사적이며 어느 정도 성숙한 바인딩 언어입니다. 나는 그 결정을 크게 지지하며, 나도 같은 결정을 했을 가능성이 매우 큽니다. 그럼에도 불구하고 우리는 그것이 다른 컨텍스트(이해, 다른 호스트/언어)에 거의 맞지 않는다는 것을 인식할 수 있습니다. Wasm은 호스트에 구애받지 않거나 언어/플랫폼에 구애받지 않도록 설계되었습니다. 나는 성숙한 웹 기술을 사용하고 웹이 아닌 시나리오에 대한 사용 사례를 찾는 아이디어를 좋아하지만 Web IDL의 경우 웹과 실제로 연결되어 있는 것 같습니다. 이것이 내가 여기에서 그 대화를 매우 밀접하게 따르는 이유입니다.

https://github.com/WebAssembly/webidl-bindings/issues/40 을 열었습니다. 이에 대한 언급이 없었기 때문에(또는 놓쳤기 때문에) 여기에 질문을 하게 되었습니다.

전체 바인딩 이야기에서 "누가"가 바인딩을 생성할 책임이 있는지 명확하지 않습니다.

• 컴파일러(프로그램을 Wasm 모듈로 변환)입니까?
• 프로그램 작성자입니까(바인딩도 손으로 작성합니까)?

나는 둘 다 유효하다고 생각합니다. 그리고 Web IDL의 경우 약간의 한계가 있는 것 같습니다(위 링크 참조). 어쩌면 내가 그 과정에서 중요한 단계를 놓쳤을 수도 있으므로 내 메시지를 잊어 버리는 것을 고려하십시오.

목표가 Web IDL을 덜 웹 ​​중심적으로 "재집중"하는 것이지만 현재로서는 매우 웹 중심입니다. 그리고 대안을 제안하기 위한 제안이 발생합니다. 따라서 이 스레드입니다. 따라서 잠재적인 단편화가 우려됩니다. 이상적으로(그리고 이것이 지금까지 Wasm이 설계된 방식입니다) 바인딩을 포함하는 Wasm 모듈이 주어지면 있는 그대로 어디에서나 실행할 수 있습니다. Web IDL, Cap'n' Proto, FlatBuffers 등으로 작성된 바인딩을 사용하면 모든 컴파일러나 프로그램 작성자가 진정한 크로스 플랫폼이 되기 위해 다른 구문으로 동일한 바인딩을 작성하지 않을 것이라고 확신합니다. 웃기게도 이것은 손으로 쓴 바인딩을 찬성하는 주장입니다. 사람들은 플랫폼 P에 대한 바인딩을 작성하여 프로그램에 기여할 수 있습니다. 그러나 이것이 전혀 이상적이지 않다는 것을 인정합시다.

요약하자면 저는 웹 바인딩과 웹이 아닌 바인딩 간의 가능한 단편화에 대해 우려하고 있습니다. 비 웹 바인딩 언어가 유지된다면 웹 브라우저에서 현실적으로 구현될까요? 그들은 바인딩 "Wasm ⟶ 바인딩 언어 B ⟶ Web IDL"을 작성해야 합니다. 이것은 모든 호스트에 대해 동일한 시나리오입니다: Wasm ⟶ 바인딩 언어 B ⟶ 호스트 API.

호기심이 사람들을 위해, 나는 Wasmer에서 일을하고 나는의 저자 해요 PHP- , Python- , Ruby- 및 이동 - Wasm 통합. 우리는 매우 다른 호스트에 대해 다른 바인딩을 해킹할 수 있는 멋진 놀이터를 갖기 시작했습니다. 다른 솔루션을 통합하거나, 피드백을 수집하거나, 실험을 시도하기를 원하는 사람이 있다면, 우리는 모두 열려 있고 협업하고 더 많은 리소스를 투입할 준비가 되어 있습니다.

'webIDL 바인딩'의 현재 방향은 아마도 webIDL에서 멀어질 것입니다.
그 자체. 그러나 딜레마는 다음과 같습니다.

모듈간 및 모듈-호스트 표현을 위한 '자연' 언어
상호 운용성은 WASM의 자연어보다 훨씬 풍부합니다. 이것
사용 가능한 IDL에 해당하는 모든 것이 상당히 임의적으로 보일 것임을 의미합니다.
WASM의 관점

반면에 C/C++의 렌즈로 세상을 보는 사람들에게는
(그리고 Rust와 그 유사) WASM의 모델보다 더 풍부한 것은
쓸 수 없는. ref 통합의 어려움으로 이미 이것을 볼 수 있습니다.
도구 체인에 입력합니다.

또한 일반 지원을 하는 것이 WASM의 직접적인 권한은 아닙니다.
언어 간 상호 운용성. IMO도 안됩니다.

(내가 말한 더 제한된 버전의 언어 간 상호 운용성이 있습니다.
믿음은 지지할 수 있을 뿐만 아니라 중요합니다.
기능 제공자와 기능 사용자가 충족할 수 있는 관심
최소한의 마찰로. (능력은 경영진의 말이지만 나는
더 나은 용어를 찾지 못했습니다.) 이것은 다른 스타일의 IDL과 하나의
완전한 언어 간 구현에 필요한 것보다 구현하기가 더 쉽습니다.
인터옵.)

결론: IDL과 동등한 경우가 있으며 필요합니다.
소유권 경계를 넘어 상호 운용성을 지원합니다. 그것이 끝나는 것
현재로서는 명확하지 않다.

2019년 6월 24일 월요일 오전 7:02 Ivan Enderlin [email protected]
썼다:

Web IDL이 바인딩 언어로 기본 제안인 이유를 이해합니다.
그것은 웹을 위한 역사적이며 어느 정도 성숙한 바인딩 언어입니다. NS
그 결정을 크게 지지합니다.
같은. 그럼에도 불구하고 우리는 그것이 다른 맥락에 거의 들어맞지 않는다는 것을 인식할 수 있습니다.
(다른 호스트/언어 이해). Wasm은 호스트에 구애받지 않도록 설계되었습니다.
또는 언어/플랫폼에 구애받지 않습니다. 나는 성숙한 웹을 사용하는 아이디어를 좋아합니다.
기술 및 웹 이외의 시나리오에 대한 사용 사례를 찾기 위해
Web IDL의 경우 실제로 웹과 연결되어 있는 것 같습니다. 내가 매우
여기에서 그 대화를 밀접하게 따르십시오.

WebAssembly/webidl-bindings#40을 열었습니다.
https://github.com/WebAssembly/webidl-bindings/issues/40 , 나를 이끌었습니다.
나는 그것에 대한 언급을 본 적이 없기 때문에 여기에서 질문을 하십시오(또는 놓쳤습니다).

전체 구속력있는 이야기에서 "누가"가 책임이 있는지 명확하지 않습니다.
바인딩 생성:

• 컴파일러(프로그램을 Wasm 모듈로 변환)입니까?
• 프로그램 작성자입니까(바인딩도 손으로 작성합니까)?

나는 둘 다 유효하다고 생각합니다. 그리고 Web IDL의 경우 약간의
제한 사항(위 링크 참조). 어쩌면 내가 중요한 단계를 놓친 것일 수도 있습니다.
내 메시지를 잊어 버리는 것을 고려하십시오.

목표가 Web IDL을 덜 웹 ​​중심적으로 "재집중"하는 것이더라도 지금 당장은
그것은 매우 웹 중심이다. 대안을 제시하기 위한 제안이 발생하고,
따라서 이 스레드. 따라서 잠재적인 단편화가 우려됩니다.
이상적으로(그리고 이것이 지금까지 Wasm이 설계된 방식입니다), 주어진 Wasm 모듈
바인딩을 포함하여 어디에서나 있는 그대로 실행할 수 있습니다. 와 함께
Web IDL, Cap'n' Proto, FlatBuffers 등으로 작성된 바인딩, 저는
모든 컴파일러 또는 프로그램 작성자가 동일하게 작성하지는 않을 것입니다.
서로 다른 구문의 바인딩은 진정한 크로스 플랫폼입니다. 웃기게도 이것은
손으로 쓴 제본을 찬성하는 주장: 사람들은
플랫폼 P에 대한 바인딩을 작성하여 프로그램
전혀 이상적입니다.

요약하자면, 저는 웹과
비 웹 바인딩. 웹 바인딩 언어가 아닌 경우
웹 브라우저에 의해 현실적으로 구현됩니까? 그들은 작성해야 할 것입니다
바인딩 "Wasm ⟶ 바인딩 언어 B ⟶ Web IDL". 동일하니 참고하세요
모든 호스트에 대한 시나리오: Wasm ⟶ 바인딩 언어 B ⟶ 호스트 API.

궁금한 분들을 위해 저는 Wasmer에서 일하고 PHP-
https://github.com/wasmerio/php-ext-wasm , 파이썬-
https://github.com/wasmerio/python-ext-wasm , 루비-
https://github.com/wasmerio/ruby-ext-wasm 및 Go-
https://github.com/wasmerio/go-ext-wasm Wasm 통합. 우리는 시작한다
매우 다른 바인딩을 해킹할 수 있는 멋진 놀이터가 있습니다.
호스트. 누군가 내가 다른 솔루션을 통합하고 수집하기를 원하면
피드백을 받거나 실험을 시도할 때 우리는 모두 열려 있고 협력할 준비가 되어 있습니다.
그리고 그것에 더 많은 자원을 투입하십시오.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/WebAssembly/design/issues/1274?email_source=notifications&email_token=AAQAXUD6WA22DDUS7PYQ6F3P4DHYRA5CNFSM4HJUHVG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAQAXUGM66AWN7ZCIVBTXVTP4DHYRANCNFSM4HJUHVGQ
.

--
프랜시스 맥케이브
SWE

우리는 ref 유형을 도구 체인에 통합하는 어려움으로 이미 이것을 볼 수 있습니다.

다른 언어로는 말할 수 없지만 Rust + wasm-bindgen은 이미 다음을 지원합니다.

• anyref

• WebIDL에서 자동 생성되는 바인딩이며 나중에 공식 WebIDL 참조 유형으로 쉽게 업그레이드할 수 있도록 신중하게 설계되었습니다.

• 공식 webidl-bindings 제안을 위한 WebIDL 폴리필

그래서 궁금합니다. 어떤 어려움을 말씀하시는 건가요?

어려움에 대한 나의 이해는 C++에 더 가깝습니다. Rust는 언어 측면에서 이것을 더 합리적으로 만들기 위해 충분히 강력한 메타프로그래밍을 가지고 있지만, userland C++는 예를 들어 anyref에 대해 추론하는 것이 더 어렵습니다.

여기에서 C++ 관련 문제에 대해 더 듣고 싶습니다. (C++ 전용입니까 아니면 LLVM 전용입니까?)

C++는 ref 유형이 무엇인지 모릅니다. 그래서 당신은 그것을 안에 가질 수 없습니다
임의의 개체. 실제로 언어의 일부가 아닙니다. 파일처럼
설명자. 문자열에 대한 재미있는 장소.

2019년 6월 24일 월요일 오후 3시 77분 Alon Zakai [email protected]에서 다음과 같이 작성했습니다.

여기에서 C++ 관련 문제에 대해 더 듣고 싶습니다. (그들은
C++ 특정 또는 LLVM 특정?)

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/WebAssembly/design/issues/1274?email_source=notifications&email_token=AAQAXUDW237MUBBUUJLKS6LP4FARJA5CNFSM4HJUHVG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LN
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAQAXUB4O3ZX4LRQSQRL763P4FARJANCNFSM4HJUHVGQ
.

--
프랜시스 맥케이브
SWE

@fgmccabe와 오프라인으로 이야기하면 구조가 선형 메모리에 저장되기 때문에 C++와 Rust 모두 구조에 ref 유형을 직접 저장할 수 없다는 것이 사실입니다. C++와 Rust는 물론 정수 핸들을 사용하여 파일 설명자, OpenGL 텍스처 등을 처리하는 것과 같은 방식으로 ref 유형을 간접적으로 처리할 수 있습니다. 내 생각에 그의 요점은 두 언어 중 어느 것도 ref 유형을 "잘"/"기본적으로" 처리할 수 없다는 것입니다(제가 틀렸다면 수정해 주세요!). 이 언어는 항상 ref 유형에서 불리할 것입니다. GC 언어와 비교하여 작업.

여기에 C++에 특정한 것이 있는지 궁금합니다. 없는 것 같은데?

여기서 C++를 어렵게 만드는 요소에 대한 내 이해는 다음과 같습니다.

struct Anyref; // opaque declaration
void console_log(Anyref* item); // declaration of ref-taking external JS API
Anyref* document_getElementById(const char* str);

void wellBehaved() {
  // This should work
  Anyref* elem = document_getElementById("foo");
  console_log(elem);
}

void notSoWellBehaved() {
  // ????
  Anyref* elem = document_getElementById("bar");
  Anyref* what = (Anyref*)((unsigned int)elem + 1);
  console_log(what);
}

좋은 소식은 후자의 예가 UB라는 것입니다(잘못된 포인터는 생성되자마자 UB가 됨). 그러나 LLVM IR에서 이를 모델링하려면 어떻게 해야 할까요?

@jgravelle-google struct Anyref; 조차도 선형 메모리에서 의미가 있는 것이라고 가정합니다. 대신, OpenGL 텍스처, 파일 핸들 등과 같이 앞에서 언급한 정수 핸들로 모델링하지 않는 이유는 무엇입니까?

using Anyref = uint32_t; // handle declaration
void console_log(Anyref item); // declaration of ref-taking external JS API
Anyref document_getElementById(const char* str);

void wellBehaved() {
  // This should work
  Anyref elem = document_getElementById("foo");
  console_log(elem);
}

정수 핸들은 사용될 때 테이블에서 조회되어야 합니다. 다시 말하지만 이것은 C++ 및 Rust와 같은 선형 메모리를 사용하는 언어의 단점일 뿐입니다. 그러나 LLVM이 아닌 경우 wasm 수준에서 최소한 로컬로 최적화할 수 있습니다.

그것은 작동하지만 table_free(elem) 를 호출해야 합니다. 그렇지 않으면 영원히 참조를 유지할 것입니다. C++에서 이상하지 않은 것은 당연합니다.

레이어링이 잘 되지 않아서 이상한 매핑이 된 것 같은데요? 마치 OpenGL과 같은 라이브러리처럼 느껴지지만 제공하는 컴파일러 마법에 의존하는 것처럼 - 별도의 선언에 의존하는 경우 인라인-wasm으로도 C++에서 anyref.h 를 빌드할 수 있다고 생각하지 않습니다. 테이블.

어쨌든 나는 그것이 모두 가능하고 다루기 쉽다고 생각하지만 간단하지 않은 것이 전부입니다.

@kripken "적절한" 기본 anyref 지원을 위해서는 LLVM(및 rustc)에 약간의 변경이 필요한 것이 사실이지만 실제로 장애물은 아닙니다.

wasm-bindgen은 실제 wasm anyref s를 wasm 테이블에 저장하고 선형 메모리에 정수 인덱스를 테이블에 저장합니다. 따라서 wasm table.get 명령을 사용하여 anyref 에 액세스할 수 있습니다.

wasm-gc가 구현될 때까지 GC 언어는 정확히 동일한 전략을 사용해야 하므로 Rust( et al)가 누락되지 않습니다.

그렇다면 LLVM의 기본 anyref 지원이 우리에게 무엇을 가져다 줄까요? 글쎄, 그것은 wasm 테이블을 통해 anyref 를 간접적으로 필요로 하지 않고 함수에서 anyref 를 직접 전달/반환하는 것을 가능하게 할 것입니다. 그것은 유용할 것입니다. 하지만 그것은 단지 성능 최적화일 뿐이며 실제로 anyref 사용을 방해하지는 않습니다.

@파우안

wasm-bindgen은 실제 wasm anyref를 wasm 테이블에 저장한 다음 선형 메모리에 정수 인덱스를 테이블에 저장합니다. 따라서 wasm table.get 명령을 사용하여 anyref에 액세스할 수 있습니다.

바로, 예, 제가 언급한 모델입니다.

wasm-gc가 구현될 때까지 GC 언어는 정확히 동일한 전략을 사용해야 하므로 Rust( et al)가 누락되지 않습니다.

예, 현재 GC 언어는 기본 wasm GC가 없기 때문에 이점이 없습니다. 그러나 희망적으로 그것은 바뀔 것입니다! :) 결국 적어도 GC를 제대로 수행한다면 GC 언어가 여기서 분명한 이점을 가질 것으로 기대합니다.

그렇다면 LLVM의 기본 anyref 지원은 우리에게 무엇을 가져다 줄까요? 글쎄, 그것은 wasm 테이블을 통해 anyref를 간접적으로 전달할 필요 없이 함수에서 anyref를 직접 전달/반환하는 것을 가능하게 할 것입니다. 그것은 유용할 것입니다. 하지만 그것은 단지 성능 최적화일 뿐이며 실제로 anyref를 사용하는 것을 막지는 않습니다.

동의합니다. 예, 이것은 C++ 및 Rust 등에 비해 (결국) GC 언어의 성능 이점일 뿐입니다. 사용을 방해하지는 않습니다.

사이클은 테이블이 루트이기 때문에 C++와 Rust에서 더 큰 문제입니다. 기본적으로 외부 GC가 이해할 수 있도록 C++/Rust 내부의 GC 링크 구조를 매핑하는 어떤 방법으로 추적 API 또는 "그림자 개체"를 사용할 수 있습니다. 그러나 나는 아직 그들 중 어떤 것에 대한 실질적인 제안이 없다고 생각합니다.

결국 적어도 GC를 제대로 수행한다면 GC 언어가 분명한 이점을 가질 것으로 기대합니다.

내가 틀릴 수도 있지만 만약 그렇다면 나는 놀랄 것이다. GC 언어는 wasm GC 구조체를 할당해야 하고 wasm 엔진은 그것이 프로그램을 통해 흐를 때 그것을 추적해야 할 것이다.

이에 비해 Rust는 할당이 필요하지 않고(테이블에 할당하기만 하면 됨) 정수만 저장하면 되며, wasm 엔진은 GC 목적을 위해 1개의 정적 이동 테이블만 추적하면 됩니다.

anyref 액세스 가 table.get 를 사용할 필요가 없기 때문에 GC 언어에 대해 최적화될 수 있다고 생각하지만 table.get 는 상당히 빠를 것으로 예상합니다.

그래서 wasm-gc 프로그램이 wasm 테이블을 사용하는 프로그램보다 더 나은 성능을 기대하는 방법에 대해 더 자세히 설명할 수 있습니까?

추신: 이것은 주제에서 상당히 벗어나기 시작했습니다. 따라서 이 토론을 새 스레드로 옮겨야 할까요?

정말 그냥: table.get/table.set 합니다. GC를 사용하면 원시 포인터가 바로 거기에 있어야 하며 간접 참조를 저장합니다. 그러나 네, Rust와 C++는 정수만 저장하면 되며 전반적으로 매우 빠르기 때문에 GC 이점이 중요하지 않을 수도 있습니다!

우리가 주제에서 벗어날 수 있다는 데 동의합니다. 주제에 있는 것은 ref 유형이 선형 메모리 사용 언어에서 자연스럽게 맞지 않는다는 @fgmccabe 의 요점이라고 생각합니다. 그것은 바인딩에 대해 어떤 방식으로 우리에게 영향을 미칠 수 있습니다(특히 C++ 및 Rust가 이를 처리할 수 없기 때문에 사이클이 걱정되지만 바인딩이 이를 무시할 수 있습니까?), 그래서 제가 생각하기에 조심해야 할 사항 - 둘 다 가능한 한 많은 언어에서 작동하도록 하고 특정 언어의 제한에 지나치게 영향을 받지 않도록 합니다.

@kentonv

Cap'n Proto의 직렬화 계층은 대부분이 관용적이고 인라인 친화적이어야 하는 넓고 얕은 API 계층이기 때문에 현실적으로 각 언어에서 독립적으로 구현되어야 합니다. RPC 계층인 OTOH는 좁지만 깊다.

어떤 폴더인가요?

@PoignardAzur 죄송합니다, 귀하의 질문을 이해할 수 없습니다.

@kentonv capnproto Github 저장소를 살펴보고 있습니다. 직렬화 계층은 어디에 있습니까?

@PoignardAzur 그래서, 이것은 내 요점으로 돌아갑니다. 당신이 가리키고 "그것이 직렬화 계층입니다"라고 말할 수 있는 곳은 실제로 단 한 곳도 없습니다. 대부분 Cap'n Proto의 "직렬화"는 기본 버퍼에 대한 로드/저장에 대한 포인터 산술입니다. 스키마 파일이 주어지면 코드 생성기를 사용하여 스키마에 정의된 특정 필드에 대해 올바른 포인터 산술을 수행하는 인라인 메서드를 정의하는 헤더 파일을 생성합니다. 그러면 애플리케이션 코드는 필드를 읽거나 쓸 때마다 생성된 접근자를 호출해야 합니다.

이것이 다른 언어로 작성된 구현을 호출하는 것이 의미가 없는 이유입니다. 모든 필드 액세스에 원시 FFI를 사용하는 것은 매우 성가신 일이므로 의심할 여지 없이 FFI를 더 예쁜(그리고 스키마에 따라) 감싸는 코드 생성기를 작성하게 될 것입니다. 그러나 생성된 코드는 적어도 Cap'n Proto가 이미 구현한 코드만큼 복잡할 것입니다. 아마도 더 복잡하고 훨씬 느릴 것입니다. 따라서 대상 언어에 대한 코드 생성기를 직접 작성하는 것이 더 합리적입니다.

Cap'n Proto 구현에는 공유할 수 있는 내부 도우미 기능이 있을 수 있습니다. 특히 layout.c++ / layout.h 에는 capnp의 포인터 인코딩을 해석하고 경계 검사 등을 수행하는 모든 코드가 포함되어 있습니다. 생성된 코드 접근자는 포인터 필드를 읽고 쓸 때 해당 코드를 호출합니다. 따라서 여러 언어에서 호출되도록 해당 부분을 FFI로 래핑하는 것을 상상할 수 있습니다. 하지만 여전히 각 대상 언어에서 코드 생성기와 일정량의 런타임 지원 라이브러리를 작성할 것으로 예상합니다.

네, 죄송합니다. 반대를 의미했습니다 ^^ (RPC 레이어)

@PoignardAzur Ohhh, 그리고 FFI에서 인터페이스를 래핑하는 방법에 대해 생각하고 있기 때문에 인터페이스를 보는 데 특히 관심이 있다고 가정합니다. 그래서 당신은 원합니다:

• capability.h : 이론상 다양한 구현으로 뒷받침될 수 있는 기능 및 RPC 호출을 나타내는 추상 인터페이스. (가장 중요한 부분입니다.)
• rpc.h : 네트워크를 통한 RPC 구현.
• rpc-twoparty.h : 단순 연결을 통한 RPC용 전송 어댑터.

이 제안은 이제 #1291: OCAP 바인딩으로 대체되었습니다.