Is burn-train + metrics + wasm a goal?

[AlexErrant]

I believe that burn-train + wasm is a goal. Should the metrics feature work on wasm?

I'm maintaining a small fork of burn(-train) that runs on browser-wasm (ref) that uses functionality gated by metrics. In the process of upgrading to v0.16.0, I ran into two areas of interest. Note that both are related to wasm and not browser-wasm.

1. async_channel calls recv_blocking here, which is not supported on wasm. The dependency on async-channel was added with the PR "Consistent sync/async handling, allow more functions to be async for wasm". There may be a future where it is supported, but there's currently no momentum. I deleted AsyncProcessor in my fork.

2. metrics uses nvml-wrapper which doesn't work with wasm. If burn-train + metrics + wasm is a goal, should we gate nvml-wrapper behind a metrics-cuda flag?

[nathanielsimard]

1. The AsyncProcessor probably helps a lot with performance, though the blocking code is because we're using a thread to process metrics, on wasm we could have another kind of worker, not spawning a thread and not using recv_blocking.

2. Having feature flags for different kind of metrics is a good idea, but we could also simply disable some metrics based on the os/arch family type.