Support for all primitive array types (i16, u8, f32, etc.)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- wasm
- Ambito
- compilers
Direzione di ricerca
Inizia leggendo l’attuale proposta su multibyte-array-access e la proposta collegata su JS String Builtins, concentrandoti su come sono rappresentati i tipi di array numerici primitivi e packed. L’issue non indica file né test; il lavoro sarebbe completato con una decisione risolta sulla proposta riguardo a se e come supportare tutti i tipi di array primitivi.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I have a feeling that limiting this proposal to only work on i8 arrays (i.e. (array i8) and (array (mut i8))) would not really bring any benefits with regard to ease of implementation, and would only preclude other potential use-cases. Given that the current version of this proposal already assumes that i8 arrays are likely to be backed by some packed memory buffer through which performant multi-byte accesses are possible, I don't think it's a stretch to further assume that all array types with any primitive or packed numeric type will be backed by untyped memory buffers which can also support multibyte array accesses.
For example, the JS String Builtins proposal works with the (array (mut i16)) type to represent UTF-16 characters in strings. By limiting this proposal to just i8 arrays, it would still not be possible to speed up certain string operations with SIMD, which could otherwise enable faster parsing, string lookups, regular expressions, etc. Remember that in the current GC proposal, there is no way to cast between different array types.
@brendandahl let me know what you think about this.
- Lingua principale
- WebAssembly
- Stelle
- 4
- Fork
- 1
- Merge medio
- 16h 35m
- PR unite (30g)
- 1
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di WebAssembly/multibyte-array-access
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
WebAssembly/multibyte-array-access#10 · 1 commento · 1 reazione ·
-
Half precision floatsAperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 50/100
WebAssembly/multibyte-array-access#8 · 1 commento ·
-
Dart SIMD use case.Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
WebAssembly/multibyte-array-access#5 · 12 commenti · 1 reazione ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
WebAssembly/multibyte-array-access#4 · 4 commenti ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
Tutte le issue di WebAssembly/multibyte-array-access
Issue simili
-
vxc prints a debug line '[flat-codegen] emitted module via the flat path' on every compileForse già presa @YodHeVauHe l’ha presa oggi. Apertadevex good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
kmmbvnr/rank#196 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
SciML/ModelingToolkit.jl#5255 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
NVIDIA/cuda-quantum#5539 ·
I maintainer di solito rispondono entro 1 giorno
-
triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
NVIDIA/cuda-python#3015 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno