Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The time the x86 emulator team found code so bad they fixed it during emulation

devblogs.microsoft.com

Post reply on HN
Print view View original

131–140 of 179 posts

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#131

Post by klodolph »

tom_ wrote: post #124
Someone wrote: post #54

Earlier quoted context omitted.

> Which basically expanded back in the day to 65k reads of 1 byte for several MB file. Each fread translated to 65k reads of ReadFile Windows API What software did that that badly? If the code asks for (up to) 65,536 single byte items, why would you split that into 65,536 calls? Also, that change changes behavior. The old call could read anything from zero to 65,536 bytes, the new one only can read zero or 65,536 byt…

The standard says that fread calls fgetc multiple times for each object: > For each object, size calls are made to the fgetc function and the results stored, in the order read, in an array of unsigned char exactly overlaying the object (wording unchanged since C99) If the file is unbuffered, depending on how the implementation handles buffering, and how it interprets the standard, then perhaps it does end up hitting…

I think it’s pretty rare for files to be unbuffered like that. AFAIK it’s mostly stderr that ends up unbuffered, at least on Unix-like systems.

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#132

Post by ryukoposting »

cranx wrote: post #106

Loop unrolling is a basic compiler optimization and depending on the machine language and processor instruction set should be faster taking into account all the house keeping required to execute a conditional, jump, move register values etc. This article is missing the analysis of why. If someone didn’t “like” it and was offended then that seems like an equally silly reason. On the surface 256k to init less does seem…

A few things to consider.

In this case we're talking about a tight initialization loop with probably a single instruction in the body. The HW optimizations necessary to make a loop like this perform equally to the unrolled form are so rudimentary that they're taken for granted on basically any CPU, even 30 years ago. Seriously, we're talking about optimizations I made in an "intro to Verilog" class as an undergrad, and I'm not even a HW engineer.

It also depends how often this code is being hit. Does the code run once while the program loads? Nobody will notice a 2 microsecond improvement in loading times. Does the code run in a timing-sensitive hot path, like a game loop or a GUI rendering thread? Well now optimization matters. But again, consider the HW argument above.

Also remember that, back then, storage wasn't cheap. 256K of code is 18% of a 1.44MB floppy, and 35% of a 720K floppy.

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#133

Post by zimmund »

I can't stop thinking about all the unoptimized code we have around. As processors (and memory) over the last 2-3 decades improved faster than we needed to fix the inefficiencies we created, we silently accepted that we don't need efficiency everywhere. So maybe a compiler, an emulator or some critical piece of code were created with this in mind, but the average app or website just waste resources left and right and pray for the best.

With more and more code being written with AI (which has notoriously inefficient solutions to simple problems), I expect this issue to become more prevalent. I just hope we optimize at the source of the problem (AI and humans using it) and not on platforms (compiler and engine/kernel heuristics)

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#134

Post by ack_complete »

selcuka wrote: post #14

To be fair it is possible that the developer enabled a special "unroll all loops, no matter what" optimisation flag during compilation. I agree it would be stupid for a compiler to even support such a flag, but those were the 1980s/90s.

Doesn't require any special flags, just hitting optimizer limits can do it with MSVC.

https://www.reddit.com/r/cpp/comments/1i36ahd/is_this_an_msv...

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#135

Post by smallstepforman »

zimmund wrote: post #133

I can't stop thinking about all the unoptimized code we have around. As processors (and memory) over the last 2-3 decades improved faster than we needed to fix the inefficiencies we created, we silently accepted that we don't need efficiency everywhere. So maybe a compiler, an emulator or some critical piece of code were created with this in mind, but the average app or website just waste resources left and right and…

Half the compute and reduce memory by factor of x4 and in a decade we’ll have double the performance we have now.

I do old school embedded, the amount of desktop bloat is insane. Any function I really need to refactor, I can reduce size and improve performance. And there are better engineers out there that are more efficient than me.

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#136

Post by floxy »

spogbiper wrote: post #118
dhosek wrote: post #115

Earlier quoted context omitted.

16 bits? Luxury. I had 6 colors when I was a kid and was happy to have them.

6?!? We had only 4 colors in low res mode and 2 in high res

Well my Hercules graphics card was only monochrome, but it was relatively high resolution.

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#137

Post by tom_ »

klodolph wrote: post #131
tom_ wrote: post #124

Earlier quoted context omitted.

The standard says that fread calls fgetc multiple times for each object: > For each object, size calls are made to the fgetc function and the results stored, in the order read, in an array of unsigned char exactly overlaying the object (wording unchanged since C99) If the file is unbuffered, depending on how the implementation handles buffering, and how it interprets the standard, then perhaps it does end up hitting…

I think it’s pretty rare for files to be unbuffered like that. AFAIK it’s mostly stderr that ends up unbuffered, at least on Unix-like systems.

You can call setbuf(fp,NULL) after opening, and now the stream is unbuffered. What this means is apparently implementation-dependent.

As to why you'd do that? - well, who knows the exact circumstances in this case. Perhaps this was faster in some meaningful case that was relevant to some other project (and then maybe the fread doesn't call fgetc after all!). I'm just speculating. Well-reused code often ends up with stuff that needs rethinking, that, even if noticed, nobody has the time or inclination to attempt to fix.

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#138

Post by smallstepforman »

account42 wrote: post #67
kalleboo wrote: post #52

Earlier quoted context omitted.

Famously if you renamed Quake 3 to "Quack" 3, it would slow down on the ATI Radeon 8500 https://web.archive.org/web/20091016055550/https://hardocp.c...

That's a case of the driver cheating but there are also lots of cases where the game is just full of bugs that the driver has to work around in order to not be blamed for them.

The driver switched to lower mipmapped texture and got caught. There is a ton of that out there for popular benchmark ready games. Run pro drivers instead of adrenaline to run generic baseline real driver.

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#139

Post by rbits »

Cthulhu_ wrote: post #40
dlcarrier wrote: post #11

SimCity had a read-after-free bug that Microsoft patched in Windows 95. That was a lot easier for customers than having Maxis fix it, which could have required exchanging copies of the game.

It feels like graphics drivers do / did this a lot too. At the very least they make specific optimizations for specific games, probably by tweaking settings and features that the game developers didn't optimize properly themselves.

Yep. I know the Minecraft optimisation mod Sodium has encountered some issues because Nvidia drivers try to optimise the game in ways that can cause issues for them

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#140

Post by Xirdus »

exrook wrote: post #130
Xirdus wrote: post #121

Earlier quoted context omitted.

Reminds me of the "community patch" to GTA Online from a few years ago. The game was plagued by 10+ minute loading times. The situation remained for years and only got worse with time. Some hacker figured out that the game spent 80% of loading time reading the in-game store listing file. The file was tens of megabytes IIRC, and it literally used the Schlemiel the Painter's Algorithm - for each entry, start reading fr…

This is not quite an accurate telling of rockstar's reaction, there were actually receptive to it and paid out $10k for the discovery. Though it's an understandable mistake given rockstar's hostile history with the gta modding scene. See the original post and discussion for the whole story: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times... https://news.ycombinator.com/item?id=26296339

That's not how I remember these events when they were playing out. I distincly remember social media posts warning about the dangers of modifying game files, plus refusal to acknowledge the issue. Note there were 2 full weeks between the blog post and the update mentioning the bounty. I'm pretty sure the massive community outrage in between has played a role in it. But I don't have any sources and I was wrong about at least one thing (lack of attribution), so I'm okay assuming I'm wrong about everything else too.
Post reply on HN