Richard W.M. Jones, a Red Hat engineer, writes about Linux virtualization, OCaml, Forth, RISC-V, FPGA tools, and libguestfs.
HN links it for JonesForth, praised as an excellent literate programming example, plus his comparison of foreign function interfaces and open source FPGA tooling.
Those are numbers from 7 years ago, so they're beginning to get a bit stale as people start to put more weight behind having frame pointers and make upstream contributions to their compilers to improve their output. People put it at <1% from much more recent testing by the very R.W.M. Jones you're replying to [0] and separate testing by others like Brendan Gregg [1b], whose post this is commenting on (and included [1b] in the Appendix as well), with similar accounts by others in the last couple years. Oh, and if you use flamegraph, you might want to check the repo for a familiar name.
Some programs, like Python, have reported worse, 2-7% [2], but there is traction on tackling that [1a] (see both rwmj's and brendangregg's replies to sibling comments, they've both done a lot of upstreamed work wrt. frame pointers, performance, and profiling).
As has been frequently pointed out, the benefits from improved profiling cannot be understated, even a 10% cost to having frame pointers can be well worth it when you leverage that information to target the actual bottlenecks that are eating up your cycles. Plus, you can always disable it in specific hotspots later when needed, which is much easier than the reverse.
Something, something, premature optimisation -- though in seriousness, this information benefits actual optimisation, exactly because we don't have the information and understanding that would allow truly universal claims, precisely because things like this haven't been…
That problem is mostly because ARM SoCs don't even have the concept of a standardised bootloader or dynamic device discovery like x86 chipsets which means every SoC needs it's own custom bootloader and it's own custom kernel where the available devices must be hardcoded.
See basically any single board ARM computer which suffer from the exact same problem. This is why the community forms around the specific device rather than the architecture in general.
ARM's openness ironically makes it unsuitable as an open software plaftorm whereas on x86 you just put your iso on a flash drive and it works pretty much everywhere.
BIOS/UEFI might be bloated but at the very least it actually achieved what it set out to do, meanwhile we are still waiting for the ARM SoC manufacturers to adopt a standard.
Source: https://rwmj.wordpress.com/2013/08/08/bring-back-the-bios/
From the "rant" rwmj just posted a link to:
https://rwmj.wordpress.com/2010/02/18/why-the-windows-registry-sucks-technically/
>This misses the point: the Registry is a filesystem. Sure it’s stored in a file, but so is ext3 if you choose to store it in a loopback mount. The Registry binary format has all the aspects of a filesystem: things corresponding to directories, inodes, extended attributes etc.
> The major difference is that this Registry filesystem format is half-arsed. The format is badly constructed, fragile, endian-specific, underspecified and slow.
Anyway, file systems and databases are essentially similar, the point revolves more around the poor implementation of the Registry (whatever it is).
[Disclosure: I spend a (not too large) _portion_ of my time on the OpenStack Compute project, so adjust my comments for bias.]
Please. You seem to be making the same mistake, that many make on blogs and news websites, of exclaiming "containers are the future!" while both VMs and containers have their place and use-cases.
I'd rather suggest you read the below. (Since I'm linking to a blog, quick background about the author: Rich is one of the long-time contributors of KVM-based Virtualization stack and the lead author / maintainer of libguestfs.org)
https://rwmj.wordpress.com/2013/06/19/the-boring-truth-full-virtualization-and-containerization-both-have-their-place/
We live in a world where MongoDB is at the butt-end of all Database and ACID jokes.
But the award should go the Windows Registry, a Key-Value store that combines the drawbacks of a half-assed filesystem with the advantages of piping your database to /dev/null.
A Database would be capable of using an index to traverse all the keys. The Registry does a linear lookup at each pathnode.
There is a good blogpost [https://rwmj.wordpress.com/2010/02/18/why-the-windows-registry-sucks-technically/] that details the insanity of a database that managed to be worse than MongoDB at the lowest level of jokes before MongoDB was even invented.
At least 4 companies are working on server-class chips, targeting "Xeon-like" performance. Of course without actual hardware to test you should take those claims with a grain of salt for the moment.
If you want a cheap, low-end single board computer you can use right now, then I'd go for either the Vision Five 2 or the Sipeed Lichee Pi 4A. Performance won't be that great, but it'll run Fedora, Debian, Ubuntu or Yocto distros pretty much out of the box. I'm working on a Hifive Unmatched vs VF2 vs Sipeed vs Raspberry Pi 4B performance comparison right now, which will appear on https://rwmj.wordpress.com