On 02.06.12 12:27, O. Hartmann wrote:
1a) On "scietific production systems", FreeBSD has been banned due to
the lack of HPC compilers and appropriate mathematical libraries. The
lack of professional/academic support, like that from NAG in the late
1990s, has been droped for FreeBSD as well as the presence of C/C++/F95
compilers.
Could you please elaborate on this a bit. "Scientific" software, as such
rarely depends on any hardware and should be practically OS agnostic.
What are these libraries, that "scientific production systems" use that
cannot be used on FreeBSD? Same about support. If someone supports an
"scientific" library on an OS, chances are they can support it on
FreeBSD just as well, except if they are religious fanatics, that is.
FreeBSD has always had more or less recent compilers available. Perhaps,
not in the base system. As you say, this issue is strictly political (to
not have "cuitting edge" [double the quote, for more pun] compilers).
The policy with FreeBSD is stability over all else and that the base
must be able to compile itself -- this is what any UNIX system is
supposed to handle, but that's another long story. The recent
developments with clang/llvm are very promising as well.
I can hardly imagine it being that difficult to maintain an "advanced"
compiler around just to compile your highly specific code. Further,
recent gcc is in ports anyway.
1b) The lack of GPGPU. This has become so important to HPC these days.
We use nVidia GPU based TESLA boards with OpenCL software (CUDA is
luckily not necessary). The lack of professional drivers for 64Bit on
FreeBSD was long time an issue, nVidia now provides drivers, but they
don't provide their CUDA/OpenCL libraries along with their nvcc compiler
natively for 64Bit FreeBSD/amd64. The Linuxulator isn't any option.
This one is regrettable. Outside of the "scientific" usage, it could let
desktop users offload a lot of processing to their (in most cases more
powerful than the CPU, video controller). But how is this FreeBSD fault?
I would attribute it more to inability of nVidia programmers, or their
lack of resources (I doubt that many people do driver development there
anyway) as the reason why we don't see it. If they have scarce resources
available, it's understandable why they do not see the immediate need to
port their code to FreeBSD. I am confident, given this hardware is not
that cheap, that any bigger user asking for FreeBSD support could
motivate them to just do it.
I also believe there is nothing hidden in FreeBSD and that in general
FreeBSD has been more stable API-wise than other UNIX platforms around.
And, I also believe should there be interest from nVidia, tey will see
support and help from FreeBSD developers. Or they could just release
their hardware spec, if they can't do it themselves for one reason or
another. After all, much more complex tasks have been resolved with FreeBSD.
2) Disk and network I/O issues under load. We realized that FreeBSD has
some issues in multithreaded environments. Even on 6/12 or 12/24
core/thread systems, under heavy load (especially network and CPU load),
disk I/O was (is?) poor. This is a no-go in a HPC environment.
Could you please elaborate on this a bit?
On one hand, I am surprised that the HPC environment will have such
requirements and on the other hand this is how typical higher-end
storage systems are built with FreeBSD. I haven't seen anything like
this and am willing to test on 24-32 core systems.
You said this is political for FreeBSD .. why? I don't get it? FreeBSD
has no policy of failing under heavy load -- quite the contrary.
3) Outdated ports OR not available ports: some important software
maintained by the US government (USGS, NASA/JPL) is only provided for
Mac OS X and some Linux derivatives.
This may be for many, many reasons, including (most often and most
unfortunately) licensing. But there is not much anyone working with
FreeBSD can do, except create an port, if the license permits.
If the license does not permit this software run on FreeBSD -- then
probably the only choice is to try and persuade it's author.
If it runs on OS X, chances are it will run on FreeBSD with very little
effort. (except if it relies heavily on Cocoa)
4) The lack of clustering capabilities. The lack of a clustered
filesystem grows more and more important in the area of HPC, where
storage systems get spread over a department. I lost track in the
development on FreeBSD since around 2003. At the moment, for me
personally this issue isn't so important, but in combination with items
1) through 3) and the migration towards Linux (we use prefereably Ubuntu
server, some Suse and on some servers CentOS/RedHat, which suffers from
the Linux-narrowminded deseas as well, in my opinion, but you'll get
support by Dell and others - in times of strangling contracts, a more
and more restricted freedom of science in favor of "business" ...
another story ...)
Can you explain on this too? What kind of clustering filesystem you
need? FreeBSD doesn't do bad in the storage area and in fact many
(most?) commercial storage solutions are built on top of FreeBSD.
Daniel
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
