systemml-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niketan Pansare" <>
Subject Re: Discussion on GPU backend
Date Wed, 25 May 2016 18:11:26 GMT

Luciano: Yes, there was a bit of confusion and hence wanted to iron things
out to foster collaboration and community feedback on GPU backend.

There are multiple issues:
1. Any work on smaller GPU PRs is dependent on the initial PR getting into
the master (as the initial PR contains the buffer-pool integration logic).
Or at least, everyone agreeing with the design of the initial PR.
2. There is an interest in collaborating on the initial PR itself and I
would like to see collaboration from early on (See and
3. The policy of squashing the PR into one commit essentially means only
one person's work will be acknowledged. I am little uneasy on asking people
to collaborate and not acknowledging their work. For example: Mike's
commit/references was lost when the
 was delivered.
4. The initial PR is waiting for following items:
- SystemML 0.10 released (as we agreed not to include GPU backend in 0.10
- The unknowns and concerns regarding GPU backend are discussed and
- So as to resolve dev dependency issue pointed by Matthias, jcu*.jar needs
to be hosted on local mvn repo. There are few alternative I have already
explored in this direction:
(a) Filed a PR against mavenized jcuda:
(b) Hosted mvn repo using github mvn plugin. Here is how we can resolve
system scope:


Niketan Pansare
IBM Almaden Research Center
E-mail: npansar At

From:	Luciano Resende <>
Date:	05/25/2016 10:06 AM
Subject:	Re: Discussion on GPU backend

But, from the original question, I was under the impression that creating
and merging multiple small prs were not a possible direction. If that is
ok, then it's regular development practice.

On Wed, May 25, 2016 at 9:20 AM, <> wrote:

> In my opinion, the problem with using a separate branch with longer-term
> work, rather than smaller PRs into the master, is that after several
> commits, say 10 or 20, it becomes much more difficult to rebase without
> running into nasty merge conflicts, especially when those conflicts are
> an intermediate commit so one would have to remember what the code looked
> like at that point in time to properly fix the conflicts. To me, this
> invites issues such as duplicated code and slower progress.
> --
> Mike Dusenberry
> GitHub:
> LinkedIn:
> Sent from my iPhone.
> > On May 25, 2016, at 9:01 AM, Luciano Resende <>
> wrote:
> >
> > On Wed, May 25, 2016 at 6:03 AM, Berthold Reinwald
> > wrote:
> >
> >> the discussion is less about (1), (2), or (3). As practiced so far,
> is
> >> the way to go.
> >>
> >> The question is about (A) or (B). Curious was the Apache suggested
> >> practice is.
> > Apache is key on fostering open collaboration, so specifically about
> > branching, having a SystemML branch that is used for
> > collaboration/experimentation is probably preferable, as it gives
> > visibility to others on the community, enables iterative development
> trough
> > review of small patches, while shield the trunk of issues these
> experiments
> > can cause.
> >
> > I would just recommend to avoid making the branch stale, and keep
> rebasing
> > it with latest master, which will make integration much easier in the
> > future.
> >
> >
> >
> > --
> > Luciano Resende
> >
> >

Luciano Resende

  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message