Moosey wrote:Having just gotten apgluxe, what command would I run to search b3-ck4e5k6is2-in35i6c8? (I use #anon)
When I try it just searches life.
Code: Select all
./apgsearch --rule b3-ck4e5k6is2-in35i6c8
Moosey wrote:Having just gotten apgluxe, what command would I run to search b3-ck4e5k6is2-in35i6c8? (I use #anon)
When I try it just searches life.
Code: Select all
./apgsearch --rule b3-ck4e5k6is2-in35i6c8
Code: Select all
Soup l_AJQCF42zWA9r22377175 lasts an estimated 31740 generations; rerunning...
Soup l_AJQCF42zWA9r22377175 actually lasts 303 generations.
(unrelated)
Soup l_AJQCF42zWA9r7066009 lasts an estimated 31740 generations; rerunning...
Soup l_AJQCF42zWA9r7066009 actually lasts 335 generations.
It's just a coincidence that particular number appeared twice. The overestimation is connected with the period-8/period-12 checking calcyman just mentioned, and tends to occur when there are p8 oscillators in the soup (for the version that checked at p8, anyway; I assume v4.98 would've done that with p12 oscillators). v4.981 might be able to avoid that entirely (I haven't tested it yet).Moosey wrote:This has already been observed, but:Why's it like 31740 so much?Code: Select all
Soup l_AJQCF42zWA9r22377175 lasts an estimated 31740 generations; rerunning... Soup l_AJQCF42zWA9r22377175 actually lasts 303 generations. (unrelated) Soup l_AJQCF42zWA9r7066009 lasts an estimated 31740 generations; rerunning... Soup l_AJQCF42zWA9r7066009 actually lasts 335 generations.
With v4.981:77topaz wrote:Okay, I have something both confusing and concerning to report: a major speed decrease in at least some rules between v4.972 and v4.98. Specifically, for b35s2467/C1, v4.972 averaged about 55000-60000 soups/sec/core and and about 81.9 tiles/soup. However, with v4.98, the speed nearly halves to 30000 soups/sec/core with around 226 tiles/soup.
However, for another rule, b2cei3aekqr4aijkny5cky6-ai78s02ai3jknq4jtyz5-acjy6-an7e/C1, there is a speed increase from around 1200-1300 soups/sec/core to 1600-1700 soups/sec/core, with the tile rate going from around 3800 tiles/soup to 2100 tiles/soup (there is a lot more variation with this rule compared to b35s2467/C1).
As a third reference point, b2k3acijr4ijqy6i7cs2aek3ijnqr4it5n/C1 goes from ~240000 tiles/soup... to around ~240000 tiles/soup, so that appears to be unaffected.
As a fourth reference point, b3-ekqr4nt5r6is02-c3/C1 goes from 4800-4900 soups/sec/core and ~490 tiles/soup to around 3800-3900 soups/sec/core and ~660 tiles/soup, another major slowdown.
Is a correction of one part in 2^18 really expected to cause such huge changes, or is something else going on here?
Data structures used by lifelib. See also the article on Life128 and vlife.Rhombic wrote:What does "tiles" refer to?
Code: Select all
./apgluxe -k (key) --rule b3-ck4e5k6is2-in35i6c8 --symmetry C1
Moosey wrote:what command do I use for the number of soups per haul?
Say I'm usingCode: Select all
./apgluxe -k (key) --rule b3-ck4e5k6is2-in35i6c8 --symmetry C1
Code: Select all
./apgluxe -k (key) --rule b3-ck4e5k6is2-in35i6c8 --symmetry C1 -n 1048576
Moosey wrote:Having just gotten apgluxe, what command would I run to search b3-ck4e5k6is2-in35i6c8? (I use #anon)
When I try it just searches life.
@Moosey, standard practice is to check any coding project like this for a README, read through it carefully, and then ask these kinds of questions if the answers aren't where they should be. But in this case it seems like they are.Moosey wrote:what command do I use for the number of soups per haul?
Say I'm usingCode: Select all
./apgluxe -k (key) --rule b3-ck4e5k6is2-in35i6c8 --symmetry C1
It's occurred to me that this bug would only occur when there's a horizontal line of at least 18 live cells. The p544 in this phase (which is the generation in which the bug occurred) has that property:wildmyron wrote:Thanks for fixing this. I would never have guessed it would be a fencepost error but I'm glad you were able to debug so quickly. I can confirm that my updated apgluxe does indeed correctly detect the p544 in both orientations.
Code: Select all
x = 41, y = 15, rule = B2cik3aeiq4aeijnr5cejy6-ak7c/S02-ak3ace4cekqrz5ainqy6cn8
20bo$7bo25bo$6bo27bo$5b2o27b2o$4b2ob2o6bo4bo4bo6b2ob2o$3b2o2bobo4bobo
2bobo2bobo4bobo2b2o$4bo3bob2ob5o2bo2b5ob2obo3bo$5ob29ob5o$4bo3bob2ob5o
2bo2b5ob2obo3bo$3b2o2bobo4bobo2bobo2bobo4bobo2b2o$4b2ob2o6bo4bo4bo6b2o
b2o$5b2o27b2o$6bo27bo$7bo25bo$20bo!
Code: Select all
x = 7, y = 5, rule = B3/S23
3ob3o$2bobobo$2bob3o$2bobobo$2bob3o!
I believe that's right. At T=30 the population is only 20, not 24.testitemqlstudop wrote:SoupSearcher::methudetect reports that this:lasts 31 generations instead of 32. Is it because it checks for population periodicity instead of pattern periodicity? If so, why doesn't it say 30...?Code: Select all
x = 7, y = 5, rule = B3/S23 3ob3o$2bobobo$2bob3o$2bobobo$2bob3o!
ah yes, me not realizing the top empty spotsdvgrn wrote:I believe that's right. At T=30 the population is only 20, not 24.testitemqlstudop wrote:SoupSearcher::methudetect reports that this:lasts 31 generations instead of 32. Is it because it checks for population periodicity instead of pattern periodicity? If so, why doesn't it say 30...?Code: Select all
x = 7, y = 5, rule = B3/S23 3ob3o$2bobobo$2bob3o$2bobobo$2bob3o!
Code: Select all
// Disable verification by default if running on a HPC;
// otherwise verify three hauls per uploaded haul:
if (verifications < 0) {
verifications = (parallelisation <= 4) ? 5 : 0;
}
Verifications are done sequentially, not in parallel. As such, if you have many cores, they'd be under-utilised if verifications were enabled by default. (You can enable this by setting -v 5 in the command-line arguments.)tod222 wrote:Why have this? Why shouldn't high-performance computers do verifications? With the increase in CPU cores these days many more computers fall into the HPC category as defined above.Code: Select all
// Disable verification by default if running on a HPC; // otherwise verify three hauls per uploaded haul: if (verifications < 0) { verifications = (parallelisation <= 4) ? 5 : 0; }
It means that most of the time my instances of apgluxe aren't doing verifications.
I suspect you probably worked out the answer to this - assuming it stopped showing up after you switched to v4.98 - but in light of calcyman's comments about how the bug in lifelib was triggered I examined the p3410 and found it does indeed have a phase with a continuous line of > 18 cells:Macbi wrote:I'm not sure if this is the same bug, but this p3410 is being stored under two apgcodes.
Code: Select all
x = 19, y = 27, rule = B2-ae3aeiq4jnw5ak6-ae7e8/S02-ak3eq4ceqryz5-aejq6-ei7e8
9bo4$8bobo$9bo$8b3o$8b3o$6bo5bo$9bo$2b2o2bo2bo2bo2b2o$bo2bo2b5o2bo2bo$
5b2ob3ob2o$19o$5b2ob3ob2o$bo2bo2b5o2bo2bo$2b2o2bo2bo2bo2b2o$9bo$6bo5bo
$8b3o$8b3o$9bo$8bobo4$9bo!
I just finished a patch which adds signal handling so that parallel apgluxe will exit gracefully in response to several signals. I typically run it with nice and in the background and wanted the quick graceful exit capability.wildmyron wrote:As 77topaz mentioned, there are cases where this won't work - in particular if the -p option for running in parallel was used.dvgrn wrote:If you're using Cygwin or you're on Linux or Mac (anything POSIX, apparently), then type "q" and wait some number of seconds. Your partial haul will be submitted and the search will exit gracefully.Moosey wrote:stupid question:
How do you end a search prematurely?
I've found that verifications are so quick that the idle cores aren't worth worrying about, at least for Conway's Life, which is all I run. I'll be changing to using -v 5 on my runs.calcyman wrote: Verifications are done sequentially, not in parallel. As such, if you have many cores, they'd be under-utilised if verifications were enabled by default. (You can enable this by setting -v 5 in the command-line arguments.)
Code: Select all
g++ -c -Wall -Wextra -pedantic -O3 -pthread -flto -march=native --std=c++11 -funsafe-loop-optimizations -Wunsafe-loop-optimizations -fprofile-use -fprofile-correction main.cpp -o main.o
clang: warning: optimization flag '-funsafe-loop-optimizations' is not supported [-Wignored-optimization-argument]
clang: warning: optimization flag '-fprofile-correction' is not supported [-Wignored-optimization-argument]
warning: unknown warning option '-Wunsafe-loop-optimizations'; did you mean
'-Wunavailable-declarations'? [-Wunknown-warning-option]
error: Could not read profile default.profdata: No such file or directory
1 warning and 1 error generated.
make: *** [main.o] Error 1
I think it's worth clarifying here that you do not have gcc on MacOS by default - Apple use a shim named gcc which links to the clang/llvm toolchain to simplify building projects which assume gcc will be used as the compiler. This evidently leads to a lot of confusion..77topaz wrote:I have gcc - it even appears in the top line of the error I posted. apgsearch just decides to use clang for part of it for some reason. But anyway, via a Discord discussion calcyman rewrote the profiling code so it now also works with clang.
However, I'm not really observing a speedup when using it.
Code: Select all
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
You can use clang now (commit bc9f3afa) with profiling; I made some makefile changes to locate the tool llvm-profdata and run it in 'merge' mode to create the profile. It emits lots of warnings, though, so I don't know how effective it is.testitemqlstudop wrote:I tested with clang myself, you can't use profiling with clang (it has weird profiler outputs.)
Well, it would still help on SSE/AVX1 (the rewritten code targets AVX2/AVX-512, and falls back to the loop otherwise). And there might be other places where automatic vectorisation helps.The only reason to use clang is for its loop unrolling and vectorization, which is unnecessary after calcyman's rewrite of the upattern movement code.