<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: nathanielsimard</title><link>https://news.ycombinator.com/user?id=nathanielsimard</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sun, 13 Sep 2026 10:33:06 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=nathanielsimard" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by nathanielsimard in "GPT‑NL: a sovereign language model for the Netherlands"]]></title><description><![CDATA[
<p>I think it will be cost effective at some point. Computers were limited to research institutes before the personal computer arrived.</p>
]]></description><pubDate>Tue, 16 Jun 2026 21:00:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=48562001</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=48562001</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48562001</guid></item><item><title><![CDATA[New comment by nathanielsimard in "Multiplatform Matrix Multiplication Kernels"]]></title><description><![CDATA[
<p>CubeCL supports WebGPU and can be used with wasm!</p>
]]></description><pubDate>Sat, 19 Jul 2025 01:17:54 +0000</pubDate><link>https://news.ycombinator.com/item?id=44611651</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=44611651</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44611651</guid></item><item><title><![CDATA[New comment by nathanielsimard in "Multiplatform Matrix Multiplication Kernels"]]></title><description><![CDATA[
<p>I don't recall the reason why, point is a valid name.</p>
]]></description><pubDate>Fri, 18 Jul 2025 22:53:58 +0000</pubDate><link>https://news.ycombinator.com/item?id=44610677</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=44610677</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44610677</guid></item><item><title><![CDATA[New comment by nathanielsimard in "Multiplatform Matrix Multiplication Kernels"]]></title><description><![CDATA[
<p>Well we can agree to disagree, CubeCL also has the concept of instruction parallelism, which would be used to target simd instructions on CPU. Our algorithms are normally flexible on both the plane size and the line size, adapting to the hardware with comptime logique. You are free to dislike the naming, but imo a mix of multiple APIs is worse than something new.</p>
]]></description><pubDate>Fri, 18 Jul 2025 22:48:48 +0000</pubDate><link>https://news.ycombinator.com/item?id=44610643</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=44610643</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44610643</guid></item><item><title><![CDATA[New comment by nathanielsimard in "Multiplatform Matrix Multiplication Kernels"]]></title><description><![CDATA[
<p>Using the naming from one of the existing API would put too much bias towards that API. It started as a WebGPU project early on, but some features are not present so mixing terms wasn't ideal. We're also working on extending CubeCL to CPU, so we want terms not only tied to the GPU word.</p>
]]></description><pubDate>Fri, 18 Jul 2025 22:26:57 +0000</pubDate><link>https://news.ycombinator.com/item?id=44610465</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=44610465</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44610465</guid></item><item><title><![CDATA[New comment by nathanielsimard in "Multiplatform Matrix Multiplication Kernels"]]></title><description><![CDATA[
<p>One of the author here, don't hesitate if you have any question or comment!</p>
]]></description><pubDate>Fri, 18 Jul 2025 21:56:58 +0000</pubDate><link>https://news.ycombinator.com/item?id=44610254</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=44610254</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44610254</guid></item><item><title><![CDATA[New comment by nathanielsimard in "CubeCL: GPU Kernels in Rust for CUDA, ROCm, and WGPU"]]></title><description><![CDATA[
<p>We have safe and unsafe version for launching kernels where we can ensure that a kernel won't corrupt data elsewhere (and therefore won't create memory error or segfaults). But within a kernel ressources are mutable and shared between GPU cores, since that's how GPUs work.</p>
]]></description><pubDate>Thu, 24 Apr 2025 17:20:52 +0000</pubDate><link>https://news.ycombinator.com/item?id=43785168</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=43785168</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43785168</guid></item><item><title><![CDATA[New comment by nathanielsimard in "CubeCL: GPU Kernels in Rust for CUDA, ROCm, and WGPU"]]></title><description><![CDATA[
<p>The need to build CubeCL came from the Burn deep learning framework (<a href="https://github.com/tracel-ai/burn">https://github.com/tracel-ai/burn</a>), where we want to easily build algorithms like in CUDA with a real programming language, while also being able to integrate those algorithms inside a compiler at runtime to fuse dynamic graphs.<p>Since we don't want to rewrite everything multiple times, it also has to be multi-platform and optimal, so the feature set must be per-device, not per-language. I'm not aware of a tool that does that, especially in Rust (which Burn is written in).</p>
]]></description><pubDate>Thu, 24 Apr 2025 12:18:30 +0000</pubDate><link>https://news.ycombinator.com/item?id=43781819</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=43781819</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43781819</guid></item><item><title><![CDATA[New comment by nathanielsimard in "CubeCL: GPU Kernels in Rust for CUDA, ROCm, and WGPU"]]></title><description><![CDATA[
<p>We support warp operations, barriers for Cuda, atomics for most backends, tensor cores instructions as well. It's just not well documented on the readme!</p>
]]></description><pubDate>Thu, 24 Apr 2025 12:11:11 +0000</pubDate><link>https://news.ycombinator.com/item?id=43781764</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=43781764</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43781764</guid></item><item><title><![CDATA[New comment by nathanielsimard in "CubeCL: GPU Kernels in Rust for CUDA, ROCm, and WGPU"]]></title><description><![CDATA[
<p>One of the main author here, the readme isn't really well up-to-date. We have our own gemm implementation based on CubeCL. It's still moving a lot, but we support tensor cores, use warp operations (Plane Operations in CubeCL), we even added TMA instructions for CUDA.</p>
]]></description><pubDate>Thu, 24 Apr 2025 12:09:46 +0000</pubDate><link>https://news.ycombinator.com/item?id=43781754</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=43781754</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43781754</guid></item><item><title><![CDATA[New comment by nathanielsimard in "CubeCL: GPU Kernels in Rust for CUDA, ROCm, and WGPU"]]></title><description><![CDATA[
<p>A lot of things happen at compile time, but you can execute arbitrary code in your kernel that executes at compile time, similar to generics, but with more flexibility. It's very natural to branch on a comptime config to select an algorithm.</p>
]]></description><pubDate>Thu, 24 Apr 2025 01:54:34 +0000</pubDate><link>https://news.ycombinator.com/item?id=43778578</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=43778578</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43778578</guid></item><item><title><![CDATA[New comment by nathanielsimard in "Improve Rust Compile Time by 108X"]]></title><description><![CDATA[
<p>During the last iteration of CubeCL, we refactored the matrix multiplication GPU kernel to work with many different configurations and element types.<p>The goal was to improve performance and flexibility by using Tensor cores when available, performing bounds checks when necessary, supporting any tensor layout without any new allocation to transpose the matrices beforehand, and implementing many improvements.<p>The performance is greatly improved, and now it works better with many different matrix shapes. However, I think we created an atrocity in terms of compilation speed. Simply compiling a few matmul kernels, using incremental compilation, took close to 2 minutes.<p>So we fixed it! I took the time to write a blog post with our solutions, since I believe this can be useful to Rust developers in general, even if the techniques might not be applicable to your projects.<p>Feel free to ask any questions here, about the techniques, the process, the algorithms, CubeCL, whatever you want!</p>
]]></description><pubDate>Thu, 16 Jan 2025 14:09:57 +0000</pubDate><link>https://news.ycombinator.com/item?id=42725297</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=42725297</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42725297</guid></item><item><title><![CDATA[Improve Rust Compile Time by 108X]]></title><description><![CDATA[
<p>Article URL: <a href="https://burn.dev/blog/improve-rust-compile-time-by-108x/">https://burn.dev/blog/improve-rust-compile-time-by-108x/</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=42725296">https://news.ycombinator.com/item?id=42725296</a></p>
<p>Points: 8</p>
<p># Comments: 1</p>
]]></description><pubDate>Thu, 16 Jan 2025 14:09:57 +0000</pubDate><link>https://burn.dev/blog/improve-rust-compile-time-by-108x/</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=42725296</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42725296</guid></item><item><title><![CDATA[New comment by nathanielsimard in "Burn 0.14.0 Released: The First Rust-Native Deep Learning Framework"]]></title><description><![CDATA[
<p>Burn is now the first fully Rust-native deep learning framework. Do everything in Rust, from GPU kernels to model definition. No CUDA, C++ or WGSL needed thanks to CubeCL that we released last month.<p>We've introduced a new tensor data format that offers faster serialization/deserialization and supports Quantization (currently in Beta). Loading and saving can be up to 4X as fast.<p>As always, we've added numerous bug fixes, new tensor operations, and improved documentation. Thanks to all contributors, over 50 for this release.</p>
]]></description><pubDate>Tue, 27 Aug 2024 17:38:29 +0000</pubDate><link>https://news.ycombinator.com/item?id=41370384</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=41370384</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=41370384</guid></item><item><title><![CDATA[Burn 0.14.0 Released: The First Rust-Native Deep Learning Framework]]></title><description><![CDATA[
<p>Article URL: <a href="https://burn.dev/blog/release-0.14.0/">https://burn.dev/blog/release-0.14.0/</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=41370383">https://news.ycombinator.com/item?id=41370383</a></p>
<p>Points: 5</p>
<p># Comments: 1</p>
]]></description><pubDate>Tue, 27 Aug 2024 17:38:28 +0000</pubDate><link>https://burn.dev/blog/release-0.14.0/</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=41370383</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=41370383</guid></item><item><title><![CDATA[New comment by nathanielsimard in "Show HN: CubeCL - Multi-Platform GPU Computing"]]></title><description><![CDATA[
<p>Introducing CubeCL, a new project that modernizes GPU computing, making it easier to write optimal and portable kernels. CubeCL allows you to write GPU kernels using a subset of Rust syntax, with ongoing work to support more language features.<p>Why it Matters<p>CubeCL tackles three major challenges in GPU computing<p>- Portability: The same codebase can be used to program any GPU without a loss in performance.<p>- Usability: No need for a new shader language — simply add an attribute on top of your Rust code and voilà, it can now run on any GPU.<p>- Performance: We generate fine-grained kernel specialization via an innovative compile-time system to use the most efficient instructions available.<p>How it works<p>CubeCL leverages Rust's proc macro system in a unique two-step process:<p>1. Parsing: The proc macro parses the GPU kernel code using the syn crate.<p>2. Expansion: Instead of immediately generating an Intermediate Representation (IR), the macro generates a new Rust function.<p>The generated function, semantically similar to the original, is responsible for creating the IR when called. This approach differs from traditional compilers, which typically generate IR directly after parsing. Our method enables several key features:<p>- Comptime: CubeCL functions can contain sections marked as Comptime.
These sections are executed during compilation rather than at runtime.
This allows for the creation of highly specialized kernels by incorporating compile-time information directly into the generated code.<p>- Automatic Vectorization: By simply vectorizing the inputs of a CubeCL function, we can determine the vectorization factor of each intermediate variable during the expansion.<p>- Rust Integration: The generated code remains valid Rust code, allowing it to be bundled without any dependency on the specific runtime.<p>Our goal extends beyond providing an optimized compute language; we aim to develop an ecosystem of high-performance and scientific computing in Rust.For now we have highly optimized matrix multiplication kernels, leveraging Tensor Cores on NVIDIA's hardware when available. We are going to focus on adding more algorithms, but community contributions are more than welcome. There is still a lot of work to be done!<p>Don't hesitate to check the repo and ask any questions that come to mind.</p>
]]></description><pubDate>Fri, 19 Jul 2024 15:06:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=41007273</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=41007273</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=41007273</guid></item><item><title><![CDATA[Show HN: CubeCL - Multi-Platform GPU Computing]]></title><description><![CDATA[
<p>Article URL: <a href="https://github.com/tracel-ai/cubecl">https://github.com/tracel-ai/cubecl</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=41007242">https://news.ycombinator.com/item?id=41007242</a></p>
<p>Points: 10</p>
<p># Comments: 2</p>
]]></description><pubDate>Fri, 19 Jul 2024 15:03:53 +0000</pubDate><link>https://github.com/tracel-ai/cubecl</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=41007242</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=41007242</guid></item><item><title><![CDATA[New comment by nathanielsimard in "Optimal Performance Without Static Graphs by Fusing Tensor Operation Streams"]]></title><description><![CDATA[
<p>Happy to share what we have been working on lately. The blog post explores Burn's tensor operation stream strategy, optimizing models through an eager API by creating custom kernels with fused operations. Our custom GELU experiment reveal a remarkable improvement of up to 78 times on our WGPU backend.</p>
]]></description><pubDate>Tue, 19 Mar 2024 22:47:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=39761106</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=39761106</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=39761106</guid></item><item><title><![CDATA[Optimal Performance Without Static Graphs by Fusing Tensor Operation Streams]]></title><description><![CDATA[
<p>Article URL: <a href="https://burn.dev/blog/fusion-tensor-operation-streams/">https://burn.dev/blog/fusion-tensor-operation-streams/</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=39761105">https://news.ycombinator.com/item?id=39761105</a></p>
<p>Points: 5</p>
<p># Comments: 1</p>
]]></description><pubDate>Tue, 19 Mar 2024 22:47:55 +0000</pubDate><link>https://burn.dev/blog/fusion-tensor-operation-streams/</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=39761105</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=39761105</guid></item><item><title><![CDATA[New comment by nathanielsimard in "Burn Deep Learning Framework Release 0.12.0 Improved API and PyTorch Integration"]]></title><description><![CDATA[
<p>This release is packed with new features and improved performance, but the major focus was on enhancing the user API and the documentation.<p>We updated the API to remove instances where the device chosen was the default one, potentially causing bugs due to device mismatch. Now, our API is more explicit about where the device should be specified, aligning well with the Rust philosophy.<p>The book has seen various updates, including a new section on dataset manipulation requested by the community. We also plan to create a contributor guide, to help new contributors get familiar with the internals of the project.<p>A lot of work has been done to improve our JIT compiler, where we can fuse WebGPU tensor operations into a single kernel for impressive performance improvement. We added automatic vectorization of element-wise operations, as well as integration with autotune. Additionally, kernels created on-the-fly can now be executed in-place for reduced memory usage. We now support running multiple optimization streams independantly, which helps when metric updates and training run on the same device, but different threads. This feature isn't enabled by default yet, but you can enable it with a backend decorator. Future releases will add more optimizations to the compiler, and we will probably ship it by default. We also have plans to add other compilation targets in addition to WebGPU, namely Vulkan and CUDA.<p>One of the major quality of life improvements is the addition of the new PyTorch recorder that allows loading PyTorch weights into Burn modules. We also support specifying regex to dynamically map the weights to your Burn model if the structure isn't the same as the PyTorch implementation.<p>With this new release, we spent a lot of time solidifying our infrastructure, testing our framework on additional OS (Windows and MacOS). Overall, our CI is more mature and allows us to more easily ensure the quality and correctness of every code change across backends and operating systems.<p>Release Notes: <a href="https://github.com/tracel-ai/burn/releases/tag/v0.12.0">https://github.com/tracel-ai/burn/releases/tag/v0.12.0</a>
Burn Book: <a href="https://burn.dev/book/" rel="nofollow">https://burn.dev/book/</a></p>
]]></description><pubDate>Wed, 31 Jan 2024 20:45:54 +0000</pubDate><link>https://news.ycombinator.com/item?id=39209142</link><dc:creator>nathanielsimard</dc:creator><comments>https://news.ycombinator.com/item?id=39209142</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=39209142</guid></item></channel></rss>