[gomp] Broken gomp branch
The gomp branch fails to bootstrap for libtool problems in libgomp. Verified on x86_64-unknown-linux-gnu and on i686-unknown-linux-gnu. It appears that the fix is pretty easy: libgomp/configure (and related files) need to be regenerated. This fix the problem on x86_64-unknown-linux-gnu. Can I ask the maintainers to fix that? Thanks, Biagio -- = Biagio Lucini Institut Fuer Theoretische Physik ETH Hoenggerberg CH-8093 Zuerich - Switzerland Tel. +41 (0)1 6332562 =
Re: [gomp] Broken gomp branch
On Mon, 28 Mar 2005, Diego Novillo wrote: > On Wed, Mar 23, 2005 at 05:35:42PM +0100, Biagio Lucini wrote: > > > The gomp branch fails to bootstrap for libtool problems in libgomp. > > Verified on x86_64-unknown-linux-gnu and on i686-unknown-linux-gnu. > > > > It appears that the fix is pretty easy: libgomp/configure (and related > > files) > > need to be regenerated. This fix the problem on x86_64-unknown-linux-gnu. > > > > Can I ask the maintainers to fix that? > > > It seems to have been regenerated recently. Do you still see a > problem with the file? > > > Diego. > As for last Wednesday, yes. The problem disappeared after I regenerated the file on my system. At the moment I am on a modem connection, and it is almost impossible for me to test anything. Next week it would be much better. Thanks, Biagio = Biagio Lucini Institut Fuer Theoretische Physik ETH Hoenggerberg CH-8093 Zuerich - Switzerland Tel. +41 (0)1 6332562 =
GCC 4.0 blacklisted for kde?
While discussing whether including gcc 4.0 in a Linux distro, someone pointed out this: http://lists.kde.org/?l=kde-devel&m=111471706310369&w=2 I have checked the gcc bugzilla and either I am wrong or there is nothing relevant. Does anyone know some more? Thanks Biagio
Re: [gomp] OpenMP IL design notes
On Tuesday 03 May 2005 21.16, Diego Novillo wrote: > > On Tue, May 03, 2005 at 11:05:05PM +0200, Lars Segerlund wrote: > > > we have to extend the gfortran internal representation also > > Yes, initially most of the effort will be in C/C++ since that's > the only parser we have so far. > Is there any obstruction in principle to have the so-called sentinel directive (!$OMP) recognised by the gfortran parser? Talking with Lars, I have understood that at the moment some misbehaviour of the front-end prevents it, but I don't quite understand what the problem is. Can anyone shed some light? Also, talking about IR, since OpenMP is mostly unique, probably we just need to link the gfortran parser to the work in the middle-end that is currently being done, with perhaps a few (hopefully no) exception. Biagio
Re: [gomp] OpenMP IL design notes
On Wednesday 04 May 2005 13.34, Paul Brook wrote: > > On Wednesday 04 May 2005 13:15, Biagio Lucini wrote > > > I have understood that at the moment some misbehaviour of the front-end > > prevents it, but I don't quite understand what the problem is. Can anyone > > shed some light? > > Basically the fortran parser does trial-and-error pattern matching, and can > end up parsing a single comment many times. > Is this a permanent feature or something that can be removed? The reason why I am asking is that I would like to experiment with this front-end a little bit. Thanks Biagio -- ========= Biagio Lucini Institut Fuer Theoretische Physik ETH Hoenggerberg CH-8093 Zuerich - Switzerland Tel. +41 (0)1 6332562 =
Benchmark of gcc 4.0
I run for my personal pleasure (since I am a number cruncher) the Scimark2 tests on my P4 Linux machine. I tested GCC 4.0 (today's CVS) vs. GCC 3.4.1 vs. Intel's ICC 8.1 For GCC, I used in both cases the flags -march=pentium4 -mfpmath=sse -O3 -fomit-frame-pointer -ffast-math Should be of some interest, for ICC I used -ipo -tpp7 -xW -align -Zp16 -O3 The results were surprisingly bad, and this is why I am writing this message: GCC 4.0 GCC 3.4.1 ICC Composite Score: 270.51 345.28 430.47 FFT Mflops: 192.10 203.77 206.66 SOR Mflops:257.61 252.88 258.30 MC Mflops: 58.61 67.96 312.13 matmultMflops:376.64557.75 564.97 LUMflops:467.58 644.03 810.29 I leave aside any personal comments, except that being involved in Monte Carlo calculations, I would love if GCC were not outperformed by a factor of ~ 4.5 in MC by ICC. I also would like to ask whether you see anything wrong with those benchmarks and/or you have suggestions to improve them. Thanks, Biagio -- ===== Biagio Lucini Institut Fuer Theoretische Physik ETH Hoenggerberg CH-8093 Zuerich - Switzerland Tel. +41 (0)1 6332562 =
Re: Benchmark of gcc 4.0
On Thursday 24 February 2005 16.52, Paolo Bonzini wrote: > > Try these five combinations: > [...] > > -O3 -fomit-frame-pointer -ffast-math -fno-tree-pre [...] This + 387 math is the one with the larger impact: it rises MC to around 80, but composite is still 279 (vs. ~ 345 for GCC 3.4). I will test on amd64, just to see whether there is any difference. Thanks, Biagio -- ===== Biagio Lucini Institut Fuer Theoretische Physik ETH Hoenggerberg CH-8093 Zuerich - Switzerland Tel. +41 (0)1 6332562 =
Re: Benchmark of gcc 4.0
On Thursday 24 February 2005 17.06, Richard Guenther wrote: > I just got interested and did a test myself. Comparing gcc 4.0 (-O2 > -funroll-loops -D__NO_MATH_INLINES -ffast-math -march=pentium4 > -mfpmath=sse -ftree-vectorize) > and icc 9.0 beta (-O3 -xW -ip): > gcc 4.0 icc 9.0 > Composite Score: 543.65609.20 > FFT Mflops: 313.71 318.29 > SOR Mflops: 441.96 426.32 > MonteCarlo: Mflops: 105.68 71.20 > Sparse matmult Mflops: 574.88 891.65 > LU Mflops: 1282.00 1338.56 > > which looks not too bad ;) > > Richard. Hi Richard, thanks a lot for your test. I have redone it, the way you suggest, and I do find: GCC4.0ICC 8.1 GCC 3.4.1 Composite Score: 330.18384.53361.55 FFT Mflops: 206.66193.80206.66 SOR Mflops: 264.91 398.13253.55 MC Mflops:63.91 61.29 67.45 Sparse matmult : 348.60 436.91469.79 LU Mflops:767.04 832.52810.29 I would leave aside ICC 8.1 because (as I have showed in my previous message) I can choose other flags and get a speed rise of about 50%. I would take your optimisation flags for GCC better than mine, since they increase the composite score of both (which is what matters to me). Even so, there is at least one place where - if I can say that - we have a regression. Ready to test again, Biagio -- ========= Biagio Lucini Institut Fuer Theoretische Physik ETH Hoenggerberg CH-8093 Zuerich - Switzerland Tel. +41 (0)1 6332562 =
Re: gomp slowness
skaller wrote: Hi, I have just run and timed a couple of tutorial examples for openMP using gcc (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4) on a dual core Athlon amd64, with OMP_NUM_THREADS set to 1 and 2, and occasionally 8 I found that 1 thread outperforms 2 by almost 2:1 on all the examples, and 8 is only fractionally slower than 2. The code was compiled with just -fopenmp, no optimisation switches. OS: Linux, Ubuntu gutsy (7.10) with Linux 2.26.22-14-rt (with real time patches). I confirmed by observing system monitor 1 thread maxes out 1 CPU, and 2 maxes out both, also the observable behaviour was correct and as expected.. it was just SLOW. I've briefly looked at the current SVN source for libgomp and can't see anything wrong there. Can anyone venture an explanation as to what might be going wrong? At least one of the tests has long independent tasks (many seconds) for each thread, so it doesn't seem to be a synchronisation issue. Differences like: 4.7 second for 1 thread, 13 seconds for two were regularly observed in ALL the tests. Note: these are the real time figures, the CPU times were even worse. [BTW: I built current SVN for gcc as well, but the installed result didn't run properly due to a missing .spec file, so I couldn't check if it was any different] It would be interesting to try with another compiler. Do you have access to another OpenMP-enabled compiler? Biagio
