nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 28 Mar 2024 16:09



Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3
Игра ЖИЗНЬ на LifeGE.NET 
Author Message
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22412
Location: Silicon Valley
Reply with quote
Shaos wrote:
AlexanderZh wrote:
Shaos wrote:
Кроме того больше суток гонял самодельную программку, которая тупо перебирала ВСЕ варианты простой заглушки... :(

В BOINC её :mrgreen:

Да я свой сервер планирую написать и клиента надо пошустрее - с хешами и т.д.

P.S. Посмотрел внимательнее по меткам времени на файлах - гонял 16 часов примерно, получается 4670 вариантов в секунду обрабатывалось (по 11 поколений каждый вариант) - по идее с хэшами было бы намного быстрее

P.P.S. Кроме хешей можно ещё добавить логику, которая на первом же поколении отбросит кучу неживучих вариантов, если они нестабильны (поглащатель должен быть стабильным неменяющимся объектом, пока в него не въедет сигнал)

Пока хеши не стал заводить, но добавил проверку на нестабильность в самом начале - уже стало намного быстрее, иду дальше:
Code:
....................
....................
....@@.@@.@@.xxxyyy.
....@@.@@.@@.xxxyyy.
.............xxxyyy.
....@@@@@@@@xxxxyyy.
...@..@.....xxxxyy..
..@.@@....@@xxxyyy..
...@...@....xxxyyy..
....@@@@@@@@xxxyyy..
.............xxyyy..
....@@.@@.@@.xxyyy..
....@@.@@.@@.xxyyy..
....................
....................

Стабильных вариантов (которые не разваливается в первом же поколении) очень мало теперь - программа работает примерно в 12 раз быстрее

P.S. За 1.4 миллиарда вариантов набралось только 33 стабильных - ничего успешного пока, но зато обнаружился почти отражатель - он отражает сигнал обратно в канал, а потом взрывается :lol:

P.P.S. Ускорил программу ещё сильнее (покидаю цикл раньше, если понятно, что с этим вариантом всё плохо) -- объём работ, что изначально выполнялся за 16 часов, теперь посчитался за полчаса - т.е. ускорение в более чем в 30 раз!!! Причём меняя программку, я продолжают с точки, где остановился, а не с самого начала - так что я уже за эти дни 2 миллиарда комбинаций перебрал :roll:

_________________
:dj: https://mastodon.social/@Shaos


18 Apr 2020 01:23
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22412
Location: Silicon Valley
Reply with quote
Shaos wrote:
За 1.4 миллиарда вариантов набралось только 33 стабильных - ничего успешного пока, но зато обнаружился почти отражатель - он отражает сигнал обратно в канал, а потом взрывается :lol:

Вот он :lol:



Attachments:
wire1ref.mp4 [32.72 KiB]
Downloaded 569 times

_________________
:dj: https://mastodon.social/@Shaos
18 Apr 2020 13:36
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22412
Location: Silicon Valley
Reply with quote
4 миллиарда вариантов перебрано - уходим за пределы 32-битного целого :rotate:
Code:
>>> TRY 0x00000001 0x00000000
GEN0 (99,98)-(119,112) 0x00000001 0x00000000
.....................
.....................
.........@@.@@.@@....
.........@@.@@.@@....
.....................
.........@@@@@@@@....
..............@..@...
.....@...@@....@@.@..
.............@...@...
.........@@@@@@@@....
.....................
.........@@.@@.@@....
.........@@.@@.@@....
.....................
.....................

P.S. Чаще всего поиск просто пытается достроить канал :)
Code:
GEN1 (99,98)-(119,112) 0x00000001 0x00501515
.....................
.....................
.........@@.@@.@@....
.........@@.@@.@@....
.....................
.......@@@@@@@@@@....
......@.....@....@...
.....@.@@@....@@@.@..
......@......@...@...
.......@@@@@@@@@@....
.....................
.........@@.@@.@@....
.........@@.@@.@@....
.....................
.....................
GEN11 (99,98)-(119,112) 0x00000001 0x00501515
.....................
.....................
.........@@.@@.@@....
.........@@.@@.@@....
.....................
.......@@@@@@@@@@....
......@....@.....@...
.....@.@@.@....@@.@..
......@....@.....@...
.......@@@@@@@@@@....
.....................
.........@@.@@.@@....
.........@@.@@.@@....
.....................
.....................

_________________
:dj: https://mastodon.social/@Shaos


18 Apr 2020 17:33
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22412
Location: Silicon Valley
Reply with quote
Есть такие штуки в "Игре Жизнь", которые называются wickstretchers - они похожи на puffers (которые похожи на spaceships, но улетая оставляют следы), которые растягивают wicks (линейные осцилляторы) и вот некоторые из них могут тянуть и полосатые каналы и через них даже можно посылать наши сигналы со скоростью света (одна клетка за такт) - например сигнал OSD4#A72B64 и wickstretcher его даже съест:

 видео1

но сигнал должен идти в правильной фазе иначе всё взорвётся :mrgreen:

 видео2

тут проигрыватель игры жизнь сам удаляется, чтобы всё происходящее было видно ;)

_________________
:dj: https://mastodon.social/@Shaos


18 Apr 2020 22:04
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22412
Location: Silicon Valley
Reply with quote
Подрыв другого wickstretcher-а (этот взрывается всегда):

 видео3

_________________
:dj: https://mastodon.social/@Shaos


19 Apr 2020 01:12
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22412
Location: Silicon Valley
Reply with quote
Shaos wrote:
4 миллиарда вариантов перебрано - уходим за пределы 32-битного целого :rotate:
Code:
>>> TRY 0x00000001 0x00000000
GEN0 (99,98)-(119,112) 0x00000001 0x00000000
.....................
.....................
.........@@.@@.@@....
.........@@.@@.@@....
.....................
.........@@@@@@@@....
..............@..@...
.....@...@@....@@.@..
.............@...@...
.........@@@@@@@@....
.....................
.........@@.@@.@@....
.........@@.@@.@@....
.....................
.....................

Во вторых 4 миллиардах оказалось только 7 стабильных конфигураций (которые тем не менее разваливались через несколько поколений), а в третьих 4 миллиардах набралось 16 стабильных...

_________________
:dj: https://mastodon.social/@Shaos


19 Apr 2020 11:42
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22412
Location: Silicon Valley
Reply with quote
Люди на форуме conwaylife.com подлатали мою недоделку, и заставили бегунка развернуться и убежать обратно от взрыва :o

 видео

_________________
:dj: https://mastodon.social/@Shaos


20 Apr 2020 18:58
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22412
Location: Silicon Valley
Reply with quote
Post Re:
Shaos wrote:
Shaos wrote:
Shaos wrote:
Особенности реализации - клетки являются ячейками таблицы, в которых хранится количество соседей (и это количество визуально видно). По ходу пересчёта временное состояние ячеек сохраняется путём установки других (не white или blue) цветов - red для умирающих клеток и purple для рождающихся - но глазом это не заметно т.к. они потом быстро заменяются на нормальные цвета во втором проходе, когда корректируются числа соседей для клеток около которых произошло рождение или смерть.

Живой пример смотреть тут: http://shabarshin.com/life/life.html

Написал про это в своём блоге http://shaos.net а также вывесил на http://lifege.net

Ещё раз объясню суть своего алгоритма 15 летней давности (смотреть по сишному коду) - вместо двухмерного массива булеанов имеем двумерный массив байтов, где храним (в младших 4 битах) заранее подсчитанное количество живых соседей для каждой клетки. В старших битах имеем один бит на текущее состояние и два бита на будущее - бит на рождение и бит на смерть. Пробегая по массиву нам уже не надо обегать каждую клетку считая соседей - они уже посчитаны - просто сверяемся по текущему состоянию и числу соседей - если клетка занята и не 2 и не 3 соседа - взводим флаг смерти, если клетка свободна и имеется ровно 3 соседа - взводим флаг рождения. После того как все флаги взведены - пробегаем по таблице ещё раз, обращая внимание только на те клетки где есть флаг смерти или флаг рождения, в соответствии с которыми декрементируем или инкрементируем суммы живых соседей в клетках вокруг. По моим понятиям вычислений будет сильно меньше, нежели в случае "честного" алгоритма, который считает соседей у каждой клетки каждый раз.

Нашёл тут один алгоритм от 1992 года, где тоже заранее подсчитанные соседи участвуют, но там клетки ещё и по 3 объединены для быстрых вычислений ;)

http://mytears.org/resources/doc/Assembly/ASNIP11/ASNIP11X/LIFE/QLIFE/

P.S. Интересно что если идти по тому же пути что и тут - складывать вместе 2 или более соседних клеток, то на то чтобы хранить количество соседей для каждой клетки уже ненадо иметь 4 бита - достаточно только 3-х, так как мы имеем как минимум на одного соседа меньше (сосед в том же пакете сидит ; ) и 0...7 (8 минус один) замечательно влезает в 3 бита!

Там же у автора есть 32-битная версия (тоже с ассемблерными частями), где он по 4 клетки за раз обрабатывает - причем в ряд. Я решил тоже сделать 4 клетки, но в квадрате 2x2 - в этом случае у каждой клетки будет только 5 внешних соседей, т.е. количество соседей которое надо хранить может варьироваться от 0 до 5 - как это наиболее компактно представить? А очень просто: n1 + 6*n2 + 36*n3 + 216*n4 (где nN - количество внешних соседей соответствующей клетки) - в этом случае информация о соседях этих 4 клеток влезет в 11 битов :)

Еще я написал текстовую программку чтобы выяснить какого размера должна быть таблица байтов, чтобы при обращении к ней по индексу не было бы потерь на копирование из памяти в кеш данных - и у меня получилось, наращивая размер таблицы от 2^1 и далее 2^2, 2^3 и т.д., что до 2^14 индексирование случайным индексом идет абсолютно одинаковое время, а вот далее - скорость обращения падает в 2 и более раз. Соответственно получилось, что таблицу быстрых вычислений надо утолкать в 16 килобайт.

Значит нам надо зная состояние этих 4 клеток и количетсво соседей вокруг них посчитать состояние этих клеток для следующего поколения - для этого мы будем индексировать таблицу байтов адресом n1+6*n2+36*n3+216*n4+2048*s1+4096*s2+8192*s3 (где sN это текущее состояние клеток) и каждый байт в этой таблице будет иметь два набора по 4 бита описывающих будущее состояние для s4=0 (младший нибл) и для s4=1 (старший нибл) - так мы утолкаемся в 16 килобайт, например - если все 4 клетки заняты и у них нет внешних соседей, т.е. s1=s2=s3=s4=1 и n1=n2=n3=n4=0 - обращаемся по адресу 11100000000000 и берем старший нибл (т.к. s4=1) где будет 1111 (т.е. ничего не изменилось - все четыре клетки остаются на месте), вариант с s1=1 s2=1 s3=1 s4=0 будет обращаться к тому же байту, но младшему нибблу где тоже будет 1111, т.е. tab[0x380]=0xFF и т.д.

Далее сравнив 4 состояния что было и 4 состояния что стало можно понять у какой клетки надо обойти соседей и для каждого изменить количество его соседей (если клетка родилась то надо сделать +1 для каждой клетки вокруг, а если умерла, то -1) - проще всего сделать это через switch(было<<4|стало)
{
case 0x00: // ничего не изменилось (было 0000 стало 0000)
break;
case 0x01: // клетка родилась в правом-нижнем углу квадрата (было 0000 стало 0001)
// сделать +1 для всех соседей правой-нижней клетки
break;
// и т.д.
}

_________________
:dj: https://mastodon.social/@Shaos


24 Apr 2020 22:28
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22412
Location: Silicon Valley
Reply with quote
Shaos wrote:
Еще я написал текстовую программку чтобы выяснить какого размера должна быть таблица байтов, чтобы при обращении к ней по индексу не было бы потерь на копирование из памяти в кеш данных - и у меня получилось, наращивая размер таблицы от 2^1 и далее 2^2, 2^3 и т.д., что до 2^14 индексирование случайным индексом идет абсолютно одинаковое время, а вот далее - скорость обращения падает в 2 и более раз...

Текст программки под спойлером и мои результаты с 64-битного дебиян-линуха на амд64 ниже:

 lutest.c
Code:
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <time.h>

#define N INT_MAX
#define T char
#define M 0xFF

int main(int argc, char **argv)
{
 int i,j,k,l,n,m;
 unsigned int s;
 time_t t1,t2;
 T *a;
 if(argc<2) n = 22;
 else n = atoi(argv[1]);
 if(n==0) return -1;
 for(l=1;l<=n;l++)
 {
  k = 1<<l;
  m = k - 1;
  a = (T*)malloc(k*sizeof(T));
  if(a==NULL) return -2;
  srand(time(NULL));
  for(i=0;i<k;i++) a[i]=rand()+(rand()<<15);
  i = s = 0;
  t1 = time(NULL);
  for(j=0;j<N;j++)
  {
    s += ((unsigned)a[i])&M;
    i = (i+j+j+s)&m;
  }
  t2 = time(NULL);
  printf("%8.8X 2^%i * %i -> %is\n",s,l,N,(int)(t2-t1));
  free(a);
 }
 return 0;
}

Code:
FFFFFF68 2^1 * 2147483647 -> 5s
AAAAAA18 2^2 * 2147483647 -> 6s
BFFFFFC2 2^3 * 2147483647 -> 5s
0000004B 2^4 * 2147483647 -> 6s
5C87B6EE 2^5 * 2147483647 -> 5s
DB6DB6B0 2^6 * 2147483647 -> 6s
1ED7E6C8 2^7 * 2147483647 -> 5s
CB4F4C26 2^8 * 2147483647 -> 6s
7E567055 2^9 * 2147483647 -> 6s
E721A4D4 2^10 * 2147483647 -> 5s
594CD3B9 2^11 * 2147483647 -> 6s
EC14A96A 2^12 * 2147483647 -> 6s
6551305A 2^13 * 2147483647 -> 5s
7C903FFD 2^14 * 2147483647 -> 6s
64DE1F79 2^15 * 2147483647 -> 15s
AFB68EBD 2^16 * 2147483647 -> 17s
CE4B0F09 2^17 * 2147483647 -> 18s
902C7F06 2^18 * 2147483647 -> 19s
AB68549C 2^19 * 2147483647 -> 28s
D0ECA61B 2^20 * 2147483647 -> 34s
A5FF4DB7 2^21 * 2147483647 -> 73s
CA388996 2^22 * 2147483647 -> 160s

Если у кого есть желание может попробовать на своём компьютере (собирать gcc -O2 lutest.c -o lutest запускать без параметров) и запостить результаты сюда :dj:

P.S. Да, похоже так и есть - у AMD процессоров размер L1 кеша данных 16кб (у меня семейство Bulldozer с микроархитектурой Steamroller):
https://www.extremetech.com/extreme/188776-how-l1-and-l2-cpu-caches-work-and-why-theyre-an-essential-part-of-modern-chips
Attachment:
AMD64-CacheChart.png
AMD64-CacheChart.png [ 213.87 KiB | Viewed 9408 times ]
L1 имеет задержку на доступ 3-4 такта, а L2 - уже 19 тактов (у Steamroller-a), поэтому массивы больше 16кб имеют в среднем в 5 раз более худшие времена доступа если лезть в них действительно случайным образом. Вот инфа про мою 4-коровую (+ 8 графических коров, которые в линухе не юзаются) конфигурацию AMD-проца: http://www.cpu-world.com/CPUs/Bulldozer/AMD-A10-Series%20A10-7850K.html (там правда написано 4 x 16 KB 4-way set associative data caches, т.е. их четыре - видимо один и тот же массив больше 16кб не может быть аккуратно порезан на разные кеши)

P.P.S. Intel Core i5 вроде как имеет 6 x 32KB 8-way дата кэш - там наверное результаты моей программки сдвинуться и до 2^15...

P.P.P.S. Так и есть - проверил на Intel Core Duo с WinXP в Cigwin:
Attachment:
IntelCoreDuo.gif
IntelCoreDuo.gif [ 17.83 KiB | Viewed 9399 times ]


P.P.P.P.S. Откопал свой чёрный G4 Cube и как ни странно он живой ;)
Я его "потерял" при переезде из Нью-Йорка в 2017, а вот сейчас "нашёл" когда коробки для очередного переезда перепаковывал :lol:
Вот его результаты, подтверждающие информацию, что процессор PowerPC G4 имеет L1 кеш данных размером 32кб:
Code:
shaos@g4cube:~/Sources/tests$ ./lutest
FFFFFF9A 2^1 * 2147483647 -> 26s
71C71C0C 2^2 * 2147483647 -> 25s
C30C3108 2^3 * 2147483647 -> 28s
1642C9D6 2^4 * 2147483647 -> 30s
1C71C59A 2^5 * 2147483647 -> 30s
A98EF52C 2^6 * 2147483647 -> 30s
30201446 2^7 * 2147483647 -> 30s
3658AAB7 2^8 * 2147483647 -> 30s
0F83DFB4 2^9 * 2147483647 -> 30s
124C7633 2^10 * 2147483647 -> 30s
3A5A0095 2^11 * 2147483647 -> 33s
66C9001B 2^12 * 2147483647 -> 30s
27B43966 2^13 * 2147483647 -> 30s
9ED6807C 2^14 * 2147483647 -> 30s
886A5016 2^15 * 2147483647 -> 31s
BB4554A4 2^16 * 2147483647 -> 64s
CDBA02EA 2^17 * 2147483647 -> 83s
B15AC01C 2^18 * 2147483647 -> 101s
EF4C360E 2^19 * 2147483647 -> 180s
C11A763B 2^20 * 2147483647 -> 388s
AA959D8B 2^21 * 2147483647 -> 582s
B72B2E0A 2^22 * 2147483647 -> 703s
Так же можно видеть, что копирование байтов из L1 кеша данных в G4 медленнее в 5-6 раз чем у AMD или Intel (разница частоты процессоров - как раз те самые 6 раз)

_________________
:dj: https://mastodon.social/@Shaos


25 Apr 2020 14:42
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22412
Location: Silicon Valley
Reply with quote
А тем временем программка заканчивает обработку 4й колонки:
Code:
....................
....................
....@@.@@.@@.xxxyyy.
....@@.@@.@@.xxxyyy.
.............xxxyyy.
....@@@@@@@@xxxxyyy.
...@..@.....xxxxyy..
..@.@@....@@xxxyyy..
...@...@....xxxyyy..
....@@@@@@@@xxxyyy..
.............xxyyy..
....@@.@@.@@.xxyyy..
....@@.@@.@@.xxyyy..
....................
....................
Это все биты помененные как x и 6 младших битов помеченных y или 3FFFFFFFFF - всего 38 битов, что есть 275 миллиардов вариантов, перебранных за 2 недели работы переборной программы

P.S. Остановил программку - ничего путнего не нашлось...

_________________
:dj: https://mastodon.social/@Shaos


03 May 2020 12:42
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22412
Location: Silicon Valley
Reply with quote
Спрятал большие видеоролики под спойлеры, чтобы не качались разом при открытии странички в браузере...

_________________
:dj: https://mastodon.social/@Shaos


14 May 2020 16:46
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22412
Location: Silicon Valley
Reply with quote
Shaos wrote:
Shaos wrote:
Еще я написал текстовую программку чтобы выяснить какого размера должна быть таблица байтов, чтобы при обращении к ней по индексу не было бы потерь на копирование из памяти в кеш данных - и у меня получилось, наращивая размер таблицы от 2^1 и далее 2^2, 2^3 и т.д., что до 2^14 индексирование случайным индексом идет абсолютно одинаковое время, а вот далее - скорость обращения падает в 2 и более раз...

Текст программки под спойлером и мои результаты с 64-битного дебиян-линуха на амд64 ниже:

 lutest.c
Code:
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <time.h>

#define N INT_MAX
#define T char
#define M 0xFF

int main(int argc, char **argv)
{
 int i,j,k,l,n,m;
 unsigned int s;
 time_t t1,t2;
 T *a;
 if(argc<2) n = 22;
 else n = atoi(argv[1]);
 if(n==0) return -1;
 for(l=1;l<=n;l++)
 {
  k = 1<<l;
  m = k - 1;
  a = (T*)malloc(k*sizeof(T));
  if(a==NULL) return -2;
  srand(time(NULL));
  for(i=0;i<k;i++) a[i]=rand()+(rand()<<15);
  i = s = 0;
  t1 = time(NULL);
  for(j=0;j<N;j++)
  {
    s += ((unsigned)a[i])&M;
    i = (i+j+j+s)&m;
  }
  t2 = time(NULL);
  printf("%8.8X 2^%i * %i -> %is\n",s,l,N,(int)(t2-t1));
  free(a);
 }
 return 0;
}

Code:
FFFFFF68 2^1 * 2147483647 -> 5s
AAAAAA18 2^2 * 2147483647 -> 6s
BFFFFFC2 2^3 * 2147483647 -> 5s
0000004B 2^4 * 2147483647 -> 6s
5C87B6EE 2^5 * 2147483647 -> 5s
DB6DB6B0 2^6 * 2147483647 -> 6s
1ED7E6C8 2^7 * 2147483647 -> 5s
CB4F4C26 2^8 * 2147483647 -> 6s
7E567055 2^9 * 2147483647 -> 6s
E721A4D4 2^10 * 2147483647 -> 5s
594CD3B9 2^11 * 2147483647 -> 6s
EC14A96A 2^12 * 2147483647 -> 6s
6551305A 2^13 * 2147483647 -> 5s
7C903FFD 2^14 * 2147483647 -> 6s
64DE1F79 2^15 * 2147483647 -> 15s
AFB68EBD 2^16 * 2147483647 -> 17s
CE4B0F09 2^17 * 2147483647 -> 18s
902C7F06 2^18 * 2147483647 -> 19s
AB68549C 2^19 * 2147483647 -> 28s
D0ECA61B 2^20 * 2147483647 -> 34s
A5FF4DB7 2^21 * 2147483647 -> 73s
CA388996 2^22 * 2147483647 -> 160s

Если у кого есть желание может попробовать на своём компьютере (собирать gcc -O2 lutest.c -o lutest запускать без параметров) и запостить результаты сюда :dj:

P.S. Да, похоже так и есть - у AMD процессоров размер L1 кеша данных 16кб (у меня семейство Bulldozer с микроархитектурой Steamroller):
https://www.extremetech.com/extreme/188776-how-l1-and-l2-cpu-caches-work-and-why-theyre-an-essential-part-of-modern-chips
L1 имеет задержку на доступ 3-4 такта, а L2 - уже 19 тактов (у Steamroller-a), поэтому массивы больше 16кб имеют в среднем в 5 раз более худшие времена доступа если лезть в них действительно случайным образом. Вот инфа про мою 4-коровую (+ 8 графических коров, которые в линухе не юзаются) конфигурацию AMD-проца: http://www.cpu-world.com/CPUs/Bulldozer/AMD-A10-Series%20A10-7850K.html (там правда написано 4 x 16 KB 4-way set associative data caches, т.е. их четыре - видимо один и тот же массив больше 16кб не может быть аккуратно порезан на разные кеши)

P.P.S. Intel Core i5 вроде как имеет 6 x 32KB 8-way дата кэш - там наверное результаты моей программки сдвинуться и до 2^15...

P.P.P.S. Так и есть - проверил на Intel Core Duo с WinXP в Cigwin:
Image

P.P.P.P.S. Откопал свой чёрный G4 Cube и как ни странно он живой ;)
Я его "потерял" при переезде из Нью-Йорка в 2017, а вот сейчас "нашёл" когда коробки для очередного переезда перепаковывал :lol:
Вот его результаты, подтверждающие информацию, что процессор PowerPC G4 имеет L1 кеш данных размером 32кб:
Code:
shaos@g4cube:~/Sources/tests$ ./lutest
FFFFFF9A 2^1 * 2147483647 -> 26s
71C71C0C 2^2 * 2147483647 -> 25s
C30C3108 2^3 * 2147483647 -> 28s
1642C9D6 2^4 * 2147483647 -> 30s
1C71C59A 2^5 * 2147483647 -> 30s
A98EF52C 2^6 * 2147483647 -> 30s
30201446 2^7 * 2147483647 -> 30s
3658AAB7 2^8 * 2147483647 -> 30s
0F83DFB4 2^9 * 2147483647 -> 30s
124C7633 2^10 * 2147483647 -> 30s
3A5A0095 2^11 * 2147483647 -> 33s
66C9001B 2^12 * 2147483647 -> 30s
27B43966 2^13 * 2147483647 -> 30s
9ED6807C 2^14 * 2147483647 -> 30s
886A5016 2^15 * 2147483647 -> 31s
BB4554A4 2^16 * 2147483647 -> 64s
CDBA02EA 2^17 * 2147483647 -> 83s
B15AC01C 2^18 * 2147483647 -> 101s
EF4C360E 2^19 * 2147483647 -> 180s
C11A763B 2^20 * 2147483647 -> 388s
AA959D8B 2^21 * 2147483647 -> 582s
B72B2E0A 2^22 * 2147483647 -> 703s
Так же можно видеть, что копирование байтов из L1 кеша данных в G4 медленнее в 5-6 раз чем у AMD или Intel (разница частоты процессоров - как раз те самые 6 раз)

Результат работы этой же программы на моём новом Apple Mac Mini M1:
Code:
7FFFFF13 2^1 * 2147483647 -> 5s
B6DB6D4C 2^2 * 2147483647 -> 5s
B6DB6D87 2^3 * 2147483647 -> 5s
6DB6DB5A 2^4 * 2147483647 -> 5s
7DF7DF3D 2^5 * 2147483647 -> 4s
1655E896 2^6 * 2147483647 -> 5s
8A212591 2^7 * 2147483647 -> 5s
251D7E59 2^8 * 2147483647 -> 5s
FCA47B05 2^9 * 2147483647 -> 5s
9DFA507A 2^10 * 2147483647 -> 5s
4978893D 2^11 * 2147483647 -> 5s
F47B73D5 2^12 * 2147483647 -> 5s
DC86CF7B 2^13 * 2147483647 -> 4s
FB6D3192 2^14 * 2147483647 -> 5s
53C65B37 2^15 * 2147483647 -> 5s
D1C9ABC1 2^16 * 2147483647 -> 5s
F28779EB 2^17 * 2147483647 -> 5s
BDF5BB47 2^18 * 2147483647 -> 10s
B7BA5EE0 2^19 * 2147483647 -> 12s
FEE7AC92 2^20 * 2147483647 -> 13s
CF852750 2^21 * 2147483647 -> 13s
B83CCEBC 2^22 * 2147483647 -> 16s

Получается размер кэша данных первого уровня на M1 аж 2^17=128KB :o

P.S. Похоже так и есть для "high-performance" ядер:
Quote:
The Apple M1 chip works with 4 high-performance cores, each of which is what Apple described as the “world’s fastest.” These high-performance cores work with ultra-wide execution architecture as well as 192KB instruction cache. These high-performance cores include 128KN data cache and a shared 12MB L2 cache.

There’ll be four high-efficiency cores as well, with wide execution architecture, 128KB instruction cache, 64KB data cache, and shared 4MB L2 cache.
https://www.slashgear.com/apple-m1-chip-revealed-first-apple-silicon-for-mac-10646654/

_________________
:dj: https://mastodon.social/@Shaos


08 Mar 2021 11:13
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22412
Location: Silicon Valley
Reply with quote
Shaos wrote:
Shaos wrote:
...Полосатость можно считать состоянием по умолчанию, т.е. все 5 нулей в столбике будут означать 2 полосы:
Code:
OOOOOOOOO <- игнорируем (всегда есть)
..O..
....OOOOO <- обычный полосатый канал
.O..O
....OOOOO <- обычный полосатый канал
...O.
OOOOOOOOO <- игнорируем (всегда есть)
vvvvv
||||\_01110 ->                     01110
|||\__00001 ->                00001
||\___10000 ->           10000
|\____00100 ->      00100
\_____00000 -> 00000
                ^ ^  ^ ^  ^ ^  ^ ^  ^ ^ <инверсия
               0101001110110100101100100 =======> 0x0A76964
               +----++++----++++----++++
Для представления более "длинных" конструкций просто добавляем битов в начало - т.е. при переполнее 32-битного целого, можно легко перейти к 64-битным (при этом можно будет покрыть все ходилки-ползалки до 12 колонок в длинну, однако реально перебрать все варианты в этом случае будет практически невозможно)...

Вот сделал онлайн тестилку объектов :)
http://lifege.net/life/osd.php?cat=5&hex=A76964
В строке адреса меняем код и глядим :mrgreen:
http://lifege.net/life/osd.php?cat=3&hex=4B3
http://lifege.net/life/osd.php?cat=5&hex=53B60
http://lifege.net/life/osd.php?cat=5&hex=A72B64
http://lifege.net/life/osd.php?cat=5&hex=A52B64
P.S. И это могут быть статические объекты тоже :)
http://lifege.net/life/osd.php?cat=5&hex=E56D4E
P.P.S. А также большие осциллирующие объекты :rotate:
http://lifege.net/life/osd_.php?cat=13&hex=3BB9555ABB49D2AEB556BAA5C96EAD554EEE

Что-то как-то я тему подзабросил:

Attachment:
Screenshot from 2023-04-11 23-38-41.png
Screenshot from 2023-04-11 23-38-41.png [ 50.04 KiB | Viewed 3326 times ]

Суть задумки была тупым перебором от маленьких к большим найти все перемещабельные по полоскам объекты, чтобы потом построить на самых удачных из них компьютер внутри игры Жизнь...

_________________
:dj: https://mastodon.social/@Shaos


11 Apr 2023 23:39
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 43 posts ]  Go to page Previous  1, 2, 3

Who is online

Users browsing this forum: No registered users and 29 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.