-
-
Notifications
You must be signed in to change notification settings - Fork 517
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
Remove all the bitset access from cython files in combinatorial polyhedron #30549
Comments
comment:1
It's a patch bomb, I know. If anyone knows a reasonable way around it, I'll do it. Currently, this is working again and I'm happy. And it's so much easier to do some something from then on. Most of the changes in the cython files are trivial (took me a while to figure out everything though). The current branch is a bit of regression with non-simple-non-simplicial polyhedra. It can take much longer. One thing is the unnecessary union of coatoms. Also the branch prediction seems to be bad, because one could know much earlier that the coatom check is useless. I'll think about a solution that works well. We waste a bit of memory by also allocating enough space for the coatoms in each case, but I wouldn't worry about it for now. In a worst case scenario this needs twice as much memory and much less in many scenarios that have less equal number of vertices/facets. Memory was never an issue for me, it was always time. |
comment:3
I'm happy with the ticket as it is. Using templates for the two algorithmic variants, the branch prediction has improved significantly. For extreme cases (see below), things got a bit slower. I don't know why. In a future ticket one can spare allocating the memory for the coatoms in case we are not using the simple/simplicial algorithm. It doesn't seem to make a difference in runtime. This is an example of slight slowdown:
This is 10 seconds faster on #30040. I could also play around with constants etc. This could also all be because the compiler ignores my Anyway, I can live with the slight slowdown for now, because the structure is so much better for further improvements. Any suggestions on how to improve things are welcome. |
comment:4
https://cython.readthedocs.io/en/latest/src/userguide/fusedtypes.html If this is better, I could move almost everything back to cython again. The only thing that really needs to be in C/C++ are those 4 functions that I want to optimize with intrinsics later on (there are going to be a few more, but they are all tiny).
in cython. However I don't know how the performance is, when you include critical |
comment:5
Also I'm happy with it now, the current status would force to move quite a lot of So for now this is a design proposal. |
Changed branch from u/gh-kliem/face_structure to u/gh-kliem/use_face_structure |
comment:6
I like it much better now. Timings with this ticket (branch (Note that I didn't apply new tricks to the algorithm. Only the data structure has changed.)
Timings on #30040:
So I would say that there is no performance-wise reason to reject the changes. The branch indicates a bit, how this could be split into seperate tickets that are doable to review. Last 10 new commits:
|
This comment has been minimized.
This comment has been minimized.
comment:9
I posted on sage devel on whether the proposed design is acceptable: |
comment:10
I am essentially happy with this ticket, but I want to wait and see what happens with the design discussion before going forward. |
This comment has been minimized.
This comment has been minimized.
Branch pushed to git repo; I updated commit sha1. This was a forced push. Last 10 new commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:17
Red branch. I'll fix it, once all the dependencies are in. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:21
Ok, this is back on needs review. Almost all dependencies are gone now. |
comment:22
LGTM. Hopefully this won't have any issues with other systems that some of the other tickets had. |
Reviewer: Travis Scrimshaw |
comment:23
Thank you. Yes, I think it is way more stable, as it just exposes bitsets, which has been working for a while now. I just didn't think, the intermediate solutions to the end. |
Changed branch from u/gh-kliem/use_face_structure to |
This goal of this ticket is to use
data_structures/biteset.pxi
for the bitset stuff in combinatorial polyhedron and cleanly seperate algorithm and data structure.This ticket is mostly resolved in smaller tickets:
Changes are:
src/sage/data_structures/bitset_intrinsics.h
). (See Enable SIMD-instructions for Bitsets #27103 and Compile with -march=native #27122.)bitset.pxi
for fuzed types fuzed types, such that an (yet to be enriched) bitset data structure specialized for combinatorial faces can use it.bitset.pxi
tobitset_base.pxd
.face_s
that gathers properties of a face and corresponding functions.face_list_s
that gathers properties of a list of faces and corresponding functions.The features of those changes are mainly:
face_s
without changing all our code.Depends on #30529
CC: @jplab @LaisRast @tscrim
Component: geometry
Keywords: combinatorial polyhedron, bitsets
Author: Jonathan Kliem
Branch/Commit:
82a747d
Reviewer: Travis Scrimshaw
Issue created by migration from https://trac.sagemath.org/ticket/30549
The text was updated successfully, but these errors were encountered: