Let's use gcc-4.2, not 4.1 -- OpenMP
Mikhail Teterin
mi+kde at aldan.algebra.com
Thu Dec 14 06:29:04 PST 2006
On Thursday 14 December 2006 00:22, Doug Barton wrote:
= Let's start over. I have a core 2 duo box so I'm interested, and I
= agree with you that at least 2 cores is going to be the "norm" sooner
= than later. So can you tell us what the benefits and risks are of 4.2
= vs. 4.1?
If you follow the AMD-links in my original e-mail:
> http://www.openmp.org/
> http://gcc.gnu.org/projects/gomp/
> http://developer.amd.com/article_print.jsp?id=79
> http://developer.amd.com/article_print.jsp?id=82
you can see examples of using OpenMP. It makes parallel programming (in C,
C++, and Fortran) much easier and more portable --
threads/mutexes/barriers/CPU-accounting is created and managed by the
implementation... I, for one, look forward to messing with sort(1) and
qsort(3) -- there is ample room for parallization there. Nothing one could
not do manually with pthreads, but nicer and more straightforward...
Although commercial compilers (like Intel's icc for Windows and Linux, or Sun
Studio on Solaris, or Visual Studio on Windows) have supported OpenMP pragmas
for a while (icc even allows parallelizing accross multiple machines),
gcc-4.2 is the first release of GCC that supports it (with `-fopenmp' flag).
I anticipate, "out-of-the-box" OpenMP support will soon be one of the
required "check-boxes" for an OS to be considered for many things...
Scott may well be right suspecting that _this support_ may be of beta-quality
at the moment, but that's not a valid argument for rejecting 4.2 in favor of
4.1. Since we are migrating from 3.x to 4.x _anyway_, may as well target 4.2,
unless it is worse than 4.1 in some parts _which we currently use_.
Even if OpenMP-support turns out to be subpar in 4.2, it will improve with
time, and we'll obtain the improvements via the next move from 4.2.x to
4.2.x+n. Such moves will be easier than going from 4.1.y to 4.2.z.
= I think someone already put forward the idea that if we were
= to adopt 4.2 that we'd have a longer support cycle, which sounds like
= a good thing to me; but I'm nowhere near an expert.
Yes, that's another plus -- GCC folks already refuse to do anything about
problems with 3.4.x, which is the base compiler in our most recent
release :-(
-mi
More information about the freebsd-current
mailing list