Hi,
I'm taking out arch and some people from the CC and only keep
curr...@. This is getting off topic for the initial thread.
Quoting Anton Shterenlikht <me...@bristol.ac.uk> (from Thu, 19 Aug
2010 21:10:24 +0100):
On Thu, Aug 19, 2010 at 11:35:48AM +0200, Alexander Leidinger wrote:
Quoting Dag-Erling SmÃ??rgrav <d...@des.no> (from Thu, 19 Aug 2010
11:16:23 +0200):
> Alexander Leidinger <alexan...@leidinger.net> writes:
>> If someone would get icc 11.x up and runnig as a port (similar to what
>> we have for outdated icc version in the ports collection), I would
>> have a look if my contact at Intel is still working there in a
>> position which allows him to get a commercial license for us.
>
> Does that really matter? We're not going to start building releases
> with icc, are we?
It could matter for ports, I do not know if it matters for parts in
src. The commercial license is also the only way that we could get icc
installed on machines in the FreeBSD cluster (if there's interest to
have another compiler *for FreeBSD development* to check the source
against... the warnng and error messages are better that those of gcc,
I do not know how they compare to clang).
If one begins to mention FreeBSD clusters, and moreover FreeBSD HPC, then
this becomes a somewhat different discussion. One of the stubmling
blocks for HPC on FreeBSD (just one of many, perhaps not even the
major one) is a complete lack of good quality commercial compilers.
All weÃ'got is gcc or clang. Both are not really that great, and
definitely inferior to commercial compilers, e.g. Intel. What IÃ'm
saying is that it would be great if Intel sold a compiler for FreeBSD.
I'd ve bought a copy. But from what others have said, my impression is that
the ICC port is unlikely to fill this void.
After I (and other people which provided patches) ported icc to
FreeBSD someone from IIRC Asia took the port as an example and ported
Intels Fortran compiler to FreeBSD in the same way (he was able to use
a lot of the icc port, only some minor modifications where necessary).
I had the impression that this was used for HPC.
P.S. My interests and expertise are in computational mechanics, not in
compilers, so feel free to correct me if IÃ'm wrong.
In general: The resulting code (for icc and ifc) was working. The
application binary code itself was/is the same (modulo differences in
system headers), the "only" things which need to be changed are the
startup code and the libs. We managed to do that.
P.P.S. Regarding FreeBSD HPC see also this thead:
http://lists.freebsd.org/pipermail/freebsd-questions/2010-August/220264.html
(FreeBSD, GPGPU and OpenCL/CUDA)
That's not the way we would like it to be, but at least it is possible:
http://blogs.freebsdish.org/jhb/2010/07/20/using-cuda-with-the-native-freebsdamd64-nvidia-driver/
When I was working on icc, I had an idea about a liblinux2freebsd
which would provide common linux-symbols and map them to
FreeBSD-equivalents (together with some predefined objdump/objcopy/...
scripts to modify linux libs) so that you can take a linux lib and use
it to create native FreeBSD programs. Sort of like the NDIS layer in
the kernel to run Windows binary drivers. Unfortunately I never got
the time to work on this. Something like this could have maybe been
used to "mangle" the linux cuda libs to be used on FreeBSD natively.
Bye,
Alexander.
--
Neither spread the germs of gossip nor encourage others to do so.
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
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"
