This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Simple Value Range Propagation


Hello,

> > > > Josef, could you please try whether there is some change in compile-time
> > > > performance if you include either my fibheap speedup patch
> > > > http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00698.html or use the
> > > > simple heaps from
> > > > http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01569.html?
> > > 
> > >                           insn-attrtab.c   combine.c
> > > total time (-O2)          ~ 20 s           ~ 5.5 s
> > > VRP + current fibheap     0.30 s           0.09 s
> > > VRP + speedup fibheap     0.27 s           0.07 s
> > > VRP + normal heap         0.23 s           0.06 s
> > 
> > OK, seems that there is still some space for speedup in fibheap,
> 
> Maybe support for other allocator than calloc (for example alloc-pool.c)
> would help. Allocation of each node is what heap.c does not do so
> speeding up allocation might help to speed up fibheap.c.

not really; the measurements I have done for df.c claim
                0.03    0.85  384460/405950      fibheap_extract_min
                0.02    0.08  384460/405950      fibheap_insert

while for simple heaps
                0.03    0.00  384460/384460      heap_extract_min
                0.02    0.00  384460/384460      heap_insert

note that there is no allocation done in fibheap_extract_min, so
improving the allocation in fibheap_insert would not help much (although
of course it would be better to use xmalloc there instead of xcalloc,
given that we initialize all fields then anyway).

Zdenek

> > if we want to have them at least comparable with ordinary heaps.
> > Daniel, any idea?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]