Hacker News with Generative AI: Code Optimization

Dirty tricks 6502 programmers use (2019) (nurpax.github.io)
This post recaps some of the C64 coding tricks used in my little Commodore 64 coding competition. The competition rules were simple: make a C64 executable (PRG) that draws two lines to form the below image. The objective was to do this in as few bytes as possible.
C++: terser (shorter) lambda == SHORTY (ab-use?) (github.com/hanickadot)
This library is intended to give terser syntax than C++'s lambdas, not replace C++ with lazy DSL.
C++26 Expansion Tricks (pydong.org)
P1306 gives us compile time repetition of a statement for each element of a range - what if we instead want the elements as a pack without introducing a new function scope?
Inline Evaluation Adventure (rigsomelight.com)
Inline evaluation has been around for a long time, but not every programmer has had the chance to use it. If you haven’t, this is an opportunity to try it.
Every line is a potential bug (2009) (teamten.com)
Every line of code you write is a potential bug. Do not write any line of code unless you absolutely need it right now and your program will suffer for the lack of it. Do not write routines speculatively. Do not write abstraction layers you don’t need right now. If an optimization will add any complexity whatsoever, even a subtraction, resist it.
Cursed fire or #define black magic (ssloy.github.io)
Have you ever wondered whether it is possible to write fully functional code using only the #define directive in C?
Yandex Open-Sources Perforator: Find Code Inefficiencies (phoronix.com)
Internet tech company Yandex announced the open-source release today of Perforator as a tool to help identify and evaluate code inefficiencies at scale.
Promising results from DeepSeek R1 for code (simonwillison.net)
ggml : x2 speed for WASM by optimizing SIMD (via) PR by Xuan-Son Nguyen for llama.cpp:
Finding Missed Code Size Optimizations in Compilers Using LLMs (arxiv.org)
Compilers are complex, and significant effort has been expended on testing them. Techniques such as random program generation and differential testing have proved highly effective and have uncovered thousands of bugs in production compilers. The majority of effort has been expended on validating that a compiler produces correct code for a given input, while less attention has been paid to ensuring that the compiler produces performant code.
LLMs and Code Optimization (wiredream.com)
Max Woolf recently asked whether repeatedly prompting a large language model (LLM) to "write better code" would make it, well, write better code.
Decomplexifying Curl (haxx.se)
Two contributing factors that make code hard to read are function length and function complexity. To keep source code easy to read, understand and debug we should strive towards keeping functions short and simple. Nothing ground-breaking in that conclusion.
Don't let dicts spoil your code (roman.pt)
How often do your simple prototypes or ad-hoc scripts turn into fully-fledged applications?
Shadow Workspace: Iterating on Code in the Background (cursor.com)
Hidden Electron windows and kernel-level folder proxies to let AIs iterate on code without affecting the user.
On over-engineering; finding the right balance (16elt.com)
A big debate among developers is whether to write code for today’s problem or to build a general-purpose solution for future needs. Both approaches have their pros and cons. Specific-purpose code can quickly become messy. But overly general code can add unnecessary complexity. This post, obviously opinionated, argues for a middle ground. That’s the sweet spot, as always.
Tic-tac-toe in a single call to printf (github.com/carlini)
Lisp with GC in 436 Bytes (justine.lol)
How much of your binary executable is just ASCII text? (lemire.me)
How to implement Retries without Cluttering your Code (cellos.blog)
What are the ways compilers recognize complex patterns? (stackexchange.com)
How short can Git abbreviate? (2013) (cuviper.com)