It’s hard to tell whether upgrading really makes sense. I remember upgrading my 386DX40, doubling the RAM from 4 to 8 MB, or adding a larger HDD (350 MB in addition to the original 105 MB one). But later, it did not seem worth the hassle. I try to get a well-balanced system, close to (but not totally) high end. Instead of changing the Graphics card after 2 years (potentially causing driver and compatibility issues, and potentially having an overpowered GPU for a too slow CPU), I’d rather wait another year and get a whole new system. But of course, when you absolutely focus on the GPU power and use it as a plain, raw computing device (as it might be indicated by your datamining package name), then it may be worthwhile to upgrade a single component.
However, I continued with the benchmark a little bit, and tried to apply this ““benchmarking library”” to the JCublas benchmark. (I still hesitate to call it a library - it’s mainly a bunch of classes computing the cartesian product of some input parameter ranges). The current state/idea is to have benchmark classes like
public class JCublasBenchmarkDgemm extends AbstractBenchmark
{
JCublasBenchmarkDgemm()
{
super("Dgemm");
}
@Override
public ValueSet execute(ValueSet inputValueSet)
{
int rows = inputValueSet.getAsInt("rows");
int cols = inputValueSet.getAsInt("cols");
int iterations = inputValueSet.getAsInt("iterations");
Timing timing = testDgemm(rows, cols, cols, iterations);
MutableValueSet result = ValueSets.createDefault();
result.put("GFLOPS", timing.getGFLOPS());
result.put("MB/s HtoD", timing.getMBPerSecondHtoD());
result.put("MB/s DtoH", timing.getMBPerSecondDtoH());
return result;
}
private static Timing testDgemm(
int rowsA, int colsA, int colsB, int iterations)
{
...
}
}
and then have a few lines in the main to generate the input space and collect the results as a CSV
List<ValueSet> valueSets = ValueSets.create()
.interpolate("cols", 200, 1000, 50)
.derive("rows", "cols", v -> (4000 * 200 * 200) / ((Integer)v * (Integer)v))
.add("iterations", 25)
.build();
List<Benchmark> benchmarks = Arrays.asList(
new JCublasBenchmarkDgemm(), new JCublasBenchmarkDsyrk());
BenchmarkRunner benchmarkRunner = BenchmarkRunner.create();
benchmarkRunner.runBenchmarks(benchmarks, valueSets);
List<ValueSet> resultValueSets = benchmarkRunner.getResultValueSets();
System.out.println(
ValueSetsPrinter.createString(resultValueSets, ";"));
ValueSetsPrinter.printCSV(resultValueSets, "results.csv");
However, I still think that there’s something odd with the SYRK benchmark. I adapted the GFLOPS computation like you said. But I’ll have to re-read your original code to understand what you did there. (The GEMM and the SYRK are somewhat unrelated, aren’t they?). I mean, you seem to have swapped the rows and columns for the SYRK case, and … using different numbers there does not really make sense for me at the moment. Or was the idea to use GEMM parameters that cause the same operation/workload to be done as with SYRK?
(BTW: This library is far from being publishable, but I’d just upload it as a plain JAR somewhere, in the case someone wants to test it)
What are the other parts for which you are considering a dedicated CUDA solution? Of course, „real“ CUDA (own kernels) tends to involve a considerable effort (compared to just using the building blocks of the runtime libraries). But maybe there are intermediate steps that could benefit from being executed on the GPU. And even if this on its own does not bring a good speedup, it may still be advantageous, if, for example, it means that one „Device->Host copy (Java Computation) Host->Device copy“ step can be omitted.