search

JeffersonLab / qphix

QCD for Intel Xeon Phi and Xeon processors
http://jeffersonlab.github.io/qphix/
Other
13 stars 11 forks source link

Merge of QPhiX and QPhiX-codegen repositories? #63

Closed martin-ueding closed 7 years ago

martin-ueding commented 7 years ago

I have the feeling that the two parts of the projects would better be in a single repository. Since there is a 1:1 correspondence, keeping it synchonized with submodules seems like more work for no apparent advantage.

If somebody else would use a different version of the code generator in a project, that would make sense. But it feels like we could merge them at this point and have less issues with git submodules.

One could still offer pre-compiled kernels for download. The build system would have to skip the steps if there is already a compiled library in there, but that is independent of the repository setup, I believe.

bjoo commented 7 years ago

I think right now MILC may use the codegen to write their own codes, but they do not use our version of QPhiX. So for them such a merge may not make sense. On the other hand they may use their own versions of the codegen too so they may not be affected. Let us check with them before doing this merge.

On June 17, 2017 4:45:11 AM EDT, Martin Ueding notifications@github.com wrote:

I have the feeling that the two parts of the projects would better be in a single repository. Since there is a 1:1 correspondence, keeping it synchonized with submodules seems like more work for no apparent advantage.

If somebody else would use a different version of the code generator in a project, that would make sense. But it feels like we could merge them at this point and have less issues with git submodules.

One could still offer pre-compiled kernels for download. The build system would have to skip the steps if there is already a compiled library in there, but that is independent of the repository setup, I believe.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_qphix_issues_63&d=DwICaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=SC-qvz5njMoFH6cliT5XZQ&m=HfyPwzR_NAJgUhmVJ8jynTp0O-8rYGNxXf4KFDH28NQ&s=-GfP8lqCv_EAiyUX2BFYp5Hw8HjKKD6WndIK7t7jA0k&e=

-- Bálint Joó, Scientific Computing Group, Jefferson Lab Email: bjoo@jlab.org Tel: +1 757 269 5339 Sent from a mobile device

martin-ueding commented 7 years ago

Do they use the kernels that we also use or do they just use the framework of the code generator? I think that the separation line would be much better between the framework and the Dslash implementation. But that would only be an interesting thing if some other project wanted to generate completely different kernels with that framework.

bjoo commented 7 years ago

We've had no feedback on this question, tho it could be because many people are at Lattice. GIven that MILC use their own codegen (with Grid-like layout) and have written a lot of their own stuff in their own repos, I don't think us doing this would hurt their efforts. So I think going ahead with this would be fine. Please go ahead in a branch as discussed on Slack #general .

martin-ueding commented 7 years ago

The old repository of qphix-codegen will be retained, so people can still use that for reference and have the various abandoned branches in there.

martin-ueding commented 7 years ago

There is a new codegen-fusion branch that now includes the whole history of the code generator instead of the submodule. Here is the point where qphix-codegen/master and qphix/devel are glued together:

jump1

The history of the code generator starts somewhere in the middle of the QPhiX commits:

jump

Its building on Travis CI, I don't expect any difference to before. Once that went through, I will push that to devel and mark the other repository as abandoned and.