vectorisation code?

Simon Peyton Jones simonpj at microsoft.com
Thu Jan 22 11:36:08 UTC 2015


The issue that Richard Eisenberg raised is not

  DPH doesn't compile (which Geoff might fix)

but rather

  no one is working on DPH, but having it all in the tree
  imposes a small cost on a large number of people
  (build/validate cycle time, grep hits, etc)

So re-adding the DPH library would worsen the perceived problem, rather than make it better.

|  > My fear is that without making it part of the nightly builds,
|  > accumulated bitrot will make it extremely difficult to ever
|  > re-integrate DPH. I would hate to see that happen.

This was the reason we originally put the DPH libraries in the build.  Before we did so, changes to GHC often broke DPH, sometimes for superficial reasons, but sometimes because the DPH libraries really push the envelope of what GHC can do.

But when literally no one is working on DPH, it's harder to justify imposing (small) costs on everyone without giving immediate benefits to anyone.  That's the point that is being made here.  I don’t have strong feelings myself.

Simon 


|  -----Original Message-----
|  From: Manuel M T Chakravarty [mailto:chak at cse.unsw.edu.au]
|  Sent: 22 January 2015 04:08
|  To: Mainland Geoffrey
|  Cc: Simon Peyton Jones; ghc-devs at haskell.org
|  Subject: Re: vectorisation code?
|  
|  Thanks for the offer, Geoff.
|  
|  Under these circumstances, I would also very much prefer for Geoff
|  getting the code in order and leaving it in GHC.
|  
|  Manuel
|  
|  > Geoffrey Mainland <mainland at apeiron.net>:
|  >
|  > I'm sorry I'm a bit late to the game here, but there is also the
|  > option of reconnecting DPH to the build.
|  >
|  > When I patched DPH for the new version of the vector library, I did
|  > not perform this step---now I'm sorry I didn't.
|  >
|  > I am willing to get DPH in working order again---I believe the
|  > required work will be minimal. However, that only makes sense if we
|  1)
|  > re-enable DPH in the nightly builds (and also by default for
|  > validate?), and 2) folks will not object too strenuously to having
|  DPH stick around.
|  >
|  > My fear is that without making it part of the nightly builds,
|  > accumulated bitrot will make it extremely difficult to ever
|  > re-integrate DPH. I would hate to see that happen.
|  >
|  > Geoff
|  >
|  > On 01/21/2015 04:11 PM, Simon Peyton Jones wrote:
|  >>
|  >> I’ve had a chat to Manuel.  He is content for us to remove DPH code
|  >> altogether (not just CPP/comment it out), provided we are careful
|  to
|  >> signpost what has gone and how to get it back.
|  >>
|  >>
|  >>
|  >> I am no Git expert, so can I leave it to you guys to work out what
|  to
|  >> do?  The specification is:
|  >>
|  >> ·        It should be clear how to revert the change; that is, to
|  >> re-introduce the deleted code.  I guess that might be “git revert
|  >> <some horrible hash>”
|  >>
|  >> ·        If someone trips over more DPH code later, and wants to
|  >> remove that too, it should be clear how to add it to the list of
|  >> things to be revertred.
|  >>
|  >> ·        We should have a Trac ticket “Resume work on DPH and
|  >> vectorisation” or something like that, which summarises the
|  reversion
|  >> process.
|  >>
|  >>
|  >>
|  >> Just to be clear, this does not indicate any lack of interest in
|  DPH
|  >> on my part.  (Quite the reverse.)   It’s just that while no one is
|  >> actually working on it, we should use our source code control
|  system
|  >> to move it out of the way, as others on this thread have
|  persuasively
|  >> argued.
|  >>
|  >>
|  >>
|  >> Manuel, yell if I got anything wrong.
|  >>
|  >>
|  >>
|  >> Thanks!
|  >>
|  >>
|  >>
|  >> Simon
|  >>
|  >>
|  >>
|  >>
|  >>
|  >>
|  >>
|  >>
|  >>
|  >>
|  >>
|  >> *From:*ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of
|  >> *Carter Schonwald
|  >> *Sent:* 21 January 2015 03:32
|  >> *To:* RodLogic
|  >> *Cc:* Manuel M T Chakravarty; ghc-devs at haskell.org
|  >> *Subject:* Re: vectorisation code?
|  >>
|  >>
|  >>
|  >> moving it to its own submodule is just a complicated version of
|  >> cutting a branch that has the code Right before deleting it from
|  master.
|  >>
|  >> afaik, the amount of love needed is roughly "one or more full time
|  >> grad students really owning it", though i could be wrong.
|  >>
|  >>
|  >>
|  >>
|  >>
|  >> On Tue, Jan 20, 2015 at 5:39 AM, RodLogic <dev at rodlogic.net
|  >> <mailto:dev at rodlogic.net>> wrote:
|  >>
|  >>    (disclaimer: I know nothing about the vectorization code)
|  >>
|  >>
|  >>
|  >>    Now, is the vectorization code really dead code or it is code
|  that
|  >>    needs love to come back to life? By removing it from the code
|  >>    base, you are probably sealing it's fate as dead code as we are
|  >>    limiting new or existing contributors to act on it (even if it's
|  a
|  >>    commit hash away). If it is code that needs love to come back to
|  >>    life, grep noise or conditional compilation is a small price to
|  >>    pay here, imho.
|  >>
|  >>
|  >>
|  >>    As a compromise, is it possible to move vectorization code into
|  >>    it's own submodule in git or is it too intertwined with core
|  GHC?
|  >>    So that it can be worked on independent of GHC?
|  >>
|  >>
|  >>
|  >>
|  >>
|  >>    On Tue, Jan 20, 2015 at 6:47 AM, Herbert Valerio Riedel
|  >>    <hvriedel at gmail.com <mailto:hvriedel at gmail.com>> wrote:
|  >>
|  >>        On 2015-01-20 at 09:37:25 +0100, Jan Stolarek wrote:
|  >>>> Here's an alternate suggestion: in SimplCore, keep the call
|  >>        to vectorise
|  >>>> around, but commented out
|  >>
|  >>> Yuck. Carter and Brandon are right here - we have git, let
|  >>        it do the
|  >>> job. I propose that we remove vectorization code, create a
|  >>        Trac ticket
|  >>> about vectorization & DPH needing love and record the commit
|  >>        hash in
|  >>> the ticket so that we can revert it easily in the future.
|  >>
|  >>        I'm also against commenting out dead code in the presence of
|  a
|  >>        VCS.
|  >>
|  >>        Btw, here's two links discussing the issues related to
|  >>        commenting out if
|  >>        anyone's interested in knowing more:
|  >>
|  >>         -
|  >>
|  >> http://programmers.stackexchange.com/questions/190096/can-
|  commented-o
|  >> ut-code-be-valuable-documentation
|  >>
|  >>         -
|  >>
|  >> http://programmers.stackexchange.com/questions/45378/is-commented-
|  out
|  >> -code-really-always-bad
|  >>
|  >>
|  >>        Cheers,
|  >>          hvr
|  >>
|  >>
|  >
|  >
|  > _______________________________________________
|  > ghc-devs mailing list
|  > ghc-devs at haskell.org
|  > http://www.haskell.org/mailman/listinfo/ghc-devs



More information about the ghc-devs mailing list