Closed martin-ueding closed 7 years ago
ddkalamk
commented
7 years ago In my opinion, the external library interface should not have any template parameters. Vector length is compile time constant and can be eliminated. External APIs should be implemented in .cpp file which instantiates appropriate template based on switch case on input arguments.
martin-ueding
commented
7 years ago The interface to tmLQCD (which is a C library) has to be done with C functions, so exactly that is done.
For Chroma I would assume that it would be a lot of work to change to a non-template interface?
bjoo
commented
7 years ago I would prefer to not create a C library interface for Chroma. However, having C interfaces is OK. There may end up being a MILC one too. We should find a part in the directory tree where these can sit without bothering each other.
Best, B
On Apr 30, 2017, at 11:18 AM, Martin Ueding notifications@github.com wrote:
The interface to tmLQCD (which is a C library) has to be done with C functions, so exactly that is done.
For Chroma I would assume that it would be a lot of work to change to a non-template interface?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
martin-ueding
commented
7 years ago The tmLQCD interface will reside within tmLQCD, as far as I have understood. There is a need for additional packing routines because tmLQCD and QPhiX have different data structures. These are best housed in tmLQCD, just like the QDP packers are housed within QPhiX, the downstream of QDP.
ddkalamk
commented
7 years ago I am fine with c++ interface (and adding C wrapper on top of it). But would keep template parameters that end users cares about. E.g. veclen or soalen are not something end user would like to bothered with and we should eliminate those from basic interface.
From: Balint Joo [mailto:notifications@github.com] Sent: Sunday, April 30, 2017 8:56 PM To: JeffersonLab/qphix qphix@noreply.github.com Cc: Kalamkar, Dhiraj D dhiraj.d.kalamkar@intel.com; Comment comment@noreply.github.com Subject: Re: [JeffersonLab/qphix] Reducing incremental compile time (#42)
I would prefer to not create a C library interface for Chroma. However, having C interfaces is OK. There may end up being a MILC one too. We should find a part in the directory tree where these can sit without bothering each other.
Best, B
On Apr 30, 2017, at 11:18 AM, Martin Ueding notifications@github.com<mailto:notifications@github.com> wrote:
The interface to tmLQCD (which is a C library) has to be done with C functions, so exactly that is done.
For Chroma I would assume that it would be a lot of work to change to a non-template interface?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/JeffersonLab/qphix/issues/42#issuecomment-298238567, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIYlT4oG9b4Sx3v27NyhhLcAB5rZSRPqks5r1KgfgaJpZM4NMlBw.
Whenever I change a single test case, I need around 100 seconds of compilation time. Changing something in the library (like
geometry.h) will result in over five minutes of recompilation.I wondered whether it would make sense to use explicit instantiation of the templates. We do know all the possible parameters of floating point type, vector length, SoA length, and compression beforehand. Therefore it would be possible to instantiate the Dslash class templates once and compile that into a static library. Then incremental builds would only have to build the non-kernel code, which should be comparably fast.
The downside might be that QPhiX then no longer is a header-only library. Downstream projects like Chroma or tmLQCD would have to adapt their build process.
Would this we worthwhile?