其他参与者原话impossible7原帖 ↗CRITICAL_BLOCK 是一个包含 for 循环的宏。断言失败说明循环体里调用了 break。这个块里唯一的 break 语句在第 2762 行。原始源文件里这个临界块中并没有 break 语句。我认为你必须删掉 2759-2762 行。原始 main.cpp 里没有这种东西。
CRITICAL_BLOCK is a macro that contains a for loop. The assertion failure indicates that break has been called inside the body of the loop. The only break statement in this block is in line 2762. In the original source file, there is no break statement in this critical block. I think you must remove lines 2759-2762. The is nothing like that in the original main.cpp.
抱歉。CRITICAL_BLOCK 并不完美。你得小心，别用 break 或 continue 跳出这个代码块。有一个 assert 会检测到 break 并发出警告。我使用这个宏的做法或许值得批评，但没有它，语法会臃肿得多，也更容易出错。
Sorry about that. CRITICAL_BLOCK isn't perfect. You have to be careful not to break or continue out of it. There's an assert that catches and warns about break. I can be criticized for using it, but the syntax would be so much more bloated and error prone without it.
有没有可能 SSE2 代码在 Intel 上慢是因为某种可以绕过的怪癖？比如，某个东西不对齐时能工作但很慢，或者缓存颠簸，或者某条指令特别慢？我不确定这东西还找不找得到，但 Intel 以前好像有个能按指令级别做性能分析的分析器。我猜如果 tcatm 手头没有装那种慢处理器的机器可测，希望就不大。但它要是能在大多数 CPU 上跑起来就太好了。
Is there a chance the SSE2 code is slow on Intel because of some quirk that could be worked around? For instance, if something works but is slow if it's not aligned, or thrashing the cache, or one type of instruction that's really slow? I'm not sure how available it is, but I think Intel used to have a profiler for profiling on a per instruction level. I guess if tcatm doesn't have a system with the slow processor to test with, there's not much hope. But it would be really nice if this was working on most CPUs.
当前版本尚未建立逐条校对状态记录。来源核验、历史审校与当前译文校对是不同事项。
译文内容版本：0a2452d26ee7。用于比对文本，不代表校对等级或更新时间。
请填写对应原文、现译文、建议译法和理由。复制后通过你联系本站作者的渠道提交；此处不会自动发送。
