apgsearch v4.0

For general discussion about Conway's Game of Life.
User avatar
cordership3
Posts: 129
Joined: August 23rd, 2016, 8:53 am
Location: Smome tomato
Contact:

Re: apgsearch v4.0

Post by cordership3 » December 24th, 2018, 10:52 pm

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

User avatar
rowett
Moderator
Posts: 3776
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: apgsearch v4.0

Post by rowett » December 28th, 2018, 7:34 am

calcyman wrote:I've also added multistate HROT rules.
What's the syntax?

User avatar
calcyman
Moderator
Posts: 2932
Joined: June 1st, 2009, 4:32 pm

Re: apgsearch v4.0

Post by calcyman » December 28th, 2018, 8:30 am

rowett wrote:
calcyman wrote:I've also added multistate HROT rules.
What's the syntax?
All of the syntaxes are listed here:

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?'}
As usual for Generations generalisations of rules, the number after 'g' is the number of states, and everything thereafter is the name of the base 2-state rule.
What do you do with ill crystallographers? Take them to the mono-clinic!

User avatar
rowett
Moderator
Posts: 3776
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: apgsearch v4.0

Post by rowett » December 30th, 2018, 12:20 am

calcyman wrote:All of the syntaxes are listed here:

https://gitlab.com/apgoucher/lifelib/bl ... nuslist.py
Excellent, thanks.

Do you have plans to support von Neumann and Circular neighbourhoods for ltl, gltl, hrot and ghrot?

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: apgsearch v4.0

Post by muzik » January 6th, 2019, 6:21 pm

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.

User avatar
Apple Bottom
Posts: 1034
Joined: July 27th, 2015, 2:06 pm
Contact:

Re: apgsearch v4.0

Post by Apple Bottom » January 7th, 2019, 2:17 am

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?
Another minor suggestion: why not send a patch (better yet, Gitlab pull request) to do exactly that?
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!

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: apgsearch v4.0

Post by muzik » January 7th, 2019, 9:35 am

Apple Bottom wrote:
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?
Another minor suggestion: why not send a patch (better yet, Gitlab pull request) to do exactly that?
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.

----

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.

User avatar
dvgrn
Moderator
Posts: 10610
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: apgsearch v4.0

Post by dvgrn » January 7th, 2019, 10:20 am

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.
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.,

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
... apgluxe could perfectly well just take "b3s23" as the desired rule and run with that.

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'.
muzik wrote:Can you please stop making these posts? I don't find them helpful in the slightest.
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.

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.

User avatar
Apple Bottom
Posts: 1034
Joined: July 27th, 2015, 2:06 pm
Contact:

Re: apgsearch v4.0

Post by Apple Bottom » January 7th, 2019, 12:11 pm

muzik wrote:Can you please stop making these posts? I don't find them helpful in the slightest.
Then perhaps you'll understand that I feel the same way about yours.

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.
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.
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.
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!

dani
Posts: 1222
Joined: October 27th, 2017, 3:43 pm

Re: apgsearch v4.0

Post by dani » January 8th, 2019, 12:00 pm

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...

User avatar
benetnasch85
Posts: 31
Joined: March 17th, 2017, 12:09 am

Re: apgsearch v4.0

Post by benetnasch85 » January 10th, 2019, 11:04 am

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

User avatar
calcyman
Moderator
Posts: 2932
Joined: June 1st, 2009, 4:32 pm

Re: apgsearch v4.0

Post by calcyman » January 10th, 2019, 1:24 pm

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
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.

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!

User avatar
calcyman
Moderator
Posts: 2932
Joined: June 1st, 2009, 4:32 pm

Re: apgsearch v4.0

Post by calcyman » January 10th, 2019, 2:03 pm

Perf using latest version:

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
Perf with 1-line change to use flatlayer(0) population count:

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
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.
What do you do with ill crystallographers? Take them to the mono-clinic!

User avatar
benetnasch85
Posts: 31
Joined: March 17th, 2017, 12:09 am

Re: apgsearch v4.0

Post by benetnasch85 » January 10th, 2019, 5:58 pm

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.
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%.

Would you like me to run this same test on our SSE and AVX2 machines?

User avatar
calcyman
Moderator
Posts: 2932
Joined: June 1st, 2009, 4:32 pm

Re: apgsearch v4.0

Post by calcyman » January 11th, 2019, 9:30 am

benetnasch85 wrote:
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.
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%.
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).

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!

User avatar
benetnasch85
Posts: 31
Joined: March 17th, 2017, 12:09 am

Re: apgsearch v4.0

Post by benetnasch85 » January 11th, 2019, 2:20 pm

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.

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: apgsearch v4.0

Post by muzik » January 19th, 2019, 6:43 pm

Are there any plans to allow apgsearch to search ltl/hrot hexagonal rules?

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: apgsearch v4.0

Post by muzik » January 20th, 2019, 11:16 am

calcyman wrote:The missing hexagonal symmetries are C3_3 and D6_3.
It's been a while; are there still any plans to support these (as well as allow catagolue to read them correctly)?

User avatar
calcyman
Moderator
Posts: 2932
Joined: June 1st, 2009, 4:32 pm

Re: apgsearch v4.0

Post by calcyman » January 20th, 2019, 11:49 am

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.
These are the timing results from Catagolue (compare only within each group):

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)
This suggests that:
  • 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!

tod222
Posts: 21
Joined: August 23rd, 2010, 12:43 am

Re: apgsearch v4.0

Post by tod222 » January 20th, 2019, 12:52 pm

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.
Catagolue: @th222 • Twitter: @th222

User avatar
benetnasch85
Posts: 31
Joined: March 17th, 2017, 12:09 am

Re: apgsearch v4.0

Post by benetnasch85 » January 20th, 2019, 3:49 pm

tod222 wrote:Should I switch to v4?
V4 is faster now than it was a year ago, and it now runs b3s23 faster on all of my machines.

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.

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: apgsearch v4.0

Post by muzik » January 25th, 2019, 5:08 pm

How are genext rulestrings formatted for apgsearch?

tod222
Posts: 21
Joined: August 23rd, 2010, 12:43 am

Re: apgsearch v4.0

Post by tod222 » January 31st, 2019, 1:40 am

benetnasch85 wrote:
tod222 wrote:Should I switch to v4?
V4 is faster now than it was a year ago…
Indeed it is!

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
Catagolue: @th222 • Twitter: @th222

User avatar
Ian07
Moderator
Posts: 891
Joined: September 22nd, 2018, 8:48 am
Location: New Jersey, US

Re: apgsearch v4.0

Post by Ian07 » February 3rd, 2019, 3:42 pm

I just updated my apgsearch to v4.87 and keep getting this error whenever the peer review process starts:

Code: Select all

Segmentation fault (core dumped)
If I switch to a new rule the error changes somewhat:

Code: Select all

./recompile.sh: line 74: 11760 Segmentation fault      (core dumped) ./apgluxe --rule $newrule "$@"

User avatar
calcyman
Moderator
Posts: 2932
Joined: June 1st, 2009, 4:32 pm

Re: apgsearch v4.0

Post by calcyman » February 3rd, 2019, 4:30 pm

Ian07 wrote:I just updated my apgsearch to v4.87 and keep getting this error whenever the peer review process starts:

Code: Select all

Segmentation fault (core dumped)
If I switch to a new rule the error changes somewhat:

Code: Select all

./recompile.sh: line 74: 11760 Segmentation fault      (core dumped) ./apgluxe --rule $newrule "$@"
Which rule are you using, and on what CPU architecture?
What do you do with ill crystallographers? Take them to the mono-clinic!

Post Reply