vectorisation code?

[Manuel M T Chakravarty]

Given the vectorisation code is in its own subdirectory already, it’s quite easy to spot in a grep, I would say.

Manuel

> Richard Eisenberg <eir at cis.upenn.edu>:
> 
> With all due respect to Manuel's request, could I opt for a different resolution? I frequently (several times during most minutes of GHC programming) grep the GHC source code for this or that. If the vectorisation code is CPP'd away but still present in the compiler/ directory, these greps will find hits in the code. Furthermore, without the specific knowledge that there is a `#if 0` at the top of the file, the code will look quite active. Of course, I could modify my grep macro to skip the vectorise directory, but the next dev down the road might not know to do this.
> 
> Here's an alternate suggestion: in SimplCore, keep the call to vectorise around, but commented out (not just with CPP, for better syntax highlighting). Include a Note explaining what `vectorise` does and why it's not there at the moment. However, move the actual vectorisation code somewhere else in the repo, outside of the source directories (`utils`? a new `attic` directory?).
> 
> Manuel, is this acceptable to you? Other devs, thoughts? Perhaps we should also make a Trac ticket asking for some love to be given to this feature.
> 
> Thanks,
> Richard
> 
> On Jan 19, 2015, at 9:21 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
>> Austin, (or anyone else)
>> 
>> Manuel says:
>> 
>> |  > Would it be ok if we left it in the repo, but CPP'd it out so that
>> |  we
>> |  > didn't compile everything?  (The DPH library is in the same state at
>> |  > the moment.)
>> |  >
>> |  > It might suffer bit-rot, but it’d still be there for resurrection.
>> |  
>> |  Sure, that’s ok.
>> 
>> Could you action this?  Just avoid compiling anything in 'vectorise/', using (I suppose) cpp to create a stub where necessary.
>> 
>> Leave enough comments to explain!
>> 
>> Simon
>> 
>> |  
>> |  I hope everything is fine in Cambridge!
>> |  Manuel
>> |  
>> |  > |  -----Original Message-----
>> |  > |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
>> |  > | Manuel M T Chakravarty
>> |  > |  Sent: 16 January 2015 02:58
>> |  > |  To: Richard Eisenberg
>> |  > |  Cc: ghc-devs at haskell.org Devs
>> |  > |  Subject: Re: vectorisation code?
>> |  > |
>> |  > |  [Sorry, sent from the wrong account at first.]
>> |  > |
>> |  > |  We currently don’t have the resources to work on DPH. I would
>> |  > | obviously prefer to leave the code in, in the hope that we will be
>> |  > | able to return to it.
>> |  > |
>> |  > |  Manuel
>> |  > |
>> |  > |  > Richard Eisenberg <eir at cis.upenn.edu>:
>> |  > |  >
>> |  > |  > Hi devs,
>> |  > |  >
>> |  > |  > There's a sizable number of modules in the `vectorise`
>> |  > | subdirectory  of GHC. I'm sure these do all sorts of wonderful
>> |  > | things. But what,  exactly? And, does anyone make use of these
>> |  wonderful things?
>> |  > |  >
>> |  > |  > A quick poking through the code shows a tiny link between the
>> |  > | vectorise code and the rest of GHC -- the function `vectorise`
>> |  > | exported from the module `Vectorise`, which is named in exactly
>> |  one
>> |  > | place from SimplCore. From what I can tell, the function will be
>> |  > | called only when `-fvectorise` is specified, and then it seems to
>> |  > | interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE
>> |  > | #-}`  doesn't appear in the manual at all, and `-fvectorise` is
>> |  > | given only a  cursory explanation. It seems these work with DPH...
>> |  > | which has been  disabled, no? Searching online finds several hits,
>> |  > | but nothing more  recent than 2012.
>> |  > |  >
>> |  > |  > I hope this question doesn't offend -- it seems that
>> |  > | vectorisation  probably has amazing performance gains. Yet, the
>> |  > | feature also seems  unloved. In the meantime, compiling (and
>> |  > | recompiling, and
>> |  > |  recompiling...) the modules takes time, as does going through
>> |  them
>> |  > | to  propagate changes from elsewhere. If this feature is truly
>> |  > | orphaned,  unloved, and unused at the moment, is it reasonable to
>> |  > | consider  putting it on furlough?
>> |  > |  >
>> |  > |  > Thanks,
>> |  > |  > Richard
>> |  > |  > _______________________________________________
>> |  > |  > ghc-devs mailing list
>> |  > |  > ghc-devs at haskell.org
>> |  > |  > http://www.haskell.org/mailman/listinfo/ghc-devs
>> |  > |
>> |  > |  _______________________________________________
>> |  > |  ghc-devs mailing list
>> |  > |  ghc-devs at haskell.org
>> |  > |  http://www.haskell.org/mailman/listinfo/ghc-devs
>> 
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs