llvm dev - Feb 2014 - [LLVMdev] [Openmp-dev] Future of the LLVM OpenMP runtime

> What's needed for CPU affinity?  We expose his via
pthread_attr_setaffinity_np() in <pthread_np.h> -
> does the runtime need anything more from the interface, or was this support
just not yet a high
> priority for you?  I'd be happy to help with this support.
The Linux code uses the sched_{get,set}affinity calls directly, rather than via
the pthread veneer.
It can also parse /proc/cpuinfo, though on X86 machines we likely avoid that in
most cases by using
info from the "cpuid" instruction to determine the hardware layout of
the machine. I have no idea
whether there are  equivalent interfaces on MIPS (Imagination) or ARM platforms
that would allow you
to discover the hardware configuration of the machine in a portable manner (I.e.
one that works no
matter what implementation of the architecture you happen to be running on).

-- Jim

James Cownie <james.h.cownie at intel.com>
SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)
Tel: +44 117 9071438


-----Original Message-----
From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David
Chisnall
Sent: Thursday, February 27, 2014 9:30 AM
To: Alp Toker
Cc: openmp-dev at dcs-maillist2.engr.illinois.edu; Cownie, James H; clang-dev
Developers; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Future of the LLVM OpenMP runtime

On 27 Feb 2014, at 08:25, Alp Toker <alp at nuanti.com> wrote:
> On 26/02/2014 09:03, David Chisnall wrote:
>> On 25 Feb 2014, at 23:13, Alp Toker <alp at nuanti.com> wrote:
>> 
>>> Now that we've kick-started the LLVM OpenMP runtime discussion,
I want to make a concrete proposal to get a test suite up and running for the
LLVM OpenMP runtime. I don't think the current setup as an LLVM subproject
is sustainable going forward without some form of testing support, automated or
otherwise.
>> I'd add that fairly high up the TODO list should probably be a
build system that's a bit easier to modify.  We're very interested in
getting the runtime working on FreeBSD with a view to importing it into the base
system at some point in the future (we've removed the GNU OpenMP runtime and
would quite like a replacement).
> 
> Some good news: We have a FreeBSD port covering both the build system and
the OpenMP runtime itself. I'll see if we can contribute this upstream in
the next few days.
> 
> This work generalises a few abstractions to ease porting to other platforms
as well.
That's awesome!  
>> We have a number of people producing experimental manycore 64-bit MIPS
systems running FreeBSD, so we'd also be interested in doing MIPS bring-up,
but the build system is currently something of a show-stopper for us.
> 
> The port is working on FreeBSD 10 x86_64 (modulo CPU affinity support) so
MIPS shouldn't be a large leap from there, hopefully this time with some
test coverage.
Excellent news!  We'll look at initially importing it and the Intel Clang
fork into the ports tree and see if we can start using it for OpenMP-requiring
ports.

What's needed for CPU affinity?  We expose his via
pthread_attr_setaffinity_np() in <pthread_np.h> - does the runtime need
anything more from the interface, or was this support just not yet a high
priority for you?  I'd be happy to help with this support.

Since Linux and FreeBSD use the same calling conventions and data layouts on
MIPS (and ARM), hopefully we can both benefit from improved architecture support
in the library.

David

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Tangentially related, I have a question:

I don't know, well, anything about how OpenMP is implemented. But does it
make sense to use Grand Central Dispatch on platforms that support it (instead
of, I assume, pthreads)?

-- 
Rick



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140227/4693f28f/attachment.sig>

On 27 Feb 2014, at 21:20, Rick Mann <rmann at latencyzero.com> wrote:
> I don't know, well, anything about how OpenMP is implemented. But does
it make sense to use Grand Central Dispatch on platforms that support it
(instead of, I assume, pthreads)?
It would certainly be interesting for an OpenMP runtime and libdispatch to use
the same kernel APIs for determining system load and the number of threads that
it makes sense to create.  For HPC applications, the number of threads that
OpenMP should use is basically the number of cores (although not always,
depending on the workload, many other disclaimers apply), but for a desktop or
mobile there may be power management concerns or other higher-priority tasks
that mean that you'll get better throughput using fewer threads.

David

On 02/28/14 04:20 AM, Rick Mann wrote:
> Tangentially related, I have a question:
>
> I don't know, well, anything about how OpenMP is implemented. But does
it make sense to use Grand Central Dispatch on platforms that support it
(instead of, I assume, pthreads)?
We played with implementing OpenMP 3.x tasks on top of libdispatch and 
while we got it to work - there was some scalability of the scheduling 
across a lot of cores which would probably need to be addressed. For 
systems with 4-8 cores I doubt it would ever cause a significant problem 
though.