Pablo Guerrero Rosel

> you can just implement the JoinHandle and ExecutorHandle types directly for each feature. In theory you don't need the enum, but I think it's more convenient. As you said,...

@mankinskin I don't think the right way to make riker agnostic is to call something like AgnosticExecutor::new() inside riker (except for the default/compatibility case, if we want it). To cover...

@lukewestby I'm working on an agnostic executor library to enable riker to use different executors, including WASM. That would be a first step into making riker wasm compatible. https://github.com/riker-rs/riker/pull/152 But...

Just to let you know, I'm not sure anymore that riker can ever support WASM without major changes. That's because WASM doesn't support catching panics, and riker heavily relies on...

Sure. Let's just say current riker design is not really WASM friendly. Anyone can apply it to their own use case ;-)

I was thinking of something like an array of Variants for the arguments, but I don't know much about the windows API so maybe it's not a good way of...

Thanks, that's great. I got it working yesterday in fp16 but my solution had a few hacks, your solution is much cleaner. I can also confirm that it works for...

I've started to test the generation speed and I've realized that even though we are loading fp16 weights, all the computations are in fp32. This results in a ~2x slowdown...

I just saw you comment, autocast seems great, it's probably what we need, I'll have a look tomorrow. In the mean time, I've created this draft PR that includes my...

This seem really interesting for me. For my use case, one important feature would be the ability to be integrated and extended in a larger engine. In particular (apart of...