Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 42

Thread: FreeBSD 9.1: LLVM/Clang Battling GCC

  1. #21
    Join Date
    Jan 2013
    Posts
    1,116

    Default

    Quote Originally Posted by systemd rulez View Post
    What BADCODE is saying is that these benchmarks can be attempted to be used by BSD zealots to advocate that gcc is a failure and clang is better since gcc narrowly beat clang in this test which is a joke as it's puting an outdated version of GCC against A New version of Clang.
    Then compare it with a new version of GCC, like in the article Michael linked to. You won't see that much difference. And when it is clearly stated that there are no benchmarks of OpenMP software because OpenMP is currently not supported by Clang/LLVM then no one that is able to read will believe that Clang is better.
    By the way, nobody is saying that, as we can clearly see in the benchmarks with the newer versions there are cases where GCC is better and other cases where Clang/LLVM is better.
    The only one insisting that one of them clearly is better are you.

    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 (although I doubt I get one, since all your claims are made up).

  2. #22
    Join Date
    Jan 2013
    Posts
    1,116

    Default

    Quote 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.

  3. #23
    Join Date
    Jan 2013
    Posts
    83

    Default

    Quote 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

  4. #24
    Join Date
    Jan 2013
    Posts
    83

    Default

    Quote 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.

  5. #25
    Join Date
    Jan 2013
    Posts
    83

    Default

    Quote 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 at 12:02 AM.

  6. #26
    Join Date
    Oct 2011
    Posts
    10

    Default 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.

  7. #27
    Join Date
    Jul 2010
    Posts
    449

    Default

    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.

  8. #28
    Join Date
    Jul 2011
    Posts
    73

    Default 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.

  9. #29
    Join Date
    Jun 2009
    Posts
    2,927

    Default

    Quote 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.

  10. #30
    Join Date
    Jun 2012
    Posts
    301

    Default

    Quote 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.

Posting Permissions

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