1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

PathScale's ENZO Compiler To Speed Code On GPU

Compiler

Published on 11 February 2013 05:43 PM EST
Written by Michael Larabel in Compiler
Comment On This Article

PathScale, the company that's focused on providing high-performance compiler solutions, is hoping to speed up traditional software packages by automatically leveraging the graphics processor when compiling software with the PathScale ENZO compiler.

After writing this weekend about the PathScale EKOPath 5.0 Beta, Christopher Bergström, the CTO of PathScale, commented in our forums about some of their current work.

First of all, one of the interesting features that Bergström notes about EKOPath 5.0 is that it's leveraging some of Clang. Clang is the C/C++ front-end compiler to LLVM and while EKOPath isn't based upon LLVM, they have adapted some of the BSD-licensed Clang code to their compiler. "EKOPath 5 is really a *BIG* difference behind the scenes. For example if you do pathcc -show hello.c # You'll notice that we're using a modified clang as part of the process. This is almost certainly what allowed us build those additional benchmarks. (To clarify a bit - we're not using the llvm backend or any llvm ir. In the past we were using a modified gnu cc1, but that and all other gnu code has been removed.)"

It was also revealed that the succeeding EKOPath compiler (likely EKOPath 5.5) will feature a new compiler back-end. "EKOPath 5.5 will have a new backend we've been working on, but pushing out both of those big changes at the same time just wasn't possible."

Bergström then commented on their ENZO compiler product that is a GPGPU and multi-core solution that supports HMPP, Fortran, and C/C++ languages. ENZO features true GPGPU network zero copy, the PSCNV open-source compute Tesla driver (their Nouveau driver fork), PathAS assembler support for GPGPU, is compatible with CUDA code, and they have their own PathScale C++ template/class libraries for GPGPU. This "sister compiler to EKOPath", he explains, can now accelerate more code on the GPU. "While it's not possible speed-up every code on the GPU - We have put a huge amount of work in the programming models available for ENZO and it's backend performance. Personally, I don't get as excited (or worried) about 5-10% CPU performance when we can offer 30% gains to 10x with the GPU. I can't make promises, but we may try to drop a few OpenACC pragma around those benchmarks and post numbers on a Tesla 2050."

He followed up to a Phoronix reader comment about the GPU usage with, "I'd certainly recommend you test EKOPath and Intel compilers if you don't have a GPU. If you can get access to a system with a GPU (Tesla 2050, 2070 or 2090) *and* you're willing to add some pragma or directives to your code ENZO may be interesting. (The performance gains can be well worth the effort) We're working on support for -autogpu which like autovectorization or other automatic optimizations requires zero code changes. This isn't ready for production and just "noteworthy" at this point. (Honestly, give us a couple more months)."

It looks like interesting times are ahead for compilers exploiting the massively parallel capabilities of graphics processors. On the open-source side there's been work for LLVM automatic GPGPU code generation although nothing too exciting for end-users at the moment. Unfortunately, OpenACC isn't too widely implemented by open-source compilers at the moment. OpenACC is an industry, open standard to simplify parallel programming on CPUs and GPUs.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. AMD's New Athlon/Semprons Give Old Phenom CPUs A Big Run For The Money
  2. 13-Way Low-End GPU Comparison With AMD's AM1 Athlon
  3. ASUS AM1I-A: A Mini-ITX Board For Socketed Kabini APUs
  4. Mini-Box M350: A Simple, Affordable Mini-ITX Case
Latest Linux Articles
  1. How Much Video RAM Is Needed For Catalyst R3 Graphics?
  2. Ubuntu 12.04 LTS vs. 14.04 LTS Cloud Benchmarks
  3. Ubuntu 12.04.4 vs. 13.10 vs. 14.04 LTS Desktop Benchmarks
  4. AMD OpenCL Performance With AM1 Kabini APUs
Latest Linux News
  1. Oracle Linux 6.5 vs. Oracle Linux 7.0 Beta Benchmarks
  2. Easter Yields The Linux 3.15-rc2 Kernel Release
  3. The Most Amazing OpenGL Tech Demo In 64kb
  4. Packard Bell LM85 Now Supported By Coreboot
  5. AmazonBasics External USB 2.0 DVD Writer For Linux
  6. TP-LINK TG-3468: A $12 Linux PCI-E Gigabit Network Adapter
  7. Linux 3.15 Lands Some DRM Graphics Driver Fixes
  8. AMD Is Disabling DPM Support For RV770 GPUs
  9. ReactOS Working On A Community Windows OS
  10. eRacks Keeps Pushing Linux, Open-Source Systems After 15 Years
  11. Borderlands Is Being Considered For Linux
  12. Mesa 10.0 & 10.1 Stable Get Updated
Latest Forum Discussions
  1. ReactOS Working On A Community Windows OS
  2. The GNOME Foundation Is Running Short On Money
  3. Updated and Optimized Ubuntu Free Graphics Drivers
  4. Catalyst 14.3 Beta
  5. Suggestions about how to make a Radeon HD 7790 work decently?
  6. Radeon 8000M problematic on Linux?
  7. Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
  8. After Jack Keane, RuseSoft will briing Ankh 3 to Linux through Desura