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)
>>
>
