Design: pThreads qualquer ETA ?

Algum tempo nos próximos trimestres é provavelmente tão preciso quanto qualquer um pode dizer. Mas reserve o rastreador de problemas para arquivar problemas.

Este projeto não tem uma lista de discussão ou outro fórum, então o rastreador de problemas é o único lugar onde as pessoas podem fazer perguntas sobre o processo de design. É valioso ter um lugar onde as pessoas possam fazer perguntas, então eu encorajo as pessoas a continuarem usando o rastreador de problemas para fazer perguntas.

@sunfishcode , justo, mas sugiro que criemos essa lista. Eu não acho que um rastreador de problemas seja um substituto adequado para isso.

Existe a lista pública w3 . Não experimenta tráfego muito pesado embora. Há também um IRC eu acredito? Acho que estava no site em algum momento, mas seria bom se ambos estivessem diretamente vinculados à seção de comunidade do site. Eu abriria um problema, mas não tenho certeza de quais caminhos vocês preferem que sejam ~expostos~ vinculados ao público

Instruções aqui:

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

Temos orientado as pessoas a usar o github. Nem todo mundo gosta, mas é melhor ter um lugar do que muitos.

Oi @rossberg-chromium e obrigado por sua resposta oportuna.

Mas reserve o rastreador de problemas para arquivar problemas.

Conforme apontado por @jfbastien , perguntei aqui porque parece o melhor lugar para fazer isso de maneira padrão.
Além disso, o suporte de rosca é um recurso de design que é decisivo para o webAssembly .
Mais do que o contexto do logotipo e "Por que não é implementado em java" vejo levantados como problemas.

Se eu estiver errado, por favor me diga onde seguir a implementação de memória compartilhada / thread.
Deve ser um processo aberto, então gostaria de dar minha opinião.

--R

@RobertoMalatesta , concordamos que os tópicos são muito importantes, mas acertá-los foi mais importante do que colocá-los no produto minimamente viável do WebAssembly. Nosso raciocínio é simples: o asm.js teve sucesso sem esse recurso.

Threads são definitivamente um recurso de fazer ou quebrar para alguns aplicativos importantes, mas não é para todos os aplicativos. O mesmo vale para GC, tratamento de exceção de custo zero, chamadas de cauda garantidas, etc.

Escolher fazer um MVP significa que não deixamos todos felizes no primeiro lançamento. Isso também significa que algumas pessoas podem usar o WebAssembly antes que tudo seja projetado, especificado e implementado.

Dito isso, esperamos adotar mais ou menos a abordagem JavaScript SharedArrayBuffer no WebAssembly. Muitos de nós estiveram envolvidos com essa especificação desde o início. Ele adicionaria recursos de baixo nível semelhantes aos do C++, além de uma API semelhante ao futex. Tem espaço para crescer com mais ordenações de memória do que consistência sequencial. Há um trabalho em andamento para criar um modelo de memória formal para ele.

O SAB está no "estágio 4" no TC39, o que significa que está pronto, pronto para ser enviado e pronto para ser usado. Espero que adotá-lo no WebAssembly não seja muito difícil.

@jfbastien obrigado pela informação perspicaz.

Dito isso, esperamos adotar mais ou menos a abordagem JavaScript SharedArrayBuffer no WebAssembly.(...)
O SAB está no "estágio 4" no TC39, o que significa que está pronto, pronto para ser enviado e pronto para ser usado. Espero que adotá-lo no WebAssembly não seja muito difícil.

Excelente. Estou ansioso para cansá-lo com muito código C++ que simplesmente precisa de threading.
Eu uso regularmente WebWorkers em meus aplicativos TS/JS e deixe-me dizer que não sou fã deles, mas eles podem ser um primeiro começo.

threads são muito importantes, mas acertá-los era mais importante do que enfiá-los no produto minimamente viável do WebAssembly. Nosso raciocínio é simples: o asm.js teve sucesso sem esse recurso.

Compreender totalmente as necessidades de um MVP para sair rapidamente (acho que foi esse o motivo de abandonar o AST para se tornar baseado em pilha) e o cuidado necessário para planejar outras etapas.

Threads são definitivamente um recurso de fazer ou quebrar para alguns aplicativos importantes, mas não é para todos os aplicativos. O mesmo vale para GC, tratamento de exceção de custo zero, chamadas de cauda garantidas, etc.

Como usuário de longa data do emscripten, gostaria de ver o WebAssembly mais desacoplado dos limites da pilha de aplicativos Javascript:

Wasm deve apenas 1) visar o mais alto desempenho e 2) fornecer soquetes, memória/threads, GDI, fs com algum padrão Posix/Unix/BSD. Dessa forma, seria uma camada fina semelhante a um sistema operacional, tanto incorporável em dispositivos móveis como uma plataforma de destino unificada quanto em servidores para competir por aplicativos implantáveis ​​na nuvem.

É esta a direção que estamos indo em um futuro de longo prazo ou estou perdendo completamente o barco?

Obrigado novamente por seu trabalho,

Roberto

Wasm é definitivamente desacoplado de alguns limites de pilha por causa de como separamos os locais do que um compilador como o LLVM precisa colocar na memória acessível ao usuário.

Com threads, especialmente se eles não forem baseados em Worker, você terá mais poder lá.

Dito isto, seria bom obter mais detalhes sobre suas ideias precisas. Qual é o caso de uso, como você o contorna em C++ e como as implementações wasm fariam isso?

Eu não espero que você venha com todas as respostas! Apenas o que vem à mente agora. Fwiw C++ tem algumas propostas para limites de pilha. Confira o subgrupo SG14.

Desculpe pelos detalhes baixos, estou sob um 👶🌯. Responderá melhor depois!

Desculpe pelos detalhes baixos, estou sob um :baby:: burrito:. Responderá melhor depois!

Você está sob um burrito de bebê? Lol

@qwertie

Você está sob um burrito de bebê? Lol

Literalmente, um bebê embrulhado.

Olá @jfbastien ,

seria bom obter mais detalhes sobre suas idéias precisas. Qual é o caso de uso, como você o contorna em C++ e como as implementações wasm fariam isso?

Geralmente meu caso de uso é na construção de software de simulação, na parte computacional o limite sendo apenas a máquina, graças às tecnologias C++, C/OpenCL e GPUs.

No front-end, a pilha HTML5+CSS+Javascript+Typescript provou ser uma maneira válida, comprovada e portátil de desenvolver aplicativos complexos de médio a grande porte.

_ O JS Web Stack (com a adição de uma linguagem estruturada como o Typescript) é tão bom hoje em dia que não sinto necessidade de recorrer ao emscripten ou tentar o wasm para a maioria das aplicações._

Concordo quase totalmente com os Objetivos de Alto Nível e os Casos de Uso de Webassembly e ainda mais com o Documento de Incorporações Não-Web .

_ WebAssembly será uma tecnologia relevante (pelo menos para mim) se permitir ser mais rápido (até o osso de um aplicativo C nativo mais, digamos 5% de sobrecarga) usar mais memória e mais livremente, ter portas/sockets totalmente implementados e permitir a execução de threads como qualquer sistema operacional normal._

A máquina Wasm deve ser muito lisa em tamanho, rápida e preditiva, então, por favor, não se prenda a ela um GC: GCs são o Esquema Ponzi de TI: você faz dívidas e não se importa com alocação até que seja tarde demais e você perca ciclos . Além disso, se tivermos uma máquina com núcleo wasm de superdesempenho, então um GC pode ser construído em cima dela.

Por uma questão de esperteza, eu o separaria progressivamente do Javascript. Se eu tiver compiladores nativos em qualquer idioma, não preciso de scripts e, de qualquer maneira, posso incorporar um Duktape/Lua/whatever simplesmente compilando nas fontes C.

Em algum lugar no site da Mozilla, vi documentos sobre como implementar a manipulação do DOM nativo do wasm: não acho que será muito útil, pois a manipulação do DOM é inerentemente sequencial e é um dos aspectos mais demorados da pilha HTML5/CSS/JS: if Eu escrevo wasm multithread super rápido apenas para ter minhas alterações do DOM serializadas esperando na fila, então todo o desempenho se foi e é melhor transpilar alguns Typescript do que usar C/C++. Nesse caso, eu preferiria o acesso direto ao OpenGL (no início com alguma implementação do WebGL e depois nativo do OpenGL). Acessar a placa gráfica será útil para oferecer recursos de GPU/CUDA com pouca ou nenhuma sobrecarga.
(Apenas fui verificar isso e obtive o problema # 273 abordando isso)

Ter uma pequena máquina wasm compartilhada por todos os fornecedores e independentes também pode resolver o pesadelo do desenvolvimento móvel, onde você tem pelo menos 4 cadeias de ferramentas para diferentes sistemas operacionais, versões e arquiteturas.
Os recursos gráficos e de entrada podem variar, mas poderíamos desenvolver para um wasm e depois consultar as APIs dos recursos ou até mesmo implantar o mesmo aplicativo em diferentes lojas de aplicativos.
A longo prazo: o mesmo com aplicativos de servidor, alcançando algum tipo de consenso sobre as facilidades (Protocolos e Pools de Conexão de BD, Sistemas de Páginas Amarelas, Protocolos e Sistemas de Mensagens etc) e empacotando-os em alguma especificação padrão como a plataforma JEE fez. (Muito do trabalho conceitual já foi apresentado nos últimos 20 anos).

Eu não espero que você venha com todas as respostas! Apenas o que vem à mente agora. Fwiw C++ tem algumas propostas para limites de pilha. Confira o subgrupo SG14.

Claro que vou fazer.

Obrigado por sua paciência e tempo.

Roubar

Como uma pequena adição, quando os encadeamentos são implementados, seria ótimo se o tamanho da pilha pudesse ser arbitrariamente grande ou, em vez disso, se pudesse ser definido para pelo menos 64 MB. Isso ocorre porque meu caso de uso é um aplicativo que usa 2 threads e o thread não principal precisa de uma pilha bem grande.

@jjpe que seria uma solicitação para uma cadeia de ferramentas específica (como emscripten) que visa wasm, em vez de para este repositório, porque é uma questão de escolha de implementação de uma cadeia de ferramentas ou ABI, em vez de algo sobre a plataforma wasm em si. (por exemplo, você pode abrir um problema em https://github.com/kripken/emscripten/)

Algumas das coisas que propus na minha mensagem anterior parecem estar incluídas na última proposta WASI.
Ver:
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Cruzando os dedos.

--R

FWIW O status atual é que o Chrome está enviando suporte a threads wasm na versão 74, o Firefox tem uma implementação que ainda não foi enviada e o Emscripten tem suporte a pthreads (https://emscripten.org/docs/porting/pthreads.html) com estava disponível agora.

(Também WASI é uma API de chamada de sistema, que é principalmente ortogonal para se uma determinada incorporação ou cadeia de ferramentas do wasm suporta ou não threads/atômicas).

Existem documentos sobre como usar as APIs de thread do Chrome e do Firefox?

É meio que uma combinação de coisas. O mecanismo wasm do navegador implementa a extensão threads/atomics para a especificação wasm (https://github.com/WebAssembly/threads/tree/master/proposals/threads) que permite que memórias wasm compartilhadas sejam instanciadas. Na web, você pode criar um web worker e enviar a memória (e quaisquer módulos wasm associados) para o trabalhador via postMessage. Em seguida, você instancia o módulo com a memória compartilhada no trabalhador (e no encadeamento principal ou em outro trabalhador) e as instâncias compartilham sua memória. A visão geral da proposta de especificação (https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md) tem um pequeno exemplo, mas não conheço outros.

Oi @dschuff e obrigado pela resposta acima.
Na minha mensagem anterior, eu estava me referindo a uma anterior, envolvendo não apenas pthreads, mas uma evolução desejável do wasm para algo mais parecido com o kernel, que alguns de nós que seguimos e usamos o emscripten desde 2010 vimos então como uma verdadeira tecnologia inovadora.
Consulte: https://github.com/WebAssembly/design/issues/992#issuecomment -285055578 .

Nove anos após o lançamento do emscripten e quase cinco após os anúncios do wasm, pouco progresso foi feito na transformação do wasm em uma tecnologia de servidor viável.

Infelizmente, porque precisamos de um padrão para aplicativos portáteis, e a melhor maneira de fazer isso, o IMHO teria sido implementar um kernel minúsculo (como BSD/Linux) com POSIX Threads e Berkeley Sockets + um sistema de arquivos virtual seguro independente (com usuários e grupos seriam suficientes). Eu mantenho o velho ditado de H.Spencer: "Aqueles que não entendem UNIX estão condenados a reinventá-lo".

Eu ainda quero manter a fé, então WASI é um passo na direção certa.

--R

PS: 2010 emscripten ainda arrasa, já que funciona no navegador imortal, o indizível unkillable usado na maioria das empresas e que verá os corpos do Firefox e Safari flutuando (pelo menos seus motores).