armv8/VMSAv8-64 has huge table support with optional contiguous bit allowing mapping up to 16GB at a time [0] [1]. Which will result in (almost) no address translations on any practical amount of memory available today.
Likely the issue is between most user systems not configuring huge tables and developers not keen on using things they can't test locally. Though huge tables are prominent in single-app servers and game consoles spaces.
Then it will be too noisy or too slow to be useful due to too many intermediate states. The feature of TLA+ is that it forces you to greatly dumb down the code to be able to use it, so it's more of verifying an algorithm represented as visual graph blocks rather than verifying assembly instructions.
I understand the wish for a magic bullet to just verify already existing code, but I recon the answer to this is to verify code before it's even written.
Same here with v3 and now being flabbergasted that my "open" project is suddenly dead-ended. (Re)doing an alternative software for PCB v3 is definitely possible, it just runs into economics, at average hourly rate we would put into it it just cheaper to buy decent espresso machine and move on.
Some popular in inner city: Tanto strandbad, Långholmsbadet, Smedsuddsbadet, Fredhällsbadet, Kristinebergsbadet, Brunnsviksbadet. Plenty of folks swim during hot periods in summer.
C# has support for unsafe code / pointer arithmetic / memory pinning / unmanaged types [1]. Using them it's possible to write performant computations where needed.
Mostly integration, for example some library can only be configured via env variables, but a developer might want to configure it from with-in the app it's integrated into and used from.
Also, few weeks ago I found a use for them when trying to pass configuration from Java/Kotlin to C++ library to be used during static constructors (invoked during dlopen) on Android, because at that phase native code cannot call back to JVM.
100% agree for "read only" software, like scanning, diagnostics, etc.
Control software is much more involved topic, let me illustrate it with a scenario: one family member is non-techy but has an insulin pump, another family member is techy and likes to hack around, they made a change to the insulin pump software to "improve it", but by accident the change triggered insulin overdose at night during sleep and family member died. We have rules and regulations not just to have rules and regulations, we have rules and regulations because they are written in blood.
While advocating for ability to freely modifying any life dependant control software is a noble goal, in my opinion it's the wrong end to approach it, instead it would be more constructive if we as computer science industry figure out ways how to make software such as we don't kill people, how to "certify" it in self service fashion (validation passed == no-one will die), etc, it's no trivial and it feels this particular part of our industry is not as developed/main stream as compared to something like civil engineering. If we have easy ways to ensure that modifying software will not lead to death then it will be easier to change the legislation to enforce this freedom.
Did some research on the topic of high bandwidth/high IOPS file accesses, some of my conclusions could be wrong though, but as I discovered modern NVMe drives need to have some queue pressure on them to perform at advertised speeds, as in hardware level they are essentially just a separate CPU running in background that has command queue(s). They also need to have requests align with flash memory hierarchy to perform at advertised speeds. So that's puts a quite finicky limitation on your access patterns: 64-256kb aligned blocks, 8+ accesses in parallel. To see that just try CrystalDiskMark and put queue depth at 1-2, and/or block size on something small, like 4kb, and see how your random speed plummets.
So given the limitations on the access pattern, if you just mmap your file and memcpy the pointer, you'll get like ~1 access request in flight if I understand right. And also as default page size is 4kb, that will be 4kb request size. And then your mmap relies on IRQ's to get completion notifications (instead of polling the device state), somewhat limiting your IOPS. Sure prefetching will help of course, but it is relying on a lot of heuristic machinery to get the correct access pattern, which sometimes fails.
As 7+GB/s drives and 10+Gbe networks become more and more mainstream, the main point where people will realize these requirements are in file copying, for example Windows explorer struggles to copy files at rates 10-25GBe+ simply because how it's file access architecture is designed. And hopefully then we will be better equip to reason about "mmap" vs "read" (really should be pread here to avoid the offset sem in the kernel).
I also work in gaming industry and IMHO it depends on games, usually the biggest fun is on consoles market, people start making AAA games with engines like Unity, Unreal Engine 3/4, Autodesk Stingray (recently was bitsquid) and then they suddenly realize "oh, we are not getting 30 fps here, because of Lua/C++/etc" and then the fun starts: IIRC one game company was even asking Microsoft to add missing intrinsics to xbox one compiler because they were used in PS4 code, and PS4 and X1 are basically almost the same chip :)
I really love time restricted environments, in my opinion they truly liberate programmers: instead of using language/library/tech/pattern/etc-of-choice they suddenly realize "oh, we don't have time for that". Do we need GC? We don't have time for that. Do we need to allocate memory? We don't have time for that. Can we maybe do this enterprise-like tens thousands source code files OOP hierarchy thing? We don't have time for that.
Realtime forces people write less, writing only what actually matters, and all this in my opinion helps people to be better engineers (in-a-way). I just wish it looked more attractable for people - hacking your way out in time/resources constrained systems (like MCU's for example) can be as fun as hacking html/js to make your site behave as you want.
Likely the issue is between most user systems not configuring huge tables and developers not keen on using things they can't test locally. Though huge tables are prominent in single-app servers and game consoles spaces.
- [0] https://docs.kernel.org/arch/arm64/hugetlbpage.html - [1] https://developer.arm.com/documentation/ddi0487/latest (section D8.7.1 at the time of writing)