apgsearch v4.0
- cordership3
- Posts: 129
- Joined: August 23rd, 2016, 8:53 am
- Location: Smome tomato
- Contact:
Re: apgsearch v4.0
Does apgsearch support non-totalistic B0 rules, and if not, could this be implemented using the B0 and non-totalistic algorithms?
evil twin of cordership2
Re: apgsearch v4.0
What's the syntax?calcyman wrote:I've also added multistate HROT rules.
LifeViewer https://lazyslug.com/lifeviewer
Re: apgsearch v4.0
All of the syntaxes are listed here:rowett wrote:What's the syntax?calcyman wrote:I've also added multistate HROT rules.
https://gitlab.com/apgoucher/lifelib/bl ... nuslist.py
The relevant one is 'Generations Higher-Range Outer-Totalistic':
Code: Select all
{'name': 'ghrot', 'regex': 'g[1-9][0-9]*r[2345]b[0-9a-f]*s[0-9a-f]*z?'}
What do you do with ill crystallographers? Take them to the mono-clinic!
Re: apgsearch v4.0
Excellent, thanks.calcyman wrote:All of the syntaxes are listed here:
https://gitlab.com/apgoucher/lifelib/bl ... nuslist.py
Do you have plans to support von Neumann and Circular neighbourhoods for ltl, gltl, hrot and ghrot?
LifeViewer https://lazyslug.com/lifeviewer
Re: apgsearch v4.0
Minor suggestion: if apgsearch can figure out the canonical rule from an incorrectly entered rulestring, why not make apgsearch run using said rulestring instead of prompting the user to reenter it?
Last edited by muzik on January 7th, 2019, 9:35 am, edited 1 time in total.
Help wanted: How can we accurately notate any 1D replicator?
- Apple Bottom
- Posts: 1034
- Joined: July 27th, 2015, 2:06 pm
- Contact:
Re: apgsearch v4.0
Another minor suggestion: why not send a patch (better yet, Gitlab pull request) to do exactly that?muzik wrote:Minor suggestion: if apgsearch can figure out the canonical rule from an incorrectly entered rulestring, why not make apgsearch run using said rukestring instead of prompting the user to reenter it?
If you speak, your speech must be better than your silence would have been. — Arabian proverb
Catagolue: Apple Bottom • Life Wiki: Apple Bottom • Twitter: @_AppleBottom_
Proud member of the Pattern Raiders!
Catagolue: Apple Bottom • Life Wiki: Apple Bottom • Twitter: @_AppleBottom_
Proud member of the Pattern Raiders!
Re: apgsearch v4.0
Because I'd rather pitch the idea to the community to get their opinions on the idea first. Also, I amn't currently able to put in so much effort to understand how every last bit of how apgluxe works to program in such an admittedly trivial modification, due to external pressures. Can you please stop making these posts? I don't find them helpful in the slightest.Apple Bottom wrote:Another minor suggestion: why not send a patch (better yet, Gitlab pull request) to do exactly that?muzik wrote:Minor suggestion: if apgsearch can figure out the canonical rule from an incorrectly entered rulestring, why not make apgsearch run using said rukestring instead of prompting the user to reenter it?
----
Might as well bring this up: it seems as though object separation also seems to be splitting up legitimate objects, like what appears to be a non-trivial (but boring) p60 in D12:
https://catagolue.appspot.com/object/xp ... k2ha/b2s3h
Currently catagolue doesn't provide D12 soups properly (and I'm not at home so I can't generate the correct soup) so I can't verify that this is some weird coincidence where multiple of these oscillators come out, but judging by the symmetry this oscillator appears to would have had I can only assume that this one is an erroneous separation.
Help wanted: How can we accurately notate any 1D replicator?
Re: apgsearch v4.0
I think muzik is suggesting that instead of erroring out on an input where apgluxe in fact "knows perfectly well" what the intended rule is, e.g.,muzik wrote:Because I'd rather pitch the idea to the community to get their opinions on the idea first. Also, I amn't currently able to put in so much effort to understand how every last bit of how apgluxe works to program in such an admittedly trivial modification, due to external pressures.
Code: Select all
$ ./apgluxe --rule B3/S23
apgluxe v4.72-ll2.0.27: Rule b3s23 does not match desired rule B3/S23.
...
ValueError: Rule "B3/S23" does not belong to any genus
My personal opinion is that apgluxe is just fine the way it is. Refusing to run on bad input is a good way to train people what the expected input is. More important, it avoids the whole problem of correcting a genuine typo to something the user didn't actually intend, and then wasting time running the wrong rule. So it's not entirely clear that a Gitlab pull request with this change would be accepted anyway.
The error message could certainly be made a little clearer, though, and that seems like a very reasonable pull request to put together:
Code: Select all
apgluxe v4.72-ll2.0.27: Canonical form does not match desired rule B3/S23. Suggestion: re-run with canonical rule form 'b3s23'.
Heh. Pot, meet kettle: I think Apple Bottom has responded to some of your previous feature-request posts in what might as well have been exactly the same words.muzik wrote:Can you please stop making these posts? I don't find them helpful in the slightest.
Here my two cents is that you both have a point: yes, endless or repeated feature requests can be annoying, if they're vague / not well thought out / seem to expect other people to do a lot of work for no reason the poster bothers to explain. But attempts to control uncontrollable enthusiasm also sometimes tend to reduce the signal-to-noise ratio.
-- Guess I'm still recommending the good old standard method of "everybody just ignore uninteresting stuff". It may be a bit rude, but it works pretty well, and like yoga it gets easier with practice and works whether you believe in it or not.
- Apple Bottom
- Posts: 1034
- Joined: July 27th, 2015, 2:06 pm
- Contact:
Re: apgsearch v4.0
Then perhaps you'll understand that I feel the same way about yours.muzik wrote:Can you please stop making these posts? I don't find them helpful in the slightest.
And between the two of us I think you're the one who's posting much more; it feels like anytime I get a notification that a thread has a new reply, there's a pretty good chance it'll be "how about X", "will we ever see Y", "suggestion: Z", and so on. I'd not find it so annoying if there was a way to filter these notification mails, but the forum does not seem to offer such a feature. (The emails sent out also do not include such things as the reply, the user replying, etc., so I cannot filter them based on that.)
But fair enough, I'll stop. You're clearly getting the message; unfortunately you're not getting the message.
Wise words. I'll do my best to get better at this, just ignore those posts, and generally try to be a bit more mellow.dvgrn wrote:Here my two cents is that you both have a point: yes, endless or repeated feature requests can be annoying, if they're vague / not well thought out / seem to expect other people to do a lot of work for no reason the poster bothers to explain. But attempts to control uncontrollable enthusiasm also sometimes tend to reduce the signal-to-noise ratio.
-- Guess I'm still recommending the good old standard method of "everybody just ignore uninteresting stuff". It may be a bit rude, but it works pretty well, and like yoga it gets easier with practice and works whether you believe in it or not.
If you speak, your speech must be better than your silence would have been. — Arabian proverb
Catagolue: Apple Bottom • Life Wiki: Apple Bottom • Twitter: @_AppleBottom_
Proud member of the Pattern Raiders!
Catagolue: Apple Bottom • Life Wiki: Apple Bottom • Twitter: @_AppleBottom_
Proud member of the Pattern Raiders!
Re: apgsearch v4.0
my opinion is that both of these posts are unhelpful
Apple Bottom (although it may not apply to this instance): 'Just lrn2program lol' is rich coming from someone with years of programming experience, but it can take years to master something like modifying apgsearch. Even I dont know how to do that right, as evidenced by the one custom symmetry I've submitted.
However, feature requests can also be a bit of a pain, as I can attest... but they can be helpful in reasonably sized amounts.
I don't feel ill will towards either side but both are wrong in a way. I also won't act like some of MY behaviours get annoying. (Mood swings and lack of patience are a perfect example personally)
Now I'll go back into my glass house...
Apple Bottom (although it may not apply to this instance): 'Just lrn2program lol' is rich coming from someone with years of programming experience, but it can take years to master something like modifying apgsearch. Even I dont know how to do that right, as evidenced by the one custom symmetry I've submitted.
However, feature requests can also be a bit of a pain, as I can attest... but they can be helpful in reasonably sized amounts.
I don't feel ill will towards either side but both are wrong in a way. I also won't act like some of MY behaviours get annoying. (Mood swings and lack of patience are a perfect example personally)
Now I'll go back into my glass house...
- benetnasch85
- Posts: 31
- Joined: March 17th, 2017, 12:09 am
Re: apgsearch v4.0
b3s23/C1 runs more slowly in v4.82-ll2.1.5 than in v4.72-ll2.0.27 under cygwin on our AVX1 machine. You can compare my hauls with these total numbeers of soups:
5700001 v4.72-ll2.0.27
5700002 v4.72-ll2.0.27
5700003 v4.82-ll2.1.5
5700001 v4.72-ll2.0.27
5700002 v4.72-ll2.0.27
5700003 v4.82-ll2.1.5
Re: apgsearch v4.0
So it looks like v4.82-ll2.1.5 is at most 2% slower than v4.72-ll2.0.27 -- the 5700003 has only lagged by 10 minutes against the others over a period of 9 hours.benetnasch85 wrote:b3s23/C1 runs more slowly in v4.82-ll2.1.5 than in v4.72-ll2.0.27 under cygwin on our AVX1 machine. You can compare my hauls with these total numbeers of soups:
5700001 v4.72-ll2.0.27
5700002 v4.72-ll2.0.27
5700003 v4.82-ll2.1.5
It might be due to me correcting the method of determining populations of still-lifes:https://gitlab.com/apgoucher/lifelib/co ... 50efe401e3
I'll have to run perf before and after to see whether this is the case.
What do you do with ill crystallographers? Take them to the mono-clinic!
Re: apgsearch v4.0
Perf using latest version:
Perf with 1-line change to use flatlayer(0) population count:
This suggests that the old (2-state-specific) method was slightly faster (in terms of time, cycles, and branch misses), but it should only make a 0.3% difference rather than the 2% observed empirically in your hauls.
Code: Select all
$ perf stat ./apgluxe -n 1000000 -t 1 -v 0 -s test
Greetings, this is apgluxe v4.82-ll2.1.5, configured for b3s23/C1.
Lifelib version: ll2.1.5
Compiler version: 5.4.0 20160609
Python version: '2.7.12 (default, Nov 12 2018, 14:36:49) [GCC 5.4.0 20160609]'
Using seed test
Running 1000000 soups per haul:
Instruction set AVX-512 detected
b3s23/C1: 56349 soups completed (5634.450 soups/second current, 5634.450 overall).
b3s23/C1: 114513 soups completed (5816.356 soups/second current, 5725.392 overall).
b3s23/C1: 172574 soups completed (5806.087 soups/second current, 5752.287 overall).
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Soup test216747 lasts an estimated 740 generations; rerunning...
Soup test216747 actually lasts 637 generations.
b3s23/C1: 229927 soups completed (5735.146 soups/second current, 5748.000 overall).
b3s23/C1: 288338 soups completed (5841.098 soups/second current, 5766.618 overall).
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
b3s23/C1: 345489 soups completed (5715.045 soups/second current, 5758.021 overall).
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
b3s23/C1: 403149 soups completed (5765.305 soups/second current, 5759.061 overall).
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
b3s23/C1: 461350 soups completed (5819.723 soups/second current, 5766.643 overall).
b3s23/C1: 518840 soups completed (5748.872 soups/second current, 5764.667 overall).
b3s23/C1: 576851 soups completed (5800.761 soups/second current, 5768.276 overall).
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Rare oscillator detected: xp8_gk2gb3z11
b3s23/C1: 634259 soups completed (5740.787 soups/second current, 5765.776 overall).
b3s23/C1: 691416 soups completed (5715.575 soups/second current, 5761.592 overall).
b3s23/C1: 750053 soups completed (5863.453 soups/second current, 5769.427 overall).
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
b3s23/C1: 807875 soups completed (5782.172 soups/second current, 5770.337 overall).
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
b3s23/C1: 866358 soups completed (5847.104 soups/second current, 5775.455 overall).
b3s23/C1: 924960 soups completed (5860.183 soups/second current, 5780.750 overall).
b3s23/C1: 982874 soups completed (5791.004 soups/second current, 5781.353 overall).
b3s23/C1: 1000000 soups completed (5846.143 soups/second current, 5782.450 overall).
----------------------------------------------------------------------
1000000 soups completed.
Attempting to contact payosha256.
testing mode
testing
Connection was successful; starting new search...
----------------------------------------------------------------------
Performance counter stats for './apgluxe -n 1000000 -t 1 -v 0 -s test':
172937.817757 task-clock (msec) # 1.000 CPUs utilized
173 context-switches # 0.001 K/sec
0 cpu-migrations # 0.000 K/sec
111,510 page-faults # 0.645 K/sec
569,519,099,179 cycles # 3.293 GHz
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
1,060,872,804,196 instructions # 1.86 insns per cycle
113,040,372,246 branches # 653.648 M/sec
6,208,602,123 branch-misses # 5.49% of all branches
173.022732371 seconds time elapsed
Code: Select all
$ perf stat ./apgluxe -n 1000000 -t 1 -v 0 -s test
Greetings, this is apgluxe v4.82-ll2.1.5, configured for b3s23/C1.
Lifelib version: ll2.1.5
Compiler version: 5.4.0 20160609
Python version: '2.7.12 (default, Nov 12 2018, 14:36:49) [GCC 5.4.0 20160609]'
Using seed test
Running 1000000 soups per haul:
Instruction set AVX-512 detected
b3s23/C1: 56581 soups completed (5657.942 soups/second current, 5657.942 overall).
b3s23/C1: 114888 soups completed (5830.687 soups/second current, 5744.307 overall).
b3s23/C1: 173123 soups completed (5823.400 soups/second current, 5770.669 overall).
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Soup test216747 lasts an estimated 740 generations; rerunning...
Soup test216747 actually lasts 637 generations.
b3s23/C1: 230392 soups completed (5725.778 soups/second current, 5759.443 overall).
b3s23/C1: 288967 soups completed (5857.492 soups/second current, 5779.050 overall).
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
b3s23/C1: 346228 soups completed (5725.993 soups/second current, 5770.207 overall).
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
b3s23/C1: 404047 soups completed (5781.817 soups/second current, 5771.864 overall).
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
b3s23/C1: 462684 soups completed (5863.698 soups/second current, 5783.342 overall).
b3s23/C1: 520302 soups completed (5761.792 soups/second current, 5780.947 overall).
b3s23/C1: 578694 soups completed (5839.198 soups/second current, 5786.771 overall).
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
Rare oscillator detected: xp8_gk2gb3z11
b3s23/C1: 636238 soups completed (5754.399 soups/second current, 5783.827 overall).
b3s23/C1: 693553 soups completed (5731.276 soups/second current, 5779.448 overall).
b3s23/C1: 752740 soups completed (5918.583 soups/second current, 5790.150 overall).
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
b3s23/C1: 810788 soups completed (5804.471 soups/second current, 5791.172 overall).
Linear-growth pattern detected: yl144_1_16_afb5f3db909e60548f086e22ee3353ac
b3s23/C1: 869065 soups completed (5827.586 soups/second current, 5793.599 overall).
b3s23/C1: 927820 soups completed (5874.941 soups/second current, 5798.683 overall).
b3s23/C1: 986282 soups completed (5846.192 soups/second current, 5801.477 overall).
b3s23/C1: 1000000 soups completed (5799.508 soups/second current, 5801.449 overall).
----------------------------------------------------------------------
1000000 soups completed.
Attempting to contact payosha256.
testing mode
testing
Connection was successful; starting new search...
----------------------------------------------------------------------
Performance counter stats for './apgluxe -n 1000000 -t 1 -v 0 -s test':
172372.363950 task-clock (msec) # 0.999 CPUs utilized
169 context-switches # 0.001 K/sec
0 cpu-migrations # 0.000 K/sec
120,876 page-faults # 0.701 K/sec
567,628,574,448 cycles # 3.293 GHz
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
1,062,851,734,598 instructions # 1.87 insns per cycle
113,693,191,609 branches # 659.579 M/sec
6,137,310,869 branch-misses # 5.40% of all branches
172.459527107 seconds time elapsed
What do you do with ill crystallographers? Take them to the mono-clinic!
- benetnasch85
- Posts: 31
- Joined: March 17th, 2017, 12:09 am
Re: apgsearch v4.0
You may have included an interval when the machine wasn't running. It looks to me like the 5700003 run is losing between 2.5 and 3 minutes per hour, which is around 4%.calcyman wrote:So it looks like v4.82-ll2.1.5 is at most 2% slower than v4.72-ll2.0.27 -- the 5700003 has only lagged by 10 minutes against the others over a period of 9 hours.
Would you like me to run this same test on our SSE and AVX2 machines?
Re: apgsearch v4.0
Oh wow -- that's quite a lot. I haven't been able to reproduce a more-than-negligible performance difference between the two versions (on a Linux machine with AVX-512).benetnasch85 wrote:You may have included an interval when the machine wasn't running. It looks to me like the 5700003 run is losing between 2.5 and 3 minutes per hour, which is around 4%.calcyman wrote:So it looks like v4.82-ll2.1.5 is at most 2% slower than v4.72-ll2.0.27 -- the 5700003 has only lagged by 10 minutes against the others over a period of 9 hours.
I suspect that your OS (Windows 7?) might be treating the processes differently for some reason. Have you set their CPU affinity in the task manager?
https://www.tech-recipes.com/rx/37272/s ... rformance/
I'd suggest setting the CPU affinity of each process so that they reside on their own cores; this should minimise environmental noise (e.g. L1 cache misses due to random CPU migrations and different processes running on the same core). In fact, since the apgluxe processes should be by far the most CPU-intensive processes on the machine, this will most likely encourage all other processes to run on the fourth core.
This could also explain why I don't see this behaviour in my Linux tests; often the entire 3-minute test will complete without any CPU migrations whatsoever.
What do you do with ill crystallographers? Take them to the mono-clinic!
- benetnasch85
- Posts: 31
- Joined: March 17th, 2017, 12:09 am
Re: apgsearch v4.0
This is a 2-core 4-processor AMD machine running Windows 8.1, and I'm running 3 instances under cygwin using "nice -n 19" to lower the priority.
For the current runs, starting around 1735 UTC, I have manually set each instance to run on one processor, and they will continue for several hours unless my wife needs to shut this machine down while teaching (some of her music students are autistic and for a few of them the machine needs to be off). I may go ahead and update one instance on another machine to run this test on a machine that can run more continuously.
I'm running each instance automatically from a script that is called by a desktop icon which has been copied into the startup folder, so I suspect that the second method described in your link would assign one of the outer processes to a particular CPU instead of assigning the apgluxe process. That's another experiment I may do on another machine.
I started looking into this because the reported "soups/second . . . overall" number was noticeably lower for the new version. Now that I have set each instance to run on its own processor, the new version shows a higher number instead of a lower one. That's probably because it's on processor 1 and the other two instances, on processor 2 and 3, may be sharing a core. I do know from previous tests that on this machine running 4 instances gives only about 3.5 times the throughput of running a single instance. I don't think any of our other 4-processor machines are running shared cores, so I may see this effect only on this machine. The next time I run this test on this machine I'll assign the instances to CPUs differently so that CPUs 2 and 3 are running the new version and one instance of the old one. In either case, it will be interesting to see if running this way increases the overall throughput from the three instances put together -- if so, we'll have to figure out a way to do this automatically.
Added:
I started new runs on our AVX2 machine (Intel, 4 cores, 4 threads, Windows 7) about 0130 UTC:
11001201 - v4.72-ll2.0.27 - core 2
11001202 - v4.82-ll2.1.5 -- core 3
11001203 - v4.72-ll2.0.27 - any core
11001204 - v4.82-ll2.1.5 -- any core
The cores were assigned manually after the apgluxe processes started, since cygwin does not seem to have the taskset or similar command. I chose cores 2 and 3 in case any system or security processes are hardwired to core 0. So far, the differences are much smaller than on our AVX1 machine.
Around 0530Z I restarted the instances on the AVX1 machine with the following assignments:
5700001 - v4.72-ll2.0.27 - cpu 1
5700002 - v4.72-ll2.0.27 - cpu 2
5700003 - v4.82-ll2.1.5 -- cpu 3
Again, the run on cpu 1 is significantly faster, most likely because it isn't sharing its core with another instance.
Around 1520Z I started the comparison on an Intel 4-core processor with SSE4 running Windows 10:
2300001 - v4.72-ll2.0.27
2300002 - v4.82-ll2.1.5
Since I have an assortment of older 64-bit processors, feel free to ask when you want real-world benchmarks of a new version against the version I'm running. If you want me to benchmark against a different older version, it will help if you can point me to the directions for updating to a version other than the latest one.
For the current runs, starting around 1735 UTC, I have manually set each instance to run on one processor, and they will continue for several hours unless my wife needs to shut this machine down while teaching (some of her music students are autistic and for a few of them the machine needs to be off). I may go ahead and update one instance on another machine to run this test on a machine that can run more continuously.
I'm running each instance automatically from a script that is called by a desktop icon which has been copied into the startup folder, so I suspect that the second method described in your link would assign one of the outer processes to a particular CPU instead of assigning the apgluxe process. That's another experiment I may do on another machine.
I started looking into this because the reported "soups/second . . . overall" number was noticeably lower for the new version. Now that I have set each instance to run on its own processor, the new version shows a higher number instead of a lower one. That's probably because it's on processor 1 and the other two instances, on processor 2 and 3, may be sharing a core. I do know from previous tests that on this machine running 4 instances gives only about 3.5 times the throughput of running a single instance. I don't think any of our other 4-processor machines are running shared cores, so I may see this effect only on this machine. The next time I run this test on this machine I'll assign the instances to CPUs differently so that CPUs 2 and 3 are running the new version and one instance of the old one. In either case, it will be interesting to see if running this way increases the overall throughput from the three instances put together -- if so, we'll have to figure out a way to do this automatically.
Added:
I started new runs on our AVX2 machine (Intel, 4 cores, 4 threads, Windows 7) about 0130 UTC:
11001201 - v4.72-ll2.0.27 - core 2
11001202 - v4.82-ll2.1.5 -- core 3
11001203 - v4.72-ll2.0.27 - any core
11001204 - v4.82-ll2.1.5 -- any core
The cores were assigned manually after the apgluxe processes started, since cygwin does not seem to have the taskset or similar command. I chose cores 2 and 3 in case any system or security processes are hardwired to core 0. So far, the differences are much smaller than on our AVX1 machine.
Around 0530Z I restarted the instances on the AVX1 machine with the following assignments:
5700001 - v4.72-ll2.0.27 - cpu 1
5700002 - v4.72-ll2.0.27 - cpu 2
5700003 - v4.82-ll2.1.5 -- cpu 3
Again, the run on cpu 1 is significantly faster, most likely because it isn't sharing its core with another instance.
Around 1520Z I started the comparison on an Intel 4-core processor with SSE4 running Windows 10:
2300001 - v4.72-ll2.0.27
2300002 - v4.82-ll2.1.5
Since I have an assortment of older 64-bit processors, feel free to ask when you want real-world benchmarks of a new version against the version I'm running. If you want me to benchmark against a different older version, it will help if you can point me to the directions for updating to a version other than the latest one.
Re: apgsearch v4.0
Are there any plans to allow apgsearch to search ltl/hrot hexagonal rules?
Help wanted: How can we accurately notate any 1D replicator?
Re: apgsearch v4.0
It's been a while; are there still any plans to support these (as well as allow catagolue to read them correctly)?calcyman wrote:The missing hexagonal symmetries are C3_3 and D6_3.
Help wanted: How can we accurately notate any 1D replicator?
Re: apgsearch v4.0
These are the timing results from Catagolue (compare only within each group):benetnasch85 wrote:I started looking into this because the reported "soups/second . . . overall" number was noticeably lower for the new version. Now that I have set each instance to run on its own processor, the new version shows a higher number instead of a lower one. That's probably because it's on processor 1 and the other two instances, on processor 2 and 3, may be sharing a core. I do know from previous tests that on this machine running 4 instances gives only about 3.5 times the throughput of running a single instance. I don't think any of our other 4-processor machines are running shared cores, so I may see this effect only on this machine.
Code: Select all
5700003: 13:19 end, 06:21 start (6h 58m)
5700002: 13:43 end, 07:22 start (6h 21m)
5700001: 13:01 end, 08:05 start (4h 56m)
11001201: 14:58 end, 06:48 start (8h 10m)
11001202: 14:52 end, 06:47 start (8h 05m)
11001203: 14:54 end, 06:25 start (8h 29m)
11001204: 15:29 end, 07:02 start (8h 27m)
- On the AVX1 machine, the old version is faster, but this difference pales in comparison with the core-sharing effect, so it simply might be that the new version is less aggressive at competing for CPU cycles or L1 cache.
- On the AVX2 machine, there is no difference between the two versions, but in both cases the fixed-core processes are faster than the any-core processes. This is to be expected, because CPU migrations are cache-unfriendly.
What do you do with ill crystallographers? Take them to the mono-clinic!
Re: apgsearch v4.0
Should I switch to v4?
I recently started running my apgmera install again and I see very few people are running v3.28. Should I upgrade to v4.0? Is the new version faster or more correct? When I asked this question about a year ago, the answer was that there wasn't a compelling reason to upgrade.
I recently started running my apgmera install again and I see very few people are running v3.28. Should I upgrade to v4.0? Is the new version faster or more correct? When I asked this question about a year ago, the answer was that there wasn't a compelling reason to upgrade.
- benetnasch85
- Posts: 31
- Joined: March 17th, 2017, 12:09 am
Re: apgsearch v4.0
V4 is faster now than it was a year ago, and it now runs b3s23 faster on all of my machines.tod222 wrote:Should I switch to v4?
I recommend making a copy of your install, upgrading the copy to V4, and running one instance of each version side by side. If V4 is still slower on your system, Calcyman will want to know about it.
Re: apgsearch v4.0
How are genext rulestrings formatted for apgsearch?
Help wanted: How can we accurately notate any 1D replicator?
Re: apgsearch v4.0
Indeed it is!benetnasch85 wrote:V4 is faster now than it was a year ago…tod222 wrote:Should I switch to v4?
The results below are observed from running the two different versions on my Haswell i7-4790K (4C/8T) at stock clockspeed with 8 threads using log file timestamp values when the system was otherwise idle. OS is Ubuntu 18.04.1 LTS and v4 is compiled with the distribution's tools.
Version 3.28 was compiled some time ago before I upgraded to 18.04 so I grepped the compiler info from the binary. For a fair comparison I should recompile v3.28 using GCC 7.3, but I'm unlikely to bother doing that.
apgluxe v4.86-ll2.1.9
Lifelib version: ll2.1.9
Compiler version: 7.3.0
Python version: '2.7.15rc1 (default, Nov 12 2018, 14:31:15) [GCC 7.3.0]'
2893.5 soups/thread/second
apgmera v3.28
GCC 4.8.4-2ubuntu1~14.04.1
2510 soups/thread/second
Re: apgsearch v4.0
I just updated my apgsearch to v4.87 and keep getting this error whenever the peer review process starts:
If I switch to a new rule the error changes somewhat:
Code: Select all
Segmentation fault (core dumped)
Code: Select all
./recompile.sh: line 74: 11760 Segmentation fault (core dumped) ./apgluxe --rule $newrule "$@"
Re: apgsearch v4.0
Which rule are you using, and on what CPU architecture?Ian07 wrote:I just updated my apgsearch to v4.87 and keep getting this error whenever the peer review process starts:
If I switch to a new rule the error changes somewhat:Code: Select all
Segmentation fault (core dumped)
Code: Select all
./recompile.sh: line 74: 11760 Segmentation fault (core dumped) ./apgluxe --rule $newrule "$@"
What do you do with ill crystallographers? Take them to the mono-clinic!