Announcement

Collapse
No announcement yet.

FreeBSD 9.1: LLVM/Clang Battling GCC

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

  • #21
    Originally posted by systemd rulez View Post
    bsd = epic anal fail
    Forgot that your alter ego was already banned but still using the same pics and slogans?
    Man, you are even not able to get that right.

    Comment


    • #22
      Originally posted by Vim_User View Post
      Forgot that your alter ego was already banned but still using the same pics and slogans?
      Man, you are even not able to get that right.
      What alter ego?

      I found that picture using google.https://www.google.com.au/search?q=phoronix+tux+beastie&oe=utf-8&aq=t&rls=org.mozilla:en-USfficial&client=firefox-a&um=1&ie=UTF-8&hl=en&tbm=isch&source=og&sa=N&tab=wi&ei=G4MUUbzM CcaUiAeUnICgBQ&biw=1024&bih=660&sei=HYMUUcqeNcHFmQ XDnIGgBw

      Comment


      • #23
        Originally posted by Vim_User View Post
        By the way, still waiting for an answer from you in the thread where you claimed that Apple has implemented surveillance technology into Clang/LLVM
        Already did.

        Comment


        • #24
          Originally posted by 0xBADCODE View Post
          And why someone should make such discounts? We need operating systems here and now. Not "in June" or whenever. Let's go further and drop all tests where clang loses. Or even better, drop all tests where Linux + recent GCC beats BSDs to a hell. Then BSD guys would be happy for sure . Yet, I doubt this approach would make BSDs anyhow popular.
          Don't worry man, Adopting clang is a death blow for FreeBSD. In fact we should wait for the first clang compiled FreeBSD to be released cause clang is so slow that a bsd compiled by it is going to be lot slower and thus more servers and users will abandon it as it will not handle internet traffic well and will be even more of a pain to startup and run programs.

          Also, because clang produces crap binaries, FreeBSD is going to be crap and may crash even more thus making BSDtards look silly when they say their OS is stable and reliable.

          The time will come soon when the number of BSD users will shrink considerably as they move to Linux cause BSD will be unreliable. This will quicken the end of BSD. Also, BSD will become even more fragmented as devs will start blaming each other for the loss of users and split.

          BSD is already heavily fragmented.
          Last edited by systemd rulez; 02-08-2013, 01:02 AM.

          Comment


          • #25
            Bogus benchmark

            Then doing a comparison of different compilers against each other one should use the highest optimiztion level each offers and specify the CPU-architecture.

            What you do want to know is which compiler can produce the best machine code and best utilize the processors functionality like AVX/XOP/FMA3/FMA4/SSE.

            Then compiling with -O2 and not specifying the arch you do not get the best and fastest machine code, and the corresponding result is not reflective of reality.

            Comment


            • #26
              Unless FreeBSD switches on the maximum optimisations available to LLVM/Clang and gcc, by default, it would not have been appropriate to do so for this benchmark. This was to test the 2 base system compilers in the manner in which they would be used.

              Comment


              • #27
                Useful comparision - though BSD is, well, ?

                I think the comparision is a nice one: It?s the practical test of the cost BSD incurs on itself by shunning GPLv3.?

                I would have liked to see as third option a fully optimized GCC 4.8 to make a stronger point of that, though. But the benchmark itself is interesting.

                Also I think it?s interesting (and you wrote that), that LLVM cannot yet build all packages which can be built with GCC 4.2.

                ?: ?we do not use GCC after 4.2, because it is GPLv3+? - So you choose the inferior technology because when you used the better one, you could not shackle your users as badly? Are you serious??? They don?t even have to ship GCC to give their users the packages. So they can actually still give them locked-down devices, they just can?t hand out the compiler and still lock down the whole device. So this is a clear political move against copyleft - and against their users. And I think it about sets the deathblow to any ideas I had to test the freebsd kernel in Gentoo. Their? reason: http://marc.info/?l=freebsd-current&...9688809480&w=2 → ?gcc couldn't be used as a convenient front end for a proprietary code generator.?

                ?: To be fair: This was not the reason of THE BSD folks. It seems to have been the reason of some very vokal GPL haters. But the rest seems to have accepted to live with inferior programs, because some of them don?t like GPL.

                Comment


                • #28
                  Originally posted by archibald View Post
                  Unless FreeBSD switches on the maximum optimisations available to LLVM/Clang and gcc, by default, it would not have been appropriate to do so for this benchmark. This was to test the 2 base system compilers in the manner in which they would be used.
                  And I still don't understand the value of benchmarks like that. The same with graphics driver tests. Pages and pages of graphs showing performance under poor conditions instead of showing what the drivers (or compilers) are actually capable off.

                  It's a bit like a benchmark of a Ferrari and a Lambo, but performed in a way a typical daily commuter would drive it in typical city traffic. And then statements like "here we can see that Lambo is faster" and "Ferrari gets better mileage" and stuff.

                  I mean, who the hell would compile highly specialised scientific computation software using FreeBSD defaults? If you use this stuff, you optimise it. If you don't optimise it, you don't use it. It's not like a typical FreeBSD desktop user who recently switched from a Mac and is afraid of compilers would go and use this stuff.

                  Comment


                  • #29
                    Originally posted by Vim_User View Post
                    I don't quite get your logic. Why would dropping the OpenMP benchmarks (of course with explicitly stating in the article that they are dropped because Clang lacks support for it) making a difference in you making a decision? .
                    Quite simple: I'm unwilling to make any discounts and if someone loses in OpenMP here and now by a factor of 3, let's admit this problem and fix it if you can. Just hiding problematic tests is lame. And as for me I'm using OSes today. I don't want to wait for June or whatever to get adequate performance. And it's better too see bad graphs immediately rather than install OS, waste a lot of time and then get surprised by shitty performance.

                    Comment


                    • #30
                      Originally posted by pingufunkybeat View Post
                      And I still don't understand the value of benchmarks like that. The same with graphics driver tests. Pages and pages of graphs showing performance under poor conditions instead of showing what the drivers (or compilers) are actually capable off.
                      Most users would never adjust defaults. "Defaults will prevail". So that's what >90% of users will actually be able to get from system. Hence it's completely fair and good idea to compare default systems without tuning.

                      Comment

                      Working...
                      X