[01:58:03] <valexey> ыы! моё однопоточное решение грузит ОБА ядра
[01:58:17] <valexey> второе ядро полностью отжирает при этом ядро линуха :-)
[01:58:34] <valexey> и при этом оно не работает быстрее чем конкуренты
[11:09:42] <s6> http://desertdwellers.org/
[11:39:35] <Kemet> мля, чудеса в решете
[11:46:05] <Kemet> кто сможет объяснить такое чудо-
[11:49:28] <Kemet> есть две процедуры, почти одинаковые, П1 и П2. В П2 дополнительно выполняются некие вычисления, в остальном процедуры идентичны.П1 вызывает П2. При этом участок кода в ПП1 выполняется за 30 сек, а такой же кчасток кода в П2 за 3 секунды. Если же ихз вызывать поочередно, то в обеих участки кода выполняются примнерно за 30.
[11:50:13] <Kemet> да в исследуемом участке П1  нет вызовов П2
[11:53:53] <TRUE> ПП1? Если П2 почти как П1, то зачем П1 вызывает П2?
[11:54:22] <TRUE> этот код на АО?
[11:54:46] <Kemet> а вот если поигратся со стеком вызывающей процедуры, например, поместить переменную, скажем VAR a: ARRAY 16 OF INT32, то тогда время примеорно равно - 3 и 4 сек соотвественно
[11:54:47] <Kemet> да
[11:56:02] <TRUE> а общий код можно вынести в отдельную процедуру?
[11:56:03] <Kemet> TRUE: в реальности там будет разный код, но есть одинаковое - чтение файла. я всё убрал и оставил только чтение,
[11:56:35] <Kemet> для теста
[11:57:15] <TRUE> так это чтение отрабатывает за разное время? Не процессор?
[11:57:20] <Kemet> просто замер времени работы второй процедуры показал, что она работает на порядок быстрее первой, хотя делает больше работы
[11:57:49] <Kemet> вот я и стал экспериментировать чтоб понять
[11:59:34] <Kemet> TRUE: ХЗ, чтение или что. Но я уже сталкивался с ситуацией, когда в одной процедуре одигнаковые, но находящиеся на разных местах участки работают за разное время
[11:59:54] <TRUE> в голову приходят два нюанса, которые могут замедлить работу:
1. важные для алгоритма переменные попали в разные строки кэша, и процессору чаще приходится обращаться в основную память за данными.
2. не отрабатывает DMA (но ОС вряд ли отдаст это на откуп программе)
[12:04:03] <Kemet> вобщзем попробовал еще другие процедуры - вызываемая работает быстрее.
[12:04:53] <TRUE> а как-то выравнивать кадр стека в АО можно?
[12:05:26] <Kemet> но не всегда
[12:05:39] <Kemet> блин это что то с выравниванием связано
[12:06:15] <Kemet> зависит от того что за переменные в определены в вызывающей процедуре, видимо общий размер
[12:06:26] <Kemet> памяти
[12:10:52] <Kemet> TRUE:  PROCEDURE{ALIGNSTACK(XX)} P*
[12:11:18] <Kemet> но это не помогает
[12:11:44] <Kemet> даже бывает хуже
[12:11:55] <Kemet> но бывает и лучше
[12:12:08] <Kemet> бобщем чудеса
[12:12:35] <TRUE> а много переменных у П1?
[12:12:55] <TRUE> что, если там их местами поперставлять
[12:13:35] <TRUE> буфер для чтения файла на стеке или в куче?
[12:14:03] <TRUE> если на стеке, но изменится что-нибудь, если его в кучу перенести?
[12:14:45] <Kemet> я запускал П1 из П0 в которой была переменная ARRAY 16 OF INT32 и тогла они работали за ссравнимое время - 3 и 4 сек ( П0->П1->П2)
[12:15:17] <Kemet> ,eath - gthtvtyyfz vjlekz
[12:15:27] <Kemet> юуфер - переменная модуля
[12:17:42] <TRUE> 16 интов? Это буфер, в который идёт чтение из файла?
[12:18:46] <Kemet> не, просто заглушка для проверки влияния стека если его убрать то 30 и 4 сек, если он есть за 3 и 4 сек
[12:20:16] <Kemet> 10 кратна просадка производительности
[12:21:05] <TRUE> а в А2 стек и сегмент данных не связаны?
[12:21:25] <TRUE> а, вряд ли.
[12:23:27] <TRUE> а нельзя ли вынести общую часть П1 и П2 за пределы процедуры?
[12:23:51] <TRUE> будь то чтение файла или дополнительные вычисления
[12:25:11] <TRUE> там большой код в П2? Можно его увидеть?
[12:37:52] <Kemet> lf!!! djn jyj!!!
[12:37:57] <Kemet> ДА!!!
[12:38:08] <Kemet> сек наво выравнивать на 64
[12:38:38] <Kemet> тепрь П1 работает за 1 сек, а П2 за 5, но тут тоже надо стек выравнять
[12:40:33] <Kemet> да, теперь за 1 и за 3
[12:41:49] <Kemet> нахождение максимального значение в 4ГБ файле Б 1сек, на голом АО, с тяжелой Files
[12:46:04] <Kemet> в 10 раз, 10, Карл!
[12:55:43] <TRUE> это SSD?
[12:55:53] <Kemet> j,sxysq dbyn
[12:55:58] <Kemet> обычный винт
[12:57:04] <TRUE> 1 ГБ в секунду читает? Разве системная шина позволяет провернуть такое?
[12:58:05] <Kemet> с 32 мб кэшем
[13:01:26] <Kemet> TRUE: хз, мож я чего накосячил счас файл перегенерирую, код проверю и повторю.
[13:02:20] <TRUE> для проверки можно прочитанные данные записывать в другой файл. Потом сравнить файлы и убедиться, что они совпадают.
[13:11:08] <Kemet> pfgbcm bltn vtlktyyj
[13:11:14] <Kemet> запись идет медленно
[13:14:34] <TRUE> нет, просто проверить, по всему ли файлу шёл поиск наибольшего значения?
[14:08:57] <Kemet> блин, удалил папку, теперь не знаю, тот ли я файл читал. Логически, программа правильная, позиции в файле устанавливаются. т.е после чтенряи очередной порции проверяю виндовой функцией. но вощможно что оно не читается или я использовал 1ГБ файл и венда его могла целиком закешировать  ибо яж много раз запускал
[14:20:58] <Kemet> лоханулся я, ага
[14:22:03] <Kemet> при перезагрузке в Вин10 там имена дисков поменялись и так совпало что я проверял на 4ГБ файле версие корая не поддерживает файлы болше 2ГБ
[14:51:07] <valexey> запустил очередной прогон. на этот раз с многопоточкой
[16:30:28] <Kemet> b rfr htpekmnfns
[16:30:38] <Kemet> и как результаты
[16:34:18] <valexey> ещё прогоняется
[16:34:54] <valexey> я не могу запустить только один тест, отдельно от остальных. вдруг там железо поменялось, или еще что-то подкрутили на стороне сервера?
[16:35:01] <valexey> поэтому каждый раз полный прогон
[16:44:31] <TRUE> на виртуалках может быть горячая миграция. Это когда она перетекает с одного железа на другое без останова.
[16:45:10] <TRUE> правда, эта штука не обязательно поддерживается твоей средой виртуализации
[16:51:26] <valexey> там еще и условия могут меняться - типа как там комп соседи нагружают
[17:31:28] <vlad2> valexey: чего не так я с cgroups сделал, что оно у меня не падает? Все делал по твоей инструкции.
[17:32:48] <valexey> оно на каждом этапе ошибку не выдает?
[17:33:12] <valexey> запускаешь через cgexec ?
[17:33:30] <vlad2> Ага. Проходит как ни в чем не бывало.
[17:34:28] <valexey> хм. а что скажет cat /sys/fs/cgroup/memory/bench128/memory.limit_in_bytes
[17:34:30] <valexey> ?
[17:34:47] <vlad2> Вечером посмотрю :)
[17:34:57] <valexey> ну и, до кучи, cat /sys/fs/cgroup/memory/bench128/memory.memsw.limit_in_bytes
[17:35:08] <valexey> второе - это ограничение по свопу
[17:35:19] <vlad2> Пока требуется экстрасенс :)
[17:35:26] <valexey> :-)
[17:35:37] <valexey> о! битва экстрасенсов!
[17:35:49] <valexey> пущай вместо поиска могил всяких, ищут багги в коде!
[17:36:45] <vlad2> memory.memsw.limit_in_bytes не записалось как ты и гововрил.
[17:37:00] <valexey> ага. логично.
[17:37:17] <valexey> можно, для чистоты эксперимента, своп на машине отключить
[17:37:26] <valexey> чтобы гарантировать что оно свопиться не полезет
[17:37:51] <valexey> благо включается-отключается своп в линухе легко и без перезагрузок
[17:38:15] <valexey> sudo swapoff -a
[17:38:37] <valexey> ну а вкл обратно: sudo swapon -a
[17:38:47] <vlad2> А включить? А если у меня памяти всего 2Gb? :)
[17:40:09] <valexey> ну, я написал как :-)
[17:40:20] <valexey> ну и видно же сколько свопа используется в системе прямо сейчас
[17:40:31] <valexey> обычно линух его не использует до последнего.
[17:40:35] <valexey> в отличие от винды
[17:49:04] <vlad2> Винда его использует, чтобы больше под файловый кэш было.
[17:49:13] <valexey> в винде всё рассчитано на то, что ОЗУ всегда недостаток. По крайней мере раньше было так. Поэтому винда всегда стремится побольше в своп скинуть, и часть оперативки держать свободной.
[17:49:28] <valexey> Ну и чтобы под файловый кеш место было, да.
[18:03:58] <valexey> хех. сейчас еще окажется, что не правильно у меня время считается для случая многопоточных программ
[18:10:55] <valexey> вот почему я читаю Аненербе исключительно как Аненеребе? :-)
[18:23:48] <valexey> да нет, правильно время считается
[18:25:12] <valexey> многопоточка на больших файлах сливает :-)
[18:25:15] <valexey> в данном случае
[18:25:24] <valexey> ну и вообще, там сложность похоже O(n^2)
[18:31:44] <valexey> по характеристикам он похож на vlad simple
[18:31:49] <valexey> только раза в два быстрее ;-)
[18:31:57] <valexey> т.е. и там и там квадратичная сложность
[18:46:16] <VAR> (* ZONE ZONA1; CODE LABELED GET_NAME ARGUMENTS () BEGIN CODE (* RETURN SMTHING *) END CODE END ZONA1 *)
[18:46:44] <VAR> ZONE LABELED ZONA1
[18:47:29] <VAR> сталкерский метахаскель пытаюсь изобрести
[18:48:06] <VAR> типы, категории, топики - это всё частные случаи зон по Стругацким Кайдановскому Тарковскому
[19:10:07] <VAR_PARALLAX> https://www.facebook.com/evgenii.philippov/posts/847388108736432?pnref=story
[19:39:10] <valexey> народ на паскале игры пишет до сих пор! o_O
[19:39:15] <valexey> https://github.com/ChaosForge/doomrl
[21:20:50] <vlad2> valexey: не, там та же сложность. медленнее потому что блоки мельче (чтобы в память влезть) и блоков больше (слияние тормознее)ю
[21:22:25] <vlad2> Кроме того за счет большего количества блока хуже работает кэширование диска.
[21:24:14] <vlad2> Т.е. без особенностей диска я думаю оно было бы быстрее. Поробуй запустить его без ограничений на дисковый кэш - должно быть быстрее.
[23:24:01] <geniepro> vlad2: а ты уже зарплату такими купюрами получешь? http://nationalgreatregistry.generalpostoffice.international/index.php?title=Office_of_the_Treasury_for_The_United_States_of_America#The_legal_tender_of_the_Government_of_The_United_states_of_america
[23:25:35] <valexey> geniepro: ты на что намекаешь?!
[23:25:38] <valexey> он же не нелегал
[23:25:50] <valexey> только нелегалы получают зарплату купюрами
[23:26:04] <geniepro> valexey: ну он же там и не граждангин ещё вроде )
[23:26:33] <valexey> и?
[23:26:44] <valexey> один фиг за кеш там никто не работает из тех кто имеет разрешение на работу
[23:26:57] <geniepro> — Ты кем в детстве мечтал стать?
— «Свободная касса» кричать!
— Офигеть, круто! Ладно, давай скафандр надевай. Сейчас солнечную батарею пойдём менять!
[23:28:45] <valexey> geniepro: думаешь с экологией скоро будет настолько фигово?