It's more than thousands, and not only it's not reasonable, it's not possible.
Plenty of games run on some critical optimizations that exploit native code quirks that may or may not hold up only because Windows papers over them by special-casing the game process at OS level. The source of such games may be stuck in IP limbo, with five different studios/companies claiming ownership (three of them dead or bankrupt), and even then, the only person who knows what and how needs to be reimplemented is on a remote tropical island, working for a competitor / happily retired / stuck collecting trash for a living, depending on how their career went.
Takes only a few such cases to turn out to be some well-known games with substantial legacy fanbase hoping to relive some childhood memories, to risk seriously damaging the "supporting everything" marketing angle.
Emulating underlying runtime is safer and more practical choice.
This is what Android does with Dalvik/Android Runtime. Apps you download from the store are compiled to bytecode that is then compiled to native code at installation time.
With the compilation making use of the native instruction set supported for your device, so it can make use of newer arm instructions on newer devices while still supporting older devices.
This is the major reason app installation is so slow in Android compared to iOS (which pre-compiles everything). But it also greatly improves app compatibility with older versions.
There is no way Valve would be able to convince all the myriad of game engine developers to support a proprietary (or even open source) bytecode format even in the future. Best they could do is make it an opt-in.
Android only pulled it off because Google provides the "engine" (Android SDK) for all apps made for the platform and it did from the start.
And even so, most Androids games actually bypass this system entirely and just hand-compile to native binaries anyway. Because, again, the game engines don't want to support this bytecode format and google doesn't offer a C++ toolchain themselves that the engine developers could integrate with.
> Apps you download from the store are compiled to bytecode that is then compiled to native code at installation time.
This is only true in Android 5 and 6.
Starting with Android 7, due to amount of time it took to compile in tiny ARM CPUs, limited optimisation levels, and Java's dynamic abilities, there was a full reboot of this process.
Which is an Assembly hand written interpreter, intended to allow for quick startup in case the JIT cache is empty, a JIT compiler, and an AOT compiler that only compiles the hot paths that the JIT already had a look into, and during idle times while charging so that it can have the CPU all for itself when doing optimisations.
Additionally several other measures were taken to optmise this process, via Play Store Services, devices can share PGO data gathered by the JIT so that each device doesn't have to start from scratch, thus the interpreter step can be skipped when metadata is available. To further improve this process, developers can do training runs, and ship the metadata themselves on the APKs.
Also during the compilation to native code, depending on code access patterns, the executable code gets remapped so that there is an optimal alignment for the instruction cache when reading from the executable code cache.
Google certainly offers clang as part of the NDK, and game development is one of the few officially supported scenarios to run native code on Android.
Your message seems to be arguing both points at the same time - at least that's how it reads to me; first, that it's absolutely feasible to do this because Android did, and then, that in reality game developers there casually defeated those efforts anyway.
"It's not reasonable to expect thousands of existing games to port to ARM"
Realistically it is possible and not actually that difficult. The hardest part would be ensuring that specific code changes from older x86 code to modern ARM code actually translate over properly and perform as expected. The majority of work done there would have to be in the libraries that were used to build the game. For way older games, like the ones you'd run under DOS, it would be much easier, as most stuff was in ASM and C (you did have the occasional BASIC game or PASCAL game flying around which would likely need a little bit of extra work) so you'd just be doing direct translation of instructions.
> Under a comment that reads // Workaround for trailing slashes, my code tacks an “a” onto the path so there’s always a last segment to cut off, then cuts it off with a find-and-replace. When the path ends in a slash, that last segment is just the “a”, and the find-and-replace takes every other “a” in the path with it.
This is top-tier. left-pad levels of "we should just implement trivial functions in our own codebases"
(I do not mean that as a knock on the author - it solved his use case just fine. Everyone who took a dependency on it afterward though...)
> they were down for 7.5% of the time I needed them, or had business hours uptime of 92.5%
You can obviously compute this for a particular customer, but being a global service, it's pretty much guaranteed that someone somewhere experienced the worse of those numbers
You can compute them for the average. In other words, the total customer impact is the number of business-hours of downtime across all customers divided by the total number of business hours of all customers.
This is important because it's quite possible that the downtime is biased toward the times they have the most active users.
Big systems worth their salt already do this as weighted uptime, considering request successes / total requests rather than wall clock uptime as internal SLOs. But these numbers aren't really ever published because it gives away information about your customer base.
"Failed customer interactions" - if you have a way to actually see requests before they hit your datacenter, e.g. some async third party client libraries.
On this topic, as a service operator, it's really nice when you also own your SDKs, and have client-side telemetry about failed requests. Gives you a much clearer picture of end-to-end reliability (at least for the subset of customers who opt-in to telemetry)
Well, someone on the business side of the house is free to negotiate. Whether engineering learns about the contract before sales has inked a 6-nines availability guarantee varies wildly by the company
The argument that models are conscious only during training, and not conscious during inference feels like a painful one to make. Are we killing models when they reach the training objective?
Technically we are killing models when they don't reach the training objective by throwing those weights away via survival of the fittest (fit meaning what we humans think we want).
Kinda like creating quantum copies of your child and keeping the ones that answer correctly and shooting the other ones in the face.
I remember a delightful trip to Canada, where I ordered a hamburger, and they'd only let me have it well-done. I asked why, and the waitress says "The beef comes from the US", with a grimace...
They still have to support the entire back-catalog. It's not reasonable to expect thousands of existing games to port to ARM
reply