Announcement

Collapse
No announcement yet.

Open64 5.0 Compiler Released w/ New Features

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

  • Open64 5.0 Compiler Released w/ New Features

    Phoronix: Open64 5.0 Compiler Released w/ New Features

    Open64, the open-source (GPLv2-licensed) compiler for C/C++ and Fortran that's backed by AMD and has been developed by SGI, HP, and various universities and research organizations, has reached a major milestone today. Version 5.0 of Open64 has been christened with many changes...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    32-bit forced

    from HOWTO-INSTALL-OPEN64
    1. Building the compiler on x86_64
    By default, on x86_64 machines, the compiler will be built in 32 bit
    mode and libraries will be built in 32 and 64 bit modes to support
    compilation in either mode. You can build 64 bit executables by
    specifying "--build=x86_64-unknown-linux-gnu" on the configure command.


    seems they don't offer anyway to disable compiling 32-bit stuff, short of hacking the build system

    There are a lot of 64-bit only machines out there in 2011.

    Comment


    • #3
      Originally posted by Soul_keeper View Post
      seems they don't offer anyway to disable compiling 32-bit stuff, short of hacking the build system

      There are a lot of 64-bit only machines out there in 2011.
      But there are some apps out there written in 32-bit assembly and I believe either the assembler or the apps don't compile properly on 64-bit systems (segfault when they're run).. Not sure why, but running apps like ZSNES is still a huge PITA if you've got a 64-bit system... The best way to do it is to compile it in a pure 32-bit lib environment and run it as a 32-bit program on a 64-bit OS.

      I don't think anybody has successfully compiled zsnes from a 64-bit OS environment as I've never seen it done without pure 32-bit libs (even the cross-over libs that make 32-bit binaries on a 64-bit OS don't work for compiling zsnes and I think it might have to do with so much of zsnes being written in x86 assembly).


      So having 32-bit libs thrown in with the compiler, I don't see that being such a big deal if it means that some apps written for just 32-bit will still compile.. Not to mention, a lot of devs do cross-compiling anyway for testing purposes..

      Comment


      • #4
        So I guess pretty much every distro out there uses GCC for all their binary packages... Even though some compilers like Open64 create much faster binaries.. I think it would make sense to just use the best compiler for the package..

        If an app runs 2x faster on Open64, then distros should be using Open64 to compile it, not GCC.. Is there any distros that do select the best compilers for their binaries? I mean, sure you can do it manually in Gentoo, but I'd rather have things pre-compiled with Open64 if the app runs significantly faster in Open64.. Seems like common sense.

        A lot of people have been touting Pov-Ray as Bulldozer getting owned by Sandy Bridge... But if you look at the Open64 optimizations for Bulldozer, it looks to boost Pov-Ray on Bulldozer by as much as 30% which makes ALL the difference in the world when everybody is using GCC (-O2) to compile Pov-Ray and post their benchmarks and reviews of Bulldozer that makes Bulldozer look so bad.. Compile Pov-Ray with Open64 and full Bulldozer optimizations and the reverse is true (Sandy Bridge starts to look terrible in performance per dollar). And that 30% performance boost is not with Open64 5.0 (
        Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

        ) .. It's with Open64 v4.2.. It's probably even more significant than 30% performance boost with Open64 v5.0, and I look forward to the benchmarks.
        Last edited by Sidicas; 10 November 2011, 01:56 PM.

        Comment


        • #5
          This looks like to be the patch for GCC to enable FMA4 accelerations for Bulldozer... Note that it's dated November 8th, 2011 and I guess is still months away from an official release in GCC?

          http://patchwork.ozlabs.org/patch/124256/

          Comment


          • #6
            Originally posted by Sidicas View Post
            But there are some apps out there written in 32-bit assembly and I believe either the assembler or the apps don't compile properly on 64-bit systems (segfault when they're run).. Not sure why, but running apps like ZSNES is still a huge PITA if you've got a 64-bit system...
            Why would anyone want to run zsnes these days? About any 64 bit system should be fast enough for snes9x or bsnes, which both have surpassed zsnes greatly in regards to properly emulating the snes.

            Comment


            • #7
              Originally posted by AnonymousCoward View Post
              Why would anyone want to run zsnes these days? About any 64 bit system should be fast enough for snes9x or bsnes, which both have surpassed zsnes greatly in regards to properly emulating the snes.
              bsnes is too slow... And the upscaling graphics modes in zsnes is better and faster than in Snes9X..

              Not to mention, there are plenty of 32-bit Intel atom netbooks on the market that run zsnes well and bsnes not so well..

              Comment


              • #8
                Originally posted by Sidicas View Post
                bsnes is too slow... And the upscaling graphics modes in zsnes is better and faster than in Snes9X..

                Not to mention, there are plenty of 32-bit Intel atom netbooks on the market that run zsnes well and bsnes not so well..
                So get something based on an AMD APU like the Z-01 http://www.cpu-world.com/CPUs/Bobcat...es%20Z-01.html

                C-60 http://www.cpu-world.com/CPUs/Bobcat...es%20C-60.html

                or E-450 http://www.cpu-world.com/CPUs/Bobcat...s%20E-450.html

                They are the best low end CPUs you can get and crush the Atoms in overall performance per watt and GPU performance.

                I've never understood why anyone would get the Atom, the only time they looked decent was the 2 core/4 thread N330 w/ Nvidia ION/9400 chipset, but Intel neutered them so, they wouldn't be as competitive with the mobile Celeron and Pentium lines. But since AMD started making low end mobile CPUs the Atom has been the fool's option.

                Comment


                • #9
                  Originally posted by Sidicas View Post
                  So I guess pretty much every distro out there uses GCC for all their binary packages... Even though some compilers like Open64 create much faster binaries.. I think it would make sense to just use the best compiler for the package..

                  If an app runs 2x faster on Open64, then distros should be using Open64 to compile it, not GCC.. Is there any distros that do select the best compilers for their binaries? I mean, sure you can do it manually in Gentoo, but I'd rather have things pre-compiled with Open64 if the app runs significantly faster in Open64.. Seems like common sense.
                  You can sure do that in most distros (that's how packages that use a language not supported by GCC are compiled after all, e.g. Haskell, etc.), but as it slows down the build daemons (GCC is installed by default, special build dependencies have to be pulled in for every package build), most distros probably suggest you give a very good reason for deviating from the default compiler. And of course a compiler to use has to be packaged before you can use it...

                  Comment

                  Working...
                  X