Paul Hsieh

Great interview! I would definitely be interested in a history of Unreal in full book length form. And if anyone hasn't already perused "Masters of Doom" by David Kushner on the early days of Id Software, it is such a good read. Regarding the Haskell love. I believe Unreal contributed to the design of a research functional programming language prototype called Cayenne back in the day: Cayenne—a language with dependent types https://dl.acm.org/citation.cfm?id=289451 I think another historical note is how everybody developed on SGI machines in the late 1990s. Primarily, due to Maya modeling. But the 3D graphics API wars were certainly a factor: Direct 3D and OpenGL by Paul Hsieh http://www.azillionmonkeys.com/windoze/OpenGLvsDirect3D.html And, yeah, MSDOS ZZT from 1991 is still playable via Internet Archive ;) https://archive.org/details/msdos_ZZT_1991

Great stuff. I think there are some potential tricks here to reduce the number of comparisons - maybe do a parallel subtract by k to pull down 'A' to -128 (smallest possible byte) then do your comparison against (ord('Z')-k). Or maybe push up 'Z' to +127..? That way you can get a single comparison and can replace a pcmpgtb and pand with a single subtract. Then switch it to SSE2, unroll and you're good to go. Alternately, http://www.azillionmonkeys.com/qed/asmexample.html in section 11 ("Converting Uppercase") contains a brainsmashing version of this entirely in SWAR ("SIMD Within a Register"), which could be adapted with a certain amount of pain (largely due to the absence of a double-quadword bitshift in SSE2, which is retardlepated).

Pipelining did also play a role. The Quake inner rasterization loop has a decent amount of non-division math in it as well that leverages the Pentium's ability to execute FP add/multiplies at 1/cycle. The K6 and 6x86 FPUs were considerably slower -- 2 and 4 cyclesnon-pipelined (http://www.azillionmonkeys.com/qed/cpuwar.html). Additionally, the FXCH instructions required to optimally schedule FPU instructions on the Pentium hurt 486/K6/6x86 performance even more since they cost additional cycles. Hard for the 6x86 to keep up when it takes 7 cycles to execute an FADD+FXCH pair vs. 1 for the Pentium.

The 7th generation comparisons: http://www.azillionmonkeys.com/qed/cpujihad.shtml

More historical context: http://www.azillionmonkeys.com/windoze/OpenGLvsDirect3D.html https://en.m.wikipedia.org/wiki/Fahrenheit_(graphics_API)#History https://softwareengineering.stackexchange.com/questions/60544/why-do-g… There was another blog with a detailed rundown on the politics behind the Fahrenheit drama but the site wend down 10 years ago and I can't remember what the link was.

You make many fine points. Paul Hsieh goes into some ways to properly correct for the modulus effect here (as well as debunking commonly suggested ways that don't work): http://www.azillionmonkeys.com/qed/random.html Alternatively, especially if you have specifically chosen an LCG because you need the periodicity, you can come up with appropriate constants to generate a perfectly distributed set of integers matching the period of your choosing: http://mathaa.epfl.ch/cours/PMMI2001/interactive/rng4.htm This second approach not only solves the modulus issue, but can be very useful for things such as parallelizing the shuffling of an array. Your shuffle won't be perfectly random (as in, some sequences will occur more often than others), but it will be properly distributed in the sense that each index will only be used once.

Here are some more bit hack algorithms http://www.aggregate.org/MAGIC/ The intersection of tricks on all those sites is quite large but on every one of them there's something you haven't seen before. By the way if you like to wrap your mind around such tricks you might also find some gems here: http://www.azillionmonkeys.com/qed/asmexample.html

We use http://www.azillionmonkeys.com/qed/pstdint.h in house.

A cool page is Paul Hsiehs' webpage. There you will find some good discussion on the trick used. http://www.azillionmonkeys.com/qed/asmexample.html Look for part 5: "A fast implementation of strlen()".

K5/Cyrix could overlap Integer and FPU operations, what they couldnt do was interleave (pipeline) FPU operations so that multiple floating point instructions ran in parallel. https://www.phatcode.net/res/224/files/html/ch63/63-02.html Here a non perspective correction related Quake FPU code example https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a39… Lcliploop: fld ds:dword ptr[0+0+esi] fmul ds:dword ptr[0+0+ebx] fld ds:dword ptr[0+4+esi] fmul ds:dword ptr[0+4+ebx] fld ds:dword ptr[0+8+esi] fmul ds:dword ptr[0+8+ebx] fxch st(1) faddp st(2),st(0) fld ds:dword ptr[0+0+edx] fmul ds:dword ptr[0+0+ebx] fld ds:dword ptr[0+4+edx] fmul ds:dword ptr[0+4+ebx] fld ds:dword ptr[0+8+edx] fmul ds:dword ptr[0+8+ebx] fxch st(1) faddp st(2),st(0) fxch st(3) faddp st(2),st(0) faddp st(2),st(0) fsub ds:dword ptr[12+ebx] fxch st(1) fsub ds:dword ptr[12+ebx] fxch st(1) fstp ds:dword ptr[Ld0] fstp ds:dword ptr[Ld1] FXCH instruction is free (zero cycles) on Pentium for most instruction combinations, AMD caught up in late 1998 with CXT revision K6-2. http://www.azillionmonkeys.com/qed/cpuwar.html

Yeah I'd read that. Kasparov was pretty freaked out by Deep Blue. He wrote this: "I got my first glimpse of artificial intelligence on Feb. 10, 1996, at 4:45 p.m. EST, when in the first game of my match with Deep Blue, the computer nudged a pawn forward to a square where it could easily be captured. It was a wonderful and extremely human move. If I had been playing White, I might have offered this pawn sacrifice. It fractured Black's pawn structure and opened up the board. Although there did not appear to be a forced line of play that would allow recovery of the pawn, my instincts told me that with so many "loose" Black pawns and a somewhat exposed Black king, White could probably recover the material, with a better overall position to boot. " about a move most computers of the time would find pretty quickly, and most decent human players would intuitively have thought OK at first glance. http://www.azillionmonkeys.com/qed/chess.html My theory is that a significant part of his game was based around human psychology, so he found it hard to grasp computers. He played computer-friendly risky openings as if to taunt the machine, and heavily talked up the influence of the programmers on Deep Blue to an almost paranoid extent. The result was that he lost against Deep Blue when he should have won fairly easily if he'd been more disciplined.