Performance audit about dftk.jl

[antoine-levitt]

The bottlenecks seem to be the same for large-ish unit cells (20x1x1 silicon supercell). I guess that doesn't change until the orthogonalization/diagonalization costs start to dominate, which should not come up until we get to systems that require distributed-memory parallelism.

[antoine-levitt]

We should compare anatomy parts performance with eg abinit, using the scripts in test/testcases_ABINIT. At this point it comes down to fine-tuning (preconditionner, eigensolver termination criteria), optimizations (real FFTs) and FFT threading/batching.

[mfherbst]

I'm happy to do that, but I'd say the result will be disappointing at first ...

[antoine-levitt]

Sure? I don't see anything apart from the above that could explain a difference, so it's clear where to go to catch up with other codes, and not that hard. Abinit has options to print timings, so we could eg get the total number of FFTs they do and compare.

[mfherbst]

Ha, that's a good angle and a good thing to try.

[antoine-levitt]

OK so I benchmarked DFTK against abinit for a very simple testcase. Ecut 50, LDA, temperature 0.01, Silicon with no kpoint, box with lattice constant a=20 (reduced position of atoms rescaled to be physical). We took 44s, abinit took 8s. I did not do any fine tuning either in abinit (just took source, made ./configure && make, and took the source of the example; I did add in FFTW, but that didn't change the timings much) or DFTK (I did specify a maximum of 4 iterations for LOBPCG, to match abinit's choice). That's not too bad! Pretty sure with a reasonable amount of work we can get to at least within a factor of 2, and possibly beat them.

I couldn't make abinit to use multithreaded, so I disabled all threading in DFTK. Turning it on (FFTW.set_num_threads(4); BLAS.set_num_thread(4)) yielded 34s, which is not great (ie we can probably do better by explicitly threading)

[mfherbst]

Hmm 44s to 34s indeed sounds pretty bad for me as well, but the ballpark of 44 (DFTK) versus 8 (ABINIT) sounds familiar from my experiments.

[mfherbst]

Just to keep track of things todo: In #44 the zeros function was discussed as an alternative to our current array = similar(data), array .= 0 pattern. This requires JuliaLang/julia#130.

[mfherbst]

We have worked quite a bit on this stuff recently. Any objections against closing it for now? I think the low-hanging fruits discussed here are kind of done now.

[antoine-levitt]

Sure. We can rebenchmark later on, but the results above might be obsolete now.