Hacker News: timmyd

David Robertson took a quantization challenge designed for CUDA experts, and solved it in Mojo with AI assistance, and ended up 1.07x to 1.84x faster than the state-of-the-art C++/CUDA implementation.

How to Beat Unsloth's CUDA Kernel Using Mojo–With Zero GPU Experience

timmyd — Wed, 14 Jan 2026 17:56:46 +0000

Article URL: https://www.modular.com/blog/how-to-beat-unsloth-s-cuda-kernel-using-mojo-with-zero-gpu-experience

Comments URL: https://news.ycombinator.com/item?id=46619517

Points: 3

# Comments: 1

New comment by timmyd in "Apple Silicon GPU Support in Mojo"

timmyd — Mon, 22 Sep 2025 04:49:19 +0000

Co-founder here. There isn't any signup - that was 2+ years ago and we've been iterating a lot with the community and listening to feedback - which has been wonderful. Go freely and install with Pip, UV, Pixi etc -> https://docs.modular.com/mojo/manual/install

New comment by timmyd in "ML needs a new programming language – Interview with Chris Lattner"

timmyd — Fri, 05 Sep 2025 22:02:23 +0000

You might also enjoy this series: https://www.modular.com/democratizing-ai-compute which goes into a lot of the details.

Matrix Multiplication on Nvidia's Blackwell: Part 1 – Introduction

timmyd — Fri, 29 Aug 2025 19:00:13 +0000

Article URL: https://www.modular.com/blog/matrix-multiplication-on-nvidias-blackwell-part-1-introduction

Comments URL: https://news.ycombinator.com/item?id=45068040

Points: 4

# Comments: 0

Inworld TTS: 20x cheaper, state-of-the-art, text-to-speech

timmyd — Wed, 25 Jun 2025 17:09:04 +0000

Article URL: https://inworld.ai/blog/introducing-inworld-tts

Comments URL: https://news.ycombinator.com/item?id=44379611

Points: 27

# Comments: 1

GPU Comic: When GPU programming hurts so much, all we can do is laugh

timmyd — Fri, 20 Jun 2025 18:44:00 +0000

Article URL: https://comic.modular.com/

Comments URL: https://news.ycombinator.com/item?id=44330672

Points: 15

# Comments: 3

Scale or Surrender: When watts determine freedom

timmyd — Mon, 09 Jun 2025 14:33:03 +0000

Article URL: https://www.timdavis.com/blog/scale-or-surrender-when-watts-determine-freedom

Comments URL: https://news.ycombinator.com/item?id=44224914

Points: 2

# Comments: 0

New comment by timmyd in "Highly efficient matrix transpose in Mojo"

timmyd — Sat, 07 Jun 2025 00:23:42 +0000

thanks jsnell - i did they and they appreciated the comment above, and unflagged it. i appreciate it!

New comment by timmyd in "Highly efficient matrix transpose in Mojo"

timmyd — Fri, 06 Jun 2025 23:45:57 +0000

FWIW I didnt take the blog as a dunk on CUDA, just as an impressive outcome from the blog writer in Mojo. It's awesome to see this on Hopper - if it makes it go faster thats awesome.

New comment by timmyd in "Highly efficient matrix transpose in Mojo"

timmyd — Fri, 06 Jun 2025 23:20:19 +0000

[op here] To be clear: Yes, there are 3 kernels - you can see those in the linked github at the end of the article if you clicked that. These are:

transpose_naive - Basic implementation with TMA transfers

transpose_swizzle - Adds swizzling optimization for better memory access patterns

transpose_swizzle_batched - Adds thread coarsening (batch processing) on top of swizzling

Performance comparison with CUDA: The Mojo implementations achieve bandwidths of:

transpose_naive: 1056.08 GB/s (32.0025% of max)

transpose_swizzle: 1437.55 GB/s (43.5622% of max)

transpose_swizzle_batched: 2775.49 GB/s (84.1056% of max)

via the GitHub - simveit/efficient_transpose_mojo

Comparing to the CUDA implementations mentioned in the article:

Naive kernel: Mojo achieves 1056.08 GB/s vs CUDA's 875.46 GB/s

Swizzle kernel: Mojo achieves 1437.55 GB/s vs CUDA's 1251.76 GB/s

Batched swizzle kernel: Mojo achieves 2775.49 GB/s vs CUDA's 2771.35 GB/s

So there is highly efficient matrix transpose in Mojo

All three Mojo kernels outperform their CUDA counterparts, with the naive and swizzle kernels showing significant improvements (20.6% and 14.8% faster respectively), while the final optimized kernel achieves essentially identical performance (slightly better by 4.14 GB/s).

The "flag" here seemed innapropriate given that its true this implementation is indeed faster, and certainly the final iteration could be improved on further. It wasn't wrong to say 14% or even 20%.