GCC 14 vs. LLVM Clang 18 Compiler Performance On Fedora 40

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Anux
    replied
    Good we have 2 OS compilers sort of competing with each other, more benefits and choices for us.

    Originally posted by avis View Post
    Not a lot of sense in comparing video codecs because they include hand written assembly for most important/heavy parts of processing, so the compiler's role is quite minimal.
    Since we see up to 5% difference in video codecs it certainly is valuable to compare them and assembly clearly isn't the only relevant factor.

    Leave a comment:


  • Kjell
    replied
    Originally posted by imaami View Post
    Yawn. I'm already on clang-19.
    Gentoo?

    Leave a comment:


  • imaami
    replied
    Yawn. I'm already on clang-19.

    Leave a comment:


  • junkbustr
    replied
    Is that clock speed on the CPU (7.79Ghz) a typo? I thought the vendor offered 5.1Ghz on the 7980X.

    ALL RIGHT! WHO USED UP ALL THE LIQUID NITROGEN??
    Last edited by junkbustr; 24 April 2024, 10:20 PM.

    Leave a comment:


  • mrg666
    replied
    At this point I am not expecting any compiler to beat GCC after averaged in a set of benchmarks like Michael did here. GCC 14 is also great with building the latest kernel version. I have been using with Fedora 40 on 8 (or so) computers and there are no problems at all. I tried LLVM before for building Linux kernel, but I did not see any performance miracles there. It is just as good as GCC. Just take your pick.

    Leave a comment:


  • vladpetric
    replied
    Originally posted by carewolf View Post

    The performce bugs I have filed has been adressed, especially if you debug it down to general cases and assembler. Though I also fixed a few of them myself. The only one I can remember that wasn't fixed, was because it was caused by a specific micro-ops limit in Sandybridge processors, so slightly more agressive optimization caused a regression, but they didn't want to hardcore such specific limits for all processors. clang also doesnt have that.
    E.g. https://bugs.llvm.org/show_bug.cgi?id=20014

    Leave a comment:


  • avis
    replied
    Originally posted by carewolf View Post

    --param max-completely-peel-times=30
    This is a workaround/hack, not a fix. I can read as well, thank you very much. Michael will not change PTS and apply this flag to this particular benchmark because we're testing standard compilers, not a load of hacks to speed up certain tests arbitrarily.

    Leave a comment:


  • carewolf
    replied
    Originally posted by vladpetric View Post

    For ICEs and bad output, I agree. Not so for performance bugs in my experience.
    The performce bugs I have filed has been adressed, especially if you debug it down to general cases and assembler. Though I also fixed a few of them myself. The only one I can remember that wasn't fixed, was because it was caused by a specific micro-ops limit in Sandybridge processors, so slightly more agressive optimization caused a regression, but they didn't want to hardcore such specific limits for all processors. clang also doesnt have that.

    Leave a comment:


  • carewolf
    replied
    Originally posted by avis View Post
    Not a lot of sense in comparing video codecs because they include hand written assembly for most important/heavy parts of processing, so the compiler's role is quite minimal.

    SMHasher SHA3-256 could be sped up on GCC a lot: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235

    No fix is proposed just yet.
    --param max-completely-peel-times=30

    Leave a comment:


  • vladpetric
    replied
    Originally posted by avis View Post

    99% of bugs that I've filed against GCC received proper attention. No idea why you get this treatment. Maybe you could provide the links to the appropriate bug reports.
    For ICEs and bad output, I agree. Not so for performance bugs in my experience.

    Leave a comment:

Working...
X