Bitcointalk · 4 hashes parallel on SSE2 CPUs for 0.3.6

中本聪,2010 年 8 月 7 日

SN-1890 已核对来源,附原文与上下文。

阅读语言
中文译文

CRITICAL_BLOCK 是一个包含 for 循环的宏。断言失败说明循环体里调用了 break。这个块里唯一的 break 语句在第 2762 行。原始源文件里这个临界块中并没有 break 语句。我认为你必须删掉 2759-2762 行。原始 main.cpp 里没有这种东西。

抱歉。CRITICAL_BLOCK 并不完美。你得小心别用它 break 或 continue 跳出去。有一个 assert 会捕获 break 并警告。用它可以挨批评,但没有它,语法会臃肿得多、也更容易出错。

有没有可能 SSE2 代码在 Intel 上慢是因为某种可以绕过的怪癖?譬如,某个东西不对齐时能工作但很慢,或者缓存颠簸,或者某条指令特别慢?我不确定这东西还找不找得到,但 Intel 以前好像有个能按指令级别做性能分析的分析器。我猜倘若 tcatm 手头没有装那种慢处理器的机器可测,希望就不大。但它要是能在大多数 CPU 上跑起来就太好了。

ORIGINAL · 英文原文
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.
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.

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.
来源
Bitcointalk 原始链接 ↗ 记录编号 SN-1890