With the compiler from the ira branch on x86_64-linux, here are the
timings reported by gfortran -c -time -save-temps with and without
IRA (two timings provided for each set of option, to check
reproducibility)
OK, I come back with fresh numbers from the current IRA branch, rev.
135035,
FX wrote:
PS: I attach the file containing all timings. For each set of option,
I ran the compiler twice; when timings differ significantly, that's
because of other users using the machine (which is a rather underused
dual-core biprocessor, with an average load during my tests of 1.09),
and I
Thanks for testing IRA. As I understand, in
# f951 135.59 6.88
the first number is wall compilation time. Could you tell me what is the
second one? Is it system time?
I suppose so. The two times are the output from gfortran -time -S.
I am trying to analyze the results and it would
Kenneth Zadeck wrote:
Vladimir Makarov wrote:
Peter Bergner wrote:
On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote:
Thanks, Peter. That was clever and email is very enlightening. I
have analogous idea for more compact conflict matrix
representation. IRA builds allocno live
Kenneth Zadeck wrote:
Thanks, Peter. That was clever and email is very enlightening. I
have analogous idea for more compact conflict matrix
representation.
I am currently working on bit matrix compression. It is not
implemented yet. I hope it will be ready in a week.
vlad, this seems
On Tue, Apr 29, 2008 at 6:22 PM, Mark Mitchell [EMAIL PROTECTED] wrote:
Vladimir, if you feel that Peter's code cannot be used directly in IRA,
would you please explain why not?
I think he already has explained, see
http://gcc.gnu.org/ml/gcc/2008-04/msg00730.html
Having looked at IRA a bit, I
On Tue, 29 Apr 2008 20:25:56 +0200, Steven Bosscher
[EMAIL PROTECTED] wrote:
On Tue, Apr 29, 2008 at 6:22 PM, Mark Mitchell [EMAIL PROTECTED] wrote:
Vladimir, if you feel that Peter's code cannot be used directly in IRA,
would you please explain why not?
I think he already has explained,
Mark Mitchell wrote:
Kenneth Zadeck wrote:
Thanks, Peter. That was clever and email is very enlightening. I
have analogous idea for more compact conflict matrix representation.
I am currently working on bit matrix compression. It is not
implemented yet. I hope it will be ready in a
Steven Bosscher wrote:
On Tue, Apr 29, 2008 at 6:22 PM, Mark Mitchell [EMAIL PROTECTED] wrote:
Vladimir, if you feel that Peter's code cannot be used directly in IRA,
would you please explain why not?
I think he already has explained, see
J.C. Pizarro wrote:
On Tue, 29 Apr 2008 20:25:56 +0200, Steven Bosscher
[EMAIL PROTECTED] wrote:
On Tue, Apr 29, 2008 at 6:22 PM, Mark Mitchell [EMAIL PROTECTED] wrote:
Vladimir, if you feel that Peter's code cannot be used directly in IRA,
would you please explain why not?
I
On 2008/4/28 Ben Elliston [EMAIL PROTECTED] wrote:
On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote:
Don't be stupid!
Could you be a bit more civil, please? It's fairly unusual for people
on this list to talk to each other in this way.
Thanks,
Ben
Excuse me, i'm not the
On Mon, Apr 28, 2008 at 09:07:51AM +0200, J.C. Pizarro wrote:
Excuse me, i'm not the unique and first person that says you stupid,
GCC did it too.
GCC is not posting on the mailing list. Please be polite to other
contributors; that includes not insulting their intelligence.
--
Daniel
J.C. Pizarro wrote on :
On 2008/4/28 Ben Elliston wrote:
On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote:
Don't be stupid!
Could you be a bit more civil, please? It's fairly unusual for people
on this list to talk to each other in this way.
Thanks,
Ben
Excuse me, i'm
On 2008/4/28 Dave Korn [EMAIL PROTECTED] wrote:
J.C. Pizarro wrote on :
On 2008/4/28 Ben Elliston wrote:
On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote:
Don't be stupid!
Could you be a bit more civil, please? It's fairly unusual for people
on this list to talk
On 2008/4/27 J.C. Pizarro [EMAIL PROTECTED] wrote:
On Fri 25 Apr 2008 22:22:55 -0500, Peter Bergner [EMAIL PROTECTED] wrote:
The difference between a compressed upper triangular bit matrix from a
standard
upper triangular bit matrix like the one above, is we eliminate space from
the
Peter Bergner wrote:
On Thu, 2008-04-24 at 20:23 -0400, Vladimir Makarov wrote:
Hi, Peter. The last time I looked at the conflict builder
(ra-conflict.c), I did not see the compressed matrix. Is it in the
trunk? What should I look at?
Yes, the compressed bit matrix was committed
On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote:
Thanks, Peter. That was clever and email is very enlightening. I have
analogous idea for more compact conflict matrix representation. IRA
builds allocno live ranges first (they are ranges of program points
where the allocno
Peter Bergner wrote:
On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote:
Thanks, Peter. That was clever and email is very enlightening. I have
analogous idea for more compact conflict matrix representation. IRA
builds allocno live ranges first (they are ranges of program points
On Mon, 2008-04-28 at 18:07 -0400, Vladimir Makarov wrote:
I am currently working on bit matrix compression. It is not implemented
yet. I hope it will be ready in a week.
Ahh, ok. Well, hopefully the code I wrote on the trunk is useful for IRA.
If you have questions about it, let me know,
On Fri 25 Apr 2008 22:22:55 -0500, Peter Bergner [EMAIL PROTECTED] wrote:
On Thu, 2008-04-24 at 20:23 -0400, Vladimir Makarov wrote:
Hi, Peter. The last time I looked at the conflict builder
(ra-conflict.c), I did not see the compressed matrix. Is it in the
trunk? What should I look at?
On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote:
Don't be stupid!
Could you be a bit more civil, please? It's fairly unusual for people
on this list to talk to each other in this way.
Thanks,
Ben
On Thu, 2008-04-24 at 20:23 -0400, Vladimir Makarov wrote:
Hi, Peter. The last time I looked at the conflict builder
(ra-conflict.c), I did not see the compressed matrix. Is it in the
trunk? What should I look at?
Yes, the compressed bit matrix was committed as revision 129037 on
October
I'm willing to try and do some benchmarking of Fortran codes using IRA
(on i686 and x86_64), and report back here with figures and reduced
testcases of eventual slow-downs. What is the current, stable way to
build an IRA compiler and run it? Should I just get the last revision
of the ira branch?
FX wrote:
I'm willing to try and do some benchmarking of Fortran codes using IRA
(on i686 and x86_64), and report back here with figures and reduced
testcases of eventual slow-downs. What is the current, stable way to
build an IRA compiler and run it? Should I just get the last revision
of the
The best way to test IRA is to build and use the branch. It is easy to
compare the old RA (which is the default on the branch) and IRA (-fira
option switches IRA on). I'd recommend to try the following option sets:
-fira
-fira -fira-algorithm=CB
OK, I've done that and I see a 40% to
FX wrote:
The best way to test IRA is to build and use the branch. It is easy to
compare the old RA (which is the default on the branch) and IRA (-fira
option switches IRA on). I'd recommend to try the following option sets:
-fira
-fira -fira-algorithm=CB
OK, I've done that and I
Yes, that is known problem for -O0. The old allocator does not use global
allocator at -O0, IRA is used always even for -O0. The correct comparison
would be at -O2.
Well, I guess it depends on what you understand by correct. I guess
to users, the correct comparison is whatever they are
(The testcase is 400k lines of preprocessed Fortran code, 16M is size,
available here:
http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz)
Thanks, I'll check it.
Vlad, I think you should also try to understand what does trunk do with
global (and without local allocation)
FX wrote:
The best way to test IRA is to build and use the branch. It is easy to
compare the old RA (which is the default on the branch) and IRA (-fira
option switches IRA on). I'd recommend to try the following option sets:
-fira
-fira -fira-algorithm=CB
OK, I've done that and I
On Thu, Apr 24, 2008 at 10:42:49AM -0400, Vladimir Makarov wrote:
FX wrote:
The best way to test IRA is to build and use the branch. It is easy to
compare the old RA (which is the default on the branch) and IRA (-fira
option switches IRA on). I'd recommend to try the following option sets:
Joe Buck wrote:
On Thu, Apr 24, 2008 at 10:42:49AM -0400, Vladimir Makarov wrote:
FX wrote:
The best way to test IRA is to build and use the branch. It is easy to
compare the old RA (which is the default on the branch) and IRA (-fira
option switches IRA on). I'd recommend to try the
On Thu, 2008-04-24 at 16:51 +0200, Paolo Bonzini wrote:
(The testcase is 400k lines of preprocessed Fortran code, 16M is size,
available here:
http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz)
Thanks, I'll check it.
Vlad, I think you should also try to understand
On Thu, 2008-04-24 at 16:33 -0500, Peter Bergner wrote:
On Thu, 2008-04-24 at 16:51 +0200, Paolo Bonzini wrote:
(The testcase is 400k lines of preprocessed Fortran code, 16M is size,
available here:
http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz)
Thanks,
Peter Bergner wrote:
On Thu, 2008-04-24 at 16:33 -0500, Peter Bergner wrote:
On Thu, 2008-04-24 at 16:51 +0200, Paolo Bonzini wrote:
(The testcase is 400k lines of preprocessed Fortran code, 16M is size,
available here:
http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz)
34 matches
Mail list logo
