Live data from Hacker News

Assembly Optimization Tips by Mark Larson (2004)

masm32.com

11–20 of 22 posts

Re: Assembly Optimization Tips by Mark Larson (2004)

#11
post #3
post #2

Looks like this was written in 2004, or thereabouts.

I was wondering why it said P4. That's an old processor.

Also P4 comes with NetBurst architecture.

"The Willamette and Northwood cores contain a 20-stage instruction pipeline. This is a significant increase in the number of stages compared to the Pentium III, which had only 10 stages in its pipeline. The Prescott core increased the length of the pipeline to 31 stages."

https://en.wikipedia.org/wiki/NetBurst

And many of that tricks actually works for long pipelines.

Re: Assembly Optimization Tips by Mark Larson (2004)

#12
post #9

This article title should have "(2004)" added; this is seriously old information. For modern use, something about ARM CPUs would be much more useful since that's what microcontrollers all use now. No one's doing ASM programming on x86 CPUs these days (and certainly not Pentium4 CPUs).

> No one's doing ASM programming on x86 CPUs these days I take your point, but I think there’s still a fair bit of x86 asm out there. For example, in ffmpeg and zstd.

I don't think anyone really cares about optimizing those codepaths, though.

Re: Assembly Optimization Tips by Mark Larson (2004)

#14

> If you have a full 32-bit number and you need to divide, you can simply do a multiply and take the top 32-bit half as the result. Can someone explain how this can work? Obviously, you can't just multiply the same numbers instead of dividing.

Of course not. It is multiplication with a reciprocal in fixed-point representation. You'd first have to compute the reciprocal as 2**32 / divisor. Therefore it is most often done with constant divisors.

A longer tutorial that goes into more depth: https://homepage.cs.uiowa.edu/~jones/bcd/divide.html

Re: Assembly Optimization Tips by Mark Larson (2004)

#18

> If you have a full 32-bit number and you need to divide, you can simply do a multiply and take the top 32-bit half as the result. Can someone explain how this can work? Obviously, you can't just multiply the same numbers instead of dividing.

Of course not. It is multiplication with a reciprocal in fixed-point representation. You'd first have to compute the reciprocal as 2**32 / divisor. Therefore it is most often done with constant divisors. A longer tutorial that goes into more depth: https://homepage.cs.uiowa.edu/~jones/bcd/divide.html

Also, x86 has an instruction that multiplies two 32-bit registers and stores the 64-bit result in two 32-bit registers. So you get the result of the division in the register with the high part of the multiplication result, and don't need to do a shift.

Re: Assembly Optimization Tips by Mark Larson (2004)

#19
post #9

Earlier quoted context omitted.

> No one's doing ASM programming on x86 CPUs these days I take your point, but I think there’s still a fair bit of x86 asm out there. For example, in ffmpeg and zstd.

I don't think anyone really cares about optimizing those codepaths, though.

Try Eigen then, where people were tweaking every last ounce of performance. Even then, it has problems matching MKL or nVidia libs for ultimate performance sometimes.

Re: Assembly Optimization Tips by Mark Larson (2004)

#20
post #11
post #3

Earlier quoted context omitted.

I was wondering why it said P4. That's an old processor.

Also P4 comes with NetBurst architecture. "The Willamette and Northwood cores contain a 20-stage instruction pipeline. This is a significant increase in the number of stages compared to the Pentium III, which had only 10 stages in its pipeline. The Prescott core increased the length of the pipeline to 31 stages." https://en.wikipedia.org/wiki/NetBurst And many of that tricks actually works for long pipelines.

Many of the tricks do not work the same way due to how instructions are now broken down by the decoder into microops. You may end up with worse RISC code than what Intel or AMD microcoded. The CPU can optimize it as well if it sees CISC. And less cache pressure can still be valuable.

Speculation and branch prediction got vastly sped up since.

Compilers themselves got way better since as well, so you can sometimes get away with just intrinsics.

Post reply on HN