In the seminal 1989 Microsoft memo Zero-defects code by Chris Mason (which is still a great read even today), the term ‘hand native’ is used several times. Some examples:
1.
Users measure our products by their speed (a major part of usability) as much as by their features. Our methods do not reveal this. We often let hand native, swap tuning, and other important optimizations slip until there’s no time to do them.
2.
In Mac Word 4, we stepped through code for two reasons: to verify the correctness of hand native, and because the profiler wasn’t giving us the right kind of information. The result was extremely clean hand native, and a lot of insight into how the program really worked, which allowed us to improve its speed dramatically.
What is this optimization? My beard is apparently not long or grey enough for me to have learned it.
5
Native Code refers to machine code native to a specific CPU. This machine code consists of instructions that the CPU can directly execute. In contrast, C code, for example, is not native to any specific CPU. It requires a compiler that translates it to native code first or an interpreter, that will interpret it on a specific CPU.
And when native code is written directly by the programmer, this is called Hand Written native code, in contrast to machine or compiler generated one.
So I assume that Hand Native is a short form for Hand Written Native Code.
At the time this paper was written, most CPUs were much simpler than they are today. Their runtime behavior was very predictable: no out of order execution, no jump prediction, no parallelization within the core, no code optimization by the CPU, and most instructions had fixed number of cycles. On the other hand, compilers were much more limited than they are today. Quite often a skillful programmer was able to write assembly code that would execute much faster than the code a C compiler could generated out of comparable C code.
Today that has changed dramatically. Quite often people think they can beat compilers but in real life benchmarks this is hardly ever the case. If you look at the assembly code a compiler generates out of C code, this is quite often very unintuitive code; no programmer would have ever come up with that kind of code to solve the problem. Yet that code is quite often the fastest code even possible for a specific CPU or CPU family. CPUs are very complex today and compilers are very smart, they use all kind of complex optimization strategies and clever tricks to create code that gets the best out of these CPUs.
Today writing assembly code by hand is only required to use CPU features that a compiler cannot easily support, e.g. the AES hardware encryption instructions of Intel CPUs. A compiler would have to detect that your code is implementing AES encryption to replace it with those special instructions and that is way to too complex for a compiler to detect. Another example are SIMD instructions which compilers can only support in rather simple cases (see automatic vectorization) but that still require hand written assembly code if you require more complex calculations.
By the way, you missed one mentioning of that term which confirms my assumption:
Hand native should be done in parallel with the C from the start. This may seem to “waste” time, but you’ll always know if the program is fast enough, and have time to correct it if it’s not.
It wastes time, as you are programming the same thing twice, once in assembly code and once in C code but only that way you can compare your hand written assembly code; if it isn’t faster than then C code, your hand written assembly code is not good. That shows the age of the document as it assumes that your hand written code must be better than what the C compiler produces whereas today, the Linux kernel developer have replaced a lot of hand written assembly with C code, as the C code is at least equally fast, cross-platform, and maintaining C code is much easier than maintaining assembly code. This clearly shows how times have changed since that document was written.