Michael Abrash‘s black book--第一章--1.2

1.2 Understanding High Performance--理解高性能

Before we can create high-performance code, we must understand what high performance is.
The objective (not always attained) in creating high-performance software is to make the software able to carry out its appointed task so rapidly that it responds instantaneously, as far as the(直到) user is concerned. In other words, high-performance code should ideally 理想地 run so fast that any further improvement in the code would be pointless(无意义).

在我们编写高性能代码前，我们必须先理解何为高性能。
创建高性能软件的目标（不是总能达到）是使软件能执行特定任务如此之快，达到秒回，直到用户满意(不知翻译的对不对)。
换句话说，高性能代码应该以理想地运行如此快速，以至于任何进一步的代码优化都毫无意义。--- 最高境界啊！

Notice that the above definition most emphatically does not say anything about making the software as fast as possible. It also does not say anything about using assembly language, or an optimizing compiler, or, for that matter(就此而言), a compiler at all.
It also doesn't say anything about how the code was designed and written. What is does say is that high performance code shouldn't get in the user's way (挡道、阻碍)-- and that's all.

注意以上定义最强调的不是使软件尽可能快（有点矛盾，这还不快？）。也不是说使用汇编，或者一个优化的编译器，就没有说编译器的事儿。它也不是说如果涉及和写代码。说的是高性能代码不应该妨碍用户，这就够了---用户至上

That's an important distinction, because all too many programmers think that assembly language, or the right compiler, or a particular high-level language, or a certain design approach is the answer to creating high-performance code.
They're not, any more than choosing a certain set of tools if the key to building a house.  you do indeed need tools to build a house, but any of many sets of tools will do . You also need a blueprint, an understanding of everything that goes into a house, and the ability to use the tools.

这是一个重要的区别，因为绝大多数程序认为创建高性能代码的答案（关键所在）是汇编，或者好的编译器，或者一个特殊的高级语言，或者一个特定的设计方法。
这都不对，如果建造一所房子，你需要的不仅仅是选择特定工具集。你确实需要建造房子的工具，但有很多工具集可以用。你也需要一个蓝图，一个对房子中每样东西的理解，和使用工具的能力。
---工具不是最重要的，关键是设计、能力

Likewise, high-performance programming requires a clear understanding of the purpose of the software being built, an overall program design,  algorithms for implementing particular tasks, an understanding of what the computer can do and of what all relevant(相关) software is doing -- and solid programming skills, preferably using an optimizing compiler or assembly language. The optimization at the end is just the finishing touch, however.

同样地，高性能编程需要对构建的软件目标的清晰理解，一个全局的程序设计，实现特定任务的算法，一个对计算机能做什么和相关软件能做什么的理解 --和坚实的编程技能， 最好使用优化的编译器或者汇编语言。而最后的优化是最后一步。

tips: Without good design, good algorithms, and complete understanding of the program's operation, your carefully optimized code will amount to  相当于 one of mankind's least fruitful creations-- a fast slow program.

贴士：没有好的设计、好的算法，和对程序指令的完全理解，你认真优化的代码将相当于一个人造的无用废物--一个快速的慢程序。

"What's a fast slow program?"you ask. That's a good question, and a brief(true) story is perhaps the best answer.
什么是个快的慢程序？这是一个好问题，一个小故事很好的回答了这个问题。

When Fast Isn't Fast  --- 什么样的快不是快

In the early 1970s, as the first hand-held calculators were hitting the market, I knew a fellow named Irwin. He was a good student, and was planning to be an engineer. Being an engineer back then meant knowing how to use a slide sule, and Irwin could jockey (移动) a slipstick with the best of them . In fact, he was so good that he challenged a fellow with a calculator to a duel(决斗)--and won, becoming a local legend in the process.

七十年代早期，当第一台手工计算机进入市场的时候，我认识一个叫艾文的人。 他是一个好学生，计划成为一个工程师。想成为一个工程师意味着知道如何使用游标卡尺，艾文能移动游标做到最好。事实上，他如此优秀以至于挑战一个使用计算机的人并取胜了，成为当地一个传奇。

When you get right down to it, though, Irwin was spitting into the wind. In a few short years his hard-earned slipstick skills would be worthless, and the entire discipline would be essentially wiped from the face of the earth. What's more, anyone with half a brain could see that changeover coming. Irwin had basically wasted the considerable effort and time he had spent optimizing his soon-to-be-absolete(很快就要绝种的) skills.

当你彻底了解这个事情时，然而，艾文已经消散在风中。短短几年功夫，他苦练获取的游标尺技能就一文不值了，而且这个游标尺的学科也彻底从地球上别抹去。而且，任何有半个脑袋的人都能用看出转变的到来。艾文浪费了大量的精力和时间来优化他那很快过时的技能

What does all this have to do with programming? Plenty. When you spend time optimizing poorly-designed assembly code, or when you count on an optimizing compiler to make your code fast, you're wasting the optimzation, much as Irwin did.

这和编程有啥关系哩？ 很大关系。当你花费时间优化糟糕设计的汇编代码，或者当你指望一个优化编译器可以让你的代码快速运行，你就是在像艾文一样浪费优化。

Particularly in assembly, you'll find that without proper up-front(预先的) design and everything else that goes into high-performance design, you'll waste considerable effort and time on making an inherently slow program as fast as possible---which is still slow --- when you could easily have improved performance a great deal more with just a little thought.

尤其汇编，你会发现没有好的预先设计和任何其他高性能设计，你将浪费大量精力和时间使得一个天生的慢程序尽可能的块--但它仍旧很慢---稍微思考一下你就能轻松的大幅度的提高性能。

As we'll see, handcrafted assembly language and optimizing compilers matter, but less than you might think, in the grand scheme of things--and they scarcely(几乎不) matter at all unless they're used in the context of a good design and a thorough understanding of both the task at hand and the PC.

就像我们看到的，手写汇编和优化编译器有用，但不如思考大的设计 --- 它们几乎完全没用除非你使用好的设计并且了解任务和PC的里里外外。