more performant rust implementations.

[NailLegProcessorDivide]

• [x] Figure out what to do with the readme, currently just concat
• [x] Implement polycube converters between reps and pass iterators for cache files to enumeration functions
• [x] Support exporting to cache files from new implementations
• [x] Give feedback to show progress running computation

Done: Add -m mode flag to determine enumeration algo Support -p parallel disable flag for point-list mode

Create polycube_reps file which stores poly cube representations used my my code, I dont Like that its a separate file from existing PolyCube rep but I cant think of how to group it more cleanly

[datdenkikniet]

These implementations really are awesomely fast :D

I'm working on making accessing a pcube file a bit easier over in #21, FYI! You can cherry-pick or copy paste stuff from there for the time being if you feel like it.

Also renamed PolyCube to NaivePolyCube so that it's a bit clearer that it is not the be-all-end-all PolyCube.

[datdenkikniet]

Oooh, this manages to calculate N = 14 using ~61 GB of memory! Ran it on a machine with two E5-2630 v3s and 96 GB of ram.

Command output

Emphasis mine ``` # cargo rustc --release --features size16 --bin opencubes -- -C target-cpu=native /usr/bin/time -v ./target/release/opencubes enumerate -m point-list --no-cache 14 Found 2 unique polycube(s) at n = 3 seeds_len 2 Elapsed time: 0.001485s Found 8 unique polycube(s) at n = 4 seeds_len 4 Elapsed time: 0.002222s Found 29 unique polycube(s) at n = 5 seeds_len 7 Elapsed time: 0.002992s Found 166 unique polycube(s) at n = 6 seeds_len 12 Elapsed time: 0.004297s Found 1023 unique polycube(s) at n = 7 seeds_len 25 Elapsed time: 0.007509s Found 6922 unique polycube(s) at n = 8 seeds_len 43 Elapsed time: 0.016611s Found 48311 unique polycube(s) at n = 9 seeds_len 73 Elapsed time: 0.049479s Found 346543 unique polycube(s) at n = 10 seeds_len 119 Elapsed time: 0.254230s Found 2522522 unique polycube(s) at n = 11 seeds_len 190 Elapsed time: 2.068149s Found 18598427 unique polycube(s) at n = 12 seeds_len 289 Elapsed time: 16.979628s Found 138462649 unique polycube(s) at n = 13 seeds_len 426 Elapsed time: 147.701935s ^[[CFound 1039496297 unique polycube(s) at n = 14 seeds_len 614 Elapsed time: 984.920787s Unique polycubes found for N = 14: 1039496297. Duration: 988700 ms Command being timed: "./target/release/opencubes enumerate -m point-list --no-cache 14" User time (seconds): 8074.51 System time (seconds): 401.90 Percent of CPU this job got: 857% Elapsed (wall clock) time (h:mm:ss or m:ss): 16:28.86 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): **61365560** Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 4 Minor (reclaiming a frame) page faults: 91024483 Voluntary context switches: 50390232 Involuntary context switches: 53659 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 ```

[NailLegProcessorDivide]

Awesome to see n=14 done Im slightly supprised the memory was so low considering I didnt think I improved the data size that much from something that ran out of memory after N=12 on my 32GB of ram.

One "flaw" in my implementations is they are hard coded to have the data structures statically sized to only work for n<=16 to keep accesses as fast as possible and reduce both heap usage and fragmentation so I should get around to adding checks for that before trying to launch an panicing if anyone gets there with one of them.

If there is a way of making a hashset of N u16s that are dynamic over the life of the program but static to a hashmap I think it would also be a small step but ultimately still far from getting up to N=16 or more.

[NailLegProcessorDivide]

Is there a way to implement Into for structs in different modules?

I implemented map_pos_to_naive and naive_to_map_pos for now but if I can do it in a more rusty way then it would be nice. I tried From but it seemed like it didnt like it or maybe I just didnt understand the issue.

[datdenkikniet]

Wdym? Generally you want to implement From<X> for Y. That automatically implements Into<Y> for X by reverse (see From).

As a note, I think converting from/to RawPCube is what we should be aiming for for all reprs, since that is the "easiest" and most portable version of a polycube. For all other things we could then just do ThirdRepr::from(RawPCube::from(some_repr)). That was my plan, at least, but having multiple impls works well too, of course :)

[NailLegProcessorDivide]

accidentally closed trying to rebase on main, I feel like this is in a good place to merge

[datdenkikniet]

Woops, before we get this in: could you cargo fmt :)

[NailLegProcessorDivide]

I could have sworn I did. Do you have a specific config? checking out the branch again and running cargo fmt in the rust/ folder also doesnt show any changes in git for me

[NailLegProcessorDivide]

and intentionally messing stuff up a bit and re running show unstaged changes that go away again after formatting

[datdenkikniet]

My bad, I had checked out the wrong main. It's formatted already!

[datdenkikniet]

@bertie2 if you're available for a review/to merge this, it would be appreciated! It looks good to me, and I think @NailLegProcessorDivide was happy with it as well

[NailLegProcessorDivide]

Yes, if you could review and merge that would be great!