> 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
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 th
> 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.
1350
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?
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
http://gcc.gnu.org/ml/gcc/2008-04/msg00730.h
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 week.
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
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
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
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 rang
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 ranges first (they are
ran
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,
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
wh
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 li
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 as
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
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
> >
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
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 Jacobo
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 no
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 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 l
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
Octobe
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)
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)
> > >>
> >
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
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 f
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 opti
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 se
(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)
> 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
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 se
> 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%
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 ir
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? Wh
35 matches
Mail list logo
