• 0 Posts
  • 27 Comments
Joined 1 year ago
cake
Cake day: June 27th, 2023

help-circle






  • From the perspective of a computer engineer SSDs are painfully slow. Waiting for data on disk is slow enough that it is typically done by asking the OS for the data and having the OS schedule another process onto the CPU while it waits. RAM is also slow although not nearly as slow. Ideally you want your data in the L1 cache which is fast enough to minimally stall the CPU. The L2 and L3 caches are slower but larger and more likely to have the data you want. If the caches are empty and you have to read RAM your CPU will either do a lot of speculative execution or more likely stall.

    Speculative execution on CPUs is a desperate attempt to deal with the fact that all memory access is slow by just continuing through the code as if you know what is in memory. If the speculative execution is wrong a lot of work gets thrown out (hopefully nothing unsound happens) and the delay is more noticable.

    Bluntly an SSD only system would probably be an order of magnitude slower. I’m also not sure switching to a new process (or even thread) to load from SSD would be viable without RAM as it would likely invalidate a lot of cache triggering more loads.




  • Getting anti-cheat that technically already works enabled on Linux has been a lot of work and Epic still won’t enable it. Piracy protection systems will also be an issue. Most EA games inspect your CPU to see if they like it on startup (I think this is using vmprotect and some non-OS x86 calls but don’t quote me on that). These kinds on anti virtualization checks are really common (not just in games ProctorU and lock down browser do them too). I don’t think valve running an open virtualization layer will be well received by companies and they will probably ban it from running games. MMOs (due to botting) and anything with anticheat will look particularly askance at this. I also suspect Valve won’t want to try hiding the VM signatures as it borders on violating DMCA.

    Newer games will probably get ported if a large part of the market buys into ARM. Unity stuff might get re-released as it is .net if the publishers can be bothered. Minecraft java edition will also always love you (the launcher might not though).


  • The main advantage of ARM right now is that there are low power cores available. The actual instruction set is unrelated to this advantage. If Intel or AMD put more serious effort into power efficiency most of the advantages go out the window.

    As for instruction set changes impacting what software you can run I think that is still a big issue. Yes porting to ARM is straitforward in more modern programming environments but most software actively developed at the moment has a lot of old cruft that won’t easily port if the engineers can even be convinced to touch it. Most businesses are dependent on old software not all of which is still maintained. Most gamers are even more tied to old software that is not going to get ported and often has annoying anti-virtualization checks (see games breaking on systems with enabled intel e-cores).

    I am not sure how large the modern non gaming personal pc market is (tablets, phones, works computers, and chromebooks probably took a chunk out of it) but that could be in play.










  • #2 is also the most insideous to update. Add another indented line to one of the conditions and the cotrol flow completely breaks while visually appearing fine.

    C and a number of other languages have annoying pair of parallel syntax systems that makes it easy for people to read code one way and computers to compile it another. People read the indentation and newlines while compilers count braces and semicolons. #2 gets rid of the braces and makes control flow driven by semicolons making human visual inspection more likely to fail