Silk discussion thread

[Anivec]

Thank you for your help, I still have a few questions:
Is there any other tools needed that are not packaged into Silk?

It has dependencies on CMake and nvcc -- but if you're using the Google Colab then you won't need to worry about installing anything, because it doesn't run on your computer; it runs on one of Google's cloud VMs where these things are preinstalled.

Finally, is CUDA compatible with iOS? I’ve been getting mixed results for compatibility with iOS.

If you're using Google Colab, then you should be able to run Silk from any browser (for the reason mentioned above); you don't need CUDA installed on your computer because the code is running elsewhere.

If you're trying to run Silk on your own machine, then apparently CUDA doesn't work on MacOS (and newer Macs don't have NVIDIA GPUs in any case): https://developer.nvidia.com/nvidia-cud ... -mac-hosts

which developer kit should I use if it doesn't work?

[apg]

which developer kit should I use if it doesn't work?

What do you mean by "doesn't work"? What system (hardware + OS + GPUs) do you have, and what error are you encountering at what part of the instructions on https://gitlab.com/apgoucher/silk/-/blo ... /README.md ?

[Anivec]

which developer kit should I use if it doesn't work?

What do you mean by "doesn't work"? What system (hardware + OS + GPUs) do you have, and what error are you encountering at what part of the instructions on https://gitlab.com/apgoucher/silk/-/blo ... /README.md ?

CPU: 3.3 GHz 6-Core Intel Core i5
OS: MacOS
GPU: AMD Radeon Pro 5300 4 GB
There doesn't seem to be any installation instructions for different Cuda applications
How do you run the search on the Cloud?
EDIT:
I can run CUDA on my AMD GPU using ZLUDA, no idea how to however.

[apg]

How do you run the search on the Cloud?

These instructions explain how to do it in Google Colab, which gives you a few hours per day of free GPU time: https://gitlab.com/apgoucher/silk#optio ... -the-cloud

If you want a beefier computer and are willing to pay for it, then you can rent one from LeaderGPU and follow the instructions in https://gitlab.com/apgoucher/silk#optio ... r-computer instead. I recommend the RTX 4090 GPUs because they're the best for non-matmul performance.

[get_Snacked]

i'm trying to run Silk locally. my GPU is a GeForce RTX 3050 (more of a gaming GPU, lol, but hopefully that's fine), and i got the following error:

Code: Select all

nvcc fatal   : Value 'native' is not defined for option 'gpu-architecture'

how can i fix this?
EDIT: this is from when i was trying to recompile, FYI.

[get_Snacked]

i'm trying to run Silk locally. my GPU is a GeForce RTX 3050 (more of a gaming GPU, lol, but hopefully that's fine), and i got the following error:

Code: Select all

nvcc fatal   : Value 'native' is not defined for option 'gpu-architecture'

how can i fix this?
EDIT: this is from when i was trying to recompile, FYI.

following up because i really want to use Silk (not right now tho, my computer is going through repair, but i still want to know what i need to fix : D)

[whatislife]

You didn't say what OS this machine is so I'm guessing gaming PC means wsl, which is what I use. I don't remember if I had that error message, but I do remember having problems until I carefully matched compatible versions of everything involved from windows drivers up. Here's what I said about that on discord a while ago:

If anyone else has trouble compiling: there are a LOT of pitfalls here, this was the best resource I found https://medium.com/ibm-data-ai/straight ... 118add9e53 (here we just need the driver and CUDA versions correct) At one point I got it to compile with messages just like the sample but it failed run_unit_tests.sh - the problem was a version mismatch between the max reported by nvidia-smi and the version pulled by the network installer, you must go to https://developer.nvidia.com/cuda-toolkit-archive, find the right version, and use the local runfile installer. When installer gets to "please make sure blah blah" it is a reminder that you need to update bashrc with your correct version like explained in step 4 here https://gist.github.com/Glavin001/3f73a ... ee41f27c34 and make sure the shell is updated before trying again. Very confusing!

For what it's worth, nvidia-smi and nvcc -V no longer report the same version on my system, so upgrading things as usual hasn't broken anything yet.

Here's something more fun from my silk logs, a 2-glider-mess-to-century conduit, here between a H-to-2-glider mess and a century-to-G to show it is connectable. New stuff in light green state 3 cells:

Code: Select all

x = 83, y = 71, rule = LifeHistory
24.2A8.2A12.4B$25.A8.A14.4B$25.A.2A2.BA.A15.4B$26.AB.A.B2A17.4B$27.B
2A2B20.4B$28.5B20.4B$20.B8.4B21.4B11.2A$19.3B2.3B.4B5.2A16.4B8.2B2AB$
19.14B4.A.A16.4B7.4B$17.17B5.A17.4B5.4B$17.21B2A.2A.A13.4B5.4B$16.24B
.A.2A14.4B4.5B$16.21B4.A18.5B.6B2.2B$15.22B3.2A19.16B$15.21B26.17B$
15.22B.B23.17B$13.2AB.21B2A23.17B$12.A.AB3.19B2A23.18B$12.A7.19B25.
18B$11.2A7.11B.7B24.20B$21.16B25.20B$20.11B2.4B24.19B$20.12B2.4B23.
19B$20.11B4.4B20.20B$20.B3D4B.2B2A3.4B14.3B2.18B$20.2BD4B3.BA.A3.4B
10.25B$20.2B3D2B6.A4.4B9.14BD10B$20.6B7.2A4.4B7.15B2D8B$19.7B9.A4.4B
6.B2C11B2D9B5.A$7.2A9.8B6.A.A6.4B5.B2C11BD10B3.3A$8.A8.8B5.3A.2A6.4B
3.27B.A$8.A.AB4.9B4.A13.4B.28BA.A$9.2AB.6B.6B3.2A13.13B2.11B.3B.2BAB$
11.7B.8B.3B14.13B2.2B.B2.2B8.2B$11.18B17.14B15.2B$11.18BAB14.3BDBD10B
13.B2AB$10.18BABAB.B11.4B3D8B15.2A$9.18BA2BA2B2A10.4BDB3D4B$7.18B.2B
2AB.B2A10.6BDBD4B$7.2BC15B2.3B3.B12.7BD3B$6.3BCBC4B.7B2.3B17.10B$7.2B
3C4B2.6B2.B2AB17.9B$6.5BC5B.7B2.2A18.9B$5.13B.6B21.11B$4.4B7.9B21.4B.
3B.C2B2.2C$4.3B9.8B20.4B3.2BCBC.C2.C$2.4B11.8B18.4B4.BCB.C.2C$2.2A14.
7B8.A8.4B7.2C2.C$3.A15.6B6.3A7.4B12.C.C$3A16.2B3D2B4.A9.4B14.2C$A5.2A
11.2BD5B3.2A7.4B$6.A.A10.B3D4B.4B6.4B$4.A.A.A9.12B7.4B$3.A.A2.A.2A6.
13B5.4B$2.A2.A.A.A2.A6.12B4.4B$2.2ABA.AB2.A.A6.11B3.4B$5.AB2A3.A5.B4.
7B3.4B$2.2A.A3B8.3B2.8B2.4B$A2.ABAB.22B.4B$2A2.AB.2B2A4B2A17B$6.2BA2B
A.BA2BA16B$2A2.AB.2B2A4B2A18B2.2A$A2.ABAB.9B.17B3.A$2.2A.A3B9.19B.A.
2A$5.AB2A3.A6.3B.12B2A.A2.A$2.2ABA.AB2.A.A10.11B.A.2A$2.A2.A.A.A2.A
14.4B3.B.A$3.A.A2.A.2A17.B5.2A$4.A.A.A19.3B$6.A.A18.B2AB$6.2A20.2A!

I like 2-glider collisions as an active region to feed silk because they are small and can be made with clearances that are easy to understand (and this became of the motivation to collect a full set of H-to-2-glider-collision conduits to connect with)

[get_Snacked]

which nvcc, cuda, and driver versions are compatible for usage of Silk? is there somewhere i can check?

[get_Snacked]

which nvcc, cuda, and driver versions are compatible for usage of Silk? is there somewhere i can check?

here is a bump, as i would like for this be answered so i can finally try searching for solutions to some long-unsolved partials.

[yoleo]

I've spent some time reading the source code of silk and figuring out what's going on in advance.py and advance.hpp. I thought I'd share in case others are interested. My starting point is the following paraphrased comments by APG, from Discord:

No cell in a still life can have over 6 nbrs, so we can represent the known info about stable state with 8 bitplanes: d0, d1, d2, l2, l3, d4, d5, and d6. d/l = dead/live, n = on nbrs. These bitplanes are stored inverted: 1 = impossible and 0 = possible. We refer to a cell as low/stable/high if current - stable is -1/0/1 respectively. i.e. low = on in stable, off in current; high = opposite. From the low/stable/high info about a cell's 8 neighbors, we compute 18 booleans, 2 per vertical line below
-6 -5 | -4 | -3 | -2 | -1 | 0 | +1 | +2 | +3 | +4 +5 +6 +7 +8
specifying whether or not we know actual difference is left/right of the line. We can then deduce info about out the next generation based on these 18 booleans. (We don't need to distinguish between -5 and -6: at most 6 nbrs in stable, and 1, 0 < 2 hence underpopulated in the current generation. Likewise, if the difference is at least +4, the cell is certainly overpopulated.)

That's the high-level overview: low/high/stable info for current gen => 18 booleans per cell => low/high/stable info for next gen. What follows is the details of how one actually goes from one to the other.

In the code and in what follows, there's certain naming conventions: f = forced, d/l = dead/live, us = unstable. not_{low/high/stable} indicates forced to be not {low/high/stable} [as opposed to possibly-not-{low/high/stable}]. Also, silk stores the 64x64 torus in 4 quadrants: the kth warp stores the kth row in each square, as the components of a uint4, a vector of 4 uint32_t's. So keep in mind that this isn't just one uint4, but one per warp.

First, going from low/high/stable for current gen to the 18 booleans. The difference of between the current population and the stable population is the number of high neighbors, minus the number of low neighbors. For brevity, I'll omit the "neighbors" in what follows.
curr_pop - stable_pop = high - low
min(high - low) <= curr_pop - stable_pop <= max(high - low)
min(high) - max(low) <= curr_pop - stable_pop <= max(high) - min(low)
min(high) + min(8 - low) <= 8 + curr_pop - stable_pop <= max(high) + max(8-low).
Here, I added 8 to both sides, and used the fact that maximizing c - x is the same as minimizing x, and vice versa. This is nice because 8-low is the size of the complement of low. In the code, we see

Code: Select all

uint4 lb_bin = kc::sum16<false>(not_low, not_low & not_stable);
uint4 ub_bin = kc::sum16<true>(not_high, not_high & not_stable);

kc::sum16 here "returns the sum of the 16 booleans obtained by taking the values of a and b on each of the 8 neighbours." The "true" here means "subtract one." lb_bin is the sum over the 8 neighbors of (must_be_high + must_be_not_low), the same lower bound I derived above. The upper bound I derived above is might_be_high + might_be_not_low = 16 - (must_be_not_high + must_be_low). Therefore ub_bin = -1 + must_be_not_high + must_be_low = 15 - (upper bound above).
Next, we need to compute the 18 booleans from lb_bin and ub_bin. Relevant comments from the advance.hpp:

Code: Select all

// lb[i] := "we know that (curr_pop - stable_pop >= i - 4)"
uint32_t lb0 = lb_bin.w | lb_bin.z;
...compute lb0-lb8...
// ub[i] := "we know that (curr_pop - stable_pop  < i - 4)"
uint32_t ub8 = ub_bin.w | ub_bin.z;
...compute ub0-ub8...

For the lb{i}s, lb_bin <= 8 + curr_pop - stable_pop, hence our lower bound for curr_pop - stable_pop is lb_bin - 8. lb{i} is true iff curr_pop-stable_pop >= i - 4 iff lb_bin - 8 >= i - 4 iff lb_bin >= i + 4. And if you reference that against the omitted binary arithmetic, that does make sense: the digits are w, z, y, x, most significant to least. E.g. lb0 means lb_bin >= 4 which means either w or z is true.

For the ub{i}'s, 8 + curr_pop - stable_pop <= 15 - ub_bin < 16 - ub_bin, hence our strict upper bound for curr_pop - stable_pop is 8 - ub_bin. ub{i} is true iff curr_pop - stable_pop < i - 4 iff 8 - ub_bin <= i - 4 iff ub_bin >= 12 - i. Again, this seems to match the binary arithmetic.
That finishes going from the high/stable/low to the 16 booleans.

Second, going from the 18 booleans to which cells are forced to be on/off/stable in the next generation. Consider some cell that might be of a given state, among d0, d1, d2, l2, l3, d4, d5, and d6. (Potential confusion: in what follows, "state" means "one of d0, d1, etc" not off/on.) Let n be its number of live neighbors. If that cell is indeed of that state, then it is:
Off in next gen <=> (n < 2) | (n < 3 & dead) | (n >= 4)
On in next gen <=> (n >= 2) & (n >= 3 | live) & (n < 4)
unstable in next <=> {on/off} in next where we're considering a {d/l} state
To get the overall forced off/on/unstable, intersect over all possible states for the cell. In advance.hpp, this looks like

Code: Select all

{ // d0
        uint32_t fd_next = (ub6 | (ub7 & not_high) | lb8) | ad0;
        uint32_t fl_next = (lb6 & (lb7 | not_stable) & ub8) | ad0;
        unstable_d0 = fl_next;
        gnot_high &= fd_next;
        gnot_stable &= fl_next;
}
...
{ // l2
        uint32_t fd_next = (ub4 | (ub5 & not_stable) | lb6) | al2;
        uint32_t fl_next = (lb4 & (lb5 | not_low) & ub6) | al2;
        unstable_l2 = fd_next;
        gnot_stable &= fd_next;
        gnot_low &= fl_next;
}
...

Here, the "| a{state}" corresponds to "possible state for the cell." (Keep in mind that the a{state} bitplanes are inverted: 1 = impossible.) A 1 in fd_next means not quite "forced dead next," but rather "forced dead next or forced not-of-{state}." gnot_{low/high/stable} start out as all 1's: the &='s remove the cells that are possibly-of-{state}-and-{low/high/stable}, by setting that bit of gnot_{low/high/stable} to 0. The relationship between gnot_{low/high/stable} and f{l/d}_next is different for l states vs d states. E.g. d = off in stable, so on = unstable = high, off = stable = not-high.

The rest of advance.hpp is fairly straightforward: compute which cells are forced stable based off search parameters, and mark those as forced-not-high and forced-not-low. Cells that are forced to be stable cannot be of a state that makes them unstable (this is why we calculated unstable_d0). Check for improvements to knowledge about stable catalyst by comparing new state bit plane to old one. Finally, update the 8 state bit planes, as well as not_low, not_high, and not_stable. Return T/F for improved info/not.

Lengthy post. Please like if you made it to the end and found it useful: writing this all up took some time. Also, APG/mvr/others more familiar with the code, if I'm wrong or missing something, feel free to chime in.

[Katrina]

Can Silk be used to find wires, reburnable fuses, or drifters? I can find people saying they've done it, but they've never explained how.

[hotcrystal0]

Can Silk be used to find wires, reburnable fuses, or drifters? I can find people saying they've done it, but they've never explained how.

Yes, if you set it up correctly, but I'm not sure about reburnable fuses.

[Katrina]

Yes, if you set it up correctly, but I'm not sure about reburnable fuses.

What do you mean by "set it up correctly"? Is there a more detailed explanation?

[Katrina]

It's been two weeks, what do you mean "set it up correctly"? I need this information.

[yoleo]

The examples folder provides a couple of examples as to how to set up searches for ways to extend a given wire.

[Katrina]

The examples folder provides a couple of examples as to how to set up searches for ways to extend a given wire.

Sorry, I don't want to extend a wire, I want to complete a partial for a wire (which could just be possible with LLS but I have no idea how to make a file that does that)

Specifically, something like this c/3d barge fuse (not sure how to word it, also it doesn't have to be exactly this pattern):

Code: Select all

x = 20, y = 19, rule = B3/S23
2o$4o$3b2o$3bobo$4bobo$5bobo$6bobo$7bobo$8bobo$9bobo$10bobo$11bobo$12b
obo$13bobo$14bobo$15bobo$16bobo$17bobo$18bo!

[dvgrn]

Sorry, I don't want to extend a wire, I want to complete a partial for a wire (which could just be possible with LLS but I have no idea how to make a file that does that)

Specifically, something like this c/3d barge fuse (not sure how to word it, also it doesn't have to be exactly this pattern):

Code: Select all

x = 20, y = 19, rule = B3/S23
2o$4o$3b2o$3bobo$4bobo$5bobo$6bobo$7bobo$8bobo$9bobo$10bobo$11bobo$12b
obo$13bobo$14bobo$15bobo$16bobo$17bobo$18bo!

Is this example a "partial for a wire"? Can you be more specific about what a completion of this "partial" might look like?

There problem here may be one of terminology. The barge fuse reaction doesn't look like a partial to me, and it doesn't seem to have anything to do with wires, either -- a burning fuse isn't re-usable (unless it's a reburnable fuse) whereas a wire is re-usable.

[Katrina]

Yes, it is an example of a "partial", and what I need is for it to rebuild itself (as in something like this)

Code: Select all

x = 36, y = 35, rule = B3/S23
bo$obo$bobo$2bobo$3bobo$4bobo$5bobo2bo$6bo2bo$8bo3bo$7bo3bo$6bo3bo3bo$
9bo3bo$8bo3bo3bo$11bo3bo$10bo3bo$13bo$12bo3b2o$16b4o$19b2o$19bobo$20bo
bo$21bobo$22bobo$23bobo$24bobo$25bobo$26bobo$27bobo$28bobo$29bobo$30bo
bo$31bobo$32bobo$33bobo$34bo!

Sorry for not being able to explain anything properly

[dvgrn]

Yes, it is an example of a "partial", and what I need is for it to rebuild itself (as in something like this)...

How about like this -- Wire#c/2 wire? You're wanting to find additional examples of wire signals like Hartmut Holzwart's c/2 diagonal telegraph signals? But maybe with different fuses?

Would you be willing to try that with Logic Life Search? It might be a little easier to set up

(though I'm only saying that because I know offhand how to set up a search like that in LLS, but I haven't done any experimenting with Silk).

EDIT: Huh, do we really not have anything about Gabriel Nivasch's diagonal lightspeed signals on the LifeWiki? (Scroll way down to the bottom.) Seems like that should be documented in the wire article.

[Katrina]

Would you be willing to try that with Logic Life Search? It might be a little easier to set up

I think that would be better
The reason why I was asking about its use in silk is because of how most of the concepts stem from dr2/dr and I heard on LifeWiki that it was used for that purpose, however I can't find any example files or anything explaining how to create a signal
The c/2 wire is also on the LifeWiki article for drifters

[dvgrn]

Would you be willing to try that with Logic Life Search? It might be a little easier to set up

I think that would be better

One big thing about these types of searches is that you have to figure out how to tell Logic Life Search that you don't want the null solution (just a long^N barge wick with no signal traveling along it) and probably that you also don't want stuff like this:

Code: Select all

x = 62, y = 59, rule = B3/S23
60bo$59bobo$58bobo$57bobo$56bobo$55bobo$54bobo$53bobo$52bobo$51bobo$50b
obo$49bobo$48bobo$47bobo$46bobo$45bobo$44bobo$43bobo$42bobo$41bobo$40b
obo$39bobo$38bobo$37bobo$36bobo$35bobo$34bobo$33bobo$32bobo$31bobo$30b
obo$29bobo$28bobo2$26bo$24b2o2b2o$23b3o2b2o$23b2o3b2o$17b2ob2o$16bo2b
3o$13bo2bo3b3o$12bobo6b2o$21bobo$9b2ob2o9b2o$3b2o3bo3b2o8bobo$2bobo5b
2o13bo$4bo2b2o14b2o$bo$2o$2o$b2o$2b2o6b2o$bo2b2o3bobo$3b3o5bo$8bo$7b2o
$4bo$3bobo$4bo!

Do you see where to start, for setting up an input file for LLS? Here's a somewhat relevant example for finding something that moves.

Along with zeroes and ones and asterisks, you can define as many variables as you want -- do things like specify that a particular cell has to be state Var1 at T=0, and that that implies that the cell to the northwest of it (let's say) has to become state Var1 at T=4, for a wire signal that's moving diagonally northwest at c/4.

It's probably a good idea to start by running that linked example, exactly as it stands -- make sure you're able to find the tagalong, so that you know LLS is working.

[apg]

Silk now supports a parameter --max-cell-stationary-distance (ported from Barrister) with the short alias -c for discarding branches of the search tree where there are 'active cells' that are locally stable but have no nearby fluctuating cells.

Larger values of the parameter are less restrictive. It looks like -c 3 is a good sweetspot; on an example I tried it was able to deliver an almost 4x speedup without missing any of the solutions:

• tl2.rle 12 12 17: 257 billion nodes, 58 fizzles, runtime: 31 minutes
• tl2.rle 12 12 17 -c 2: 27 billion nodes, 28 fizzles, runtime: 3.5 minutes
• tl2.rle 12 12 17 -c 3: 70 billion nodes, 58 fizzles, runtime: 8.5 minutes

In practice I expect that this speedup will grow with scale, i.e. it's an asymptotic speedup rather than a constant-factor speedup.

[hotcrystal0]

How do Silk input files work?