This is in relation to their TPCH benchmark which can be due to a variety of reasons. My guess would be that they can generate stencils for whole operators which can be transformed into more efficient code at stencil generation time while LLVM-O0 gets the operator in LLVM-IR form and can do no such transformation. Though I can't verify this because their benchmark setup seems a bit more involved.
When used in a C/C++ compiler the stencils correspond to individual (or a few) LLVM-IR instructions which then leads to bad runtime performance. Also as mentioned, on larger functions register allocation becomes a problem for the Copy-and-Patch approach.
TPDE is a framework for writing a back-end for various SSA IRs.
TPDE-LLVM is an LLVM back-end written using TPDE, but TPDE itself is independent of LLVM.
The paper also mentions back-ends written for Cranelift's IR and Umbra IR using TPDE.
> All the money in the world won't change the fact that Source is an outdated pile of garbage.
Given that the engine has been in, essentially, maintenance mode for almost a decade now, that is not really surprising. A more apt comparison would be Source 2 I assume.
> some events can take half a second to make it from a player's action to another player's system
What are events here? At least in normal source this should be impossible for anything movement/input related as the server processes the input each tick and then distributes that to each client (the Apex implementation should still do this). If it takes half a second to forward such an action, the whole server should hang for this time in the eyes of each client.
> The game's input processing is done in relation to framerate
This is a behavior added by Respawn, not something normal Source does.
> The security and anti-cheat in the game is so hamstrung by Source
That is a really broad claim imo. AFAIK CSGO only had this issue once in its lifetime and that was caused not by an issue in the engine but in the matchmaking service. So isn’t it more likely that Respawn just screwed something up?
The author striked out the part about CedarDB not being available -- which is true -- but Umbra is available as a docker container[1] for some time now. The "Umbra paper" linked also contains an artifact[2] with a copy of Umbra as well as some instructions on how to control the back-ends used etc. (Cranelift is not available as an option in the docker versions however)
I kind of disagree with the assumption that baseline compilers are easy to build (depending on your definition of baseline). A back-end like DirectEmit is not easy to write and even harder to verify. If you have a back-end written for your own IR you will likely have to write tests in that IR and it will probably be quite hard to simply port over codegen (or run-) tests from other compilers. Especially in the context of databases it is not very reassuring if you have a back-end that may explode the second you start to generate code slightly differently.
We're working on making this a bit more commoditized but in our opinion you will always need to do some work since having another IR (with defined semantics someone could write a code generator for you) for a back-end is very expensive. In Umbra, translating Umbra-IR to LLVM-IR takes more time than compiling to machine code with DirectEmit.
Also, if it is easy to write them, I would expect to see more people write them.
Copy-and-patch was also tried in the context of MLIR[3] but the exec-time results were not that convincing and I have been told that it is unlikely for register allocation to work sufficiently well to make a difference.
One thing I noticed though is that when autocompleting C++ statements like if or while it will add only the opening curly braces which is a bit annoying but makes sense. But it also sometimes adds them @_@
though I believe in RISC-V‘s case what will happen is that every vendor will have that realization at the same time, not tell anyone and make an extension and now there‘s five different incompatible encodings for the same operation.
The bin packing will probably make it slower though, especially in the bool case since it will create dependency chains.
For bools on x64, I don‘t think there‘s a better way than first having to get them in a register, shift them and then OR them into the result. The simple way creates a dependency chain of length 64 (which should also incur a 64 cycle penalty) but you might be able to do 6 (more like 12 realistically) cycles.
But then again, where do these 64 bools come from? There aren‘t that many registers so you will have to reload them from the stack.
Maybe the rust ABI already packs bools in structs this tightly so it‘s work that has to be done anyway but I don‘t know too much about it.
And then the caller will have to unpack everything again.
It might be easier to just teach the compiler to spill values into the result space on the stack (in cases the IR doesn‘t already store the result after the computation) which will likely also perform better.
Maybe people don‘t because they see, for example, Valve (a billion dollar company) struggling to get GNOME to implement drm-leasing for VR headsets. IIRC they‘ve been at it for multiple years, too.
Or maybe it‘s because the compositor developers are not exactly concerned about ease of development.
To quote a GNOME dev[0] about support for the aforementioned drm-leasing protocol:
> I honestly don't have a problem with forcing clients to implement the portal if they want to work on mutter.
I wouldn‘t blame the people who choose to simply not engage with that process, especially those who work on these things in their free time.
I'm not sure but is this meant ironically? Because taking a screenshot is a thing people do very often. Capturing your screen is, too. Even by third-party programs.
And yet they never put it in the protocol but just said to go to dbus.
> GNOME, KDE, and wlroots have each implemented a different protocol
Is that true? My understanding was that GNOME never put forth a protocol but always did their dbus thing. I know that wlroots proposed a bunch of protocol extensions but those never went anywhere since, well, GNOME didn't want to implement them[1].
Nowadays I think every compositor(?) just implements the xdg-portal stuff.
That‘s a very nice writeup, I like the style. The mix of text to illustrations/memes was really pleasent. I have my reservations about the RISC/CISC nomenclature but I guess that‘s „each to their own“ >.>
As someone who has spent some time figuring out how parts of the kernels work I can sympathize with the pain it probably was (but well worth it given the article imo).
For NT, I think that Windows Internals covers a lot about the stuff one wants to know and Microsoft‘s documentation is also not bad (certainly better than Linux‘s kernel docs imo); it‘s a really good starting point.
For more info about Windows I can recommend gamehacking forums/resources. There‘s a lot of filtering needed but they are a pretty good source of info for niche things sometimes.
As a last note, I noticed that the font of some code blocks are pretty large when viewed on my smartphone making them hard to read (e.g. Ch. 6/main.c)
P.S.:
> If you are a teenager and you like computers and you are not already in the Hack Club Slack, you should join right now
How so? The bootloader already runs in long mode with UEFI and it also takes care of bringing up other cores so this is not really a problem in my experience.
That reminds me of a somewhat funny story. I was listening to a presentation about a startup with about 10 people as you mentioned doing hospital digitalization (gist of it seemed to be sending patient data from one doctor to another). They explained that they wanted to choose a “robust” architecture so they chose microservices (kubernetes and all). I thought that was a bit odd for something hosted at a hospital locally especially because they had like 7 or so services (and maybe even two databases but not sure on that one).
Well, we later asked them how much data they were even handling and (after a bit of side-stepping) they said it was around 200mb excluding images.
That was my “but why?” moment.
Apparently you need 7 services to have a web frontend for 200mb of data with most of it probably never accessed and hospitals can suddenly get three new floors overnight.
CERN at least seems to be using a solution that is running over Ethernet[1] but with custom hardware that is probably fairly expensive. They use a single time source and then measure the delay between each switch/node.
Though, this is limited by needing to be able to run a cable between each node so idk how your definition of a distributed experiment fits.
When used in a C/C++ compiler the stencils correspond to individual (or a few) LLVM-IR instructions which then leads to bad runtime performance. Also as mentioned, on larger functions register allocation becomes a problem for the Copy-and-Patch approach.