> 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
"C. Bergström"
2014-Feb-28 03:03 UTC
[LLVMdev] [Openmp-dev] Future of the LLVM OpenMP runtime
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.