> resulting VM outperforms both my previous Rust implementation and my hand-coded ARM64 assembly
it's always surprising for me how absurdly efficient "highly specialized VM/instruction interpreters" are
like e.g. two independent research projects into how to have better (fast, more compact) serialization in rust ended up with something like a VM/interpreter for serialization instructions leading to both higher performance and more compact code size while still being cable of supporting similar feature sets as serde(1)
(in general monomorphisation and double dispatch (e.g. serde) can bring you very far, but the best approach is like always not the extrem. Neither allays monomorphisation nor dynamic dispatch but a balance between taking advantage of the strength of both. And specialized mini VMs are in a certain way an extra flexible form of dynamic dispatch.)
---
(1): More compact code size on normal to large project, not necessary on micro projects as the "fixed overhead" is often slightly larger while the per serialization type/protocol overhead can be smaller.
(1b): They have been experimental research project, not sure if any of them got published to GitHub, non are suited for usage in production or similar.
A new Go protobuf parser [1] made the rounds here eight months ago [2] with a specialized VM that outperforms the default generated protobuf code by 3x.
It doesn't make sense to me that an embedded VM/interpreter could ever outperform direct code
You're adding a layer of abstraction and indirection, so how is it possible that a more indirect solution can have better performance?
This seems counterintuitive, so I googled it. Apparently, it boils down to instruction cache efficiency and branch prediction, largely. The best content I could find was this post, as well as some scattered comments from Mike Pall of LuaJIT fame:
Interestingly, this is also discussed on a similar blogpost about using Clang's recent-ish [[musttail]] tailcall attribute to improve C++ JSON parsing performance:
> It doesn't make sense to me that an embedded VM/interpreter could ever outperform direct code. You're adding a layer of abstraction and indirection, so how is it possible that a more indirect solution can have better performance?
It is funny, but (like I’ve already mentioned[1] a few months ago) for serialization(-adjacent) formats in particular the preferential position of bytecode interpreters has been rediscovered again and again.
The earliest example I know about is Microsoft’s MIDL, which started off generating C code for NDR un/marshalling but very soon (ca. 1995) switched to bytecode programs (which Microsoft for some reason called “format strings”; these days there’s also typelib marshalling and WinRT metadata-driven marshalling, the latter completely undocumented, but both data-driven). Bellard’s nonfree ffasn1 also (seemingly) uses bytecode, unlike the main FOSS implementations of ASN.1. Protocol Buffers started off with codegen (burying Google user in de/serialization code) but UPB uses “table-driven”, i.e. bytecode, parsing[2].
The most interesting chapter in this long history is in my opinion Swift’s bytecode-based value witnesses[3,4]. Swift (uniquely) has support for ABI compatibility with polymorphic value types, so e.g. you can have a field in the middle of your struct whose size and alignment only become known at dynamic linking time. It does this in pretty much the way you expect[5] (and the same way IBM’s SOM did inheritance across ABI boundaries decades ago): each type has a vtable (“value witness”) full of compiler-generated methods like size, alignment, copy, move, etc., which for polymorphic type instances will call the type arguments’ witness methods and compute on the results. Anyways, here too the story is that they started with native codegen, got buried under the generated code, and switched to bytecode instead. (I wonder—are they going to PGO and JIT next, like hyperpb[6] for Protobuf? Also, bytecode-based serde when?)
You could probably rephrase almost any enum dispatch whatsoever as a "bytecode interpreter" of a sort, especially if run recursively to parse over some kind of sequence. If bytecode helps you achieve a more succinct representation of some program code than the native binary representation for your architecture, it makes sense that this could be faster in some cases.
Yeah, Clang's musttail and preserve_none make interpreter writing much simpler, just make yourself a guaranteed tail call opcode dispatch method (continuation passing style works a treat here), stitch those together using Copy-and-Patch and you have yourself a down and dirty jit compiler.
the problem here is more the programs you run on top of the OS (browser, electron apps, etc.)
realistic speaking you should budged at least 1GiB for you OS even if it's minimalist, and to avoid issues make it 2GiB of OS + some emergency buffer, caches, load spikes etc.
and 2GiB for your browser :(
and 500MiB for misc apps (mail, music, etc.)
wait we are already at 4.5 GiB I still need open office ....
even if xfc would safe 500 MiB it IMHO wouldn't matter (for the recommendation)
and sure you can make it work, can only have one tab open at a time, close the browser every time you don't need it, not use Spotify or YT etc.
but that isn't what people expect, so give them a recommendation which will work with what they expect and if someone tries to run it at smaller RAM it may work, but if it doesn't it at least isn't your fault
they compared the Ubuntu minimal recommended RAM to Windows absolute minimal RAM requirements.
but Windows has monetary incentives (related to vendors) to say they support 4GiB of RAM even if windows runs very shitty on it, on the other had Ubuntu is incentivized to provider a more realistic minimum for convenient usage
I mean taking a step back all common modern browsers under common usage can easily use multiple GiB of memory and that is outside of the control of the OS vendor. (1)
As consequence IMHO recommending anything below 6 GiB is just irresponsible (iff a modern browser is used) _not matter what OS you use_.
---
(1): If there is no memory pressure (i.e. caches doesn't get evicted that fast, larger video buffers are used, no fast tab archiving etc.) then having YT playing likely will consume around ~600-800 MiB.(Be aware that this is not just JS memory usage but the whole usage across JS, images, video, html+css engine etc. For comparison web mail like proton or gmail is often roughly around 300MiB, Spotify interestingly "just" around 200MiB, and HN around 55MiB.
putting aside that MS is too huge to even just know about the names of your senior engineers across the globe and that the mail might have gone directly to spam
there is still the issue that this might have been classified as "a crazy letter"
a lot of the article reminds me of people which might (or might not) have competency but insists they know better and are very stubborn and very bad and compromising on solutions. The subtext of the articles is not that far afar from "everyone does everything wrong, I know better, but no one listens to me". If you frame it like that it very much sounds like a "crazy" letter.
Strictly speaking it reminds me a lot about how Pirate Software spoke about various EA related topics. (Context: Pirate Software was a streamer and confidence man who got complemented up due to family connections and "confidently knew" everything better while having little skill or contributions and didn't know when to stop having a "confidently bad" opinion. Kinda sad ending given that he did motivate people to peruse their dream in game design and engage themself for animal protection.).
Or how I did do so in the past. Appearing very confident in your know-how ironically isn't always good.
And in case it's not clear: The writing reminding me of it and having patters of someone trying to create a maximally believable writing to make MS look bad doesn't mean that he behaves like that or that the writing is intended to be seen that way.
It's more about how we have a lot of "information" which all look very believable, but in the end miss means to both: Verify many of the named "facts". And, more importantly, judge the sentiment/implicit conveyed information.
Especially if we just take the mentioned "facts" without the implicit messages and ignore the him<->management communication issues I would guess a lot of that is true.
In many cases the understanding of the term "touch typing" isn't just "typing without looking" but a very specific way of doing so.
You should be able to type without looking at your keyboard.
But the specific 5 finger arrangement taught often as "tough typing" isn't needed for that, some common issues:
- it being taught with an orthogonal arrangement of your hand to they keyboard, that is nearly guaranteed to lead to carpal tunnel syndrome if you have a typical keyboard/desk setup. Don't angle your wrist when typing.
- Pinky fingers of "average" hands already have issues reaching the right rows, with extra small or extra short hands they often aren't usable as intended with touch typing.
IFF we interpret "touch typing" as the typical thought typing method and not just "typing without looking at the keyboard".
In general key arrangement traces back to physical limitations of type writers not ergonomics and layout choice isn't exactly ergonomic based either.
But even if it where, the biggest issue of touch typing is that it's often thought around the idea of your hands being somewhat orthogonal to your keyboard, _which they never should be_ (if you use a typical keyboard on a typcal desk setup) as it leads to angling you hands/wrist which is nearly guaranteed to cause you health issues long term if you are typing a lot.
The simple solution is to keep your wrist straight leading to using the keyboard in a way where you hand is at an angle to it's layout instead of orthogonal which in turn inhibits perfect touch typing. But still allows something close to it.
As keys are arranged in shifted columns this kinda works surprisingly well, an issue is the angle differs depending on left/right hand :/
Split or alice style keyboards can also help a bit, but I often feel man designs kinda miss the point. Especially many supposedly ergonomic keyboards aren't aren't really that ergonomic, especially if your hand is to large, small, or otherwise unusual...
Which brings us to the next point, human autonomy varies a lot, some people have just some very touch typing incompatible hands, like very short pinky fingers making that finger unusable for typical touch typing (even with normal hands it's a bit suboptimal which is why some keyboards shift the outer rows down by half a row).
Anatomy might matter if you're talking about world champion speed typing. I don't think it matters for just being competent (I say this as a man with short and fat fingers)
you posted this twice, probably accidentally in context of some connectivity issues or accidental navigation (at least that way it happened to me before)
but Trump also now has a excuse to abandon Ukraine,
and a excuse to lifte trade Embargos on Russian Oil (he already did)
this might still not change the outcome of the war, but might still be more useful then drone parts in the sense that if you either don't have money to buy drone parts or the seller stops selling you are better of with money?
and maybe he hopes for a Iranian terrorist attack before the midterms so that he can use that as an excuse to not have proper Election (Iran using terrorism for retaliation when other means fail isn't exactly new, so this isn't even that unlikely and a iff we assume he or the people consulting him really are that evil, then a false flag attack is also an option.)
quite good for China to better understand US military capabilities
maybe good for Trump if he wants to come up with excuses to fully size government power / avoid or fake mid term elections or even "just" frighten voters that if the a government change happens now it will be "very bad" for the US etc.
bad for the US (both as a supper power and for it's citizens)
and if escalating (which seems very likely) potentially far worse for Europe, Turkey and likely some other places because the refuge wave this can cause is one a completely different level then the one by Syria (like >4x times as bad if worst comes to worst, 1)
simple put for all those who want to destroy democracy in the west this is grate in many ways.
---
1: Syria had ~21 Mil citizens before the war, Iran has ~92 Mil + 9 Mil refuges from Afghanistan + others. In general Iran is the land wich currently houses the largest number of refuges AFIK. If thinks go bad this are the people which often will have to flee first. To make matters worse there is a ongoing drinking water crisis, even without a ware or destroyed desalination plants Iran might need to evacuate Tehran (~10 Mil).
it's always surprising for me how absurdly efficient "highly specialized VM/instruction interpreters" are
like e.g. two independent research projects into how to have better (fast, more compact) serialization in rust ended up with something like a VM/interpreter for serialization instructions leading to both higher performance and more compact code size while still being cable of supporting similar feature sets as serde(1)
(in general monomorphisation and double dispatch (e.g. serde) can bring you very far, but the best approach is like always not the extrem. Neither allays monomorphisation nor dynamic dispatch but a balance between taking advantage of the strength of both. And specialized mini VMs are in a certain way an extra flexible form of dynamic dispatch.)
---
(1): More compact code size on normal to large project, not necessary on micro projects as the "fixed overhead" is often slightly larger while the per serialization type/protocol overhead can be smaller.
(1b): They have been experimental research project, not sure if any of them got published to GitHub, non are suited for usage in production or similar.
reply