Go : параллельное выполнение

Olej писал(а): ↑
29 фев 2024, 02:53
скорость когда число горутин заметно превышает число физических процессоров/ядер

Сравниваем:
40 горутин (как было уже показано):

olej@R420:~/2024/own.BOOKs/BHV.Go.3/examples.work/goproc/mining$ ./mining -b 8000 -v 1000000 -w=20 -g=40
горутин 40; размер блока 8000
       1.448µs : 0000000 | 1630B8A0062DF2282D00EC3083748DC7E32636A218...
      80.552µs : 0000002 | 110649121CB89CDF23BBDEF0A182D521D9C95C99D0...
     101.152µs : 0000001 | 110649121CB89CDF23BBDEF0A182D521D9C95C99D0...
     735.311µs : 0000013 | 0A70DE125FDF60C82600AA5F7E787D4EF60CED4C63...
     832.933µs : 0000031 | 0066A9BBA0F4149C5423D136D92484D58AE62EA353...
    5.545726ms : 0001490 | 003AC6A27060ACBCFBEC6D7AB123AF80AAFB6CB60D...
    6.086617ms : 0001670 | 001443A6F720352EC00B335F0060DA1701E52C3744...
   21.325801ms : 0008708 | 000FED88A9BE6D729B70589C5F34884B24ABB3538C...
   33.648817ms : 0013631 | 0007B65302A8EF35D6AC335879CA65FBCECB5BFD7E...
   37.524484ms : 0014874 | 0002D2DA3F63FB9805B47609C6225191989B49E59D...
   65.608028ms : 0028765 | 000269355591B2C2EAD19F7F77F86F93445F10FDC3...
   82.251744ms : 0036214 | 00012E5924E21796CB3E2B9CBBBA6495A90D093836...
   142.65488ms : 0063781 | 000038E088D0320665B3EC72000E0250CCB55F9B4C...
  242.268921ms : 0112182 | 00001797F86B7E769526228A1E636BD8B3EA34EBCA...
  2.013846182s : завершение опроса

100 горутин - 100 параллельных веток выполняется...

Код: Выделить всё

  
olej@R420:~/2024/own.BOOKs/BHV.Go.3/examples.work/goproc/mining$ ./mining -b 8000 -v 1000000 -w=20 -g=100
горутин 100; размер блока 8000
       1.763µs : 0000000 | 1630B8A0062DF2282D00EC3083748DC7E32636A218...
      85.927µs : 0000002 | 110649121CB89CDF23BBDEF0A182D521D9C95C99D0...
     201.614µs : 0000001 | 110649121CB89CDF23BBDEF0A182D521D9C95C99D0...
     237.443µs : 0000013 | 0A70DE125FDF60C82600AA5F7E787D4EF60CED4C63...
     275.222µs : 0000031 | 0066A9BBA0F4149C5423D136D92484D58AE62EA353...
    5.357094ms : 0001490 | 003AC6A27060ACBCFBEC6D7AB123AF80AAFB6CB60D...
    5.797881ms : 0001670 | 001443A6F720352EC00B335F0060DA1701E52C3744...
   18.240994ms : 0008708 | 000FED88A9BE6D729B70589C5F34884B24ABB3538C...
   22.794165ms : 0011400 | 0008CCC1EBE1AFAC852097E6162A77A61B80B2234D...
   26.512151ms : 0013631 | 0007B65302A8EF35D6AC335879CA65FBCECB5BFD7E...
   59.065388ms : 0028765 | 000269355591B2C2EAD19F7F77F86F93445F10FDC3...
   73.726334ms : 0036214 | 00012E5924E21796CB3E2B9CBBBA6495A90D093836...
   128.75394ms : 0063781 | 000038E088D0320665B3EC72000E0250CCB55F9B4C...
  226.454647ms : 0112182 | 00001797F86B7E769526228A1E636BD8B3EA34EBCA...
  1.768752404s : завершение опроса

И всё ещё есть какое-то улучшение, где-то что-то выскребается: 1768752404÷2013846182=0,878295681 - 88% от предыдущих 100%.
1000 горутин - 1000 параллельных веток выполняется

Код: Выделить всё

olej@R420:~/2024/own.BOOKs/BHV.Go.3/examples.work/goproc/mining$ ./mining -b 8000 -v 1000000 -w=20 -g=1000
горутин 1000; размер блока 8000
       1.848µs : 0000000 | 1630B8A0062DF2282D00EC3083748DC7E32636A218...
     115.931µs : 0000002 | 110649121CB89CDF23BBDEF0A182D521D9C95C99D0...
     135.766µs : 0000001 | 110649121CB89CDF23BBDEF0A182D521D9C95C99D0...
     161.356µs : 0000013 | 0A70DE125FDF60C82600AA5F7E787D4EF60CED4C63...
     347.502µs : 0000087 | 06AF3918ACD6F1B25C98EBEE82A2AB63220483C823...
      631.74µs : 0000314 | 02D3187BE1EF07F056ABBC2858F85BCCF4AE14C7EA...
    1.036444ms : 0000453 | 0215C820E323C6B30486B2AE95335D90A3DC2411E9...
    1.575007ms : 0000541 | 009689102B4179F39E537B0E39607A7DC1E7DBE4AA...
    1.712514ms : 0000540 | 009689102B4179F39E537B0E39607A7DC1E7DBE4AA...
    3.627501ms : 0001146 | 00836430BF88A6FF93C676AD47FC369B930B8EFE08...
    5.046854ms : 0001283 | 001443A6F720352EC00B335F0060DA1701E52C3744...
    5.277489ms : 0001670 | 001443A6F720352EC00B335F0060DA1701E52C3744...
   23.665708ms : 0008708 | 000FED88A9BE6D729B70589C5F34884B24ABB3538C...
   28.781342ms : 0011400 | 0008CCC1EBE1AFAC852097E6162A77A61B80B2234D...
    32.44628ms : 0013631 | 0007B65302A8EF35D6AC335879CA65FBCECB5BFD7E...
   35.227234ms : 0014874 | 0002D2DA3F63FB9805B47609C6225191989B49E59D...
   59.086869ms : 0028765 | 000269355591B2C2EAD19F7F77F86F93445F10FDC3...
   75.135977ms : 0036214 | 00012E5924E21796CB3E2B9CBBBA6495A90D093836...
  125.498503ms : 0063781 | 000038E088D0320665B3EC72000E0250CCB55F9B4C...
  219.189608ms : 0112182 | 00001797F86B7E769526228A1E636BD8B3EA34EBCA...
  1.803812843s : завершение опроса

Вот теперь уже точно одинаково: хоть в 100 параллельных ветвей выполняй, хоть в 1000.

Olej писал(а): ↑
29 фев 2024, 03:12
Вот теперь уже точно одинаково: хоть в 100 параллельных ветвей выполняй, хоть в 1000.

Вообще то, Go идеально подходит для выполнения криптографических задач: ни один из (широкораспространённых) языков программирования не располагает:
1). такой простотой превращения записи в коде последовательного алгоритма в параллельное выполнение... (это плюс для программиста)
2). такой эффективной, лёгкой модели параллельного выполнения (это плюс для программиста).

В примере майнинга выше, для конкретизации, использован крипто алгоритм SHA-512 (использующийся также, например, в формировании IPv6 адресов пиринговой сети Yggdrasil), точно так же можно использовать SHA-256, применяемый, по традиции (идущей ещё от Bitcoin), в блокчейнах практически всех криптовалют.
Но с той же лёгкостью вы сможете перестроить такой код под несколько десятков крипто алгоритмов из стандартной библиотеки Go, или под любой дополнительных алгоритмов, из импортируемых пакетов ("golang.org/x/crypto") репозитория GoLang.

Olej писал(а): ↑
29 фев 2024, 03:25
Но с той же лёгкостью вы сможете перестроить такой код под несколько десятков крипто алгоритмов из стандартной библиотеки Go, или под любой дополнительных алгоритмов, из импортируемых пакетов ("golang.org/x/crypto") репозитория GoLang.

Смотрю как это делать...
В Go «раскрутка» программной поддержки криптографии для вашего кода начинается от пакета crypto, где мы найдём (https://pkg.go.dev/crypto) любопытный комментарий, который подскажет вам где и как использовать поддерживаемые методы:

Код: Выделить всё

type Hash uint

const (
   MD4         Hash = 1 + iota // import golang.org/x/crypto/md4
	MD5                         // import crypto/md5
	SHA1                        // import crypto/sha1
	SHA224                      // import crypto/sha256
	SHA256                      // import crypto/sha256
	SHA384                      // import crypto/sha512
	SHA512                      // import crypto/sha512
	MD5SHA1                     // no implementation; MD5+SHA1 used for TLS RSA
	RIPEMD160                   // import golang.org/x/crypto/ripemd160
	SHA3_224                    // import golang.org/x/crypto/sha3
	SHA3_256                    // import golang.org/x/crypto/sha3
	SHA3_384                    // import golang.org/x/crypto/sha3
	SHA3_512                    // import golang.org/x/crypto/sha3
	SHA512_224                  // import crypto/sha512
	SHA512_256                  // import crypto/sha512
	BLAKE2s_256                 // import golang.org/x/crypto/blake2s
	BLAKE2b_256                 // import golang.org/x/crypto/blake2b
	BLAKE2b_384                 // import golang.org/x/crypto/blake2b
	BLAKE2b_512                 // import golang.org/x/crypto/blake2b
)

Olej писал(а): ↑
29 фев 2024, 03:29
подскажет вам где и как использовать поддерживаемые методы

Делаю такое маленькое приложение:

Код: Выделить всё

package main

import (
	"crypto"
	"fmt"
	_ "golang.org/x/crypto/md4"
	_ "crypto/md5"
	_ "crypto/sha1"
	_ "crypto/sha256"
	_ "crypto/sha512"
	_ "golang.org/x/crypto/ripemd160"
	_ "golang.org/x/crypto/sha3"
	_ "golang.org/x/crypto/blake2s"
)

func main() {
	for hash := crypto.MD4; hash < crypto.BLAKE2b_512; hash++ {
		fmt.Printf("%-15s\t%v\t%d\n", 
		           hash, hash.Available(), hash.Size())
	}
}

Мы всего лишь хотим посмотреть доступность каждого из методов для использования в своём коде, и длину создаваемой каждым из этих методов хеш-суммы.
При компиляции приложения нас ждёт, ожидаемая впрочем, неприятность:

Код: Выделить всё

olej@R420:~/2024/own.BOOKs/BHV.Go.3/examples.work/goproc/mining$ go build cripto+.go
cripto+.go:13:2: no required module provides package golang.org/x/crypto/blake2s; to add it:
    go get golang.org/x/crypto/blake2s
cripto+.go:6:2: no required module provides package golang.org/x/crypto/md4; to add it:
    go get golang.org/x/crypto/md4
cripto+.go:11:2: no required module provides package golang.org/x/crypto/ripemd160; to add it:
    go get golang.org/x/crypto/ripemd160
cripto+.go:12:2: no required module provides package golang.org/x/crypto/sha3; to add it:
    go get golang.org/x/crypto/sha3

Но мы уже работали с модулями ранее по тексту, и знаем как побороть такую напасть (и не ручным импортом, как говорят подсказки: go get ... — хотя и так можно) а вот так:

Код: Выделить всё

olej@R420:~/2024/own.BOOKs/BHV.Go.3/examples.work/goproc/mining$ go mod tidy
go: finding module for package golang.org/x/crypto/sha3
go: finding module for package golang.org/x/crypto/blake2s
go: finding module for package golang.org/x/crypto/ripemd160
go: finding module for package golang.org/x/crypto/md4
go: downloading golang.org/x/crypto v0.20.0
go: found golang.org/x/crypto/blake2s in golang.org/x/crypto v0.20.0
go: found golang.org/x/crypto/md4 in golang.org/x/crypto v0.20.0
go: found golang.org/x/crypto/ripemd160 in golang.org/x/crypto v0.20.0
go: found golang.org/x/crypto/sha3 in golang.org/x/crypto v0.20.0
go: downloading golang.org/x/sys v0.17.0

Происходит импорт из Интернет, в результате чего (после некоторой паузы связанной с реальной загрузкой из Интернет) файл манифеста текущего модуля поменяется:

Код: Выделить всё

olej@R420:~/2024/own.BOOKs/BHV.Go.3/examples.work/goproc/mining$ cat go.mod
module mining

go 1.22.0

require golang.org/x/crypto v0.20.0

require golang.org/x/sys v0.17.0 // indirect

Вот теперь приложение можно собирать и исполнять...

Olej писал(а): ↑
29 фев 2024, 03:36
Вот теперь приложение можно собирать и исполнять...

Код: Выделить всё

olej@R420:~/2024/own.BOOKs/BHV.Go.3/examples.work/goproc/mining$ go build cripto+.go

Код: Выделить всё

olej@R420:~/2024/own.BOOKs/BHV.Go.3/examples.work/goproc/mining$ ./cripto+
MD4             true    16
MD5             true    16
SHA-1           true    20
SHA-224         true    28
SHA-256         true    32
SHA-384         true    48
SHA-512         true    64
MD5+SHA1        false   36
RIPEMD-160      true    20
SHA3-224        true    28
SHA3-256        true    32
SHA3-384        true    48
SHA3-512        true    64
SHA-512/224     true    28
SHA-512/256     true    32
BLAKE2s-256     true    32
BLAKE2b-256     false   32
BLAKE2b-384     false   48

Вот это приложение, бесцельное по своему выполнению, в общем, можно использовать как заготовку, которую наполняем целевым кодом при намерении использовать любой из алгоритмов хеширования (я, по крайней мере, так пользуюсь).

Olej писал(а): ↑
29 фев 2024, 03:25
Но с той же лёгкостью вы сможете перестроить такой код под несколько десятков крипто алгоритмов из стандартной библиотеки Go, или под любой дополнительных алгоритмов

Прямо сегодня, вот сейчас, в Telegram-канале по EmerCoin (https://t.me/emernews) проскочило очень актуальное обсуждение относительно алгоритмов хэширования и их реализации, в частности с использованием SIMD инструкций процессора. Это сильно актуально, поэтому сохраняю как цитаты (а не как ссылки):

Дело не в медленности а в стандарте и в том что там 64 раунда которые дают математически доказанное распределение ни такое идеальное как sha3 но в 2009 и 2013 sha3 еще не был ни стандартизирован, ни доказан.
Sha3 оптимальнее чем sha256, имеет меньше раундов-13, более легковесен в имплементации(что cpu,что кремний) и дает лучшее распределение результатов.
Он бы больше подошёл чем sha256 в момент изобретения биткойна, но его тогда просто небыло.

Ответ потому что blake3/aragon другие, они сильно отличаются приспособленны для других задач, и дают менее "хорошие" результаты. Быстрее - не всегда значит лучше.
В случае хеширования есть куча математических и криптографических критериев которые описывают финальный результат и требования, в том числе распределение.
В случае например blake3 он появился в 2020 году как эволюция над blake2(2012), но не является хорошо проверенным стандартом как sha256 (2001).
Кроме того blake3 в большинстве процессоров отсутствует как встроенная и аккселерированная функция, его нету в библиотеках, и внедрение займет еще года прежде чем получит признание и распространение.
В случае большинства arm/intel/amd/riscv он будет даже кое где медленне в разнородных задачах изза слома контекста... И опять же ecdsa использует не блейк а значит у вас будет еще и зоопарк хешфункций с большими рисками

Я в курсе за симды, и знаю как они работаю на глубоком уровне, это моя прямая специализация.
Я вовлечен как в создание чипов, так и в оптимизации кода под разные платформы hpc.

Но чтобы не уходить от темы
1) ответ на вопрос почему sha256 что в битке, что в emercoin был выше.

2) я понимаю ваш фанатизм под лозунгом давайте засунем везде "blake3" и SIMD, на это ответ был выше blake3 еще юн и не стандартизирован, не везде присутствует.
- Кроме того для криптографии все еще требуется sha256 и никуда вы от этого быстро не уйти, если вы хотите чтобы ваш телефон открывал ссылки, проходила оплата кредитной картой, включался свет/газ и работали еще 80мил разных приложений каждый день

3) SIMD инструкции не новы это Flynn's арч их использовали еще в Cray-1 1977, и в CM-1/CM-2 (1983-1987) hypercube thinking machine довелось на них тоже поработать, они не идеальны и как вы выше упомянули крепко завязаны на триды/ядра - при массивном использовании в отличии от single thread тестов вы получите крайне сильное замедление и снижение частоты соседних процессов и ядер. Это последствия.

И при кажущейся скорости в 1 потоке, в многопоточной обработке скорость упадет более чем в 3-6-8 раз для Intel.
Это не реально параллельные SIMT, SIMD жертва баланса дешево/массово.

Olej писал(а): ↑
01 мар 2024, 10:30
сильно актуально

Если интересно почитать, почитайте тут.
https://stackoverflow.com/questions/375 ... ogram-down
Если мало и будут вопросы, дам еще/либо самострятельно гугл в помощь.
При использовании SIMD инструкций в thread/multicpu режимах частота ядер, в том числе и соседних будет снижаться, поскольку SIMD потребляют точечно в разы больше энергии для моментального исполнения инструкций, плюс из-за массового обращений к памяти немного будет блокировать соседей притормаживая их по тактам.

Linux-ru