簡體   English   中英

CPU 哈希比 GPU 快?

[英]CPU hashes faster than GPU?

我想生成一個隨機數,並使用OpenCL在我的 GPU 上使用SHA256散列 基本代碼(而不是散列那些預先給定的純文本,它散列隨機數)。
我讓所有的散列在我的 GPU 上工作,但有一個問題:
使用 OpenCL 時每秒完成的散列量會降低嗎?

是的,您沒聽錯,目前僅使用 CPU 比僅使用 GPU 更快。
我的 GPU 僅運行~10%而我的 CPU 運行在~100%

我的問題是:這怎么可能,更重要的是,我該如何解決?

這是我用於生成Pseudo-Random Number的代碼(在兩次運行之間根本不會改變):

long Miner::Rand() {
    std::mt19937 rng;
    // initialize the random number generator with time-dependent seed
    uint64_t timeSeed = std::chrono::high_resolution_clock::now().time_since_epoch().count();
    std::seed_seq ss{ uint32_t(timeSeed & 0xffffffff), uint32_t(timeSeed >> 32) };
    rng.seed(ss);
    // initialize a uniform distribution between 0 and 1
    std::uniform_real_distribution<double> unif(0, 1);
    double rnd = unif(rng);
    return floor(99999999 * rnd);
}

這是為我計算哈希率的代碼:

void Miner::ticker() {
    SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_HIGHEST);
    while (true) {
        Sleep(1000);
        HashesPerSecond = hashes;
        hashes = 0;
        PrintInfo();
    }
}

從這里被調用:

void Miner::Start() {
    std::chrono::system_clock::time_point today = std::chrono::system_clock::now();
    startTime = std::chrono::system_clock::to_time_t(today);
    std::thread tickT(&Miner::ticker, this);
    PostHit();
    GetAPIBalance();
    while (true) {
        std::thread t[32]; //max 32
        hashFound = false;
        if (RequestNewBlock()) {
            for (int i = 0; i < numThreads; ++i) {
                t[i] = std::thread(&Miner::JSEMine, this);
            }
            for (auto& th : t)
                if (th.joinable())
                    th.join();
        }
    }
}

這反過來又被稱為這樣:

Miner m(threads);
m.Start();

CPU 具有比 GPU 更好的延遲特性。 也就是說,CPU 可以執行一種操作方式,即比 GPU 快 WAAAAYYYY。 這甚至沒有考慮 CPU -> 主 RAM -> PCIe 總線 -> GDDR5“全局”GPU -> GPU 寄存器 ->“全局 GPU” -> PCIe 總線返回 -> 主 RAM -> CPU 往返時間(和我在這里跳過了幾個步驟,比如固定和 L1 緩存)

GPU 具有比 CPU 更好的帶寬特性(前提是數據集可以容納在 GPU 有限的本地內存中)。 GPU 執行數十億次SHA256 哈希的速度比 CPU 執行十億次SHA256 哈希的速度快。

比特幣需要數百萬、數十億甚至數萬億的哈希值才能實現具有競爭力的哈希率。 此外,計算可以在 GPU 上進行,無需與 CPU 進行太多協作(無需通過 PCIe 進行緩慢的往返)。

這是一個基本設計的問題。 CPU 旨在最大限度地減少延遲,但 GPU 旨在最大限度地提高帶寬。 看起來您的問題是延遲限制(您計算的 SHA256 哈希值太少,GPU 無法生效)。 32 是......在我們談論的范圍內真的很小。

在您擁有至少 64 個工作項之前,AMD GCN 架構甚至無法全速運行,並且可以說您確實需要 256 個工作項才能最大化 44 個計算單元中的一個,比如說……R9 290x。

我想我想說的是:用 11264 個(或更多)工作項再試一次,這是 GPU 設計使用的工作項的數量。 不是 32。我從 R9 290x 上的 44 個計算單元 * 每個計算單元 4 個向量單元 * 每個向量單元 64 個工作項中得到這個數字。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM