Re: PathScale EKO Path 5 not for FreeBSD anymore?

I forwarded this thread to Christopher Bergst=F6m and got this reply:

> ----------------
> FreeBSD simply isn't a scientific computing platform - There isn't any ma=
rket 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 comput=
ing field)
> ----------------
> However, we haven't dropped support for it
> http://c591116.r16.cf2.rackcdn.com/enzo/nightly/FreeBSD/enzo-2013-02-19-i=
nstaller.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 b=
e win/win for everyone.
> ----------------
> Apologies if I may have dropped the ball on communication.  I'm not subsc=
ribed 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 platf=
orms), but they need committing.  Of the 31 test failures in the libc++ tes=
t suite (which covers most of C++11) that I see currently, 18 are due to mi=
ssing C99 functionality.  Most of the missing functions are implemented, bu=
t committing them was held up by style nits in the source code.  This is ju=
st embarrassing.  =

- GPU support has been quite poor on FreeBSD, and this has a knock-on effec=
t 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 perfo=
rmance-per-dollar accelerators available on the market and so are of intere=
st in a number of markets.  If you or your company is using FreeBSD and wan=
ts 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 fun=
ded work on KMS, GEM and TTM, and so open source driver support is improvin=
g.  If you're willing to fund some more of this work, then please get in to=
uch with the Foundation.  Most of the companies in this space don't care wh=
at we say, they care what their customers (and potential customers) say.  T=
hey won't support FreeBSD if there's no (perceived) demand, so it's importa=
nt 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 us=
e 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) larg=
e-scale deployments of FreeBSD for scientific computing.  If you have one t=
hat you're willing to talk about, please contact the Foundation and let the=
m know.  =

David
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"