Give me advice on GSoC OpenMP
Hi! I'm Sho Nakatani, a student of the University of Tokyo, Japan. I'd like to tackle GSoC this year! I'm trying to speed up the OpenMP implementation in GCC. The following graph shows the OpenMP in GCC is much slower than that of Intel C Compiler. https://github.com/laysakura/GCC-OpenMP-Speedup/raw/master/img/task-gcc-vs-icc.png Here is the code I on measured the exec time. https://github.com/laysakura/GCC-OpenMP-Speedup/blob/master/test/openmp-fibonacci.c And I compiled it by the following command: gcc -O3 -fopenmp -o openmp-fibonacci-gcc openmp-fibonacci.c icc -O3 -openmp -o openmp-fibonacci-icc openmp-fibonacci.c After that, I executed them on a machine with 32 AMD CPUs (each has 4 cores). Currently, I'm planning to change the algorighm of `task' premitive in `libgomp'. This plan is of course for GSoC but also for my graduation thesis. My teacher has some idea on the better algorithm (but I haven't learned it yet). Are there any advice from the members of GCC ML? Anything is OK: Although I know some about C programming and I have implemented a very small C compiler myself, I'm quite new to GCC. I welcome advice on how to get accepted from GSoC, too :-) Thanks, -- Sho Nakatani
More consistent set of allowed values of std flag
Hi, I have same suggestions connected with the set of allowed values for std flag in gcc for C and C++. According to manual, there are 3 categories of accepted values: ISO standard reference number (ex. iso9899:1990), common name (c90) and version with gnu extensions (ex. gnu90) . But for same standards (amendment C90 and C++) there is only one of them supported. So mu suggestion is to extend set of possible values to: c90, iso9899:1990; gnu90 *c94* or *c95*, iso9899:199409; *gnu94* or *gnu95* (optionally) c99, iso9899:1999 gnu99 c1x, *iso9899:201x* gnu1x c++98, *iso14882:1998** *gnu++98 c++0x,*iso14882:200x* gnu++0x Regards Tomasz
Re: More consistent set of allowed values of std flag
2011/4/2 Tomasz Kamiński: > Hi, > > I have same suggestions connected with the set of allowed values for std > flag in gcc for C and C++. According to manual, there are 3 categories of > accepted values: ISO standard reference number (ex. iso9899:1990), common > name (c90) and version with gnu extensions (ex. gnu90) . But for same > standards (amendment C90 and C++) there is only one of them supported. So mu > suggestion is to extend set of possible values to: > > c90, iso9899:1990; > gnu90 > > *c94* or *c95*, iso9899:199409; > *gnu94* or *gnu95* (optionally) gcc/c-family/c-opts.c says "There is no concept of gnu94." > c99, iso9899:1999 > gnu99 > > c1x, *iso9899:201x* > gnu1x > > c++98, *iso14882:1998** > *gnu++98 > > c++0x,*iso14882:200x* C++0x is not an ISO standard yet, so it's not appropriate to add iso14882:200x - even when it is a standard it will probably be 2011 not 200x (you might have noticed we missed that date ;-) The same applies to c1x. Consistency is sometimes nice, but personally I don't really see any benefit to this change.
Re: More consistent set of allowed values of std flag
W dniu 02.04.2011 16:17, Jonathan Wakely pisze: 2011/4/2 Tomasz Kamiński: Hi, I have same suggestions connected with the set of allowed values for std flag in gcc for C and C++. According to manual, there are 3 categories of accepted values: ISO standard reference number (ex. iso9899:1990), common name (c90) and version with gnu extensions (ex. gnu90) . But for same standards (amendment C90 and C++) there is only one of them supported. So mu suggestion is to extend set of possible values to: c90, iso9899:1990; gnu90 *c94* or *c95*, iso9899:199409; *gnu94* or *gnu95* (optionally) gcc/c-family/c-opts.c says "There is no concept of gnu94." In this case simply omit this value. c99, iso9899:1999 gnu99 c1x, *iso9899:201x* gnu1x c++98, *iso14882:1998** *gnu++98 c++0x,*iso14882:200x* C++0x is not an ISO standard yet, so it's not appropriate to add iso14882:200x - even when it is a standard it will probably be 2011 not 200x (you might have noticed we missed that date ;-) The x is hexadecimal number and now it is B (this is the best explanation I have ever found :-) ). Anyway I have been suggested by the for C99 aliases present (but deprecated) in gcc-4.4.3: C9x and iso9899:199x. Also WG14 (C Standard committee) uses this kind of numeration (ex. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1539.pdf). The same applies to c1x. Consistency is sometimes nice, but personally I don't really see any benefit to this change. In my opinion the ability to use consistent set of options for specifying language standard is more convenient for a developer (user).
Re: Give me advice on GSoC OpenMP
Hi all, I conducted another experiment. Compiler version: - gcc (GCC) 4.7.0 20110331 (experimental) - icc (ICC) 12.0.3 20110309 CPU info: 32 AMD CPUs. Each has 4 cores. I calculated fibonacci(37) both by gcc and icc. As the OMP_NUM_THREADS increase, - gcc increased the exec time steadly. - icc decreased the exec time. I got a graph but it seems nonsense because the exection time of the program compiled by gcc was far slower than icc. Here is the result: ===Execution Time with the Increase of Number of Threads=== # OMP_NUM_THREADS Exec time [sec] # gcc 1 11.90681 2 91.97240 4 142.69790 8 281.87043 16 751.86979 321103.64058 # icc 18.38479 2 16.03128 47.81509 84.34125 16 2.19561 32 1.32377 == This paper also shows that OpenMP implementation in GOMP is slower than others. https://iwomp.zih.tu-dresden.de/downloads/runtime-olivier.pdf (There are graphs from page 5.) So, I'd like to speed up GOMP. I'm planning to use `Lazy Task Creation' algorithm for it. I heard from my teacher that my senior associate has made a library for Lazy Task Creation. So I can utilize it for the experimental purpose. >From now on, I try to visualize how tasks are created as time passes not just to show the reason why GOMP is slower compared to icc implementation but to make my idea clear for myself :-) So, I need to know OpenMPI API to get tasks info like: - A task is created - A task finished its job - On which CPU core a task is on Do you know any document? Thanks, -- Sho Nakatani
Re: old software versions on ftp://gcc.gnu.org/pub/gcc/infrastructure/
On Tue, 29 Mar 2011, Vincent Lefevre wrote: > ftp://gcc.gnu.org/pub/gcc/infrastructure/ contains old versions of > some libraries (like GMP, MPFR and MPC). Shouldn't they be updated? > GNU MPFR can also be downloaded from: http://ftp.gnu.org/gnu/mpfr/ I believe that these days they should be removed, rather than updated. Provding them was more important before they became more popular (and GNU programs in two cases actually). Note that the versions there strictly match the minimal versions listed at http://gcc.gnu.org/install/prerequisites.html and sadly some newer versions cause issues, for example on SPARC. Gerald
Re: new mirror in Nicosia, Cyprus
On Sat, 5 Mar 2011, Grigory Rayskin wrote: > We have set up a new GCC mirror server offering HTTP access: > http://fileboar.com/gcc/ > > This server is located in Nicosia, Cyprus. The update is scheduled twice > a week. I was just going to add this sever, but something does not seem right: All directories have 29-Mar-2011 09:14 (plus some minutes in some cases) as their date and time. Is there, possibly, a problem with the sync always pulling everything down? Also, it seems there has not been a sync for more than half a week? > Thanks in advance for listing us. Any chance you could look into the above and suggest a patch against http://gcc.gnu.org/mirrors.html with how you suggest the mirror to be listed? Thanks, Gerald
Re: darwin LTO broken under Xcode 3.2.6/4.0
On Mon, 14 Mar 2011, Jack Howarth wrote: >Would someone please correct http://gcc.gnu.org/gcc-4.6/changes.html by > deleting > the reference to darwin LTO support. Specifically we should just kill the > line... Done thusly. Gerald Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/changes.html,v retrieving revision 1.124 diff -u -r1.124 changes.html --- changes.html22 Mar 2011 20:11:00 - 1.124 +++ changes.html2 Apr 2011 22:26:45 - @@ -974,8 +974,6 @@ context of format attributes and arguments (see the documentation for format attributes for limitations). At present, 8-bit character types are supported. - LTO-support.Darwin has benefited from ongoing work on - LTO; support for this is now stable and enabled by default. Object file size reduction. The Darwin zeroed memory allocators have been re-written to make more use of .zerofill sections. For non-debug code, this can
Re: fsf paperwork?
On Tue, 15 Mar 2011, Ian Lance Taylor wrote: > I would appreciate it if the steering committee, as the official FSF > maintainers, could pass this on to the FSF. I've raised this with RMS. Gerald
gcc-4.7-20110402 is now available
Snapshot gcc-4.7-20110402 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20110402/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 171894 You'll find: gcc-4.7-20110402.tar.bz2 Complete GCC (includes all of below) MD5=e441a4c7ab40795e14788f1216f570a6 SHA1=dc892df1cc10ef617b736a35c20e67042c305f27 gcc-core-4.7-20110402.tar.bz2C front end and core compiler MD5=84a40f161ffee09cb8e8eb73ac310c2c SHA1=b6b439b52efab149d4be7dbef1c8c2ef78998339 gcc-ada-4.7-20110402.tar.bz2 Ada front end and runtime MD5=989ba1ec1a2fbb966905296aadad57ee SHA1=971df24ea8e983f023c4b86104b1638231e67434 gcc-fortran-4.7-20110402.tar.bz2 Fortran front end and runtime MD5=c0aa7072c69f0b1dbe563fc0451a0015 SHA1=0326a3fbaafccaa4ade692f19780463ef68df372 gcc-g++-4.7-20110402.tar.bz2 C++ front end and runtime MD5=6eb117525bb6548460d6f04d620d07b8 SHA1=c4dbed892889a197b80cf38ea8e5ac27f6c8ede0 gcc-go-4.7-20110402.tar.bz2 Go front end and runtime MD5=c42f7865fa953bdaf1af8600853580f4 SHA1=2fa98cebd7e60605a4fd1961e3d4ca5eaa9448e5 gcc-java-4.7-20110402.tar.bz2Java front end and runtime MD5=bfbc19bb1a8422d019fa92ee9ba649b1 SHA1=d97fbe9a09eb21d8d3f2cada187ca1e361b727ae gcc-objc-4.7-20110402.tar.bz2Objective-C front end and runtime MD5=86aae46da5cb3b557e03d57d452965d7 SHA1=b15899ad807a73588dbea92b1129bc735b80e203 gcc-testsuite-4.7-20110402.tar.bz2 The GCC testsuite MD5=756a18669e876cad48ad31ffac3febbe SHA1=cfec29d12246514550ea00aab166a9a2210905f0 Diffs from 4.7-20110326 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
