search for: jhenning

Alexandre, Thanks for further shedding some light on the way OpenMP handles dependencies between tasks. I'm sorry for leaving that out of my document, it was just because I didn't know much about the way OpenMP handled its workflows. On Mon, Mar 28, 2016 at 11:43 AM Jason Henline <jhen at google.com> wrote: > Hi Carlo, > > Thanks for helping to clarify this point about

Hi Carlo, Thanks for helping to clarify this point about libomptarget vs liboffload, I have been getting confused about it myself. I think the open question concerns libomptarget not liboffload (others can correct me if I have misunderstood). My analysis from looking through the code was that libomptarget had some similarities with the platform support in SE, so I just wanted to consider how

Jason, Am I got it right, that SE interfaces are bound to the stream that is passed as argument? As I can see the stream is an abstraction of the target - hence data transfers for particular stream is limited to this stream? As for libomptarget implementation the data once offloaded can be reused in all offload entries, without additional data transfer. Is it possible in SE approach? Regarding

I talked to Chandler about the name "offload_libs" vs "parallel_libs" and he said he thinks "offload" is too narrow of a term for the scope he sees for this subproject. One example he brought up was AVX 512. He thinks that code explicitly targeting CPU parallelism should also be included in this project, even though it doesn't fit in the category of

Hi Andrey, Sorry, I definitely misspoke when I said it was likely for OpenMP stuff to end up in this new project. I meant to say that it was possible in the long run, but there are no plans for that now. On Thu, Jun 16, 2016 at 11:55 AM Andrey Bokhanko <andreybokhanko at gmail.com> wrote: > On Thu, Jun 16, 2016 at 9:05 PM, Jason Henline via Openmp-dev < > openmp-dev at

Hi Sergos, Am I got it right, that SE interfaces are bound to the stream that is passed as argument? As I can see the stream is an abstraction of the target - hence data transfers for particular stream is limited to this stream? As for libomptarget implementation the data once offloaded can be reused in all offload entries, without additional data transfer. Is it possible in SE approach? If I

Hola Chandler, On Tue, Mar 15, 2016 at 1:44 PM, Chandler Carruth via Openmp-dev < openmp-dev at lists.llvm.org> wrote: > It seems like if the OpenMP folks want to add a liboffload plugin to > StreamExecutor, that would be an awesome additional platform, but I don't > see why we need to force the coupling here. > > Let me give you a reason: while user-facing sides of

Jason, > If I understand your interpretation of streams, it does not match my > understanding. SE follows the CUDA meaning of "stream". I think of a stream > as a "work queue" and each device can have several active streams. Memory > space on the device does not belong to any stream, so any stream can access > it. The thing that does belong to the stream is the

I did a more thorough read through liboffload and wrote up a more detailed doc describing how StreamExecutor platforms relate to libomptarget RTL interfaces. The doc also describes why the lack of support for streams in libomptarget makes it impossible to implement some of the most important StreamExecutor platforms in terms of libomptarget (

----- Original Message ----- > From: "Arpith C Jacob" <acjacob at us.ibm.com> > To: llvm-dev at lists.llvm.org > Cc: jhen at google.com, "Hal J. Finkel" <hfinkel at anl.gov> > Sent: Thursday, March 10, 2016 10:38:46 AM > Subject: Re: [llvm-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries > > Hi Jason, >

...tual user's maildir to another virtual user but am running into problems with dsync and doveadm. I'm trying to move the maildir of a user who is no longer with the company to a manager's maildir. For doveadm I am using the command: doveadm move -u scavenaugh at lamontanita.coop jhenning at lamontanita.coop/INBOX/scavenaugh INBOX ALL The error is: doveadm(scavenaugh at lamontanita.coop): Error: user scavenaugh at lamontanita.coop: Auth USER lookup failed /var/log/dovecot.log shows: passdb doesn't support lookups, can't verify user's existence dovecot...

I've put together a proposed "charter" for this new project, which I am calling parallel_utils (although I'm very open to suggestions for a better name). The text of my charter is below, and I welcome any input on how it can be improved. ===================================================== LLVM Parallel Utils Subproject Charter

Hi Jason, This is probably because I'm not aware of the details, but it was claimed in this thread that liboffload can target Xeon Phi and Nvidia GPUs. Adding a new library that the compiler has to be aware of has to bring significant benefit. So it is not clear to me yet why the compiler should target two different runtime libraries that seems to have large chunk of overlapping

Thanks for your help, Tanya! I haven't created the project in SVN yet. Am I able to set it up myself on the LLVM servers, or does someone else need to do that part? I'll be glad to volunteer to moderate the new mailing lists. We will want a website. I think there will be a top-level docs directory for the project and a docs directory for each subproject. To begin with, StreamExecutor

Hi Jason, The long discussion made me wondering where this was going, but re-reading you original email [0], there was an acknowledgment of a potential future merge between the projects, and I can of make sense of the current picture. So you can forget about my question below! [0]: http://lists.llvm.org/pipermail/llvm-dev/2016-March/096576.html

Chandler, That raises a more meta-question for me, which is “Why should StreamExecutor be in LLVM at all?” AFAICS, with you approach · It is not a runtime library whose interface the compiler needs to understand. · It does not depend on any LLVM runtime libraries. · It is expected to be used with out-of-tree plugins. If I got all of that right, what connection does it

Hi Reading through the comments: both Chris and Chandler referenced to liboffload, while I thought the subject of conversation was libomptarget and SE. I am being picky about names because liboffload is a library available as part of omp (llvm's openmp runtime library) that, I believe, only targets Intel Xeon Phi. Did you mean liboffload or libomptarget? Thanks -- Carlo From: Alexandre

I respect Hal's more tactful approach and response.. Let me play devils advocate for a minute 1) Yet another programming model - Is the advantage spelled out somewhere? (I know there are reasons, but I'd like to see a FAQ or this clearly documented. Examples pretty please.. More for long term than my own selfish benefit) 2) Is this an "open standard" - If I wanted to propose a

Hi Tanya, As discussed in the past few weeks in the llvm-dev thread “RFC: Proposing an LLVM subproject for parallelism runtime and support libraries”, we would like to start a new LLVM subproject called parallel-libs (a kind of a parallel cousin to compiler-rt), and I was told you were the one to contact in order to get it created. The charter for the project is included below. Are you able to

I created a GitHub repo that contains the documentation I have been creating for StreamExecutor. https://github.com/henline/streamexecutordoc It contains the design docs from the original email in this thread, and it contains a new doc I just made that gives a more detailed sketch of the StreamExecutor platform plugin interface. This shows which methods must be implemented to support a new