Телеграмм чат группы modernperl страница 7704

Andrey Konovalov

Цикл конечно жесть, если так на мильон символов - всё время потратим тупо на интерпретацию "байт-кода" perl

это ты самый медленный код пытался придумать?

21:10пожаловаться #1

$ perl -MDevel::Peek -E '$a="abcdefghijkl"; $b="abcdef01234"; $c = $a ^ $b; Dump($c);'
SV = PV(0x99b110) at 0x9ffa90
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x9c6a10 "\0\0\0\0\0\0WY[Y_l"\0
  CUR = 12
  LEN = 14

21:11пожаловаться #2

Sergey Zhmylove

Щьо за трэш? И это производительный код?? Ффууу

Это как таковой "алгоритм". Я не думаю, что такое вообще нужно делать на perl

21:11пожаловаться #3

ксор для строк в перле особым образом определён

21:11пожаловаться #4

ксор для строк в перле особым образом определён

Оно понятно, но что если совпадают первые несколько символов из миллиона? Зачем читать из памяти весь миллион? perl же не знает, зачем тебе этот xor нужен дальше

21:12пожаловаться #5

хранить строки на миллион символов тоже так себе идея

21:13пожаловаться #6

Понятно, что и по одному байту читать - тоже треш. Должен быть архитектурно-зависимый код, который будет, например, для 64-х битного Intel юзать соотв инструкции процессора.

21:14пожаловаться #7

При этом читать выровнено по 8 байт за раз и делать xor rax, rbx, дальше не помню как инструкцию называется - в общем, искать 1-й установленный бит

21:15пожаловаться #8

Но если xor rax, rbx дало сразу ноль, то это по флагу z по-моему заметно будет

21:15пожаловаться #9

это всё было давно. щас лучше даже не пытаться лезть с колхозными оптимизациями

21:15пожаловаться #10

это всё было давно. щас лучше даже не пытаться лезть с колхозными оптимизациями

Ну, сишный код в принципе скомпилируется весьма оптимизированно

21:16пожаловаться #11

Хотелось бы верить конечно...

21:16пожаловаться #12

зависит от того, считаешь ли ты четверть-половину пропускной способности рам достаточно для себя оптимизированными

21:17пожаловаться #13

Просто действительно держать в голове весь гигантский набор современных инструкций - можно конечно, но нужно заниматься этим долгие годы. А так да, вроде как gcc вполне оптимизирует, а уж Intel compiler так и того круче :)

21:17пожаловаться #14

соответственные функции соответствующей либц не зря кушают свой хлеб

21:18пожаловаться #15

Ну, я начинал с 386-го, и для меня в общем до сих пор свято правило "чем меньше читаешь память - тем лучше".

21:18пожаловаться #16

читать память всё равно придётся

21:18пожаловаться #17

весь вопрос как сделать так чтобы оно по максимуму попало в кеши и не сбрасывалось

21:19пожаловаться #18

читать память всё равно придётся

Но одно дело читать её ровно до того момента, пока не будет расхождения, а другое дело - непредсказуемое количество памяти читать.
Т.е. подход "давайте $a поксорим с $b" - очень такой себе, поскольку мы заранее не можем гарантировать, что $a и $b - это не "гигабайт-тебе-в-спул" случай

21:20пожаловаться #19

недавно ж статью я где-то кидал, тут или в беседке. про оптимизацию перемножения матриц. код там сишный, но его в несколько приёмов оптимизировали и всё равно тема была не до конца раскрыта