Hi Brian --
Everything looks normal there. I won't have time to try reproducing what
you've seen for several days, but if all the hello*.chpl tests work for
you then you should have pretty good basic functionality working. I'd
encourage you to keep exploring, and we'll try to help if you run into
any other problems.
greg
On 3/17/2015 9:51 AM, Brian Guarraci wrote:
OK, I hope it's some basic config issue.
ubuntu@tegra-ubuntu:~/scm/chapel$ $CHPL_HOME/util/printchplenv produce
machine info: Linux tegra-ubuntu 3.10.24-g6a2d13a #1 SMP PREEMPT Fri
Apr 18 15:56:45 PDT 2014 armv7l
CHPL_HOME: /home/ubuntu/scm/chapel
script location: /mnt/ssd/scm/chapel/util
CHPL_HOST_PLATFORM: linux32
CHPL_HOST_COMPILER: gnu
CHPL_TARGET_PLATFORM: linux32
CHPL_TARGET_COMPILER: gnu
CHPL_TARGET_ARCH: unknown
CHPL_LOCALE_MODEL: flat
CHPL_COMM: gasnet
CHPL_COMM_SUBSTRATE: udp
CHPL_GASNET_SEGMENT: everything
CHPL_TASKS: fifo
CHPL_LAUNCHER: amudprun
CHPL_TIMERS: generic
CHPL_MEM: cstdlib
CHPL_MAKE: make
CHPL_ATOMICS: intrinsics
CHPL_NETWORK_ATOMICS: none
CHPL_GMP: none
CHPL_HWLOC: none
CHPL_REGEXP: none
CHPL_WIDE_POINTERS: struct
CHPL_LLVM: llvm
CHPL_AUX_FILESYS: none
On Tue, Mar 17, 2015 at 8:46 AM, Greg Titus <[email protected]
<mailto:[email protected]>> wrote:
I would guess that you shouldn't have to hack the GASNet Makefile
themselves to get gcc as your target compiler. That should be
arranged as a result of your setting CHPL_TARGET_COMPILER=gnu (or
taking that as the default). If that's not happening we might need
to do some more work in our Makefiles. That wouldn't be surprising
given how little experience we have with ARM. (My own exploration
was with CHPL_COMM=none.)
What does running $CHPL_HOME/util/printchplenv produce?
thanks,
greg
On 3/17/2015 9:24 AM, Brian Guarraci wrote:
I tried turning on gasnet to verify if i can use multilocales on
ARM and hit some compilation issues. I have worked around them
by hacking the third-party/gasnet/GASNet-1.24.0 headers to
assume PLATFORM_COMPILER_GNU. I have been able to run the hello
world example but wonder if I'm going to hit some subtle bug later.
diff --git
a/third-party/gasnet/GASNet-1.24.0/gasnet_atomic_bits.h
b/third-party/gasnet/GASNet-1.24.0/gasnet_atomic_bits.h
index f2d751e..97241e2 100644
--- a/third-party/gasnet/GASNet-1.24.0/gasnet_atomic_bits.h
+++ b/third-party/gasnet/GASNet-1.24.0/gasnet_atomic_bits.h
@@ -2574,7 +2574,8 @@
#endif
/*
------------------------------------------------------------------------------------
*/
#elif PLATFORM_ARCH_ARM && defined(GASNETI_HAVE_ARM_CMPXCHG)
- #if PLATFORM_COMPILER_GNU && PLATFORM_OS_LINUX
+ //#if PLATFORM_COMPILER_GNU && PLATFORM_OS_LINUX
+ #if PLATFORM_OS_LINUX
#define GASNETI_HAVE_ATOMIC32_T 1
typedef struct { volatile unsigned int ctr; }
gasneti_atomic32_t;
diff --git a/third-party/gasnet/GASNet-1.24.0/gasnet_membar.h
b/third-party/gasnet/GASNet-1.24.0/gasnet_membar.h
index 70e4ac6..17c0e93 100644
--- a/third-party/gasnet/GASNet-1.24.0/gasnet_membar.h
+++ b/third-party/gasnet/GASNet-1.24.0/gasnet_membar.h
@@ -225,7 +225,7 @@
#define GASNETI_RMB_IS_MB
#define GASNETI_WMB_IS_MB
/*
------------------------------------------------------------------------------------
*/
-#elif PLATFORM_ARCH_ARM && PLATFORM_OS_LINUX &&
PLATFORM_COMPILER_GNU
+#elif PLATFORM_ARCH_ARM && PLATFORM_OS_LINUX //&&
PLATFORM_COMPILER_GNU
#if defined(GASNETI_UNI_BUILD)
/* On a uniprocessor build avoid performing what reduces to
an expensive no-op */
#define gasneti_local_mb() gasneti_compiler_fence()
On Mon, Mar 16, 2015 at 8:54 PM, Brian Guarraci <[email protected]
<mailto:[email protected]>> wrote:
setting CHPL_TASKS=fifo works! Thanks! I'll see what I can
get going now.
On Mon, Mar 16, 2015 at 7:26 AM, Greg Titus <[email protected]
<mailto:[email protected]>> wrote:
Hi Brian --
(I'm Greg Titus, on the Chapel core team. I work mainly
on the runtime, especially tasking and communications.)
I've built Chapel on a Cavium ARM system and run one test
(hello world, of course!). I did have trouble with the
third-party/qthreads build there, and so had to drop back
to using our old fifo tasking layer by setting the
CHPL_TASKS environment variable to 'fifo'. If you do this
does the build get further or even succeed?
(We're a little busy at present since we're right at the
end of our release cycle, so I'll beg forgiveness ahead
of time if we're a bit slow in responding to things.)
greg
On 3/16/2015 8:05 AM, Brian Guarraci wrote:
I would definitely like to talk about Chapel as a great
way to utilize a highly distributed system. What I've
seen in these open-source communities, especially for
systems such as Parallella (which I also have an 8 node
version of), is that developers don't have a good way to
actually use the hardware. Python theano is one of the
easiest ways I've seen so far for GPU.
Regarding Chapel on ARM, I've tried compiling it
yesterday and hit an issue compiling pthread. The
Jetson TK1 boards running Ubuntu 14 don't seem to have
arm-uncontext.h. In short, if I can get some help
ironing out the build then I will work on some demos.
Thanks!
On Mon, Mar 16, 2015 at 6:56 AM, Michael Ferguson
<[email protected] <mailto:[email protected]>> wrote:
Hi Brian -
You could certainly run Chapel on your system across
the ARM chips
and ignore running on the GPUs for your demo. It
might be that
the current version of Chapel will show better on
one of the other
clusters you plan to bring, also. In any case, I
think it would
be really exciting to have Chapel shown at such an
event!
Just to add a little bit to what Brad mentioned
about GPU support.
There are a number of possible paths to running
Chapel code on GPUS:
- Generating CUDA code and then using nvcc (this
was Albert's approach)
- Generating OpenACC directives is another possibility
- Generating OpenCL
- Generating LLVM that can run on a GPU and using
e.g. OpenCL calls to
launch it
- (and idea I haven't brought up before)
integrating with the
Intel SPMD compiler and using its existing
capabilities
as the Chapel back-end
I'd be interested to know if you have an opinion
about how we build
GPU support. Besides that, any help you can offer in
development and
testing of such support would really help the project.
Cheers,
-michael
On 3/15/15, 2:56 AM, "Brad Chamberlain"
<[email protected] <mailto:[email protected]>> wrote:
>
>Hi Brian --
>
>There is no support for GPUs in the official Chapel
releases or on the
>master branch at GitHub. Albert Sidelnik (formerly
UIUC, now Nvidia) did
>some work on porting Chapel to GPUs a few years
back which was published
>at IPDPS and the paper is available here:
>
> http://polaris.cs.uiuc.edu/~asideln2/ipdps12.pdf
<http://polaris.cs.uiuc.edu/%7Easideln2/ipdps12.pdf>
>
>A few people have tried to resurrect this work from
time-to-time and
>catch
>it up to the current release, but I'm not aware
that any efforts have
>been
>terribly successful. Adding support for GPUs is on
our TODO list, but
>not
>at the top at present.
>
>Thanks for your interest in Chapel, and we' d be
curious to know more
>about your demo as it approaches,
>-Brad
>
>
>On Sat, 14 Mar 2015, Brian Guarraci wrote:
>
>> Hi,
>>
>> I'm interested in using Chapel to illustrate
parallel computing at a
>>Maker
>> Faire demo coming up in May. I have a couple
different cluster
>>computers
>> I'm going to be showing and one has 16 Nvidia
Jetson TK1 boards, which
>>is
>> an ARM-based SoC w/ CUDA GPU. I'm curious about
using Chapel for
>>showing
>> some demos on how to leverage the system. Has
anyone done this kind of
>> thing already?
>>
>> Thanks!
>> Brian
>>
>
>--------------------------------------------------------------------------
>----
>Dive into the World of Parallel Programming The Go
Parallel Website,
>sponsored
>by Intel and developed in partnership with Slashdot
Media, is your hub
>for all
>things parallel software development, from weekly
thought leadership
>blogs to
>news, videos, case studies, tutorials and more.
Take a look and join the
>conversation now. http://goparallel.sourceforge.net/
>_______________________________________________
>Chapel-developers mailing list
>[email protected]
<mailto:[email protected]>
>https://lists.sourceforge.net/lists/listinfo/chapel-developers
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel
Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your
hub for all
things parallel software development, from weekly thought
leadership blogs to
news, videos, case studies, tutorials and more. Take a look and
join the
conversation now.http://goparallel.sourceforge.net/
_______________________________________________
Chapel-developers mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/chapel-developers
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
