Results 1 to 3 of 3

Thread: gcc 9.1.1 released

  1. #1
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Location
    Kharkov, Ukraine
    Posts
    3,134
    Thanks
    179
    Thanked 921 Times in 469 Posts

    gcc 9.1.1 released

    https://www.phoronix.com/scan.php?pa...piler-Released

    https://gcc-mcf.lhmouse.com/

    Other places to look for windows toolchains (no gcc9 yet):

    http://mingw-w64.org/doku.php/download
    https://sourceforge.net/projects/mingw-w64/files/
    https://osdn.net/projects/sfnet_mingw-w64/
    http://www.msys2.org/

    https://nuwen.net/mingw.html

    Did a small benchmark with my recent CM coder, somehow gcc82 wins?
    Code:
        x32
    book1  wcc386
    3.422s 2.984s:  CMo8-gcc82-x32-SSE4
    3.610s 3.234s:  CMo8-gcc91-x32-SSE4
    4.266s 3.640s:  CMo8-ic19-x32-ia32-PGO
    4.235s 3.656s:  CMo8-ic19-x32-SSE4-PGO
    3.594s 3.219s:  CMo8-ic19-x32-SSE4
    
        x64
    book1  wcc386
    3.265s 2.860s:  CMo8-gcc82-x64-native
    3.281s 2.859s:  CMo8-gcc82-x64-SSE4
    3.468s 3.000s:  CMo8-gcc83-x64-SSE4
    3.313s 2.937s:  CMo8-gcc91-x64-native
    3.484s 3.047s:  CMo8-gcc91-x64-SSE4
    3.422s 3.094s:  CMo8-gcc91-x64-SSE4-PGO
    3.188s 2.781s:  CMo8-ic19-x64-SSE4-PGO
    3.437s 3.062s:  CMo8-ic19-x64-SSE4

  2. The Following 5 Users Say Thank You to Shelwien For This Useful Post:

    Bulat Ziganshin (7th May 2019),encode (8th May 2019),kassane (12th May 2019),Mike (7th May 2019),xinix (11th May 2019)

  3. #2
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 659 Times in 354 Posts
    People say that GCC 9.1 is already in MYSY2 (I've not tried it myself!):

    pacman -S[w] mingw-w64-x86_64-gcc mingw-w64-x86_64-gdb mingw-w64-x86_64-make mingw-w64-x86_64-tools-git mingw-w64-x86_64-gcc-fortran mingw-w64-x86_64-gcc-libs

  4. The Following 2 Users Say Thank You to Bulat Ziganshin For This Useful Post:

    kassane (8th June 2019),Shelwien (6th June 2019)

  5. #3
    Member
    Join Date
    Nov 2015
    Location
    boot ROM
    Posts
    83
    Thanks
    25
    Thanked 15 Times in 13 Posts
    Quote Originally Posted by Shelwien View Post
    Did a small benchmark with my recent CM coder, somehow gcc82 wins?
    If you take a look on phoronix in more details and then dig compiler devs mailing lists and somesuch, you'll eventually notice code optimization is a very tricky business. So when new compiler released it isn't unusual to get code larger or smaller on particular algo. Same for speed. To make it more complicated, unless you specify -march/-mcpu/-mtune, compiler targets something "generic", it is debatable what kind of compromises is to be taken to perform reasonably everywhere. There is nothing wrong in eventually changing notion of "reasonable".

    Long story short, when it comes to compilers, on new release some platforms/(sub-)archs win, some lose. Some algos win, some lose. It is rare to see TOTAL regression, where compiler would perform worse on all algos and cpu flavors - it usually prevents release until regression fixed. Yet it also eventually possible. If code generation regression hurts and seems to affect more than 1 algo, and especially on different -march/-mtune/-mcpu it can make sense to file a bug.

    Most funny part? If you obsessed by just one particular CPU core flavor and algo, measuring only these, it not to be taken as granted latest compiler would always be best choice. However it doesn't really tells much about overall code generation quality of compiler. It takes a lot of measurements on various algos to get anyhow reasonable idea on this. Some phoronix benchmarks can give coarse idea how it could appear. I bet it same with clang, with exception early versions had crappy optimizer but fast compile time, and now it got comparable optimizer ... and comparable compile times, because it's not like if one can have free lunch

    Side note: I've had some fun measuring ARM Cortex code generation vs various GCCs, interestingly, I've been mostly interested in smallest code size and RAM use, while performance is "good to have" but not really pressing matter. Across GCC 6.x to 8.3 it proven to be rather "chaotic" but fun to measure. In this particular cpus bloodline, code generation basically evolved making code slightly larger but considerably faster (somehow affecting even -Os). Ironically it wasn't what I really wanted under my assumptions, but tradeoff looked very sane. After all I dodged the bullet by changing CPU type to target crappy cortex-M0 cores. Cortex M0 got far more crippled instruction set (compared to M3 I really had), so generated code is considerably slower (underusing core capabilities). Yet, somehow, it also makes code size noticeably smaller, while target CPU still can run that code (at which point mission accomplished). So for me smallest combo been GCC 7 in M0 mode. Previous and later compilers lose to this combo (by rather low margins, but it really depends on how much you're pressed by system resources).

    p.s. if someome is obsessed on code size (e.g. for small systems), GCC got fairly neat thing, called LTO. It brings no speed penalty - but can reduce code size, eliminating unreachable/unused code. Ironically it does its job so damn well that in standalone environment it eliminated me WHOLE FIRMWARE (!!!), failing to see its entry point is used. I failed to persuade LTO in this setup my code is "used", though GCC also supports yet another cheat, putting all functions and vars to own sections - and then pruning unused ones. This trick worked, chopping code size considerably. However LTO is more radical and efficient at this. In small systems there is inherent catch - say, interrupt handlers are inherently "unused" - rest of code never calls them.

    p.p.s. if one needs for speed, gcc also got ton of "less reliable" things to try. -O5...9 could work. Or not. Same for -ffast-math, -funsafe-loop-optimizations and so on. One can get better performance at cost of incomplete compliance with standards, so some code would break. But most algos can get with it - eventually getting faster. If it's all that matters, it could be way to go.
    Last edited by xcrh; 15th July 2019 at 20:51.

Similar Threads

  1. IntelC 11.1.065 vs gcc 4.5
    By Shelwien in forum The Off-Topic Lounge
    Replies: 35
    Last Post: 15th March 2011, 04:30
  2. GCC 4.6 faster than previous GCC, faster than LLVM
    By willvarfar in forum The Off-Topic Lounge
    Replies: 2
    Last Post: 15th November 2010, 16:09
  3. GCC 4.4.1 for Windows
    By Bulat Ziganshin in forum The Off-Topic Lounge
    Replies: 1
    Last Post: 16th January 2010, 00:39
  4. GCC 4.4 and compression speed
    By Hahobas in forum Data Compression
    Replies: 14
    Last Post: 5th March 2009, 18:31
  5. GCC mmx support
    By toffer in forum Forum Archive
    Replies: 6
    Last Post: 19th January 2008, 14:20

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •