[Bug middle-end/114563] ggc_internal_alloc is slow

2025-04-01 Thread rguenther at suse dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 --- Comment #15 from rguenther at suse dot de --- On Tue, 1 Apr 2025, ak at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 > > ak at gcc dot gnu.org changed: > >What|Removed |A

[Bug middle-end/114563] ggc_internal_alloc is slow

2025-04-01 Thread ak at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 --- Comment #14 from ak at gcc dot gnu.org --- >to do this for entry_size < G.pagesize * GGC_QUIRE_SIZE, this should >avoid fragmenting the virtual address space. Possibly do this only >for USING_MADVISE, not sure. Okay let me test that.

[Bug middle-end/114563] ggc_internal_alloc is slow

2025-04-01 Thread ak at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 ak at gcc dot gnu.org changed: What|Removed |Added CC||ak at gcc dot gnu.org --- Commen

[Bug middle-end/114563] ggc_internal_alloc is slow

2025-04-01 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 --- Comment #12 from Richard Biener --- (In reply to andi from comment #8) > > > Needs a workload where it matters > > > > PR119387 had > > > > 85.81% 1500713 cc1plus cc1plus [.] > > ggc_internal_alloc(un > > > > for m

[Bug middle-end/114563] ggc_internal_alloc is slow

2025-04-01 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 --- Comment #11 from Richard Biener --- (In reply to Andi Kleen from comment #10) > It doesn't really help for the PR119387 test case, perhaps not surprising > because it optimizes freeing not allocation: > > Summary > ./gcc/cc1plus-opt -w -s

[Bug middle-end/114563] ggc_internal_alloc is slow

2025-03-28 Thread andi-gcc at firstfloor dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 --- Comment #10 from Andi Kleen --- It doesn't really help for the PR119387 test case, perhaps not surprising because it optimizes freeing not allocation: Summary ./gcc/cc1plus-opt -w -std=c++20 ~/gcc/git/tsrc/119387-formatted.ii -quiet ran

[Bug middle-end/114563] ggc_internal_alloc is slow

2025-03-28 Thread andi-gcc at firstfloor dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 Andi Kleen changed: What|Removed |Added Attachment #60907|0 |1 is obsolete|

[Bug middle-end/114563] ggc_internal_alloc is slow

2025-03-28 Thread andi at firstfloor dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 --- Comment #8 from andi at firstfloor dot org --- > > Needs a workload where it matters > > PR119387 had > > 85.81% 1500713 cc1plus cc1plus [.] > ggc_internal_alloc(un > > for me. Can we keep an index to freelist from

[Bug middle-end/114563] ggc_internal_alloc is slow

2025-03-28 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 --- Comment #7 from Richard Biener --- (In reply to Andi Kleen from comment #6) > Created attachment 60907 [details] > patch for multiple free lists in ggc-page > > I saw it in some profile, but later trying didn't help anymore. > > Needs a wo

[Bug middle-end/114563] ggc_internal_alloc is slow

2025-03-28 Thread andi-gcc at firstfloor dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 --- Comment #6 from Andi Kleen --- Created attachment 60907 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60907&action=edit patch for multiple free lists in ggc-page I saw it in some profile, but later trying didn't help anymore. Needs

[Bug middle-end/114563] ggc_internal_alloc is slow

2024-04-03 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 --- Comment #5 from Richard Biener --- Btw, I'd say for the sake of avoiding virtual memory fragmentation free_unit should be equal to GGC_QUIRE_SIZE. But we should possibly merge adjacent entries we don't free to power-of-two chunks and possib

[Bug middle-end/114563] ggc_internal_alloc is slow

2024-04-03 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 --- Comment #4 from Richard Biener --- Created attachment 57858 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57858&action=edit better release_pages Ah, and it's not so much fragmentation but large free_unit (1MB) that's hard to get to.

[Bug middle-end/114563] ggc_internal_alloc is slow

2024-04-03 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 --- Comment #3 from Richard Biener --- Created attachment 57856 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57856&action=edit quick skip-list patch Before: > /usr/bin/time ./cc1plus -quiet -o /dev/null /tmp/a-test-poly.ii -O 173.29use

[Bug middle-end/114563] ggc_internal_alloc is slow

2024-04-03 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #

[Bug middle-end/114563] ggc_internal_alloc is slow

2024-04-02 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563 Richard Biener changed: What|Removed |Added Keywords||compile-time-hog See Also|