I don't know if its the right place to ask this question. But why did Apple choose to use llvm and its clang implementation to code for OpenCL/OpenGL?? What benefits did it bring to them and how? Excuse my ignorance on this topic, I know not much about this.
Apple created Clang as a drop in replacement to GCC for C/C++/ObjC and ObjC++. The creator of LLVM works at Apple inside their compiler divisions. In a joint effort with the University of Illinois who hosts the projects Apple has created complete replacements for GCC, GDB [see LLDB], libstdc++ [see libc++] and several new projects.
The GPLv3 was the final straw that ended Apple's interest in contributing to GCC which is the reason Apple ended it at GCC 4.2.x.
LLVM/Clang is rapidly supplanting GCC across the industry.
LLVM is now a misnomer of a title.
Present Target hardware supported in LLVM/Clang:
-- Targeting ARM
-- Targeting CppBackend
-- Targeting Hexagon
-- Targeting Mips
-- Targeting MBlaze
-- Targeting MSP430
-- Targeting NVPTX
-- Targeting PowerPC
-- Targeting Sparc
-- Targeting X86
-- Targeting XCore
-- Clang version: 3.3
Soon added out-of-the-box AMD R600 code base.
Clang is C99 compliant. OpenCL uses a subset of C99. Clang is the most complete C11 compliant Compiler suite available free of charge.
FreeBSD has moved to LLVM/Clang as the default set up for the upcoming 10.0 distribution.
AMD and Nvidia build their OpenCL stacks with LLVM/Clang.
Intel is moving their OpenCL and much more to LLVM/Clang.
Google is all in with LLVM/Clang. Ditto for Adobe, Sony, IBM, Cray, etc.
GCC is a mess of an architecture. The modularity of LLVM/Clang makes its rate of improvement and options for developers a much greater ceiling.
The Developer and User Guides for LLVM/Clang 3.2 are now very solid, with 3.3 trunk adding a much greater amount of docs to understand the benefits of LLVM/Clang.
The pace of development of high quality compiler code is second to none.
Straight from an LLVM/Apple Developer
More info, PDF Slides
LLVM is used in two different ways, at runtime:
Runtime code specialization within the fixed-function vertex-processing
pipeline. Basically, the OpenGL pipeline has many parameters (is fog
enabled? do vertices have texture info? etc) which rarely change:
executing the fully branchy code swamps the branch predictors and
performs poorly. To solve this, the code is precompiled to LLVM .bc
form, from which specializations of the code are made, optimized,
and JIT compiled as they are needed at runtime.
OpenGL vertex shaders are small programs written using a family of
programming langauges with highly domain-specific features (e.g. dot
product, texture lookup, etc). At runtime, the OpenGL stack translates
vertex programs into LLVM form, runs LLVM optimizer passes and then JIT
compiles the code.
(more details in the link above)
Because they contribute to the develop of Clang/LLVM and because source code compiled with LLVM/Clang produce faster binary than GCC ...
Clang's developers claim that it provides reduced memory footprint and
increased compilation speed compared to competing compilers, such as
GCC. To support their claim, they present that, as of October 2007,
Clang compiled the Carbon libraries well over twice as fast as GCC,
while using about one-sixth GCC's memory and disk space.
http://en.wikipedia.org/wiki/Clang
Related
I have an intel i7 haswell cpu, and I would like to start exploring OpenCL development. In particular, I am interested to run OpenCL code on the integrated GPU.
Unfortunately, by now, I was not able to find any SDK on Intel's site..
May you provide some links, together with a summary of the current status of OpenCL tools for the Linux platform and Intel hardware?
I think this would be useful to many other people..
Thanks a lot!
Intel does not provide free support for OpenCL on their iGPUs under Linux - you have to buy the Intel Media Server Studio, minimum $499. On Windows, you can download a free driver to get OpenCL capability for the iGPU: https://software.intel.com/en-us/articles/opencl-drivers#philinux.
Note that you can use any OpenCL SDK you want - it doesn't have to be Intel. The SDK is only useful for building your program. For running an OpenCL program, you need an appropriate runtime (driver) from the manufacturer. The AMD SDK will give you access to the CPU as an OpenCL device, but not the iGPU.
There is Open Source OpenCL implementation for Intel GPUs on Linux called Beignet, maintained by bunch of guys from Intel.
Sadly, couldn't personally try and check if Your's GPU is properly supported, but on their wiki they states:
Supported Targets
4th Generation Intel Core Processors "Haswell", need kernel patch currently, see the "Known Issues" section.
Beignet: self-test failed" and almost all unit tests fail. Linux 3.15 and 3.16 (commits f0a346b to c9224fa) enable the register whitelist by default but miss some registers needed for Beignet.
This can be fixed by upgrading Linux, or by disabling the whitelist:
# echo 0 > /sys/module/i915/parameters/enable_cmd_parser
On Haswell hardware, Beignet 1.0.1 to 1.0.3 also required the above workaround on later Linux versions, but this should not be required in current (after 83f8739) git master.
So, it's worth a shoot. Btw, it worked well on my 3rd generation HD4000.
Also, toolchain and driver in question includes bunch of GPU-support test cases.
For anyone who comes across this question as I did, the existing answers have some out-of-date information; Intel now offers free drivers for Linux on the site posted above: https://software.intel.com/en-us/articles/opencl-drivers#philinux
The drivers themselves are only supported on 5th, 6th and 7th gen Core processors (and a bunch of other Celerons and Xeons, see link), with earlier processors such as 4th gen still needing the Media Server Studio.
However, they now offer a Linux Community version of Media Server Studio which is free to download.
They also have a Driver Support Matrix for Intel Media SDK and OpenCL which has some useful information about compatibility: https://software.intel.com/en-us/articles/driver-support-matrix-for-media-sdk-and-opencl
You may check intel open source Beignet OpenCL library: http://arrayfire.com/opencl-on-intel-hd-iris-graphics-on-linux/
For me (ubuntu 15.10 + Intel i5 4th generation GPU) it works quite well.
P.S.
Also I must say that I managed to download "media server" for linux a couple of months ago (but didn't used it yet). So you may check it also.
I am interested in using the LLVM's Clang compiler. LLVM claims to be cross-platform however it is not clear which platforms can be targeted. I have done quite a lot of Googling on this but there doesn't seem to be much information about LLVM's supported platforms. The only thing I did find was "this" which is kinda confusing. I am not sure if it means I can compile binaries for those platforms using LLVM or if it just runs on those platforms (or both). Could someone who knows more about the LLVM/Clang compiler tell me which platforms I can target using Clang or any other LLVM front ends? I want specific information (like "It supports Windows 32bit, Windows 64bit, Linux 32bit, Linux 64bit, etc). Thanks!
EDIT:
Ok, I think I am just confused about what LLVM really is. From what I just figured out LLVM is simply a byte-code interpreter. Since LLVM is interpreted how much slower is LLVM binaries compared to executable binaries? So if performance is important LLVM is not the right choice? "Here" I found the architectures it supports but it did not say what operating systems it supports. Does it run on all operating systems if I avoid platform dependent code? I will look for more articles that explain LLVM in more detail if I can find any.
With llvm installed type
llc -version
and you will see something like
Registered Targets:
alpha - Alpha [experimental]
arm - ARM
bfin - Analog Devices Blackfin [experimental]
c - C backend
cellspu - STI CBEA Cell SPU [experimental]
cpp - C++ backend
mblaze - MBlaze
mips - Mips
mipsel - Mipsel
msp430 - MSP430 [experimental]
ppc32 - PowerPC 32
ppc64 - PowerPC 64
ptx32 - PTX (32-bit) [Experimental]
ptx64 - PTX (64-bit) [Experimental]
sparc - Sparc
sparcv9 - Sparc V9
systemz - SystemZ
thumb - Thumb
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
xcore - XCore
Go to github.com and search for mbed_samples to see llvm and clang being used to cross compile for ARM. Somewhere around blinker03 or 04 is where it comes in. LLVM works the same way for any platform, the llc step is where you choose your target, the compiling merging, optimizing, etc are all platform independent (well you might use -m32 for example to choose the int size) then llc gets you to platform dependent assembler.
There are many possible applications of LLVM in terms of target machine.
GPGPU (GPU). There are approaches like GPUOcelot for retargeting to gpu, here is an example : LLVM to PTX Backend.
According to OpenCL wikipedia at 2011-09: "The Apple,[22] Nvidia,[23] RapidMind[24] and Gallium3D[25] implementations of OpenCL are all based on the LLVM Compiler technology and use the Clang Compiler as its frontend."
Javascript as LLVM Target ! - Yes, tool, that is does it Emscripten - Emscripten GitHub homepage wiki with Demos, blog note about Emscripten 1.0, Emscripten documentation paper,
According to the clang manual clang can target X86, Arm with partial support for PPC, SPARC and MSP430.
Clang can also generate LLVM bytecode though. LLVM can run on quite a few more platforms.
So if you want native machine code then the list is pretty small. If you want LLVM bytecode you have a broader choice of platforms.
I'm only answering the edit's question here (it would probably be more appropriate to make a new question).
This is a good architectural overview of LLVM. This page also contains a ton of documentations on all aspects of LLVM.
The short version is that LLVM is the optimizer and backend of a traditionnal compiler. It operates on a bytecode which is essentially it's intermediate representation of the code and is used to optimize and generate the final binary. The LLVM frontends are independent and uses there own internal ASTs to eventually generate bytecode.
LLVM is actually pretty flexible when it comes to when you want to generate the final binary. You can either do it right away or delay it until the program is being installed. I believe you can even use its JIT to generate the final binary during execution (not 100% sure of this). The main advantage of delaying like this is that it can apply optimizations that are specific to the environment it is executing on.
I have been using the GCC Compiler for months, which is great, and works very well. But I wonder which C++ Compiler do big/medium enterprises use for high optimizations/performance in Linux (x86, PowerPC...).
It may seem a very stupid question, but I havent found the answer anywhere.
As far as I know, the best PowerPC Compiler is the XL, but x86 I dont know anything.
EDIT: Thanks a lot for all the answers. They were all very helpful. You have convinced me to use GCC ;) Regards!
In the places I have worked we have always used gcc, even for embedded applications/software.
Performance improvements are much more likely to come from your code rather than your compiler choice anyway!
Intel sells its own compilers which are supposed to generate very performant code...at least on Intel CPUs.
The nice thing about ICC compared to GCC is that ICC uses EDG's C++ frontend, which means that it has better support for some advanced C++ features than GCC.
Everyone uses GCC - most Sun sites (for example) I've worked at replace their crappy Sun development tools (And boy, are they crappy) with Open Source ones like GCC.
For embedded PowerPC, check out the Wind River Diab Compiler.
Intel Compiler Collection, Sun ONE Studio, IBM XL C Compiler, Open64, Open Watcom, and of course GCC.
I presume some companies must be using Sun ONE & xlC for porting large projects as there is no reason why anyone would normally to use them.
EKOPath 4 Compiler Suite
https://github.com/path64/repositories
http://www.pathscale.com/ekopath-compiler-suite
PathScale is freely releasing the
source to the EKOPath 4 Compiler
Suite. EKOPath 4 is a high-performance
compiler that up until now has been
proprietary and costs nearly $2000 USD
per license, but now it's open-source
and can sharply outperform GCC in many
computationally-intense workloads.
The community indeed is excited for EKOPath now being open-source (GPLv3)
I have a question concerning llvm, clang, and gcc on OS X.
What is the difference between the llvm-gcc 4.2, llvm 2.0 and clang? I know that they all build on llvm but how are they different?
Besides faster compiling, what is the advantage of llvm over gcc?
LLVM originally stood for "low-level virtual machine", though it now just stands for itself as it has grown to be something other than a traditional virtual machine. It is a set of libraries and tools, as well as a standardized intermediate representation, that can be used to help build compilers and just-in-time compilers. It cannot compile anything other than its own intermediate representation on its own; it needs a language-specific frontend in order to do so. If people just refer to LLVM, they probably mean just the low-level library and tools. Some people might refer to Clang or llvm-gcc incorrectly as "LLVM", which may cause some confusion.
llvm-gcc is a modified version of GCC, which uses LLVM as its backend instead of GCC's own. It is now deprecated, in favor of DragonEgg, which uses GCC's new plugin system to do the same thing without forking GCC.
Clang is a whole new C/C++/Objective-C compiler, which uses its own frontend, and LLVM as the backend. The advantages it provides are better error messages, faster compile time, and an easier way for other tools to hook into the compilation process (like the LLDB debugger and Clang static analyzer). It's also reasonably modular, and so can be used as a library for other software that needs to analyze C, C++, or Objective-C code.
Each of these approaches (plain GCC, GCC + LLVM, and Clang) have their advantages and disadvantages. The last few sets of benchmarks I've seen showed GCC to produce slightly faster code in most test cases (though LLVM had a slight edge in a few), while LLVM and Clang gave significantly better compile times. GCC and the GCC/LLVM combos have the advantage that a lot more code has been tested and works on the GCC flavor of C; there are some compiler specific extensions that only GCC has, and some places where the standard allows the implementation to vary but code depends on one particular implementation. It is a lot more likely if you get a large amount of legacy C code that it will work in GCC than that it will work in Clang, though this is improving over time.
There are 2 different things here.
LLVM is a backend compiler meant to build compilers on top of it. It deals with optimizations and production of code adapted to the target architecture.
CLang is a front end which parses C, C++ and Objective C code and translates it into a representation suitable for LLVM.
llvm gcc was an initial version of a llvm based C++ compiler based on gcc 4.2, which is now deprecated since CLang can parse everything it could parse, and more.
Finally, the main difference between CLang and gcc does not lie in the produced code but in the approach. While gcc is monolithic, CLang has been built as a suite of libraries. This modular design allow great reuse opportunities for IDE or completion tools for example.
At the moment, the code produced by gcc 4.6 is generally a bit faster, but CLang is closing the gap.
llvm-gcc-4.2 uses the GCC front-end to parse your code, then generates the compiled output using LLVM.
The "llvm compiler 2.0" uses the clang front-end to parse your code, and generates the compiled output using LLVM. "clang" is actually just the name for this front-end, but it is often used casually as a name for the compiler as a whole.
Are there c++ compilers that I can run on a brand x system that will create machine code that will run on a brand y system? Would this be considered a cross compiler?
Yes, that's exactly what a cross compiler is.
The GNU Compiler Collection (which includes gcc and g++) are a prime example of a portable cross compiler with hundreds of supported CPU types.
There are many ways to configure GCC to be a cross compiler. Most of it depends on the target machine and what's available from it - mostly because of the C runtime environment. For example, compiling GCC for an ARM Linux target requires an ARM Linux glibc pre-compiled to build the cross compiler libstdc++.
This is quite common using gcc.
There are a number of tutorials around that describe building your own cross-compiler environment.
This is one, but a quick google will probably provide a link to someone doing exactly the mix of environments that you're after.
edit:
This is a more thorough tutorial, using crosstool
Yes there are such compilers; yes, they are called cross compilers. For example, GCC can be configured in this manner, so that I can run the compiler on a 32-bit x86 system, but produce 64-bit code for an x64 system, and that's just the tip of the iceberg.
Crosstool is a really handy tool suite for creating a cross-compiling GCC.
HTH,
Eric Melski
Electric Cloud, Inc.
Yes this is what cross-compilation is about (although I would say "brand X" isn't appropriate classification term).