1) Won't that have bad interactions with pre-compilation? Since macros
apply at parse time, the package will stay in the "state" the it
precompiles in: so if one precompiles the package and then adds
ParallelAccelerator, wouldn't that not be used? And the other way around,
if one removes ParallelAccelerator, won't the package be unusable without
manually deleting the precompile cache? I think that to use this you'd have
to link the precompilation of the package to whether you have changes in
ParallelAccelerator.
2) Shouldn't/Won't Base auto-parallelize broadcasted calls? That seems like
the clear next step after loop fusing is finished and threading is no
longer experimental. Where else is the implicit parallelism hiding?
On Thursday, October 27, 2016 at 2:02:38 PM UTC-7, Todd Anderson wrote:
>
> To answer your question #1, would the following be suitable? There may be
> a couple details to work out but what about the general approach?
>
> if haskey(Pkg.installed(), "ParallelAccelerator")
> println("ParallelAccelerator present")
>
> using ParallelAccelerator
>
> macro PkgCheck(ast)
> quote
> @acc $(esc(ast))
> end
> end
> else
> println("ParallelAccelerator not present")
>
> macro PkgCheck(ast)
> return ast
> end
> end
>
> @PkgCheck function f1(x)
> x * 5
> end
>
> a = f1(10)
> println("a = ", a)
>
>
> 2) The point of ParallelAccelerator is to extract the implicit parallelism
> automatically. The purpose of @threads is to allow you to express
> parallelism explicitly. So, they both enable parallelism but the former
> has the potential to be a lot easier to use particularly for scientific
> programmers who are more scientist than programmer. In general, I feel
> there is room for all approaches to be supported across a range of
> programming ability.
>
> On Thursday, October 27, 2016 at 10:47:57 AM UTC-7, Chris Rackauckas wrote:
>>
>> Thank you for all of your amazing work. I will be giving v0.2 a try soon.
>> But I have two questions:
>>
>> 1) How do you see ParallelAccelerator integrating with packages? I asked
>> this in the chatroom, but I think having it here might be helpful for
>> others to chime in. If I want to use ParallelAccelerator in a package, then
>> it seems like I would have to require it (and make sure that every user I
>> have can compile it!) and sprinkle the macros around. Is there some
>> sensible way to be able to use ParallelAccelerator if it's available on the
>> user's machine, but not otherwise? This might be something that requires
>> Pkg3, but even with Pkg3 I don't see how to do this without having one
>> version of the function with a macro, and another without it.
>>
>> 2) What do you see as the future of ParallelAccelerator going forward? It
>> seems like Base Julia is stepping all over your domain: automated loop
>> fusing, multithreading, etc. What exactly does ParallelAccelerator give
>> that Base Julia does not or, in the near future, will not / can not? I am
>> curious because with Base Julia getting so many optimizations itself, it's
>> hard to tell whether supporting ParallelAccelerator will be a worthwhile
>> investment in a year or two, and wanted to know what you guys think of
>> that. I don't mean you haven't done great work: you clearly have, but it
>> seems Julia is also doing a lot of great work!
>>
>> On Tuesday, October 25, 2016 at 9:42:44 AM UTC-7, Todd Anderson wrote:
>>>
>>> The High Performance Scripting team at Intel Labs is pleased to announce
>>> the release of version 0.2 of ParallelAccelerator.jl, a package for
>>> high-performance parallel computing in Julia, primarily oriented around
>>> arrays and stencils. In this release, we provide support for Julia 0.5 and
>>> introduce experimental support for the Julia native threading backend.
>>> While we still currently support Julia 0.4, such support should be
>>> considered deprecated and we recommend everyone move to Julia 0.5 as Julia
>>> 0.4 support may be removed in the future.
>>>
>>> The goal of ParallelAccelerator is to accelerate the computational
>>> kernel of an application by the programmer simply annotating the kernel
>>> function with the @acc (short for "accelerate") macro, provided by the
>>> ParallelAccelerator package. In version 0.2, ParallelAccelerator still
>>> defaults to transforming the kernel to OpenMP C code that is then compiled
>>> with a system C compiler (ICC or GCC) and transparently handles the
>>> invocation of the C code from Julia as if the program were running normally.
>>>
>>> However, ParallelAccelerator v0.2 also introduces experimental backend
>>> support for Julia's native threading (which is also experimental). To
>>> enable native threading mode, set the environment variable
>>> PROSPECT_MODE=threads. In this mode, ParallelAccelerator identifies pieces
>>> of code that can be run in parallel and then runs that code as if it had
>>> been annotated with Julia's @threads and goes through the standard Julia
>>> compiler pipeline with LLVM. The ParallelAccelerator C backend has the
>>> limitation that the kernel functions and anything called by those cannot
>>> include code that is not type-stable to a single type. In particular,
>>> variables of type Any are not supported. In practice, this restriction was
>>> a significant limitation. For the native threading backend, no such
>>> restriction is necessary and thus our backend should handle arbitrary Julia
>>> code.
>>>
>>> Under the hood, ParallelAccelerator is essentially a domain-specific
>>> compiler written in Julia. It performs additional analysis and optimization
>>> on top of the Julia compiler. ParallelAccelerator discovers and exploits
>>> the implicit parallelism in source programs that use parallel programming
>>> patterns such as map, reduce, comprehension, and stencil. For example,
>>> Julia array operators such as .+, .-, .*, ./ are translated by
>>> ParallelAccelerator internally into data-parallel map operations over all
>>> elements of input arrays. For the most part, these patterns are already
>>> present in standard Julia, so programmers can use ParallelAccelerator to
>>> run the same Julia program without (significantly) modifying the source
>>> code.
>>>
>>> Version 0.2 should be considered an alpha release, suitable for early
>>> adopters and Julia enthusiasts. Please file bugs at
>>> https://travis-ci.org/IntelLabs/ParallelAccelerator.jl/issues .
>>>
>>> See our GitHub repository at
>>> https://github.com/IntelLabs/ParallelAccelerator.jl for a complete list
>>> of prerequisites, supported platforms, example programs, and documentation.
>>>
>>> Thanks to our colleagues at Intel and Intel Labs, the Julia team, and
>>> the broader Julia community for their support of our efforts!
>>>
>>> Best regards,
>>> The High Performance Scripting team
>>> (Parallel Computing Lab, Intel Labs)
>>>
>>
