Earlier quoted context omitted.
Ahh... Good old funrollloops... https://www.shlomifish.org/humour/by-others/funroll-loops/Ge...
Right up there with fun, safe math optimizations
At least these actually make things faster usually.
The time the x86 emulator team found code so bad they fixed it during emulation
71–80 of 179 posts
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#72Earlier 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…
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??
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#73Earlier 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.
I've said over the years a few times, this isn't our fault but it's our problem.
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#74Earlier 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??
before writing to some area, it would erase it (clearing with white) up to 9 times
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#75Earlier 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…
A long time ago I worked with someone who read 1 byte at a time from a socket because they insisted data was cached so the kernel was going to batch it magically somehow. It took me days to convince them to measure it.
That's different: you're talking about the application code, like OP.
But I think the parent comment's point is that the issue is in the implementation of fread itself in the standard library. It's perfectly reasonable for an application to pass it 1, 65536 (i.e. one byte, up to 65536 times) and expect it not to issue 65536 separate OS calls.
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#76Arguably more of an optimization, rather than a fix. Looks like un-unrolling a loop, or better, rolling a loop. Or rolling straight line code?
Yeah, but after a certain point the win is negligible. Huge code can also increase cache misses which will slow down things.
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#77Earlier 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??
Several layers of white is what makes the black really pop. (Just kidding).
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#78Earlier 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??
It means they were time travellers! Secretly, they came from an alternate future where everyone used e-ink displays, and wanted Excel to be ready!
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#79Earlier quoted context omitted.
A long time ago I worked with someone who read 1 byte at a time from a socket because they insisted data was cached so the kernel was going to batch it magically somehow. It took me days to convince them to measure it.
That's different: you're talking about the application code, like OP. But I think the parent comment's point is that the issue is in the implementation of fread itself in the standard library. It's perfectly reasonable for an application to pass it 1, 65536 (i.e. one byte, up to 65536 times) and expect it not to issue 65536 separate OS calls.
Is it? I get what you're saying, but asking for 1 byte 65536 times, is indeed different than asking for 65536 bytes, 1 time. There may be reasons, such as when you pull off the end of a buffer, it shifts. And the buffer size is 1 byte. Or 10. Or whatever.
No, I'm not saying that's why. I'm simply saying there is a difference between asking for 1 byte or 65k bytes of something. Even dd runs the same under Linux.
dd bs=10k count=1 is faster than bs=1 count=10k
I remember trying to recover some data from a spinning disk, and trying to slowly creep up on the data. So I wanted 1 byte per, I wanted it to nibble, until it hit whatever the errored part was. If I just grabbed the lot, it'd error out from the whole read.
Re: The time the x86 emulator team found code so bad they fixed it during emulation
#80Earlier quoted context omitted.
Who's problem is this? Nvidia probably doesnt officially say anything about this and 99.9% of people do not rename process name
It's definitely Nvidia's problem if this breaks something. Nothing in the D3D/OpenGL specs says that you can (not) use certain executable names.
[dead]