【问题标题】:RootBeer silently fails for large arrays?对于大型阵列,RootBeer 静默失败?
【发布时间】:2014-08-28 15:24:19
【问题描述】:

我有一个简单的应用程序,(目前)在一个大数组中模拟错误校正。

该位生成数据并将 16 字节的 Reed-Solomon 奇偶校验添加到每个 255 字节的块中。

ReedSolomonEncoder encoder = new ReedSolomonEncoder(QR_CODE_FIELD_256);
int[][] data = new int[params.getNumBlocks()][255];
int[][] original = new int[params.getNumBlocks()][];

int value = 0;
for (int i = 0; i < params.getNumBlocks(); i++) {
    int[] block = data[i];
    for (int j = 0; j < 239; j++) {
        value = (value + 1) % 256;
        block[j] = value;
    }
    encoder.encode(block, 16);
    original[i] = Arrays.copyOf(block, block.length);

    // Corrupt a byte
    block[50] += 1;
}

这是我的内核:

public class RsKernel implements Kernel {
    private final int[] block;

    public RsKernel(int[] block) {
        this.block = block;
    }

    @Override
    public void gpuMethod() {
        block[50] -= 1;
    }
}

它只是手动恢复每个块中损坏的字节(它不执行实际的 Reed-Solomon 纠错)。

我使用以下代码运行内核:

ArrayList<Kernel> kernels = new ArrayList<>(params.getNumBlocks());
for (int[] block : data) {
    kernels.add(new RsKernel(block));
}
new Rootbeer().run(kernels);

我用JUnitassertArrayEquals验证解码:

Assert.assertArrayEquals(original, data);

奇怪的是,如果我使用多达 8192 个(多么方便的数字)块(内核)运行此代码,则报告数据已正确解码;对于 8193 块及以上,它没有正确解码:

Exception in thread "main" arrays first differed at element [8192][50]; expected:<51> but was:<52>
    at org.junit.Assert.internalArrayEquals(Assert.java:437)
    at org.junit.Assert.internalArrayEquals(Assert.java:428)
    at org.junit.Assert.assertArrayEquals(Assert.java:167)
    at org.junit.Assert.assertArrayEquals(Assert.java:184)
    at com.amphinicy.blink.rootbeer.RootBeerDemo.main(Jasmin)

什么可能导致这种行为?

这是java -jar rootbeer-1.1.14.jar -printdeviceinfo的输出:

device count: 1
device: GeForce GT 525M
  compute_capability: 2.1
  total_global_memory: 1073414144 bytes
  num_multiprocessors: 2
  max_threads_per_multiprocessor: 1536
  clock_rate: 1200000 Hz

【问题讨论】:

  • 我也有同样的问题。请注意,我的 GTX 760 的硬件限制为 12288。这只是并发线程的数量。应该可以向设备发送 2^32-1 个线程。

标签: cuda rootbeer


【解决方案1】:

查看代码,我认为它可能是因为以下原因:

// Corrupt a byte
block[50] += 1;

可以将 1 加到 255,得到 256,这不是有效字节。像这样破坏字节可能会更好:

block[50] ^= 0x40;

这会翻转位置 7 中的位,而不是添加来破坏字节。

【讨论】:

  • 这是一个非常好的观察!我将更正我的损坏代码 :) 但是,正如您从我添加的错误消息中看到的那样,您可以看到这不是字节溢出的情况(51 对 52)。
猜你喜欢
  • 2018-11-07
  • 2019-01-31
  • 1970-01-01
  • 2012-03-28
  • 1970-01-01
  • 2017-01-10
  • 2018-09-30
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多