I forwarded this thread to Christopher Bergstöm and got this reply: > ---------------- > FreeBSD simply isn't a scientific computing platform - There isn't any market > demand, it's not designed for it, many of the tools commonly used aren't > available and the amount of work to change that is significant. (I don't > just mean technical, but also mindshare for those in the technical computing > field) > ---------------- > However, we haven't dropped support for it > http://c591116.r16.cf2.rackcdn.com/enzo/nightly/FreeBSD/enzo-2013-02-19-installer.run > > There's a few GPGPU related bugs we'd have to fix for it to work for you, but > those are pretty small and wouldn't take more than a few days. > ---------------- > We made some big changes in EKOPath 5/ENZO and development is closed for now. > We're trying to figure out a strategy which will have an impact and be > win/win for everyone. > ---------------- > Apologies if I may have dropped the ball on communication. I'm not > subscribed to -current or -performance and please cc me on any replies. > > ./C
A few additional comments: - FreeBSD libm really needs to get the missing C99 functions committed. We have good versions of these written now (with better accuracy than several competing operating systems that are successful scientific computing platforms), but they need committing. Of the 31 test failures in the libc++ test suite (which covers most of C++11) that I see currently, 18 are due to missing C99 functionality. Most of the missing functions are implemented, but committing them was held up by style nits in the source code. This is just embarrassing. - GPU support has been quite poor on FreeBSD, and this has a knock-on effect on GPGPU. It's a mistake to think of GPUs as just things gamers need and therefore not too important for FreeBSD - they're currently the best performance-per-dollar accelerators available on the market and so are of interest in a number of markets. If you or your company is using FreeBSD and wants to do GPGPU things, then make sure that AMD, Intel, and nVidia all know, and ideally let Qualcomm and ARM know too. The FreeBSD Foundation has funded work on KMS, GEM and TTM, and so open source driver support is improving. If you're willing to fund some more of this work, then please get in touch with the Foundation. Most of the companies in this space don't care what we say, they care what their customers (and potential customers) say. They won't support FreeBSD if there's no (perceived) demand, so it's important to make sure that they're aware of the demand. - A big part of the problem is mindshare. Linux is seen as the thing to use on clusters and supercomputers, even when it isn't the best tool for the job. It's hard to contradict this view when there aren't any (public) large-scale deployments of FreeBSD for scientific computing. If you have one that you're willing to talk about, please contact the Foundation and let them know. David _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
