Thomas Viehmann comments

Results 227 comments of


                                            Thomas Viehmann

Use `int64_t` for nll_loss with cuda inputs

> oof, it even has its own index dispatcher. What an absolute mess of a function. Well, so it has the index dispatcher for different dtypes of the class input,...

Use `int64_t` for nll_loss with cuda inputs

> My point is, why not using AT_DISPATCH_INDEX_TYPES? If we used that, we wouldn't need to bake in int64_t or int, we could simply use index_t where appropriate and auto...

Better error message when format of `examples` is incompatible with `inputs`

Hi! I was about to file an issue about checking examples against the input spec in general (I got an impenetrable JS error on the browser console and no UI...

Batched Augmentations Fail With `torch.autocast()` When `0 < p < 1`

I didn't look at it in detail, but @JanSellner 's approach of being more diligent with casting as needed sees like the right way to do it.

Support for CUDA kernels

Yeah, if anyone has suggestions for a great cuda kernel, I'll take them, or I ask the people on cuda mode...

Support for CUDA kernels

I have made the demo for this weeks cuda mode lecture with cuda-python and that seemed to work well enough that I'd make it into a Thunder example.

Fix the potential int overflow related to BTV

64 bit indexing used to be a *lot* slower than 32 bit indexing (to the point that PyTorch ships two kernels for some things), so you might also want to...

Add FAQ to docs

Supergood start on the FAQ!

Operator support for `F.one_hot`

Hello @kyo-takano , thank you for trying out thunder! This is the thunder way (we should have a FAQ) of saying "this operator is not supported yet in thunder". We...

[performance] from_pretrained is still much slower than torch.load and seems to be initializing weights

In extension of @stas00 's number one, one might enhance the context manager solution with a diversion of the `init` functions. I wrote up [a bit more detail on my...