Date: Wed, 20 Feb 2013 10:18:43 +0000 From: David Chisnall <theraven@FreeBSD.org> To: "O. Hartmann" <ohartman@zedat.fu-berlin.de> Cc: freebsd-performance@FreeBSD.org, Current FreeBSD <freebsd-current@FreeBSD.org>, =?iso-8859-1?Q?=22C=2E_Bergstr=F6m=22?= <cbergstrom@pathscale.com> Subject: Re: PathScale EKO Path 5 not for FreeBSD anymore? Message-ID: <D033402C-2194-4D0C-8CB9-52198A37273B@FreeBSD.org> In-Reply-To: <5124063D.2060604@zedat.fu-berlin.de> References: <5124063D.2060604@zedat.fu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
I forwarded this thread to Christopher Bergst=F6m 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-in= staller.run >=20 > 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. >=20 > ./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. =20 - 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. =20 David=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D033402C-2194-4D0C-8CB9-52198A37273B>