Tuesday, January 16, 2018

AClang

"ACLang is an open source LLVM Clang based compiler that implements the OpenMP Accelerator Model. It adds a new runtime library to LLVM/CLang that supports OpenMP offloading to accelerators like GPUs. Kernel functions are extracted from OpenMP annotated regions and are dispatched as OpenCL or SPIR code to be loaded and compiled by OpenCL drivers before being executed by the device. AClang leverages on the ISL implementation of the polyhedral model to implement a multilevel tiling optimization on the extracted kernels. AClang also provides a vectorization pass developed specifically to exploit the vector instructions available in OpenCL. This whole process is transparent and does not require any programmer intervention."

https://omp2ocl.github.io/aclang/

Compiling and Optimizing OpenMP 4.X Programs to OpenCL and SPIR - https://hgpu.org/?p=17798

Given their massively parallel computing capabilities heterogeneous architectures comprised of CPUs and accelerators have been increasingly used to speed-up scientific and engineering applications. Nevertheless, programming such architectures is a challenging task for most non-expert programmers as typical accelerator programming languages (e.g. CUDA and OpenCL) demand a thoroughly understanding of the underlying hardware to enable an effective application speed-up. To achieve that, programmers are usually required to significantly change and adapt program structures and algorithms, thus impacting both performance and productivity. A simpler alternative is to use high-level directive-based programming models like OpenACC and OpenMP. These models allow programmers to insert both directives and runtime calls into existing source code, thus providing hints to the compiler and runtime to perform certain transformations and optimizations on the annotated code regions. In this paper, we present ACLang, an open-source LLVM/Clang compiler framework (http://www.aclang.org) that implements the recently released OpenMP 4.X Accelerator Programming Model. ACLang automatically converts OpenMP 4.X annotated program regions into OpenCL/SPIR kernels, while providing a set of polyhedral based optimizations like tiling and vectorization. OpenCL kernels resulting from ACLang can be executed on any OpenCL/SPIR compatible acceleration device, not only GPUs, but also FPGA accelerators like those found in the Intel HARP architecture. To the best of our knowledge and at the time this paper was written, this is the first LLVM/Clang implementation of the OpenMP 4.X Accelerator Model that provides a source-totarget OpenCL conversion.

CUDAnative.jl

"Julia support for native CUDA programming.

 GPUs and other accelerators are popular devices for accelerating compute-intensive, parallelizable applications. However, programming these devices is a difficult task. Writing efficient device code is challenging, and is typically done in a low-level programming language. High-level languages are rarely supported, or do not integrate with the rest of the high-level language ecosystem. To overcome this, we propose compiler infrastructure to efficiently add support for new hardware or environments to an existing programming language. We evaluate our approach by adding support for NVIDIA GPUs to the Julia programming language. By integrating with the existing compiler, we significantly lower the cost to implement and maintain the new compiler, and facilitate reuse of existing application code. Moreover, use of the high-level Julia programming language enables new and dynamic approaches for GPU programming. This greatly improves programmer productivity, while maintaining application performance similar to that of the official NVIDIA CUDA toolkit.
 
https://github.com/JuliaGPU/CUDAnative.jl 

https://hgpu.org/?p=17878 

LIFT

"Lift is a novel approach to achieving performance portability on parallel accelerators. Lift combines a high-level functional data parallel language with a system of rewrite rules which encode algorithmic and hardware-specific optimisation choices. Applications written in Lift are able to take advantage of GPUs (and in the future other accelerators), transparently from the user.

"Lift is a high-level domain-specific language and source-to-source compiler, targeting single system as well as distributed heterogeneous hardware. Initially targeting image processing algorithms, our framework now also handles general stencil-based operations. It resembles OpenCL, but abstracts away performance optimization details which instead are handled by our source-to-source compiler. Machine learning-based auto-tuning is used to determine which optimizations to apply. For the distributed case, by measuring performance counters on a small input on one device, previously trained performance models are used to predict the throughput of the application on multiple different devices, making it possible to balance the load evenly. Models for the communication overhead are created in a similar fashion and used to predict the optimal number of nodes to use." 


http://www.lift-project.org/

https://github.com/lift-project/lift

https://hgpu.org/?p=17926

ImageCL

"ImageCL is a simplified version of OpenCL, specifically aimed at image processing. A source-to-source translator can translate a single ImageCL program into multiple different OpenCL versions, each version with different optimizations applied. An auto-tuner can then be used to pick the best OpenCL version for a given device. This makes it possible to write a program once, and run it with high performance on a range of different devives."

https://github.com/acelster/ImageCL

https://hgpu.org/?p=17926

ratfor90

“Ratfor” is a dialect of Fortran that is more concise than raw Fortran. The newest Ratfor “compiler”, ratfor90 is a simple preprocesor program written in Perl that inputs an attractive Fortran-like dialect and outputs Fortran90. Mainly, the preprocessor produces Fortran statements like ” end do ”, “end if”, “end program”, and “end module”, from the Ratfor ”}”. Ratfor source is about 25-30% smaller than the equivalent Fortran making it equivalently more readable.

Bare-bones Fortran is our most universal computer language for computational physics. For general programming, however, it has been surpassed by C. Ratfor is Fortran with C-like syntax. Ratfor was invented by the people who invented C. After inventing C, they realized that they had made a mistake (too many semicolons) and they fixed it in Ratfor, although it was too late for C. Otherwise, Ratfor uses C-like syntax, the syntax that is also found in the popular languages C++ and Java .

At SEP we supplemented Ratfor77 by preprocessors to give Fortran77 the ability to allocate memory on the fly. These abilities are built into Fortran90 and are seamlessly included in Ratfor90. To take advantage of Fortran90's new features while maintaining the concise coding style provided by Ratfor required us to write a new Ratfor preprocessor, Ratfor90, which produces Fortran90, rather than Fortran77 code."

http://sepwww.stanford.edu/doku.php?id=sep:software:ratfor90

Wednesday, November 8, 2017

MooseFS

"Moose File System (MooseFS) is an Open-source, POSIX-compliant distributed file system developed by Core Technology. MooseFS aims to be fault-tolerant, highly available, highly performing, scalable general-purpose network distributed file system for data centers.

The file system comprises three components:
  • Metadata server (MDS) — manages the location (layout) of files, file access and namespace hierarchy. The current version of MooseFS does support multiple metadata servers and automatic failover. Clients only talk to the MDS to retrieve/update a file's layout and attributes; the data itself is transferred directly between clients and chunk servers. The Metadata server is a user-space daemon; the metadata is kept in memory and lazily stored on local disk.
  • Metalogger server — periodically pulls the metadata from the MDS to store it for backup. Since version 1.6.5, this is an optional feature.
  • Chunk servers (CSS) — store the data and optionally replicate it among themselves. There can be many of them, though the scalability limit has not been published. The biggest cluster reported so far consists of 160 servers.[9] The Chunk server is also a user-space daemon that relies on the underlying local file system to manage the actual storage.
  • Clients — talk to both the MDS and CSS. MooseFS clients mount the file system into user-space via FUSE.
 The file system comprises three components:
  • Metadata server (MDS) — manages the location (layout) of files, file access and namespace hierarchy. The current version of MooseFS does support multiple metadata servers and automatic failover. Clients only talk to the MDS to retrieve/update a file's layout and attributes; the data itself is transferred directly between clients and chunk servers. The Metadata server is a user-space daemon; the metadata is kept in memory and lazily stored on local disk.
  • Metalogger server — periodically pulls the metadata from the MDS to store it for backup. Since version 1.6.5, this is an optional feature.
  • Chunk servers (CSS) — store the data and optionally replicate it among themselves. There can be many of them, though the scalability limit has not been published. The biggest cluster reported so far consists of 160 servers.[9] The Chunk server is also a user-space daemon that relies on the underlying local file system to manage the actual storage.
  • Clients — talk to both the MDS and CSS. MooseFS clients mount the file system into user-space via FUSE.
https://moosefs.com/

https://en.wikipedia.org/wiki/Moose_File_System

https://github.com/moosefs/moosefs

LizardFS - fork of MooseFS

https://lizardfs.com/

From NFS to LizardFS - https://cedarandthistle.wordpress.com/2016/09/30/from-nfs-to-lizardfs/

Wednesday, August 2, 2017

Beyond Functional Programming: Manipulate Functions with the J Language

"In this article we'll get a brief introduction to the J programming language. The goal is to wet your appetite for an exciting programming paradigm rather than providing an in-depth introduction. As we move along we'll learn just enough J to explore a fascinating corner of the language that lets us manipulate functions as data. You'll see how these techniques differ from traditional functional programming, why manipulating functions is interesting and how it lets you solve real problems with a minimum of code."

http://www.adamtornhill.com/articles/jlang/beyondfunctional.html