Slashdot Mirror

← Back to Stories (view on slashdot.org)

LLVM 7.0 Released: Better CPU Support, AMDGPU Vega 20; Clang 7.0 Gets FMV and OpenCL C++ (phoronix.com)

Posted by msmash on from the onward-and-upward dept.

LLVM release manager Hans Wennborg announced Wednesday the official availability of LLVM 7.0 compiler stack as well as associated sub-projects including the Clang 7.0 C/C++ compiler front-end, Compiler-RT, libc++, libunwind, LLDB, and others. From a report: There is a lot of LLVM improvements ranging from CPU improvements for many different architectures, Vega 20 support among many other AMDGPU back-end improvements, the new machine code analyzer utility, and more. The notable Clang C/C++ compiler has picked up support for function multi-versioning (FMV), initial OpenCL C++ support, and many other additions. See my LLVM 7.0 / Clang 7.0 feature overview for more details on the changes with this six-month open-source compiler stack update. Wennborg's release statement can be read on the llvm-announce list.

13 of 76 comments (clear)

  1. But does it have a code of conduct by Anonymous Coward · · Score: 2, Funny

    if not, it needs one

    1. Re:But does it have a code of conduct by Anonymous Coward · · Score: 2, Informative

      Yes, it has one that openly discriminates against white males.

      A principal developer has already walked away from the project because of it.

  2. Should GPU Coding become more standardize. by jellomizer · · Score: 3, Interesting

    I finally got myself a computer with a an above average Video Card (NVIDIA) and have been playing the CUDA core logic.
    It is great, having access to thousands of parallel CPU's can really bring my execution time of code down a Big O level.

    However what I am doing only seems to work with nVidia Chips. And AMD GPU's probably will need different coding as well.
    The main point of C/C++ is write once compile anywhere. However at this point it is still very shaky in support. So any program that uses the GPU for calculation would need to be coded multiple times for different platforms (Or at least with a switch inside the code for the platform particular issues).
    It reminds me a lot like early C, where you needed to switch to assembly language a lot more, because the default core sets wasn't robust enough for many actions.

    --
    If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    1. Re:Should GPU Coding become more standardize. by Anonymous Coward · · Score: 5, Informative

      It is great, having access to thousands of parallel CPU's can really bring my execution time of code down a Big O level.

      That's not how Big O works...

    2. Re:Should GPU Coding become more standardize. by Anonymous Coward · · Score: 4, Funny

      That's what she said.

    3. Re:Should GPU Coding become more standardize. by Anonymous Coward · · Score: 2, Informative

      Isn't that OpenCL is?

    4. Re:Should GPU Coding become more standardize. by UnknownSoldier · · Score: 4, Informative

      Uhm, hello, that's what OpenCL provides - a standardized way to access the GPU in a vendor neutral way.

    5. Re:Should GPU Coding become more standardize. by jimtheowl · · Score: 3, Informative

      Yes.

      https://wiki.tiker.net/CudaVsO...
      https://create.pro/blog/opencl...

    6. Re:Should GPU Coding become more standardize. by Guybrush_T · · Score: 3, Interesting

      Well, that was also my thoughts when I wrote my first CUDA program : apart from some new implicit structures (threadIdx / blockIdx / ...), CUDA is just C++.

      However, writing a program that has just decent performance in CUDA is very different from writing CPU code : you have to twist your mind to think wide (lots of slow but very synchronous cores) instead of long (several unsynchronized but fast cores). Usually, it makes the optimized code quite different and it is hard to abstract.

      Surely, there are some cases that can be easily described to work well in both cases, like process this 3D matrix. But there are things for which the language cannot do much because you really need to optimize for a specific architecture that has made important and distinctive design choices in the memory model and compute architecture.

      So in the end, writing CUDA or OpenCL is likely not a 20-years investment. Things are moving fast and maybe GPUs will converge to a similar model in the future (just like there used to be very different types of CPUs at some point), but for now, writing CUDA or OpenCL code is optimizing for a specific architecture. It is somewhat expensive but makes a big difference.

    7. Re:Should GPU Coding become more standardize. by Anonymous Coward · · Score: 2, Informative

      WTF is "a speed O(log(n)) "? Throwing more cores at a problem does not ever reduce the number of operations. Back to the "speed" thing. O(N^100) can be faster than O(1). It's not an issue of speed, but an issue of complexity. All parallel algorithms can be run serially, but not visa versa. And what are you smoking that you think you can reduce the minimum complexity by throwing cores at a problem?

  3. Re: They kicked out the creator. Remember that. by Zero__Kelvin · · Score: 2

    ... ah, great point! None of these improvements matter; you have identified the one salient issue!

    --
    Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  4. Re: They kicked out the creator. Remember that. by Zero__Kelvin · · Score: 2

    I find it hard to believe that, even with Poe's law in mind, you didn't know I was being scarcastic. All the improvements matter to someone, unlike the completely off topic "point" the OP tried to make.

    --
    Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  5. Nothing to do with C/C++ by jimtheowl · · Score: 2

    "The main point of C/C++ is write once compile anywhere."

    Since when?

    If you have new or different hardware you simply have to deal with it.

    The C++ language Standard doesn't deal with specific hardware abstraction.

    It is the same as C. You have to deal with new/different hardware, and it is not because "the default core sets wasn't robust eno ugh for many actions".

    CUDA is an API written by Nvidia.

    Hardware manufactures do not have strong incentives to write libraries that will work for their competitors, hence where lies your issue.