Design: pThreads 모든 ETA?

다음 몇 분기의 시간은 아마도 누구나 말할 수 있는 만큼 정확할 것입니다. 그러나 문제를 제출하려면 문제 추적기를 예약하십시오.

이 프로젝트에는 메일링 리스트나 다른 포럼이 없으므로 문제 추적기는 사람들이 디자인 프로세스에 대해 질문할 수 있는 유일한 장소입니다. 사람들이 질문할 수 있는 장소가 있다는 것은 가치 있는 일이므로 사람들이 계속해서 문제 추적기를 사용하여 질문할 것을 권장합니다.

@sunfishcode , 충분히 공정하지만 그런 목록을 만드는 것이 좋습니다. 이슈 트래커가 그에 대한 적절한 대안이 될 수 없다고 생각합니다.

w3 공개 목록 이 있습니다. 하지만 트래픽이 많이 발생하지는 않습니다. 내가 믿는 IRC도 있습니까? 어느 시점에서 웹 사이트에 있었던 것 같은데 웹 사이트의 커뮤니티 섹션에서 둘 다 직접 링크되면 좋을 것입니다. 나는 문제를 제기하고 싶지만 여러분 모두가 대중과 연결되는 ~노출~을 선호하는 방법이 무엇인지 잘 모르겠습니다.

지침:

• https://github.com/WebAssembly/design/blob/master/Contributing.md
• http://webassembly.org/community/feedback/

우리는 사람들에게 github를 사용하도록 안내해 왔습니다. 모든 사람이 좋아하는 것은 아니지만 여러 곳보다 한 곳이 더 좋습니다.

@rossberg-chromium님 안녕하세요. 적시에 답변해 주셔서 감사합니다.

그러나 문제를 제출하려면 문제 추적기를 예약하십시오.

@jfbastien 이 지적한 것처럼 표준 방식으로 수행하기에 가장 좋은 장소인 것 같아서 여기에 질문했습니다.
게다가 스레드 지원은 webAssembly의 성공 여부 를 결정하는 디자인 기능입니다.
로고 컨텍스트와 "Java에서 구현되지 않는 이유"보다 더 많은 문제가 제기되었습니다.

내가 틀렸다면 공유 메모리 / 스레드 구현을 따라야 할 위치를 알려주십시오.
열린 과정이어야 하므로 제 의견을 말하고 싶습니다.

--아르 자형

@RobertoMalatesta 우리는 스레드가 매우 중요하다는 데 동의하지만 WebAssembly의 최소한으로 실행 가능한 제품에 스레드를 밀어 넣는 것보다 스레드를 올바르게 얻는 것이 더 중요했습니다. 추론은 간단합니다. asm.js는 이 기능 없이도 성공을 거뒀습니다.

스레드는 일부 중요한 응용 프로그램에서 확실히 성공 또는 중단 기능이지만 모든 응용 프로그램에 적용되는 것은 아닙니다. GC, 제로 비용 예외 처리, 보장된 꼬리 호출 등도 마찬가지입니다.

MVP를 선택한다는 것은 처음 출시할 때 모든 사람을 기쁘게 하지 않는다는 것을 의미합니다. 그것은 또한 우리가 모든 것을 설계, 사양화 및 구현하기 전에 WebAssembly 를 전혀 사용하지 못하는 사람들도 있다는 것을 의미합니다.

즉, WebAssembly에 JavaScript SharedArrayBuffer 접근 방식을 어느 정도 채택할 것으로 예상합니다. 우리 중 많은 사람들이 처음부터 해당 사양에 참여했습니다. C++에 있는 것과 유사한 저수준 기능과 futex와 같은 API를 추가합니다. 순차 일관성보다 더 많은 메모리 주문으로 성장할 여지가 있습니다. 이를 위한 형식적 메모리 모델 을 만들기 위한 작업이 진행 중입니다.

SAB는 TC39에서 "4단계"에 있으며, 이는 완료, 배송 준비 및 사용할 준비가 되었음을 의미합니다. WebAssembly에 채택하는 것은 그리 어렵지 않을 것으로 예상합니다.

@jfbastien 통찰력 있는 정보 감사합니다.

즉, WebAssembly에 JavaScript SharedArrayBuffer 접근 방식을 어느 정도 채택할 것으로 예상합니다.(...)
SAB는 TC39에서 "4단계"에 있으며, 이는 완료, 배송 준비 및 사용할 준비가 되었음을 의미합니다. WebAssembly에 채택하는 것은 그리 어렵지 않을 것으로 예상합니다.

엄청난. 나는 단순히 스레딩을 위해 굶주린 많은 C++ 코드로 그것을 걷어차고 싶어합니다.
저는 정기적으로 WebWorkers를 TS/JS 응용 프로그램에 사용하며 저는 WebWorkers의 팬은 아니지만 첫 번째 시작으로 사용할 수 있습니다.

스레드도 매우 중요하지만 WebAssembly의 최소한으로 실행 가능한 제품에 스레드를 집어 넣는 것보다 올바르게 처리하는 것이 더 중요했습니다. 추론은 간단합니다. asm.js는 이 기능 없이도 성공을 거뒀습니다.

MVP가 빨리 빠져나와야 하는 필요성과(이것이 스택 기반으로 전환하기 위해 AST를 중단한 이유라고 생각합니다) 추가 단계를 계획하는 데 필요한 주의를 완전히 이해합니다.

스레드는 일부 중요한 응용 프로그램에서 확실히 성공 또는 중단 기능이지만 모든 응용 프로그램에 적용되는 것은 아닙니다. GC, 제로 비용 예외 처리, 보장된 꼬리 호출 등도 마찬가지입니다.

emscripten의 오랜 사용자로서 WebAssembly가 Javascript 애플리케이션 스택 제한에서 더 분리되기를 바랍니다.

Wasm은 1) 최고의 성능을 목표로 하고 2) 일부 Posix/Unix/BSD 표준과 함께 소켓, 메모리/스레드, GDI, fs를 제공해야 합니다. 그렇게 하면 통합 대상 플랫폼으로 모바일 장치와 클라우드 배포 가능한 응용 프로그램을 놓고 경쟁하는 서버에 모두 포함할 수 있는 얇은 OS와 같은 계층이 됩니다.

이것이 wasm이 장기적인 미래로 향하는 방향입니까, 아니면 내가 완전히 배를 놓치고 있습니까?

노고에 다시 한 번 감사드리며,

로베르토

Wasm은 LLVM과 같은 컴파일러가 사용자 액세스 가능한 메모리에 넣어야 하는 것과 로컬을 분리하는 방법 때문에 일부 스택 제한에서 확실히 분리되었습니다.

스레드를 사용하면 특히 작업자 기반이 아닌 경우 더 많은 권한을 얻을 수 있습니다.

즉, 정확한 아이디어에 대한 자세한 내용을 얻는 것이 좋습니다. 사용 사례는 무엇이며 C++에서 이 문제를 해결하는 방법은 무엇이며 wasm 구현은 이를 어떻게 수행합니까?

나는 당신이 모든 답을 생각해 낼 것이라고 기대하지 않습니다! 지금 생각나는 것. Fwiw C++에는 스택 제한에 대한 몇 가지 제안이 있습니다. SG14 하위 그룹을 확인하십시오.

👶🌯 아래에 있습니다. 나중에 더 잘 대답하겠습니다!

낮은 세부 사항에 대해 죄송합니다. 저는 :baby:: burrito: 아래에 있습니다. 나중에 더 잘 대답하겠습니다!

아기 부리또 아래에 있습니까? ㅋ ㅋ ㅋ

@qwertie

아기 부리또 아래에 있습니까? ㅋ ㅋ ㅋ

말 그대로 포장된 아기.

안녕하세요 @jfbastien ,

정확한 아이디어에 대한 자세한 내용을 얻는 것이 좋습니다. 사용 사례는 무엇이며 C++에서 이 문제를 해결하는 방법은 무엇이며 wasm 구현은 이를 어떻게 수행합니까?

일반적으로 내 사용 사례는 시뮬레이션 소프트웨어를 구축하는 것인데, 계산 부분에서는 C++, C/OpenCL 및 GPU 기술 덕분에 기계로만 제한됩니다.

프론트엔드에서 HTML5+CSS+Javascript+Typescript 스택은 중간 규모의 복잡한 응용 프로그램을 개발하는 유효하고, 입증된, 이식 가능한 방법임이 입증되었습니다.

_ JS 웹 스택(Typescript와 같은 구조화된 언어 추가)이 요즘 너무 좋아서 대부분의 애플리케이션에서 emscripten 에 의지하거나 wasm을 시도할 필요를 느끼지 않습니다._

나는 높은 수준의 목표 와 웹 어셈블리 사용 사례 에 거의 전적으로 동의하며 웹이 아닌 임베딩 문서 에 대해서는 훨씬 더 동의합니다.

_ WebAssembly 는 더 빠른 속도(네이티브 C 앱의 뼈대에 더하여 5% 오버헤드)를 허용하고 더 많은 메모리와 더 자유롭게 사용하고 포트/소켓을 완전히 구현하도록 허용한다면 관련 기술이 될 것입니다(적어도 저에게는) 일반 OS처럼 스레드를 실행할 수 있습니다._

Wasm 기계는 크기가 매우 매끄럽고 빠르고 예측 가능해야 하므로 GC에 집착하지 마십시오. GC는 IT의 Ponzi Scheme입니다. 부채를 지고 너무 늦고 주기가 느슨해질 때까지 할당에 신경 쓰지 않습니다. . 게다가, 우리가 고성능 wasm 코어 머신을 가지고 있다면 그 위에 GC를 구축할 수 있습니다.

매끄럽게 하기 위해 Javascript에서 점진적으로 분리합니다. 어떤 언어로든 기본 컴파일러가 있으면 스크립팅이 필요하지 않으며 어쨌든 Duktape/Lua/무엇이든 단순히 C 소스에서 컴파일하여 임베드할 수 있습니다.

Mozilla 사이트 어딘가에서 wasm 네이티브 DOM 조작 구현에 대한 문서를 보았습니다. DOM 조작은 본질적으로 순차적이고 HTML5/CSS/JS 스택에서 가장 시간이 많이 걸리는 측면 중 하나이기 때문에 그다지 유용하지 않을 것이라고 생각합니다. 나는 초고속 다중 스레드 wasm을 작성하여 내 DOM 변경 사항이 대기열에서 직렬화되기를 기다리면 모든 성능이 사라지고 C/C++를 사용하는 것보다 일부 Typescript를 변환하는 것이 좋습니다. 이 경우 직접 OpenGL 액세스를 선호합니다(처음에는 일부 WebGL 구현 후 OpenGL 네이티브 사용). 그래픽 카드에 액세스하면 오버헤드가 적거나 없는 GPU/CUDA 기능을 제공하는 데 유용합니다.
(방금 이것에 대해 확인하러 갔고 이에 대한 문제 #273이 발생했습니다)

모든 공급업체와 독립 기업이 공유하는 작은 wasm 머신을 보유하면 모바일 개발의 악몽을 해결할 수 있습니다. 여기에서 다른 OS, 버전 및 아키텍처에 대해 최소 4개의 도구 체인이 있어야 합니다.
그래픽 및 입력 기능은 다를 수 있지만 하나의 wasm으로 개발한 다음 기능 API를 쿼리하거나 다른 앱 스토어에 동일한 애플리케이션을 배포할 수도 있습니다.
장기적으로: 서버 응용 프로그램과 동일하게 시설(DB 연결 프로토콜 및 풀, 전화번호부 시스템, 메시징 프로토콜 및 시스템 등)에 대한 일종의 합의에 도달하고 JEE 플랫폼과 같은 일부 표준 사양으로 포장합니다. (많은 개념 작업이 이미 지난 20년 동안 배치되었습니다).

나는 당신이 모든 답을 생각해 낼 것이라고 기대하지 않습니다! 지금 생각나는 것. Fwiw C++에는 스택 제한에 대한 몇 가지 제안이 있습니다. SG14 하위 그룹을 확인하십시오.

물론 내가 할거야.

기다려 주셔서 감사합니다.

롭

작은 추가 사항으로 스레드를 구현할 때 스택 크기를 임의로 크게 만들 수 있거나 그 대신 최소 64MB로 설정할 수 있다면 좋을 것입니다. 제 사용 사례는 2개의 스레드를 사용하는 애플리케이션이고 비주 스레드에는 꽤 큰 스택이 필요하기 때문입니다.

@jjpe 는 wasm 플랫폼 자체에 대한 것이 아니라 도구 체인의 구현 또는 ABI 선택의 문제이기 때문에 이 저장소가 아니라 wasm을 대상으로 하는 특정 도구 체인(예: emscripten)에 대한 요청입니다. (예: https://github.com/kripken/emscripten/에서 문제를 열 ​​수 있음)

내가 이전 메시지에서 제안한 것 중 일부는 최신 WASI 제안에 포함된 것 같습니다.
보다:
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

교차 손가락.

--아르 자형

FWIW 현재 상태는 Chrome이 버전 74에서 wasm 스레드 지원을 제공하고 있으며 Firefox에는 아직 제공되지 않은 구현이 있으며 Emscripten에는 pthreads 지원(https://emscripten.org/docs/porting/pthreads.html)이 있습니다. 지금 사용 가능했습니다.

(또한 WASI는 시스템 호출 API로, 주어진 wasm 임베딩 또는 툴체인이 스레드/원자학을 지원하는지 여부와 대부분 직교합니다.)

Chrome 및 Firefox 스레드 API를 사용하는 방법에 대한 문서가 있습니까?

일종의 조합입니다. 브라우저의 wasm 엔진은 wasm 사양(https://github.com/WebAssembly/threads/tree/master/proposals/threads)에 대한 스레드/원자학 확장을 구현하여 공유된 wasm 메모리를 인스턴스화할 수 있습니다. 웹에서 웹 작업자를 만들고 postMessage를 통해 작업자에게 메모리(및 연결된 wasm 모듈)를 보낼 수 있습니다. 그런 다음 작업자(및 기본 스레드 또는 다른 작업자)의 공유 메모리로 모듈을 인스턴스화하고 인스턴스가 메모리를 공유합니다. 사양 제안 개요(https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md)에 작은 예가 있지만 다른 사람은 모릅니다.

안녕하세요 @dschuff 이며 위의 답변에 감사드립니다.
이전 메시지에서 나는 pthreads뿐만 아니라 2010년부터 emscripten을 따르고 사용하는 우리 중 일부가 당시를 진정한 획기적인 기술로 여겼던 더 커널과 유사한 것으로 wasm의 바람직한 진화를 포함하는 이전 메시지를 언급했습니다.
참조: https://github.com/WebAssembly/design/issues/992#issuecomment -285055578 .

emscripten이 나온 지 9년, 그리고 wasm이 발표된 지 거의 5년이 지났지만 wasm을 실행 가능한 서버 기술로 변환하는 데 거의 진전이 없었습니다.

슬프게도 우리는 휴대용 앱에 대한 표준이 필요하고 이를 수행하는 가장 좋은 방법은 POSIX 스레드 및 버클리 ​​소켓 + 자급식 보안 가상 파일 시스템(사용자 및 그룹으로 충분합니다). 나는 H.Spencer의 옛 말을 확고히 합니다. "UNIX를 이해하지 못하는 사람은 UNIX를 재발명해야 합니다."

그래도 믿음을 갖고 싶기에 WASI는 올바른 방향으로 나아가는 한 걸음입니다.

--아르 자형

추신: 2010 emscripten은 대부분의 기업에서 사용되는 불멸의 브라우저인 불멸의 브라우저에서 작동하기 때문에 여전히 흔들리고 있습니다.