Given that games tend to be deployed on a wide range of computers, it's hard for them to use newer x86 extensions (e.g. AVX), while most scientific computing applications tend to be compiled for a specific machine. To get to see the larger improvements, you must use the newer instructions and registers, like you can see in BLAS benchmarks[1].
Yep, at my old job we still had to support Windows XP 32 bit for the game client (internal tools were Windows 7 64 bit) as so many people were still playing on systems. I don't remember if we could use SSE2 or what the minimum was in that regard.
> Seems like they are being optimized to be better at vector math, and games just happen to highly use these pieces of HW.
It may in fact be that desktop/mobile CPUs are being optimized for their contemporary benchmark suites, thus targeting the ensuing benefits in marketing. The benchmarks themselves were, for a fair amount of their existence, focused on games-related performance, at least from what I recall.
I don't mind the downvotes, but more interested to know why if anyone cares to comment? I should have specified that by desktop/mobile, I do mean desktop/laptop essentially (and, not smartphone CPUs). And, I am talking about Intel/AMD largely, and how I perceive their evolution over the past two and half decades.
In short, I think "optimizing for games" means nothing to a CPU designer at say Intel, and anyways qualitative differences (expanding the ISA, or integrating new features on the IC) are more expensive to develop and sometimes tricky to market. Instead, marketing quantitative differences is much easier (hence optimize for benchmarks) - though arguably no easier to develop. Witness Intel's first rocky attempt at targeting the benchmarks in the early 2000s: Netburst [0]. Of course, in the past 5 years, things have changed (the rise of smartphones, meteoric rise in GPU performance with expanding markets & new software, CPU "per core" performance stagnation), so Intel is in the process of re-positioning itself.
Major time spent developing this game was on the engine and the plan was to reuse this engine on other Konami properties and developing more Kojima games. Also, for sure Kojima is one of the few people who can get away with the time it takes to make his games, but he is also one of the few people in the gaming industry who is doing what he is doing. With the cinematic, the wild story and even though MGS5 didn't have a wild story. Once you start to think just how much engineering and time spent on creating that incredible smart AI, the open world and an engine that can handle all this, its easy to see why it took so long.
"This boot-loader, unfortunately, did not support loading any kernel images larger than 4 megabytes. This turned into a problem very quickly as it turns out that rustc is far less adept than gcc at creating succinct output. In fact, I was hitting this problem so early I was barely able to make a “Hello World” before having to stop working on rust code."
This really caught me. I have not played around with rust that much but having the executable be over 4MB, with such a small program such as just a Hello World is kind of nuts. I know that they still have lot of compiler optimization, but I just thought that was a very interesting portion of the read.
The actual kernel binary was smaller but the loader s limit was based on the amount of memory the kernel laid out in memory takes, including anonymous sections.
Also turning on optimizations in rust and the linker helped a lot but were not enough in the end.
I guess you are the author of linked paper. Well done.
I wonder if you have any opinions on how useful higher-kinded types (HKTs), one of the most requested features for Rust, would have been in implementing this OS. For example the absence of HKTs means that Rust can't have smooth and general handling of monads that is comparable to Haskell's. Would Haskell-style monads or Arrows have been helpful?
I believe HKT would have been useful but am not really sure how much HKT would have helped me overall. They would likely have been most useful (if at all) in the VFS/S5FS/VM stages that I was unable to fully get to.
Honestly, I have not used haskell enough to definitively say whether monads/arrows would have been useful.
Ah, so all memory used by the kernel must be listed in sections loaded by the bootloader? As opposed to the normal situation where the kernel just starts grabbing it from the hardware?
I know no specifics of the situation, but llvm optimisations can be manually toggled through rustc. Maybe there are more special-case optimisations that could help.
Unfortunately, the kinds of people who care about that sort of thing overlap heavily with rust's intended user base.
Also, end users might not care that much about binary size, but distribution maintainers do -- they want to fit as much functionality they can within a reasonable-sized iso download. If including a rust program in the base OS means omitting a dozen C programs that would have fit in the same space, that's a hard sell.
I am optimistic that these kinds of issues will be worked out as the language stabilizes and the tools improve.
"CPU designers see vastly more benefit to spending area on, e.g.,vectorized floating-point multipliers."
followed by "Intel is doubling the vector size in its newest CPUs---again!---this time from 256 bits to 512 bits."
Seems like they are being optimized to be better at vector math, and games just happen to highly use these pieces of HW.