Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move MarkBag* funcs into GCs so they can inline MarkBag #3840

Merged
merged 1 commit into from
Jan 10, 2020

Conversation

ChrisJefferson
Copy link
Contributor

@ChrisJefferson ChrisJefferson commented Jan 9, 2020

While tracking down a slowness, I found that splitting functions involved in marking bags between different files created a significant slowdown in gasman. This patch pulls these functions into a header which should be included into each GC. I'm not totally happy with how this is done, but it feels like the best way to do things without duplicating code.

The ".inc" extension is something I've used in other systems for headers which must only be included in one file. I'm open to alternative suggestions. Another (horrible) option would be to put this stuff into gasman.h, guarded by a macro (IN_GC?), which would be #defined in each GC file...

On master:

gap> l := List([1..10000], x -> ListWithIdenticalEntries(10000, 0));; # make some stuff
gap> GASMAN("collect");
gap> time;
649
gap> GASMAN("collect");
gap> time;
501
gap> GASMAN("collect");
gap> time;
453

With this patch:

gap> l := List([1..10000], x -> ListWithIdenticalEntries(10000, 0));; # make some stuff
gap> GASMAN("collect");
gap> time;
396
gap> GASMAN("collect");
gap> time;
273
gap> GASMAN("collect");
gap> time;
295

@ChrisJefferson
Copy link
Contributor Author

I am aware this needs some cleaning up, but I'm interested on opinions on the general layout (in particular having the Inc file at all)

@fingolfin
Copy link
Member

Wow, that's massive. And my fault, I guess (never expect inlining to be so vital in this case, but I should have measured back then sigh).

I am not "hot" for those .inc files, but I don't really see a better alternative. Of course we could also just return to the old way and duplicate the code to each of the three GC implementations. Honestly, both of these options seem equally appealing to me.

@fingolfin fingolfin added topic: kernel topic: performance bugs or enhancements related to performance (improvements or regressions) labels Jan 9, 2020
src/bags_funcs.inc Outdated Show resolved Hide resolved
src/bags_funcs.inc Outdated Show resolved Hide resolved
src/julia_gc.c Outdated Show resolved Hide resolved
@fingolfin fingolfin added the kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements label Jan 9, 2020
@fingolfin
Copy link
Member

I just checked, and luckily, this regression is not present in GAP 4.10, but of course it is present in the (as of yet unreleased) GAP 4.11. As such, I'd like to backport this to GAP 4.11, if possible (CC @alex-konovalov).

@coveralls
Copy link

Coverage Status

Coverage increased (+0.0003%) to 84.728% when pulling 34eedc4 on ChrisJefferson:inline-mark into db5b45d on gap-system:master.

@fingolfin fingolfin merged commit 26bf15a into gap-system:master Jan 10, 2020
@fingolfin
Copy link
Member

Backported in 8b3ec23

@ChrisJefferson ChrisJefferson deleted the inline-mark branch February 15, 2021 14:40
@ThomasBreuer ThomasBreuer self-assigned this Feb 17, 2021
@ThomasBreuer ThomasBreuer added the release notes: added PRs introducing changes that have since been mentioned in the release notes label Feb 17, 2021
@ThomasBreuer ThomasBreuer removed their assignment Feb 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport-to-4.11-DONE kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements release notes: added PRs introducing changes that have since been mentioned in the release notes topic: kernel topic: performance bugs or enhancements related to performance (improvements or regressions)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants