Slashdot Mirror


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

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.

35 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. Re:But does it have a code of conduct by Anonymous Coward · · Score: 1

      Yeah, you're a fucking idiot. http://archive.is/vTETG

    3. Re:But does it have a code of conduct by Desler · · Score: 1

      Yes.

    4. Re:But does it have a code of conduct by jbengt · · Score: 1

      The word Hispanic means having to do with Hispania, the Iberian Peninsula. It is/em. often used in the US as a noun for a Spanish-speaking person, but it's not limited to that.

    5. Re:But does it have a code of conduct by DCFusor · · Score: 1

      And literacy. "There _is_ a lot of LLVM improvments". Why should I believe it's going to handle a set of very picky language specs if it can't speak English?

      --
      Why guess when you can know? Measure!
  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
    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 ooloorie · · Score: 1

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

      That has never been "the main point of C/C++".

      The main point of C is "let programmers get their work done, and give them access to low-level features when they need to".

      The main point of C++ is OOP with C-like features.

    8. Re:Should GPU Coding become more standardize. by Anonymous Coward · · Score: 1

      "bring my execution time of code down a Big O level" That's a nonsensical statement.

    9. Re:Should GPU Coding become more standardize. by jellomizer · · Score: 1

      The top single CPU Sorting algorithm can be performed at a speed of O(n)
      If you can have a processor for nearly every one of your data elements a parallel algorithm such as a Shear Sort can give you a speed O(log(n)) because in essence the longest part of the sort is the diagonal of the square.

      When you have a lot of cores like 1024 you can really program your algorithm in a way that will bring down the Big O based on normal sized data sets.
       

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

      Yeah, but that's still not how big O works...

    11. 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?

    12. Re:Should GPU Coding become more standardize. by Anonymous Coward · · Score: 1

      I understand what you mean, but please don't say it that way. People who understand Big O notation will rightfully complain about abuses like that. What you're saying is technically wrong and not a good way of expressing what you mean. It makes you look like an uneducated hack spewing buzzwords. You're throwing massive amounts of (parallel) processing power at a problem and that can make higher complexity algorithms feasible for certain problem sizes, but this effect is precisely what Big O notation is meant to abstract away. Having a processor that is 1000 times faster (or 1000 processors, worse due to non-linear speedup) doesn't affect the Big O of an algorithm. You could have simply left out "a Big O level" at the end of your comment: You would have been right and there would have been less room for misinterpretation.

    13. Re:Should GPU Coding become more standardize. by K.+S.+Kyosuke · · Score: 1

      I used to put my hopes into HSAIL, but now I'm rather in the SPIR(-V) territory. If Vulkan becomes widespread, it shouldn't matter whether you like C, C++, or anything else. Of course, unless nVidia finds ways to screw things up for everyone again, as they like to do.

      --
      Ezekiel 23:20
    14. Re:Should GPU Coding become more standardize. by K.+S.+Kyosuke · · Score: 1

      Or OpenGL 4.x compute shaders, or Vulkan.

      --
      Ezekiel 23:20
  3. They kicked out the creator. Remember that. by Anonymous Coward · · Score: 1, Informative

    They kicked out the creator. Remember that.

    1. 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
    2. Re: They kicked out the creator. Remember that. by TechyImmigrant · · Score: 1

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

      FMV? *looks up FMV* - Oooh, I want that for my crypto libraries (using rdrand, aesni, etc,).
      FMV matters.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    3. 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
    4. Re: They kicked out the creator. Remember that. by TechyImmigrant · · Score: 1

      I got it. But it was a convenient place to unload the FMV experience I had been through minutes earlier.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    5. Re: They kicked out the creator. Remember that. by Zero__Kelvin · · Score: 1

      Fair enough ... You may not like me, but would always hope you know I don't fall on the extereme SJW part of the asshole spectrum ;-)

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

      Well using caps in abrivations is not shouting it is actually the concert way of doing it

    7. Re: They kicked out the creator. Remember that. by K.+S.+Kyosuke · · Score: 1

      Considering the license, the implementation language, etc., one might argue that this project may have been somewhat underwhelming from the very beginning.

      --
      Ezekiel 23:20
  4. 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.

  5. Their Code of Conduct says no such thing by Anonymous Coward · · Score: 1

    Maybe you're such a dense motherfucker that you missed it, so here's what you glossed over, dicknozzle:

    [ nonsense redacted ]

    I normally wouldn't reply to such an obvious troll, however, to avoid the off-chance that someone actually believes this drivel ...

    As a Gentoo user I prefer gcc over llvm for most things (faster code, better support by the distro), so I'm not exactly a fanboi, however, your post appears to be complete fiction (as well as a rather poorly constructed troll). The LLVM code of conduct contains no such language as you've described. Don't believe me? Have a look for yourself (appended here for those too lazy to click on a link: https://llvm.org/docs/CodeOfConduct.html ):

    The LLVM community has always worked to be a welcoming and respectful community, and we want to ensure that doesn’t change as we grow and evolve. To that end, we have a few ground rules that we ask people to adhere to:

    be friendly and patient,
    be welcoming,
    be considerate,
    be respectful,
    be careful in the words that you choose and be kind to others, and
    when we disagree, try to understand why.
    This isn’t an exhaustive list of things that you can’t do. Rather, take it in the spirit in which it’s intended - a guide to make it easier to communicate and participate in the community.

    This code of conduct applies to all spaces managed by the LLVM project or The LLVM Foundation. This includes IRC channels, mailing lists, bug trackers, LLVM events such as the developer meetings and socials, and any other forums created by the project that the community uses for communication. It applies to all of your communication and conduct in these spaces, including emails, chats, things you say, slides, videos, posters, signs, or even t-shirts you display in these spaces. In addition, violations of this code outside these spaces may, in rare cases, affect a person’s ability to participate within them, when the conduct amounts to an egregious violation of this code.

    If you believe someone is violating the code of conduct, we ask that you report it by emailing conduct@llvm.org. For more details please see our Reporting Guide.

    Be friendly and patient.
    Be welcoming. We strive to be a community that welcomes and supports people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, colour, immigration status, social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion or lack thereof, and mental and physical ability.
    Be considerate. Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account. Remember that we’re a world-wide community, so you might not be communicating in someone else’s primary language.
    Be respectful. Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one. Members of the LLVM community should be respectful when dealing with other members as well as with people outside the LLVM community.
    Be careful in the words that you choose and be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behavior aren’t acceptable. This includes, but is not limited to:

    Violent threats or language directed against another person.
    Discriminatory jokes and language.
    Posting sexually explicit or violent material.
    Posting (or threatening to post) other people’s personally identifying information (“doxing”).
    Perso

  6. Damn.... by LordHighExecutioner · · Score: 1

    ...I just installed last week the previous version of LLVM on my laptop, configured Code::Blocks, and compiled all the libraries I use for my development. Now back again to square one!

  7. Scrollback by fyngyrz · · Score: 1

    And they shell get their wish.

    You're just Bashing them now.

    --
    I've fallen off your lawn, and I can't get up.
    1. Re: Scrollback by fyngyrz · · Score: 1

      Your line was buffer than mine. I suspect you have a history of this.

      --
      I've fallen off your lawn, and I can't get up.
  8. Re: How Goodly Does Compiler Gig Pay Me? by K.+S.+Kyosuke · · Score: 1

    $9 for the compiler, I presume?

    --
    Ezekiel 23:20