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

91–100 of 179 posts

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

#91

Post by fsfod »

psanchez wrote: post #20

This reminds me of a story from 15 years ago, where I was developing a technology to download games on demand by hooking into the OS calls. There was a particular game that was superslow when this tech was applied. Original game loading took around 15-20 seconds, whereas once the tech was applied it took easily 3-5 min, even with all data already downloaded. When I started digging into it, I realized the reason was t…

Part of Windows Explorer actually does tons of tiny 4 byte ReadFile calls in to its tracking database like file when you delete a file. If you deleting lots of files this quickly adds up.

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

#92

Post by notorandit »

selcuka wrote: post #13
notorandit wrote: post #7

Earlier quoted context omitted.

Which optimizer replaces a 64k loop with 64k instructions? Ah, yes. Microsoft's!

There is no indication that the compiler that produced the code was Microsoft's. Actually the article hints otherwise ("[...] whatever compiler was used to compile this code").

Who has been validating that approach to solve their own optimization target?

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

#93

Post by DarkUranium »

chadgpt3 wrote: post #87
mort96 wrote: post #81

Earlier quoted context omitted.

Wait, is that wrong? I always call fread as: fread(data, 1, sizeof(buffer), f); with the rationale that I'm interested in reading sizeof(buffer) individual bytes. The buffer size is incidental, not the size of the items I'm trying to read from the file; "read one item whose size is sizeof(buffer)" seems semantically wrong. Is this just the case of Windows having a bad stdlib fread implementation 15 years ago or is my…

It's not wrong. Guy just wrote a bad implementation of fread and blamed everyone else.

He didn't write it.

The C runtime authors did (presumably Microsoft, if it's MSVCRT).

He's hooking into ReadFile, a layer below the stdlib. By the time it reaches the hook, it's already split.

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

#94

Post by DarkUranium »

SyzygyRhythm wrote: post #66
Cthulhu_ wrote: post #40

Earlier quoted context omitted.

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.

There are many, many, cases like this, including correctness fixes. One recent example I remember had a shader that computed: x = a / b * b The optimizer was allowed, but not obligated, to transform that into: x = a However, in this case, b was sometimes 0. And if so, the unoptimized version computed: x = a / 0 * 0 = Inf * 0 = NaN So badness ensued if the that particular path didn't get optimized, which could happen…

I'm curious, what's the ratio of:

- deciding to inform the game developer & wait for reply vs not waiting for reply vs just fixing it yourself without informing the developer; and

- if informed: developer actually fixing it vs only saying they would fix it vs no reply whatsoever (not counting automated "thank you for your inquiry" replies, in cases where you don't already have more direct channels to the dev than email)

I've always kind of wondered this because in a way, it's kind of weird that it's fixed for them, at least for new releases / games actively being developed.

(Full disclosure: I'm a game developer myself, with a very high interest in engine plumbing & dev [including graphics], though finding a job for the latter is easier said than done.)

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

#95

Post by PaulHoule »

Taniwha wrote: post #26
psanchez wrote: post #20

This reminds me of a story from 15 years ago, where I was developing a technology to download games on demand by hooking into the OS calls. There was a particular game that was superslow when this tech was applied. Original game loading took around 15-20 seconds, whereas once the tech was applied it took easily 3-5 min, even with all data already downloaded. When I started digging into it, I realized the reason was t…

I used to be a graphics card/chip architect for macs in the early/mid 90s - our chips were the fastest, but some programs were resistant because they did stupid stuff: pagemaker invalidated the font cache every time it went thru its main loop, quark with ATM did an n*2 thing every time it wrote text etc etc. We had special hardware to accelerate text drawing and it did nothing because the software pissed it away. We…

I remember when 24 bit color was exotic and aspirational and you had to settle for 16.

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

#96

Post by Sesse__ »

chadgpt3 wrote: post #85
psanchez wrote: post #20

This reminds me of a story from 15 years ago, where I was developing a technology to download games on demand by hooking into the OS calls. There was a particular game that was superslow when this tech was applied. Original game loading took around 15-20 seconds, whereas once the tech was applied it took easily 3-5 min, even with all data already downloaded. When I started digging into it, I realized the reason was t…

Why does your fread to anything other than multiplying the two arguments?

The idea of having two arguments to fread() is presumably to be able to do something else than all-or-nothing when there's a short read.

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

#97

Post by xattt »

Taniwha wrote: post #26
psanchez wrote: post #20

This reminds me of a story from 15 years ago, where I was developing a technology to download games on demand by hooking into the OS calls. There was a particular game that was superslow when this tech was applied. Original game loading took around 15-20 seconds, whereas once the tech was applied it took easily 3-5 min, even with all data already downloaded. When I started digging into it, I realized the reason was t…

I used to be a graphics card/chip architect for macs in the early/mid 90s - our chips were the fastest, but some programs were resistant because they did stupid stuff: pagemaker invalidated the font cache every time it went thru its main loop, quark with ATM did an n*2 thing every time it wrote text etc etc. We had special hardware to accelerate text drawing and it did nothing because the software pissed it away. We…

What would have been the purpose of stupid code like that?

Was it a workaround for things that didn’t fully complete on one iteration, so the devs kept hammering away at it until it worked?

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

#98

Post by Taniwha »

nxobject wrote: post #83
Taniwha wrote: post #26

Earlier quoted context omitted.

I used to be a graphics card/chip architect for macs in the early/mid 90s - our chips were the fastest, but some programs were resistant because they did stupid stuff: pagemaker invalidated the font cache every time it went thru its main loop, quark with ATM did an n*2 thing every time it wrote text etc etc. We had special hardware to accelerate text drawing and it did nothing because the software pissed it away. We…

Does that make you the first in a long tradition of GPU developers going to blockbuster app devs to say "hey, you should be doing this instead?" PS – I am looking through the NuBus cards that I have... did you work for SuperMac or RasterOps?

I was probably not the first to have to do that, we knew what apps our customers used, making them better was the whole point of the operation

I did the architectural design for the SuperMac cards. I figured out what needed to be accelerated, dropping code into people's machines to see where the cycles were going. Others did the physical design for the first 2 cards, I did the design of the chip in the Thunder and later cards (designed the data paths and state machines and a full simulation, someone else actually laid the gates)

If your card has a SQD01 on it it's my work. It peaks at 1.5Gb/s on solid fills

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

#99

Post by macintux »

Someone wrote: post #54
psanchez wrote: post #20

This reminds me of a story from 15 years ago, where I was developing a technology to download games on demand by hooking into the OS calls. There was a particular game that was superslow when this tech was applied. Original game loading took around 15-20 seconds, whereas once the tech was applied it took easily 3-5 min, even with all data already downloaded. When I started digging into it, I realized the reason was t…

> 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…

I assumed it was a simple mistake: easy to forget what order the two integers are sent.

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

#100

Post by Taniwha »

trelbutate wrote: post #72
urbandw311er wrote: post #49

Earlier quoted context omitted.

This is a horrible and yet not unexpected insight into the internals of Excel

> To be fair excel would erase places white that it wanted to write up to 9 times before it drew any black pixels I feel like I'm having a stroke trying to read this, what does it mean??

Well all they needed to do was erase the screen with white and draw on it, but their app's internal logic meant that they erased it more than once.

I was capturing QuickDraw library calls - the low level graphics primitives, to figure out where the graphics time in apps was going and found out sometimes excel did it 9 times

Of course users didn't see it more than once, but our hardware made all that wasted time run faster

Post reply on HN