有道翻译 vs google翻译

原文

This code works great. That’s exactly the kind of complexity I want to see in the final version or our renderer. It is definitely inefficient (multiple divisions, and the like), but it is short and readable. Note that it has no asserts and no checks on going beyond the borders, which is bad. In these articles I try not to overload this particular code, as it gets read a lot. At the same time, I systematically remind of the necessity to perform checks.

So, the previous code works fine, but we can optimize it. Optimization is a dangerous thing. We should be clear about the platform the code will run on. Optimizing the code for a graphics card or just for a CPU — are completely different things. Before and during any optimization, the code must be profiled. Try to guess, which operation is the most resource-intensive operation here?

For tests, 1,000,000 times I draw 3 line segments we have drawn before. My CPU is Intel® Core™ i5-3450 CPU @ 3.10GHz. For each pixel, this code calls the TGAColor copy constructor. Which is 1000000 * 3 line segments * approximately 50 pixels per line segment. Quite a lot of calls, isn’t it? Where to start with optimization? The profiler will tell us.

有道翻译

这段代码工作得很好。这正是我希望在最终版本或渲染器中看到的复杂性。这显然是低效的(多个部门，等等)，但它是简短的和可读的。注意，它没有断言和检查，这是不好的。在这些文章中，我尽量不重载这个特定的代码，因为它会被大量阅读。同时，我系统地提醒进行检查的必要性。

所以，前面的代码工作得很好，但我们可以优化它。优化是一件危险的事情。我们应该清楚代码运行的平台。为显卡或只为CPU优化代码是完全不同的事情。在任何优化之前和期间，必须对代码进行概要分析。试着猜猜，哪个操作是这里资源最密集的操作?

对于测试，我画了1,000,000次我们之前画的3个线段。我的CPU是Intel®Core™ i5-3450 CPU @ 3.10GHz。对于每个像素，这段代码调用TGAColor复制构造函数。也就是1000000 * 3个线段*大约每个线段50像素。好多电话，不是吗?从哪里开始进行优化?侧写师会告诉我们。

google翻译

这段代码效果很好。这正是我希望在最终版本或我们的渲染器中看到的那种复杂性。它绝对是低效的（多分区等），但它简短易读。请注意，它没有断言，也没有检查越界，这很糟糕。在这些文章中，我尽量不重载这个特定的代码，因为它会被大量阅读。同时，我系统地提醒进行检查的必要性。

所以，前面的代码工作正常，但我们可以优化它。优化是一件危险的事情。我们应该清楚代码将在哪个平台上运行。为显卡或仅为 CPU 优化代码是完全不同的事情。在任何优化之前和期间，必须对代码进行概要分析。试着猜一下，这里哪个操作是最耗费资源的操作？

对于测试，我绘制了我们之前绘制的 3 条线段 1,000,000 次。我的 CPU 是 Intel® Core™ i5-3450 CPU @ 3.10GHz。对于每个像素，此代码调用 TGAColor 复制构造函数。即 1000000 * 3 条线段 * 每条线段大约 50 个像素。很多电话，不是吗？从哪里开始优化？分析器会告诉我们。

比较

• 都有不准确的地方 e.g. Quite a lot of calls, isn’t it? 都翻译成了很多电话,实际上应该理解为：引起了很多问题。
  也就是说翻译还没智能到能100%结合上下文语境来翻译。

• 总体，个人认为还是google相对更准确。
  e.g. multiple divisions, and the like
  有道翻译成了多部门
  googl翻译为多分区

• 结合专业背景的能力
  no asserts 都翻译为了断言，而在语言开发者来说声明，应该更准确 就是断言的意思
  断言(assertion)是一种在程序中的一阶逻辑(如：一个结果为真或假的逻辑判断式)，目的为了表示与验证软件开发者预期的结果——当程序执行到断言的位置时，对应的断言应该为真。若断言不为真时，程序会中止执行，并给出错误信息。

经验

通过chunck（意群）化和泛化来理解会相对更准确。但翻译工作量大，目的还是写代码，矫正一下即可（机翻+土翻）

英语中还有俚语的说法，这些都需要去了解它的文化以及积累