Wasmtime GitHub notifications bot (Feb 18 2021 at 22:17): Wasmtime GitHub notifications bot (Feb 18 2021 at 22:17):cfallin labeled Issue #2667:
We are planning to apply to Google Summer of Code; let's brainstorm projetcs that might be interesting! I'll start with a few and can update as ideas come in:
Language bindings for Wasmtime engine: currently, we have bindings to allow Wasmtime to be used within a program written in Go, Python, or a .NET language. It would be useful to extend this list further. This becomes even more interesting when we have Interface Types working: can we marshal native language types (lists and strings) across host/Wasm call boundaries for various host languages?
Cranelift backend: improve instruction selection and speed up the compiler. We've been working on a new compiler backend for Cranelift, which is part of the technology that underlies our other projects (Wasmtime and Lucet). We believe that there are always ways to improve the generated code if one looks long enough! This project would involve finding and understanding sources of slowdown and learning enough about the compiler to change the instruction sequences that it uses. The rewards can be significant when one fixes an issue for a particular benchmark and many times the fixes are pretty simple (generate a different, better-suited instruction). This project would be an opportunity to learn about the innards of the compiler and has potential to be very interesting!
Please feel free to contribute other ideas!
Wasmtime GitHub notifications bot (Feb 18 2021 at 22:17):cfallin labeled Issue #2667:
We are planning to apply to Google Summer of Code; let's brainstorm projetcs that might be interesting! I'll start with a few and can update as ideas come in:
Language bindings for Wasmtime engine: currently, we have bindings to allow Wasmtime to be used within a program written in Go, Python, or a .NET language. It would be useful to extend this list further. This becomes even more interesting when we have Interface Types working: can we marshal native language types (lists and strings) across host/Wasm call boundaries for various host languages?
Cranelift backend: improve instruction selection and speed up the compiler. We've been working on a new compiler backend for Cranelift, which is part of the technology that underlies our other projects (Wasmtime and Lucet). We believe that there are always ways to improve the generated code if one looks long enough! This project would involve finding and understanding sources of slowdown and learning enough about the compiler to change the instruction sequences that it uses. The rewards can be significant when one fixes an issue for a particular benchmark and many times the fixes are pretty simple (generate a different, better-suited instruction). This project would be an opportunity to learn about the innards of the compiler and has potential to be very interesting!
Please feel free to contribute other ideas!
Wasmtime GitHub notifications bot (Feb 18 2021 at 22:17):cfallin opened Issue #2667:
We are planning to apply to Google Summer of Code; let's brainstorm projetcs that might be interesting! I'll start with a few and can update as ideas come in:
Language bindings for Wasmtime engine: currently, we have bindings to allow Wasmtime to be used within a program written in Go, Python, or a .NET language. It would be useful to extend this list further. This becomes even more interesting when we have Interface Types working: can we marshal native language types (lists and strings) across host/Wasm call boundaries for various host languages?
Cranelift backend: improve instruction selection and speed up the compiler. We've been working on a new compiler backend for Cranelift, which is part of the technology that underlies our other projects (Wasmtime and Lucet). We believe that there are always ways to improve the generated code if one looks long enough! This project would involve finding and understanding sources of slowdown and learning enough about the compiler to change the instruction sequences that it uses. The rewards can be significant when one fixes an issue for a particular benchmark and many times the fixes are pretty simple (generate a different, better-suited instruction). This project would be an opportunity to learn about the innards of the compiler and has potential to be very interesting!
Please feel free to contribute other ideas!
Wasmtime GitHub notifications bot (Feb 18 2021 at 22:19):peterhuene edited Issue #2667:
We are planning to apply to Google Summer of Code; let's brainstorm projects that might be interesting! I'll start with a few and can update as ideas come in:
Language bindings for Wasmtime engine: currently, we have bindings to allow Wasmtime to be used within a program written in Go, Python, or a .NET language. It would be useful to extend this list further. This becomes even more interesting when we have Interface Types working: can we marshal native language types (lists and strings) across host/Wasm call boundaries for various host languages?
Cranelift backend: improve instruction selection and speed up the compiler. We've been working on a new compiler backend for Cranelift, which is part of the technology that underlies our other projects (Wasmtime and Lucet). We believe that there are always ways to improve the generated code if one looks long enough! This project would involve finding and understanding sources of slowdown and learning enough about the compiler to change the instruction sequences that it uses. The rewards can be significant when one fixes an issue for a particular benchmark and many times the fixes are pretty simple (generate a different, better-suited instruction). This project would be an opportunity to learn about the innards of the compiler and has potential to be very interesting!
Please feel free to contribute other ideas!
Wasmtime GitHub notifications bot (Feb 19 2021 at 00:59):sunfishcode commented on Issue #2667:
- Networking support in cap-std.
cap-stdis a version of the Rust standard library API using capabilities, such as aDirtype to represent a directory that one can open once and then use to open files inside it, rather than always using string paths. The idea for networking is to have a type which represents a set of addresses (a netmask, a hostname or set of hostnames with a wildcard, or perhaps even a simple list of addresses), which can be used to make connections to addresses in the set. Such a mechanism would be useful for fine-grained sandboxing of native code, and could also contribute to networking support in WASI.- Port interesting codebases to
cap-std.tide-native-static-filesis an example of some real-world code ported to use cap-std for filesystem access; this patch shows the changes -- using aDirinstead of a string for the root directory. It would be interesting to identify other codebases which could be made to use aDirtype, perhaps such as cargo. A ported version can serve as an example of how to use cap-std, as well as helping us find ways to improve cap-std.
Last updated: Nov 22 2024 at 17:03 UTC