HDDs also have a spinning medium and a read head , so the optimization is similar to optical media like CDs.
Let’s say you have UI textures that you always need, common player models and textures, the battle music, but world geometry and monsters change per stage.
Create an archive file (pak, wad, …) for each stage, duplicating UI, player and battle music assets into each archive. This makes it so that you fully utilize HDD pages (some small config file won’t fill 4kb filesystem pages or even the smaller disk sectors). All the data of one stage will be read into disk cache in one fell swoop as well.
On optical media like CDs one would even put some data closer to the middle or on the outer edge of the disc because the reading speed is different due to the linear velocity.
This is an optimization for bandwidth at the cost of size (which often wasn’t a problem because the medium wasn’t filled anyway)
> HDDs also have a spinning medium and a read head , so the optimization is similar to optical media like CDs.
HDDs also have to real with fragmentation, I wonder what the odds that you get to write 150 GBs (and then regular updates in the 30GB range) without breaking it into fragments...
Microsoft has a paper somewhere that shows IO speed starts to drop when fragments of files get below 64MB. So you can split that file up into a few thousand pieces without much performance loss at all.
The game installer can't control the layout on an HDD without doing some very questionable things like defragging and moving existing user files around the disk. It probably _could_ but the risk of irrecoverable user data loss or accidentally corrupting a boot partition via a bug would make it completely not worth it.
Even if you pack those, there's no guarantee they don't get fragmented by the filesystem.
CDs are different not because of media, but because of who owns the storage media layout.
It's less about ensuring perfect layout as it is about avoiding almost guaranteed terrible layout. Unless your filesystem is fully fragmented already it won't intentionally shuffle and split big files without a good reason.
Single large file is still more likely to be mostly sequential compared to 10000 tiny files. With large amount of individual files the file system is more likely to opportunistically use the small files for filling previously left holes. Individual files more or less guarantee that you will have to do multiple syscalls per each file and to open and read it, also potentially more amount of indirection and jumping around on the OS side to read the metadata of each individual file. Individual files also increases chance of accidentally introducing random seeks due to mismatch between the order updater writes files, the way file system orders things and the order in which level description files list and reads files.
I don't disagree that large files are better, or at least simpler. I do think gaming drives are more likely than most to be fragmented (large file sizes, frequent updates plus uninstalling and re-installing). A single large file should make the next read predictable and easy to buffer.
I am a little curious about the performance of reading several small files concurrently versus reading a large file linearly. I could see small files performing better with concurrent reads if they can be spread around the disk and the IO scheduler is clever enough that the disk is reading through nearly the whole rotation. If the disk is fragmented, the small files should theoretically be striped over basically the entire disk.
TFA says performance might be worse, but it’s easy to beat libc because it supports different formats etc that you don’t need. Float parsing is tough to beat, but only if you want perfect precision for the full range. If you just parse millions of physical distance measurements from some csv you don’t have such issues either.
Sometimes you double click and it opens everything just fine and silently corrupts and changes and drops data without warning or notification and gives you no way to prevent it.
The day I found that Intellij has a built in CSV tabular editor and viewer was the best day.
I’m not a blind person but I was curious about once when I tried to make a hyper-optimized website. It seemed like the best way to please screen readers was to have the navigation HTML come last, but style it so it visually comes first (top nav bar on phones, left nav menu on wider screens).
Props to you for taking the time to test with a screen reader, as opposed to simply reading about best practices. Not enough people do this. Each screen reader does things a bit differently, so testing real behavior is important. It's also worth noting that a lot of alternative input/output devices use the same screen reader protocols, so it's not only blind people you are helping, but anyone with a non-traditional setup.
Navigation should come early in document and tab order. Screen readers have shortcuts for quickly jumping around the page and skipping things. It's a normal part of the user experience. Some screen readers and settings de-prioritize navigation elements in favor of reading headings quickly, so if you don't hear the navigation right away, it's not necessarily a bug, and there's a shortcut to get to it. The most important thing to test is whether the screen reader says what you expect it to for dynamic and complex components, such as buttons and forms, e.g. does it communicate progress, errors, and success? It's usually pretty easy to implement, but this is where many apps mess up.
”Each screen reader does things a bit differently, so testing real behavior is important.”
Correction: each screen reader + os + browser combo does things a bit differently, especially on multilanguage React sites. It is a full time job to test web sites on screen readers.
If only there was a tool that would comprehensively test all combos on all navigation styles (mouse, touch, tabbing, screen reader controls, sip and puff joysticks, chin joysticks, eye trackers, Braille terminals, etc)… but there isn’t one.
Wouldn’t that run afoul of other rules like keeping visual order and tab order the same? Screen reader users are used to skip links & other standard navigation techniques.
Just to say, that makes your site more usable in text browsers too, and easier to interact with the keyboard.
I remember HTML has an way to create global shortcuts inside a page, so you press a key combination and the cursor moves directly to a pre-defined place. If I remember that right, it's recommended to add some of those pointing to the menu, the main content, and whatever other relevant area you have.
The original repo is about using a subset of a language to compare language implementations. I can see the point in that. But language benchmarks like this are incredibly useless and very easy to get wrong anyway. For example it you actually cared about performance for the bounce example you would never write it like this in C. Bouncing 100 balls in a loop 50 times with 4 ifs just tests the branch predictor. There is nothing to learn from this in practice.
Respectfully disagree. This is a compiler engineering tool backed by peer-reviewed research (DLS'16, 112+ citations) and used in 30+ academic publications across PLDI, OOPSLA, and ECOOP. It requires understanding controlled experimental methodology and compiler optimization theory to interpret correctly. Perhaps that context clarifies its purpose. The goal is to assess compiler effectiveness for a common set of core language abstractions (objects, closures, arrays), not to represent application-level performance or claim that production C code would be written this way. Your "branch predictor" criticism actually validates the benchmark's design: if different language implementations handle the same branching patterns with dramatically different performance, that reveals genuine differences in compiler designs.
When he introduces himself to a new audience on podcasts his standard intro is that he is not a performance guy, and he refers to his past colleagues who he learned a lot from as being on a higher tier than him.
He preaches reasonable performance instead of completely shitting the bed or optimization to the maximum (although he also teaches that).
Look at the JetBeans Java challenge on YouTube where he coaches a (imo below average) programmer. He is very kind. So your assessment just seems unfair to me.
Yeah, maybe I’m wrong. I don’t know him and I’ve never interacted with him personally. That’s just the vibe that I’ve got after seeing various pieces of his stuff over the years. Just trying to describe how the title made me feel personally.
I implemented the OpenGL API for fixed function hardware once, and chose the cut off at 1.5 with some extensions like framebuffer objects. 1.x has a lot of cruft that nobody should use, but is still easy to implement. 2.x has a lot of stuff like shaders that are a lot more work to implement in software.
Let’s say you have UI textures that you always need, common player models and textures, the battle music, but world geometry and monsters change per stage. Create an archive file (pak, wad, …) for each stage, duplicating UI, player and battle music assets into each archive. This makes it so that you fully utilize HDD pages (some small config file won’t fill 4kb filesystem pages or even the smaller disk sectors). All the data of one stage will be read into disk cache in one fell swoop as well.
On optical media like CDs one would even put some data closer to the middle or on the outer edge of the disc because the reading speed is different due to the linear velocity.
This is an optimization for bandwidth at the cost of size (which often wasn’t a problem because the medium wasn’t filled anyway)
reply