<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: brianpane</title><link>https://news.ycombinator.com/user?id=brianpane</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Wed, 07 Oct 2026 07:02:39 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=brianpane" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by brianpane in "Beating the compiler (2024)"]]></title><description><![CDATA[
<p>With hand-written assembly, you can (with effort and care) ensure that the code runs in constant time and doesn’t leak any information through side channels (such as which memory or cache addresses it accesses). That’s important for most encryption code. It’s difficult to ensure constant time execution in pure Rust (or C, or most high level languages in general) because you can’t tell if some future compiler optimization will break your attempts at constant-time code.</p>
]]></description><pubDate>Mon, 05 Oct 2026 21:24:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=49971011</link><dc:creator>brianpane</dc:creator><comments>https://news.ycombinator.com/item?id=49971011</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49971011</guid></item><item><title><![CDATA[New comment by brianpane in "Nvidia dismisses "circular financing", says every $1 it invests brings back $100"]]></title><description><![CDATA[
<p><a href="https://www.youtube.com/watch?v=tO5sxLapAts" rel="nofollow">https://www.youtube.com/watch?v=tO5sxLapAts</a></p>
]]></description><pubDate>Sun, 13 Sep 2026 11:38:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=49682860</link><dc:creator>brianpane</dc:creator><comments>https://news.ycombinator.com/item?id=49682860</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49682860</guid></item><item><title><![CDATA[New comment by brianpane in "Why Addresses Have Numbers"]]></title><description><![CDATA[
<p>Have Eircodes improved the situation? I know they’re supposed to provide a postcode unique to a specific address, but I’m not clear on how thoroughly they’ve been implemented.</p>
]]></description><pubDate>Mon, 10 Aug 2026 19:18:56 +0000</pubDate><link>https://news.ycombinator.com/item?id=49248384</link><dc:creator>brianpane</dc:creator><comments>https://news.ycombinator.com/item?id=49248384</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49248384</guid></item><item><title><![CDATA[New comment by brianpane in "IETF draft-meow-mrrp-00"]]></title><description><![CDATA[
<p>This seems ill-advised. The protocol as documented is trivially exploitable by reflection attacks. The cat next door said one meow, and now every cat in the neighborhood is wailing in response.</p>
]]></description><pubDate>Fri, 17 Apr 2026 16:00:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=47807372</link><dc:creator>brianpane</dc:creator><comments>https://news.ycombinator.com/item?id=47807372</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47807372</guid></item><item><title><![CDATA[New comment by brianpane in "WolfSSL sucks too, so now what?"]]></title><description><![CDATA[
<p>There is a rustls side project called Graviola that's building a fast crypto provider in Rust+ASM. It's taken an interesting approach: starting with an assembly library that's been formally proven correct, and then programmatically translating that into Rust with inline assembly that's easy to build with Rust tooling.</p>
]]></description><pubDate>Sat, 14 Feb 2026 19:45:32 +0000</pubDate><link>https://news.ycombinator.com/item?id=47017659</link><dc:creator>brianpane</dc:creator><comments>https://news.ycombinator.com/item?id=47017659</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47017659</guid></item><item><title><![CDATA[New comment by brianpane in "Zlib-rs is faster than C"]]></title><description><![CDATA[
<p>I basically did manual PGO because I was also reducing the size of several integer fields at the same time to pack more into each cache line. I’m excited to try out the rustc+LLVM PGO for future optimizations.</p>
]]></description><pubDate>Mon, 17 Mar 2025 12:37:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=43387865</link><dc:creator>brianpane</dc:creator><comments>https://news.ycombinator.com/item?id=43387865</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43387865</guid></item><item><title><![CDATA[New comment by brianpane in "Zlib-rs is faster than C"]]></title><description><![CDATA[
<p>I contributed a number of performance patches to this release of zlib-rs. This was my first time doing perf work on a Rust project, so here are some things I learned:
Even in a project that uses `unsafe` for SIMD and internal buffers, Rust still provided guardrails that made it easier to iterate on optimizations. Abstraction boundaries helped here: a common idiom in the codebase is to cast a raw buffer to a Rust slice for processing, to enable more compile-time checking of lifetimes and array bounds.
The compiler pleasantly surprised me by doing optimizations I thought I’d have to do myself, such as optimizing away bounds checks for array accesses that could be proven correct at compile time. It also inlined functions aggressively, which enabled it to do common subexpression elimination across functions. Many times, I had an idea for a micro-optimization, but when I looked at the generated assembly I found the compiler had already done it.
Some of the performance improvements came from better cache locality. I had to use C-style structure declarations in one place to force fields that were commonly used together to inhabit the same cache line. For the rare cases where this is needed, it was helpful that Rust enabled it.
SIMD code is arch-specific and requires unsafe APIs. Hopefully this will get better in the future.
Memory-safety in the language was a piece of the project’s overall solution for shipping correct code. Test coverage and auditing were two other critical pieces.</p>
]]></description><pubDate>Mon, 17 Mar 2025 10:06:11 +0000</pubDate><link>https://news.ycombinator.com/item?id=43386768</link><dc:creator>brianpane</dc:creator><comments>https://news.ycombinator.com/item?id=43386768</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43386768</guid></item><item><title><![CDATA[New comment by brianpane in "SPDY: What I Like About You"]]></title><description><![CDATA[
<p>The way Chrome achieves this backward-compatibility is by using the SSL Next Protocol Negotiation (NPN) extension during SSL handshaking. When the browser is establishing an SSL session, it mentions to the server that it's willing to speak SPDY (as part of the ClientHello message). If the server also speaks SPDY, it can communicate that fact back to the client. If the client sees that the server supports SPDY, it proceeds to send SPDY messages over the newly established connection once the SSL handshaking is complete. Otherwise, it sends HTTP messages. The cool thing about this approach is that it doesn't add any additional network round trips.</p>
]]></description><pubDate>Fri, 23 Sep 2011 15:10:54 +0000</pubDate><link>https://news.ycombinator.com/item?id=3030232</link><dc:creator>brianpane</dc:creator><comments>https://news.ycombinator.com/item?id=3030232</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=3030232</guid></item><item><title><![CDATA[New comment by brianpane in "Rob Pike on regular expressions in lexing and parsing"]]></title><description><![CDATA[
<p>I've found Ragel ( <a href="http://www.complang.org/ragel/" rel="nofollow">http://www.complang.org/ragel/</a> ) to be a good compromise: it's less error-prone and easier to maintain a Ragel grammar than a handwritten lexer, but Ragel lets you use regular expressions for all the little places near the leaves of a grammar where it's easy to represent token rules as regular expressions.  In contrast to most regex APIs, it does the state machine compilation at build time rather than runtime, and the generated code can be quite fast (although you have to make a speed-vs-code-size tradeoff).</p>
]]></description><pubDate>Tue, 23 Aug 2011 04:27:59 +0000</pubDate><link>https://news.ycombinator.com/item?id=2915342</link><dc:creator>brianpane</dc:creator><comments>https://news.ycombinator.com/item?id=2915342</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=2915342</guid></item><item><title><![CDATA[New comment by brianpane in "The demise of the low level programmer"]]></title><description><![CDATA[
<p>In my experience, it's useful, even when writing high-level applications, to be aware of the relative cost of low-level operations.  The "Numbers Everyone Should Know" slide from this deck is a reasonable starting point: <a href="http://research.google.com/people/jeff/stanford-295-talk.pdf" rel="nofollow">http://research.google.com/people/jeff/stanford-295-talk.pdf</a>  To generalize a bit, the small numbers at the top of that chart are mostly a concern for people doing systems programming, but as you progress down the list you'll find operations costly enough to have a noticeable impact on application programs.  E.g., if you build a typical web application in a high-level language, your user won't be able to tell if you add a hundred prediction-resistant conditional branch instructions or a hundred L1 cache misses per page view; but if you add a hundred network round trips per page view they'll observe a measurable slowdown.  Similarly, if you're making a game and you want to display graphics at 60 frames per second, you can do quite a large amount of computation per frame, but you can't read a file from disk on every frame.</p>
]]></description><pubDate>Mon, 08 Aug 2011 02:33:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=2858524</link><dc:creator>brianpane</dc:creator><comments>https://news.ycombinator.com/item?id=2858524</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=2858524</guid></item></channel></rss>