Pannoniae

1. I'm not familiar with the hardened stdlib stuff except for the msvc debug runtime but if you have a solution for this, skip this one. You presumably want boundschecking (and throwing/failing hard) or at the very least, logging out of bounds accesses.

2. A non-inlined grow. If you have large collections you modify often, you want a vector implementation where the reallocation is out of line and the rare case. All the STLs treat it as a normal method and have inlined by codegen.

3. Trivial relocation support so you don't need to destruct objects where there are no pointers inside or external objects pointing to them.

In your case it's probably not as relevant/important, yes

No I'm not. And it's not just MSVC-specific either, they're just not very good.

std::vector doesn't have trivial relocation so any type with a destructor ends up doing elementwise destruct+construct instead of a memcpy.

std::map and std::list are memes and if you use them you're giving your CPU the 1995 treatment with all that pointer chasing.

You thought std::unordered_map is better? Well, actually not because node stability, so it's still chained-bucket, you almost always want to use a flat map like boost::unordered_flat_map or the abseil/eastl version.

<random> is hard-to-use and isn't very performant, std::regex is "you might as well write it in Python and it'd be faster", <iostreams> is virtual calls galore, both the formatting and the stdio functionality are slow.

The conveniently-named std::function is a very general device resulting in a heap allocation and usually a virtual call, there's specific optimisations but don't rely on it.

The STL string manipulation functions are also usually slow, they check the locale for string manipulation rules.

The floating-point functions set errno preventing vectorisation and emitting branches in your straight-line float code unless you use fastmath (the thing people tell you never to do) or one of the more fine-grained compiler-specific switches to turn it off.

std::shared_ptr is Arc<T>, not Rc<T> and eating the cost of atomics can add up in many situations especially with all the other memory traffic going on.

std::variant and std::visit are also not very fast either.

std::filesystem as a whole also has several pain points like iteration which is like a magnitude slower than the native APIs, std::chrono isn't much better either

std::error_code sounds like a simple integer or even a struct.... lol no guess what, more virtual calls

1. Compilers barely do even basic optimisations such as interprocedural register allocation when faced with non-trivial code. You often also need the most aggressive optimisation settings, LTO or even PGO enabled for many of these.

2. Virtuals are, with the exception of PGO, mostly a black box i.e. you get a hard optimisation boundary, no inlining at all.

3. The C++ standard library is usually comically slow (yes, even compared to Java/C#/the likes) so if your project uses std::vector and the such instead of specialised libraries, you've already lost at the beginning.

4. If you don't pay attention to performance from the get-go, the approximate amount of autovectorisation you'll get is close to zero. Some compilers are better than others (Clang>MSVC for example) but I've seen codebases with 8 figures of LoC where the number of vectorised divides/multiplys was like less than ten when you dumped the object listing. In the whole program.

5. Since aliasing and other optimisation barriers (you didn't use restrict or manually hoist, did ya?), it's not uncommon for large C++ programs to spend a third of their runtime doing atomic increments because shared_ptr is supposedly cheap and who cares about lifetimes anyway.

6. If you're targeting Windows, the default new operator / malloc is also comically slow. Luckily that one is fairly easy to fix with installing mimalloc and deploying the hijack dll, but the negative effects on cache by the fragmented allocations is also significant.

No it's not because it sucks the air out from the actual solution. ISPC more than a decade ago managed to demonstrate close-to-linear speedups for increasing vector sizes, even for branchy code.

Nowadays you can even get AI to write intristics and it works just fine, the portable libraries/autovec aren't really a serious player here.

Portability is also overstated - see the recent shift where Spotify decided to make native Android/iOS apps again instead of React Native. Usually, the number of relevant platforms is somewhere between 2 and 3, so portability concerns are more theoretical than real.

I'm a pro-AI midwit and I've upvoted you, but please don't solicit upvotes, it's against the site rules...

Great job! 32-to-64-bit conversions are always fun :) One question though. If this is intended for desktop, why bother with WASM at all? Do you gain anything other than less performance?

"No" is also an answer. Sadly one which isn't considered by many people :)

No but almost all good ideas can be reduced down to a few sentences if you're good at explaining things. It's a different kind of intelligence than what's commonly called IQ but it's something like that regardless.

Sure the explanation will oversimplify a lot but then you can expand it recursively if needed, you gotta start somewhere.

Most musicians in history didn't know how to read music, yeah. Less so in the present day but just about every folk song has spread by the word of mouth, and even in pop music many genres have a strong oral tradition (jazz, blues, rock, you name it), they play by ear and not by sheet.

Yuuuup exactly. I guess this is masked because old 90s games are often more culturally significant so people haven't found these problems yet but yes, these are serious challenges.

Yeah IMO the next big thing will be a way of verifying equivalence while filtering out the "noise" differences in optimisation. Otherwise you can't really decide whether you got it correct or not.

Correct me if I'm wrong (I'm not very well-versed in game decomp scenes) but aren't all those bytematched decomps from 90s or at the latest early 2000s games? They didn't have global optimisation (MSVC introduced it in VS .NET or 2003 I think and many games didn't use it until later)

So these are mostly problems with more advanced compilers yk

Hey I'm not working in matching something with LTCG atm :) I'm just saying in general.

And yes if you have a pdb / an Od build then things are much easier, I was assuming arbitrary game i.e. release binaries.

The "knowledge laundering" approach you describe might help in reconstructing headers, class layouts and function names which is a godsend although I don't think it would be enough to get a match. Getting functionally equivalent code is muuuch easier (although there's the problem of "how do you verify that without running every function")

Cheers, enjoy the rabbithole:)

A small pointer, it's hard to do interpret statistics because most people play on multiple platforms. Roughly 75% of gamers play on mobile, 45% on PC and 40% on console.

I'm not 100% sure about the numbers, just off the top of my head about looking at market research, updated numbers welcome

"assign all these pointers to the correct types, a wrong guess leads to different COMDAT folding"

"get the order of local variables in this function right, otherwise the register allocation doesn't match. Oh and there's 150 local variables just in this function, good luck trying them all"

"Find out the translation unit boundaries exactly (assume there's no pdb otherwise this is trivial) and after doing so, figure out the order they were compiled in, otherwise it won't match"

"brute force the compilation flags for the project and if you're done, also bruteforce it for the CRT or any other middleware which usually came prebuilt so it doesn't match the main game"

Should I continue;)

With /LTCG /GL I don't think it's possible to get matching (or at least it's a very tall order), the codegen is wayy too volatile for an exact match and since inlining and reg alloc work on heuristics with thresholds it really cascades. Even stuff like what order you declare your locals in or the exact frontend syntax can mess things up...

Correct, this is just hacks for stuff you didn't manage to match exactly. Either that or your build environment isn't the same. Sadly, there are things which aren't really possible to reproduce in a byte-identical manner, things like exact file layout or variable declaration order, compilation order and that kinda stuff. And they might cause small but equivalent changes like different inlining/optimisation decisions, so it's really tricky to get it byte-exact.

I said it's not possible to legislate some things away, i.e. unviable legislation. A hard ban on modding / AI reimplementation isn't viable, because you can't really keep data off the internet, evidenced by things like leaks, Anna's Archive etc. remaining online. People can always reupload the remade GTA or whatever onto noname fileshares, code forges, torrent and so on.

TL;DR: You got promoted or you wanted to get promoted. You decide you want to make a bigger project to show ambition, advance your career and whatnot. You embark on making some grand project, disappearing from view. This often leads to you getting stuck with something, falling behind and various negative effects like getting a PIP or becoming depressed.

His prescription to avoid this is to keep checking in and show some progress on something every day so you don't lose touch.

(My analysis: I don't think this is particularly a senior engineer problem, to me it just reads like ADHD-coded problems with time and interests)

In that case, wouldn't piracy shift to hacking the servers and exfiltrating the binaries/code?

You don't have a buffer overflow problem if you read it in a memory-safe way i.e. read it in chunks and realloc when you reach the size of your allocation.

What you will have is a potential denial-of-service attack - although this one isn't particularly great because there's zero amplification (they might as well just send garbage into your firewall)

Sorry, I'm just being realistic. "Whenever there's a will there's a way" and so on. People have tried to legislate all sorts of various things, even stuff like "PI = 3" without much success because they weren't viable.

I don't see how this disproves my point. There's a vast divide between "theoretical" and "applied" software engineering. You don't usually see Google engineers publish their search optimisations in journals. And similarly, you don't see university professors making commercial libraries from their articles' ideas. This isn't the case in every field but in software, it very much is.

And this implies that training on the "theoretical" side of things doesn't give you much insight on the "practical" side. Stuff like cyclomatic complexity, UML diagrams and all that stuff might be well-represented in literature but way less so in real software, so training on the literature will produce completely different software than training on production software code.

>The PC market is shrinking.

You have very good points but I'd say this is somewhat of a fallacy. If you look at graphs for phone shipments and PC shipments, they're both somewhat declining between 2015-2025 (I'm focusing on this time period to exclude the current temporary component shortages). However, this doesn't mean they're becoming less popular in either usage or platform spending like buying apps, games and subscriptions. How can this circle be squared you might ask? Just about everyone has a phone or a laptop today. They're typically not first-time buyers, they'll be replacing their systems. Even if the number of devices shipped are decreasing today, doesn't mean the market itself has shrunk. Even if for some reason, all laptops became e-waste from next year January 1st, you'd see several hundred million sales next year for the replacement device, because the market is there.

For those consoles, that's not the case. (src: https://www.gamesindustry.biz/analyst-game-console-shipments...) Look at how Switch is the majority of shipments most of the time, and there are years where traditional consoles sell only a few million copies. Contrast that to the personal computer or the phone market where the numbers are in the tens of millions or hundreds each year. It's just not comparable.

>But not in manufacturing it.

LLMs won't build you a frontier fab that's for sure, but the point is that you don't necessarily need the latest'n'greatest with diminishing returns. An RTX 5090 is like ten times faster than a GTX 980 released 12 years ago. It doesn't run games which are ten times better. Similarly, something like the Galaxy S26 is ~7 times faster than an S6 around that time. Is it seven times better to use? Of course not :P

So the conclusion is that the performance the architecture you need to reach isn't an ever-racing frontier, you can make a new product (and in this hypothetical case, a product focused on openness) without having SOTA performance.

For a case of an "alternate" product like this, just see the Switch - much slower than "normal" consoles, good form factor, portable, and fairly cheap to produce. No one cares that it doesn't do 4K when undocked.

But software isn't like traditional academia. It might have grown from it but most advances aren't really published in the traditional sense, you've got blogposts, presentations and source code instead.

This would be like teaching cooking without looking at any recipes, just from physics and first principles. Or learning music without looking at the sheet music / listening to any existing songs, just generic musical theory and chords. I don't think humans can do it "zero-shot" either...

Fair enough, but as things stand now, the usual LLM-assisted piece of software is usually also partly or wholly LLM-designed too. Not just implemented on a function level or a file level. And LLM design is usually called "slop" because it's nothing spectacular unless you bring fresh ideas to it from a human perspective.

Hand-written memory leaks don't have a market but hand-designed software with hand-designed UX and a hand-designed vision does :)

They can write any EULA they want but it's not like they will be able to enforce it in a meaningful way, to be fair. You can't legislate modding away, that's like legislating piracy away, which has famously failed. Music piracy wasn't killed by banning it, it has shrunk in importance because Spotify is fairly cheap and easy. Despite that, many people do still pirate music.

In the hypothetical GTA VI case, what can they do about it? Take just about any historical data leak, in pretty much zero cases anyone has been able to scrub all copies of it from the internet. There's plenty of lost media, the stuff no one cares about. But if enough people care about, it can't really be scrubbed away.

That's right, but other closed systems are kind of withering away (the two major consoles - Xbox and Playstation - are dying in favour of PC gaming).

We're at an inflection point because hardware progress has slowed down and while the mobile duopoly does benefit from network effects, in the long run those are outweighed by missteps by the incumbents. See how Windows has been a monopoly on the PC market for ages, then they've dropped the ball, Linux has grown then Microsoft got their shit together somewhat in order to catch up.

I don't think open / general-purpose computing is doomed in the future or anything like that, as long as there is demand for it, someone will supply it.

And LLMs can also help you design your own hardware in the worst case:)

I mean, they can write anything in their EULA, I'm talking about enforcement. Sure, most free software advocates are squeamish about good old fashioned piracy today but I don't think that's an immutable fact of life.

The best anyone can do is send takedowns to GitHub / other websites hosting the code or downloads but it's trivial to upload them to random russian code forges or whatever.

To be fair, you also don't restrict yourself to those texts either. You read news, you use other programs, you look at websites and so on. And while the norms vary per field, things aren't really reinvented from scratch. The standard FPS controls aren't reinvented for every shooter game. The standard website layouts aren't reinvented for every website. The standard command line behaviour isn't reinvented for every CLI program and so on.