glouwbug

I wonder if the sea people were just displaced-farmers-turned-raiders that created some open loop feedback that in turn spawned more sea people in self defence or self survival.

The mythological idea of them just appearing out of nowhere is nice too. Makes it feel aligned with something like the pyramids having no explanation

Of course its unfair. You're competing against students

Wouldn't engineering then be the safest place to be? Engineers have always been embedding loose requirements into runtime law. They (supposedly) understand the business model better than most and have the technical know how to validate that

When you write something you constantly remodel your understanding through refactors and rewrites until you internalize it. By internalizing it you gain the capacity to reason about it (during critical downtime) and communicate it. An entire team that can communicate can solve problems together, from one guy's vision to products white boarding to engineering's infrastructure to UX and UI's artistry.

It boggles me we completely forgot that the world operated like this just 4 years ago

That, and it frees the compiler from reasoning about virtual inlining, and that the std::variant approach can pack potentially more than one object into a single cacheline. TLBs also work with 4096 byte pages, so 32 polymorphic 128 byte entities may (at the absolute worst case) use 32 distinct pages which requires 32 TLB virtual translations, while the std::variant one uses 1.

The next step of going SOA benefits from all of the above, it just further unlocks you packed quad and oct instructions (AVX256 and 512 depending if you buy AMD or not).

Likely the best tip would to `objdump -d` and inspect the assembly then checking performance counters. Prepending (__attribute__((used)) will allow you to inspect your functions.

A quick restrict example:

    #define fn __attribute__((used))

    fn void copy1(int* to, const int* from, const int size)
    {
        for(int i = 0; i < size; i++)
            to[i] = from[i];
    }

    fn void copy2(int* to, const int* from)
    {   
        constexpr int size = 1024;
        for(int i = 0; i < size; i++) 
            to[i] = from[i];
    }

    fn void copy3(int* restrict to, const int* restrict from)
    {
        constexpr int size = 1024;
        for(int i = 0; i < size; i++) 
            to[i] = from[i];
    }

    gcc test.c -c -O3 && objdump -d ./test.o

copy1 is 52 lines, copy2 is 28 lines, copy3 is 2 lines (just a call to memcpy).

This is a good starting point for self teaching. The impact of your TLB, L1, and overall instruction count (with IPC) can further be measured with `./perf stat -d -d -d ./a.out`. If you want a quick rule of thumb, no instructions are fast instructions.

True, but moving from a list of unique polymorphic pointers to a std::variant gains you at least a 2-3x speed up in terms of TLB and cacheline locality. From there, swapping to SOA will net you another 4-8x, so you're looking at nearly 25x improvement by going data first. That may not matter in the unique case of say, games, where rendering a million entities will dwarf the cost of SIMD processing a million entities, but in something like numerical simulations (fluids) or quant it will be warmly welcomed

Learn which instructions SIMD nicely (sqrt / fabs, etc). Use ternaries in loops for masking. Use trig identities and lookup tables (don't recompute sin(3t) when you can use two vector multiples using a table of sin(t) eg. sin(t) * sin(t) * sin(t)). Use divisible constexpr constants in loops to eliminate the SIMD tail. Be careful with type casts and floats. `float x; x += 0.5` will introduce *cvt instructions even if the compiler statically knew better otherwise (use 0.5f). Compile with --fast-math and friends so errno doesn't invalidate your SIMD pipeline.

Some of us want fast food

From fridge to freezer

A whole industry is about to rediscover software engineering fundamentals

Maybe with this piece of information we can end WWI

I'm not sure I follow. C++ just added a SIMD library for this exact problem. And even then, SIMD-intrinsic-free C++ with the right data structures and some basic hardware understanding gets you mostly there in a hardware agnostic portable way.

Right, but that is self contained domain. Hook it up to anything and an impedance mismatch will offset the intent of your poles. Failure modes, cross domains, integration, loads, design intersections; AI can build components, but its the sprouting of these components that exponentially magnifies the number of failure modes.

Engineering needs to be failure free, or at least failure preventive via redundancy, and the latter requires the same full systems understands as the former

I think you're thinking of (;,,;)

Friend of mine had it on the original gameboy

What about a referral program + 5-10 interviews with no intent to hire?

Guys, remember when language features allowed re-usability?

Very nice. Let's see Paul Allen's quicksort

I’m not sure I follow their point. By going with structs of arrays you’re already getting your max SIMD bandwidth 80% there even with the most naive implementations. Learning which math operations are hardware SIMDable gets you another 10%. It’s the last 10% where you rely on math expressions (eg. trig identities), restricted pointers, and ternary “masking magic” where the author may have a point.

A recent example: https://glouw.com/2026/08/14/Ensim5.html

Zero AI child policy

Getting closer to the hardware exponentially magnifies failure modes that LLMs cannot reason about. Being closer to the hardware also moves you to build and compiler machinery that LLMs lack in their training set. Being closer to the hardware also moves you closer to fields that require deep domain knowledge external to computer science, eg. electrical engineering via embedded systems (telecom and SDR), mechanical engineering and control systems via robotics, computer engineering via AAA game engine development (like OP) or silicon bringup, or rigid documentative fields like medical devices or aerospace.

You're facing strict requirements for fundamentals in 3 independent axis. If there's recommendation to anyone looking to "write code" today, its to specialize in a field where software (or firmware) is applied to a hard engineering domain. This has been common advice since 2010 [1], long before LLMs:

"People who can code in the world of technology companies are a dime a dozen and get no respect. People who can code in biology, medicine, government, sociology, physics, history, and mathematics are respected and can do amazing things to advance those disciplines."

[1] https://learnpythonthehardway.org/book/advice.html

Generative AI reverts to the mean: Prose will be over explanatory and miss subtly that human expression normally hits. Same for software: LLMs have a natural tendency to modularize and sprout. You'll find yourself knee deep in enterprise fizz buzz hell [1]. If you're fine with a product that regresses to the mean, great, but what I find that isn't discussed here on hackernews is reason for being. By choosing to create you choose to exist. An LLM may very well be capable of generating _the mean_ of what you're trying to express, but without you consuming it, rewriting it, and ultimately learning it, your team and you are robbed of the ability to communicate and reason about a piece of crucial machinery.

So yes, fuck it, make it anyway, so that you can continue to exist and provide the communicative, engineering, and reasoning value that others still need from you.

[1] https://wiki.c2.com/?RavioliCode

Try triangulating with multiple LLMs to synthesize information. The build by hand. The final composition will master understanding

A good measure is communication. If there's a common understanding, then the origin doesn't necessarily matter.

Then put your money where the mouth is and start committing prompts and having your LLM “compile” them with each production release.

It’s alright, by doing it you understand it. We need people like you still, to improve their understanding, so that they can verify LLM output, or enjoy the craft

Valheim had its 1.0 release today too

WoW released a steady stream of expansions from 2004 to present day. At some point players wanted the old game, so Blizzard released WoW 2004, known as classic, in 2018, and reran the stream of expansions, stopping before any mass enshittification. You can draw the same parallels with C and C++, where C began picking the best from C++ in 1999, 2011, 2023, and soon to be 2029, and carving its own "classic" path.

We even have our Herb Sutter: Jens Gustedt

Not having to write

    #define len(x) sizeof(x) / sizeof(*x)

Is arguably the feature I've waited for for 20 years