Date: Thu, 14 Dec 2006 09:17:24 -0500 From: Mikhail Teterin <mi+kde@aldan.algebra.com> To: Doug Barton <dougb@freebsd.org> Cc: current@freebsd.org Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP Message-ID: <200612140917.25523@aldan> In-Reply-To: <4580DFAB.3080601@FreeBSD.org> References: <20061213192150.CF83D16A417@hub.freebsd.org> <200612131711.50921.mi%2Bmx@aldan.algebra.com> <4580DFAB.3080601@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612140917.25523>