Announcement

Collapse
No announcement yet.

Why FreeBSD Doesn't Aim For OpenMP Support Out-Of-The-Box

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

  • #11
    Originally posted by caligula View Post
    Well, I guess FreeBSD doesn't run on multi-core systems then. Seems rather stupid to waste 50-96% of the performance potential since your programming paradigm was invented in the 1970s. The basic work sharing constructs in OpenMP are already years old. I already implemented some programming assignments in school some 10 years ago with OpenMP 2.0.
    I'll see your 10 years and raise you 10 more. And I was running my OpenMP apps efficiently on 32-processor SGI Altix systems 15 years ago, using all 32 processors, and still well on the "good" part of the scaling-curve (that was the largest system the bean-counters would let me have :-). FWIW.

    Comment


    • #12
      Originally posted by coats View Post

      I'll see your 10 years and raise you 10 more. And I was running my OpenMP apps efficiently on 32-processor SGI Altix systems 15 years ago, using all 32 processors, and still well on the "good" part of the scaling-curve (that was the largest system the bean-counters would let me have :-). FWIW.
      Too bad BSD didn't catch up to this system, yet. Furthermore, it doesn't care about security:

      [/quote]Aside from not aiming for good out-of-the-box performant defaults, it was also pointed out that while various Linux distributions are beginning to pass various compile-time options for their packages to increase security, FreeBSD doesn't appear to be doing much (anything?) with approaching those options for consideration by default and instead just kept with conservative defaults.
      [/quote]

      I bet it will be very unstable with such options enabled. That's probably why it didn't catch up with Altix mentioned above.

      Comment


      • #13
        Well in michael defence BSD's are not an easy horse to tame, specially for benchmarking and SOME BSD communities aren't very sweet to work with either.

        So i do admit i've used BSD in certain situations, i'll even admit there are some things in BSD that are absolutely beatifully done and there are instances and tasks where BSD is indeed superior to Linux but is also true BSD has a very ugly side too.

        I even agree with you in the fact that michael BSD benchmarks aren't the most BSD friendly ones but i understand the point michael is making too because is not intuitive if you haven't spent a lot of time fist fighting with a BSD system.

        BSD issues:

        * BSD ecosystem is an WW1 stalemate set of bunkers of warring factions that hold the "TRUE UNIX" flag, hence is not easy to pick a BSD for benchmarks because where 1 BSD system flys another maybe not be even in the same league(Couple BSD variants started to support SMP in 2014 and 2015 for a simple example.). So someone will get butt hurt whatever you do(omg that BSD is for network ofc is slow on X bench, lol this BSD fs don't have that feature ofc is slow OMG, etc. etc. etc.)

        * Many BSD share code from the original Berkely codebase but not all of them are API/ABI compatible with each other or have a minimal set of features or even reuse the good parts of the same kernels, etc. this doesn't make benchmarking any easier. Sure you can find some benchmark suite that can work on most with the specific fixes to run on all those variants but in some cases instead of user you will get angry developers coming at you since that software compiles and run but the dude that patch it to work on X BSD didn't use the better X API on their BSD but the old generic approach OMG, so unfair, of course, bla bla bla. biased .....

        * The last problem is the pragmatic License issue with BSD systems where sometime override technical priorioties to solve license issues, Clang for example. Clang wasn't and isn't ready to be used on production systems, i mean yeah is cool and fast and overall great but is a WIP compiler and still lack many standard features(of course great improvements keep coming but still) that any developer expect to work in any decent system.

        The apologist may come yelling "LOL, Mac uses it? hater, fanboi ..... and sure is true that Apple uses it and is true is good enough for them because their system are tailor made for certain scenarios were those missing features are not important(on their product vision) or has been replaced by more appropiate (for their product vision) subsystems somewhere else in the OS (OpenMP vs GCD for example).





        So is valid that micheal wonder why BSD is having issues with OpenMP? of course, because GCC, ICC, VS, Sun Studio, etc support it just fine and is not exactly anything new either and is something very easy to fix, use GCC until clang support all the features or just simply allow both for a while

        Is fair to show OpenMP and other BSD weak benchmarks here? maybe, certainly is important for me to know if OpenMP or any other feature is not fully functional on BSD but i agree there is a lack of benchmarks that show BSD strenghts

        So, why not open a thread where BSD guru can agree on a set of strong BSD benchmarks and send michael patches for PTS and maybe even ask nicely to highligth in the articles which benches are weak and strong on BSD so the readers can make their decisions with both sides of the coin?

        Comment


        • #14
          Originally posted by jrch2k8 View Post
          ... and there are instances and tasks where BSD is indeed superior to Linux
          Like what?

          Comment


          • #15
            like being a hipster and being more alternative than you. if more-alternative-than-you hipsters stopped using bsd, there would be no bsd users left.

            Comment


            • #16
              Originally posted by Pawlerson View Post

              Like what?
              Latency and throughput on extremely high network loads, BSD network tcp stack is quite cool in features for this cases.

              Solaris firewall in its time was more robust than IPtables on certain very very complex routing scenarios(i think bpf took a lot from it)

              OpenBSD is quite tough on network security(or at least was for a good while), equivalent to Linux+grsec+hardening

              Some databases systems really shines on Solaris/BSD with ZFS but a case can be made that today linux ZFS support is good enough.

              Some network cluster applications run better on BSD but i think many of the bottlenecks on linux were already fixed(4.4)

              Comment


              • #17
                Originally posted by Pawlerson View Post
                I bet it will be very unstable with such options enabled. That's probably why it didn't catch up with Altix mentioned above.
                Well, I think you have to be fair here. What is the point of enabling these features for every single binary within a distro?! This can only help the very paranoid. You'd also would want to put a tin foil hat on in that case.

                I find it's a bit silly and senseless to do this for an entire distribution. You really only want to enable these features for shared libraries and the base system. But if one actually has a real security issue with optional software such as ImageMagick/GraphicsMagick then the linker and compiler features will make very little difference. It also won't stop a user from producing binaries and libraries without these features and from within a system and so undermining it.

                You would want to compile vulnerable code with every available feature and not only a few, and then run it in a container or chroot if you really expected a security breach, or else would you not be honest with yourself or thorough. So instead would you want the best performance and then expect no reasonable person will run it with root privileges or within an otherwise vulnerable environment just like you don't expect anyone to type in rm -rf / as root.

                In short, you'd either aim for full security or for full performance depending on what you are compiling, but not for a "mixed sauce", which won't serve anybody right. Security isn't some gut feeling that one calms with throwing features at it.

                That's just my opinion.

                Comment


                • #18
                  Before everyone freaks out, you do know that you can install llvm37 llvm38 llvm39 and llvm40 all with working openmp on freebsd, right? It is just not installed by default. Oh, an btw these are official packages for stable freebsd versions. None of the major linuxes provide these, Ubuntu doesnt even have any c++ compiler installed by default so what actually is the point of this thread?

                  Comment


                  • #19
                    Originally posted by h**2 View Post
                    Before everyone freaks out, you do know that you can install llvm37 llvm38 llvm39 and llvm40 all with working openmp on freebsd, right? It is just not installed by default. Oh, an btw these are official packages for stable freebsd versions. None of the major linuxes provide these, Ubuntu doesnt even have any c++ compiler installed by default so what actually is the point of this thread?
                    You haven't followed the entire conversation up to this article, but nobody will blame you. The point is that because FreeBSD doesn't support a few things in their base system have some developer also not included it in optional packages. In other words, the lack of an Open MP-capable compiler within the base system has led to developers compiling packages such as GraphicsMagick without it. This then has led to FreeBSD performing underwhelming when run out-of-the-box, which is however what most users do.

                    Comment


                    • #20
                      I use FreeBSD and I'm glad they don't enable OpenMP. OpenMP is not the future of parallel computing, it is an abandoned dead end. It's crap and we should be phasing it out, not pushing for its adoption. Pthreads or C11 threads are the way to go.

                      Comment

                      Working...
                      X