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)