[00:35:44] <vlad2> TRUE: да, российскую
[00:45:06] <valexey> как бы намекают, что с этой страной лучше не связывать своё финансовое благополучие
[01:46:36] <valexey> http://ic.pics.livejournal.com/chlord/14449090/6169/6169_900.gif
[01:46:48] <valexey> про заказчика и исполнителя
[02:16:06] <valexey> Поправил скрипты, чтобы нормально отрабатывалось и модуловское решение (merge_qs), запустил быстрый прогон (каждый файл один раз будет прогнан). Так что часов через 5 наверно прогон будет закончен, результаты автоматически опубликуются.
[02:23:19] <vlad2> Эх, долго ждать...
[02:45:15] <vlad2> Apple have closed the case with the following response:
This issue behaves as intended based on the following:
It was requested by security, you can no longer create items in /Volumes unless root.
[02:45:50] <vlad2> Народ срет кирпичами. This is a horrible, stupid change. Just how does it enhance security?
[02:46:20] <valexey> ыыы
[02:46:24] <valexey> жесть
[02:50:41] <vlad2> Причем с точки зрения кастомеров наш продукт глючит, а не новенький мак. НЕНАВИСТЬ
[02:59:40] <_valexey__> ну логично. операционка она как стихия, она как природа - она просто есть
[02:59:50] <_valexey__> а вы обязаны под нее подстраиваться и решать проблемы!
[02:59:57] <_valexey__> за это вам и платят!
[03:00:16] <_valexey__> требуйте привилегий рута :-)
[03:05:23] <_valexey__> новое решение от comdiv'a похоже быстрее (или такое же) как твой fast
[03:05:31] <_valexey__> посмотрим что там с многопоточкой будет :-)
[03:16:14] <_valexey__> vlad2: http://forum.oberoncore.ru/viewtopic.php?f=70&t=5925&p=99557#p99554
[03:16:16] <_valexey__> читал?
[03:16:26] <_valexey__> "Однако последний раз, насколько я помню, Вы прицепились к Ткачёву.
Я не помню у Информатики-21 примеров "наглого вранья"."
[03:16:28] <_valexey__> :-)
[03:16:42] <_valexey__> " (а что, разбираться в тонкостях кэширования, допустим, конкретного процессора да ещё под него оптимизироваться - это ГЛАВНОЕ? Или главное - качества софта и асимптотика в быстродействии)"
[03:16:45] <_valexey__> бгг
[03:16:55] <_valexey__> Главное это асимптотики в быстродействии...
[03:17:03] <_valexey__> /me triplefacepalm
[03:17:20] <_valexey__> а ничего что алгоритмы с худшей асимптотикой часто работает в разы быстрее чем с лучшей?
[03:17:37] <_valexey__> даже на больших объемах данных
[03:19:00] <_valexey__> модуловское решение нишмогло:
128 18.30
256 38.12
512 76.50
1024 154.81
2048 failed
4096 failed
[03:34:32] <vlad2> _valexey__: да там все одно и тоже - щаз просто кемета выгонят и продолжится заповедник.
[03:41:21] <_valexey__> не, ну они потихоньку эволюционируют. то вот автокомплит для себя открыли, то вот осознали что секции объявлений сущностей удобней в произвольном порядке иметь
[03:41:34] <_valexey__> глядишь, и до объявление переменных по месту додумаются :-)
[03:42:20] <_valexey__> а потом, может быть, кто-то из них и поймет наконец какое отношение имеют асимптотики сложности алгоритмов к реальной жизни и чем в действительности нужно руководствоваться
[03:43:48] <_valexey__> вон у comdiv'a теоретиццки его алгоритм имеет O( n ) сложность, то есть линейную, а mmap-решение имеет O( n * log n )
[03:43:55] <_valexey__> и шо, кто в реальной жизни быстрее получился?
[03:44:57] <_valexey__> при том, что из за того, что время произвольного доступа при росте колличества данных растет, линейный алгоритм внезапно может стать нелинейным!
[06:17:17] <_valexey__> готовы результаты прогона тестов
[06:17:23] <_valexey__> https://github.com/valexey/bigbench
[06:17:32] <_valexey__> https://github.com/valexey/bigbench/blob/master/results.txt
[06:22:12] <_valexey__> многопоточное решение от однопоточного по производительности оказалось неотличимым
[08:06:11] <geniepro> _valexey__: у тебя на сервере ненастоящие два ядра ))
[08:27:50] <geniepro> http://www.arbinada.com/ru/node/1550 Кактус, или как перестать грызть Lazarus (Serguei_Tarassov, чт, 28/07/2016 - 10:15)
"Первый раз о тестировании сладкой парочки, состоящей из Free Pascal (FPC) - компилятора и библиотек общего назначения FCL, и Lazarus - библиотеки компонентов LCL и среды разработки, я написал еще в 2010 году. Выводы были не слишком утешительные.
С той поры минуло 6 лет, за которые довелось не только разработать несколько небольших проектов на FPC/Lazarus (например, Firebird profiler), но и проделать реальный эксперимент по миграции достаточно большой (около 1М строк) системы класса Small ERP. Предупрежу сразу, что эксперимент я волюнтаристски прервал ввиду превращения Lazarus в тот самый кактус из фольклора.
Сказанное не значит, что Кактус плох. Инструмент вполне пригоден для профессиональной коммерческой разработки. Для себя я установил эмпирический лимит в 100К строк, за которыми начинаются проблемы, систематическое и героическое преодоление которых будет стоить намного дороже, чем лицензии на Delphi Professional. Для других классов приложений лимит может оказаться иным, но не думаю, что порядки величин будут различаться."
[09:53:01] <Kemet> _valexey__: у меня отличаются результаты одно и многопоточного решения на АО
[09:53:19] <Kemet> но в АО ФС тормозная, может в этом дело
[09:54:18] <Kemet> и таки перевести на 64 битные указатели в файлах оказалось сложнее ибо вместо того, чтобы использовать спецтип Files.Address все лепили LONGINT
[10:39:22] <prospero3000> Вся скорость вычислитльной задачи свелась к скорости ввода вывода?,))
[10:39:30] <prospero3000> Кто бы мог подумать))
[10:45:48] <prospero3000> На счёт Лазарус, по личному опыту -- прикольно, но не более того. Бывает очень неудобен.
[10:49:49] <prospero3000> Рассказ о том, как "мы не умеем проектировать архитектуру".
[10:52:00] <Kemet> prospero3000: зависит от реализации, если сортировку норм делать, то получится то же самое что в БД индексирование, а это в сотню строк кода не влезет
[10:53:00] <prospero3000> А как сортировку можно сделать не норм?
[10:53:27] <Kemet> однако, индексы в БД не про это, ьам сама индексация может быть не сильно быстрая, часьл используют быструю соритровку + слияние, нужда в индексах- быстрый доступ, быстрая выборка. Так что да, задача не айс
[10:54:00] <prospero3000> Так мжет не надо использовать БД? SQL торомоз, не?
[10:54:39] <Kemet> с чего бы
[10:55:23] <Kemet> доступ по индексам - быстро, там всякий технокалий для этого
[10:56:21] <prospero3000> Ну, например. Сетевое соединение, фрагментированность БД, затраты на преобразование запроса, длинный запрос на короткую выборку, для чтения одной строки -- можно прочитать всю базу. Разве нет?
[10:56:55] <Kemet> кэши
[10:57:33] <prospero3000> Кэши?))) При базе в 50 ГБ?))) Удачи)
[10:58:33] <Kemet> а ты думал. кэши и индексы. их правильное построение и использование
[10:59:12] <prospero3000> Разделение таблиц на разных машинах.
[10:59:23] <prospero3000> Лучший кэш.
[11:01:07] <Kemet> это уже другое
[11:02:13] <prospero3000> Это как раз то самое. Когда приходишь в СберБанк и тётя за стеклом говорит "подождите 5 минут, компьютер посла запрос" хочется перестрелять всех разработчиков СберБанка.
[11:14:11] <prospero3000> Кемет, ты давай уже или туда, или сюда. У меня компьютер устал тренькать)
[11:15:01] <Kemet> это ты помехи наводишь
[11:16:27] <prospero3000> Тем хуже для тебя. Плохо у тебя с межмодульным контролем))
[11:24:35] <TRUE> если кто-то не смог нормально спроектировать СУБД, то это не значит, что она плохая
[11:25:24] <TRUE> более того - если они там не смогли воспроизвести у себя модель на уровне СУБД, то и архитектуру они себе никакую не сделают.
[11:25:58] <TRUE> так что "мы не умеем проектировать архитектуру" станет ещё страшнее без СУБД
[11:27:56] <geniepro> prospero3000: так нафига тебе компилятор языка oberon-07 с русскоязычным синтаксисом?
[11:29:09] <prospero3000> Да вроде написал же на форуме. Для носителя русског оязыка предпочтительней русский язык. Экономия ресурсов.
[11:30:19] <prospero3000> Есть ещё пара целей, но это очень далеко.
[11:40:36] <geniepro> prospero3000: но почему именно самодельный оберон-07, когда есть тот же Глагол или симантическая IDE с разными синтаксисами
[11:41:13] <geniepro> если уж экономить ресурсы -- так надо брать готовое
[11:41:27] <prospero3000> Потому что Глагол -- это бестолковая поделка. Оберон-07 -- вылизанный язык
[11:42:03] <geniepro> оберон-07 -- менее пригоден для промышленного применения, чем оберон-2, а глагол -- это тот же оберон-2
[11:42:44] <geniepro> ладно, другая итерация -- вот делали блекбокс с национальными ключевыми словами -- почему его не взять?
[11:43:22] <prospero3000> Можно. БлекБокс мне наиболее симпатичен. Но надо лезть во внутрь кодогенератора. А это бесполезно.
[11:43:45] <geniepro> prospero3000: если раньше не смотрел, то посмотри: http://www.sem-tech.net/
[11:45:15] <prospero3000> Нет таког осайта))
[11:45:30] <prospero3000> Упсь.
[11:45:34] <prospero3000> Открылось))
[11:48:51] <prospero3000> Затея интересная. Будем посмотреть.
[11:50:57] <prospero3000> Ах вот оно что...))) "Введите 20-значный ключ"!))
[11:51:25] <prospero3000> Нет уж. Уж лучше БлэкБокс.
[11:54:37] <geniepro> ну да, эта их идея с толи продажей, то ли просто регистрацией и сгубила их проект
[11:54:49] <geniepro> но там посмотреть можно и в демо режиме
[11:55:08] <prospero3000> Посмотрел. Практически Паскал на русском.
[11:55:31] <geniepro> ну вот там можно все эти кийворды взять, а не выдумывать по сотому разу
[11:55:54] <geniepro> там есть разные варианты синтаксиса -- сишный, паскальный, питоний
[11:56:55] <prospero3000> Я и не собирался их выдумывать. Сделал, что первое пришло  голову. Собственно, что я и ожидал на форуме -- предложения по форме.
[11:59:18] <prospero3000> перменная булевское
[11:59:35] <prospero3000> женский род со средним родом)))
[11:59:57] <prospero3000> И слово "булевское" что-то из дворового жаргона детей средних классов.
[12:00:46] <prospero3000> Опят ьвтащили пространство имён. Ноги .Net торчат отовсюду.
[12:01:38] <prospero3000> Ссылку они приводят на компонетный Паскаль (как вариант Оберона). Это заслуживает внимания.
[12:01:58] <prospero3000> Но ,прибито гвоздями к .Net
[12:04:50] <prospero3000> Хм... Не вижу я кроме Паскаль никаких намёков на Компонетный Паскаль.
[13:33:33] <TRUE> средний род со средним родом
[13:33:50] <TRUE> но "булевское" - это и вправду как-то странно звучит
[13:34:05] <TRUE> "логическое", думаю, было бы лучше
[13:34:55] <prospero3000> "Переменная" -- это женский род? Новая жертва кофе (оно)?))
[13:35:53] <TRUE> это не переменная
[13:36:23] <TRUE> "переменная" - это переменная, а "булевское" - это значение
[13:36:24] <prospero3000> Это ключевое слово. ПЕРЕМЕННАЯ БУЛЕВСКОЕ.
[13:37:06] <prospero3000> Стоят в тексте рядом.
[13:37:30] <prospero3000> И дальше сама переменная.
[14:53:38] <Kemet> кто знает, почему файловых аоперациях винапи используется знаковое целое -типа INT64, а не беззнаковое.
[14:54:10] <Kemet> LONGLONG
[14:58:11] <prospero3000> Потому что индексы могут быть отрицательные при чтении файла по указанной позиции.
[14:58:36] <prospero3000> А запас индексов в плюс и минус должен гарантированно перекрывать максимальный размер файла.
[15:00:26] <prospero3000> Впрочем, не перекрывает. Максимальный размер файла 2**64
[15:00:48] <prospero3000> Хотя и файлов я таких не видел.
[15:01:38] <prospero3000> Реально ,у людей файлы более 16 ГБ не копируются.
[15:02:27] <Kemet> точно SetFilePointerEx может принимать отрицательное значение
[15:03:14] <prospero3000> Вот неплохое рассмотрение ситуации п оразмеру файла в NTFS
[15:03:22] <prospero3000> https://toster.ru/q/56788
[15:22:34] <prospero3000> цвет поменялся у сообщений?
[15:23:10] <prospero3000> А то я как-то блегдно выгляжу.
[15:23:32] <prospero3000> Блин...
[15:30:25] <Kemet> у меня не читаемо - темносиний на черном
[15:30:35] <Kemet> у когото норм
[15:32:06] <prospero3000> А вот так?
[15:37:07] <geniepro> http://507movements.com/
[15:38:56] <prospero3000> 1 -- kdg
[15:39:05] <geniepro> prospero3000: http://s1.bild.me/bilder/240416/7357618______.PNG
[15:39:35] <prospero3000> 1 -- лвп
[15:40:25] <prospero3000> 2 встречное вращение, какое -- хз
[15:41:12] <prospero3000> Короче, представляю себе но вращение может быт ьв две стороны. Так что вот.
[15:48:22] <_valexey_> prospero3000: посмотри на график результатов прогона. Некоторые решения на порядок быстрее других.
[15:49:05] <_valexey_> Так что не норм сделать просто. Сложно сделать норм.
[15:49:23] <_valexey_> И я знаю что можно еще в несколько раз ускорить.
[15:49:42] <prospero3000> Не сомневаюсь. Можно найти решение на два порядка тормознее. Я не говорил, что нормально сделать легко)) Нормально -- это самый тяжёлый труд))
[15:50:06] <prospero3000> Я говорил, что задача решаема.
[15:51:40] <geniepro> _valexey_: трурль поляк что ли? о_О
[15:52:25] <geniepro> prospero3000: тебя не интересуют задачи, про которые известно что они решаемы, тебе нравятся нерешаемые задачи?
[15:52:57] <prospero3000> Мне нравятся задачи, которые делают жизнь лучше для всех. А не повыёживаться "смотрите какой я умный"
[15:53:57] <_valexey_> prospero3000: дык задача сделать максимально быстро, атне просто решить.
[15:54:26] <prospero3000> Это единственное, что я понял в этой задаче. Польза людям какая?
[15:55:13] <_valexey_> Ну вот эта задача типичная задача для субд например. Умеешь ее решать чтобы было быстро - значит сможешь и с данными эффективно работать реальными.
[15:55:25] <prospero3000> ))) Наивный.
[15:55:25] <geniepro> prospero3000: ну типа наработка алгоритмов быстрой обработки больших файлов в условиях ограниченных ресурсов? ))
[15:55:49] <prospero3000> Если начальник сказал надо вчера -- позавчера будет уже то, что не будет неделю азад))
[15:56:27] <_valexey_> И попутное получение кучи знаний как бы. Там масса нюансов.
[15:57:05] <prospero3000> Я понял. Тебе нужно найти оправдание бессмысленно потраченному времени.
[16:00:32] <valexey> например trurl выдвигал гипотезу что самым быстрым решением будет комбинация mmap + quicksort
[16:00:40] <valexey> и он ошибся.
[16:01:28] <prospero3000> Не могу отвечать за действия трутла. mmap -- заведомо лишний шаг.
[16:01:37] <valexey> И да, если про простую пользу от решений к задачке на разных ЯП - такую задачку например дают в виде тестового задания, после собеседования.
[16:02:12] <valexey> нет, не заведомо. с mmap решение проще и быстрее чем без него (по крайней мере для ряда алгоритмов)
[16:02:24] <prospero3000> Глупость. Бежат ьнадо с такой работы.
[16:03:00] <prospero3000> 99% времени приходится разбираться в чужом говнокоде.
[16:03:22] <valexey> с чего бы? если там именно обработка огромных массивов данных, то человек не умеющий банально написать программу быстро сортирующую файл, просто не нужен.
[16:03:40] <valexey> у каждой работы своя специфика, тащемто.
[16:04:00] <prospero3000> В 99% случаев требуется сопровожждение легаси-говна. А не написание нового кода.
[16:05:05] <valexey> а чтобы понимать почему в легаси говне вот это написано так, работает так, и как это изменить при переходе на SSD - сильно пригодятся знания полученные при решении данной задачки ;-)
[16:05:59] <prospero3000> За 22 года трудовой деятельности НИ РАЗУ не сталкивался с чем-то подобным. В лучшем случае -- путь подправить, базу почистить, цвет буковок и их размер подправить.
[16:07:06] <valexey> у каждого своя специфика.
[16:07:10] <valexey> я сталкивался.
[16:08:27] <prospero3000> Я пытался на почте кмень сдвинуть. Дело закончилось тем, что из Москвы прислали гневную телеграмму "куда лезешь".
[16:13:27] <valexey> o_O
[16:13:45] <valexey> госконторы такие госконторы...
[16:38:59] <valexey> такс, запущу ка я пока что многопроходный тест
[16:39:18] <Kemet> тэкс, В WinA2 вроде перевел Ввод/Вывод на 64 бита
[16:40:51] <valexey> если я сейчас запущу тест, то оно будет часов 15 наверно гоняться
[16:41:27] <valexey> но думаю раньше у тебя решения не будет, да и я за этот вечер не успею разобраться как для A2 что-либо собирать.
[16:41:59] <Kemet> дык я за линупсовую еще не брался
[16:42:32] <Kemet> там тоже на 64 бита переводить надо
[16:43:12] <Kemet> но тут проще ибо общее я сделал, осталась платформспецифика
[16:43:53] <valexey> гут
[16:44:13] <valexey> щща гляну, грузит ли оба ядра решение vlad2
[16:45:30] <valexey> упс. похоже ошибка в скриптах...
[16:49:40] <valexey> в сборочном скрипте ошибка и в тестирующем скрипте наведенная ошибка
[16:49:50] <valexey> в итоге тестировалось обычное fast решение, а не многопоточка
[16:52:01] <vlad2> prospero3000: лично для меня польза такая, что отвлекает от "хуяк-хуяк и в продакшн" и от 99% времени ковыряния в легаси говне. Смотришь на задачу с чистого листа, не обременяясь кучей существующей специфики. И, действительно, помогает потом вернувшись в продакшн некоторые вещи переосознать.
[16:52:03] <Kemet> у меня 4гб файл 1 минуту читается.  пустое чтение
[16:52:49] <vlad2> valexey: я тебе хотел об этом спросить (не то же самый ли тест?), но постеснялся ;)
[16:53:04] <valexey> vlad2: не надо стесняться, я же рукожоп :-)
[16:53:21] <valexey> а чтобы оно собиралось, там надо было еще опцию воткнуть -lboost_system
[16:53:29] <valexey> иначе оно шлепалось на этапе линковки
[16:53:34] <vlad2> у меня на нетбуке в какой-то момент оно грузит честные 200% в top'e.
[16:54:00] <vlad2> valexey: это в новом бусте, в старом не надо было
[16:54:23] <valexey> вот сейчас оно тоже грузит честно 200
[16:54:33] <valexey> надо с ограничением запустить будет
[16:55:24] <valexey> А! О! С ограничением по памяти оно падает с out of memory eггог
[16:55:34] <vlad2> У него там есть шанс по память вылетить - потому как сколько-то блоков оно перевыделяет, я не стал заморачиваться с пулом паммятти
[16:55:36] <valexey> не хватает ему 128
[16:55:54] <vlad2> Придется заморочиться :)
[16:56:07] <vlad2> Там еще сами потоки могу отжирать сколько-то.
[16:56:28] <valexey> ну да, небось по 8 метров под стек каждый
[16:56:29] <vlad2> Типа на винде тольео под стэк отдается 1Mb. На линуксе - ХЗ.
[16:56:39] <valexey> около восьми вроде
[16:57:00] <valexey> т.е. если у тебя три потока (главный и два воркера), то под стек отожрется 24Мб
[16:57:12] <valexey> но за счет ленивого выделения памяти это не всегда стрельнет небось :-)
[16:57:36] <vlad2> Можешь посмотреть сколько ему хватит?
[16:57:55] <vlad2> На 150 проходит?
[16:59:43] <vlad2> Кстати, как ты ограничение выставляешь? Я могу на юбунте это сделать?
[17:00:01] <valexey> через cgroups
[17:00:08] <valexey> я хз с какой версии ядра это появилось
[17:00:12] <valexey> делается как-то так:
[17:00:20] <valexey> у тебя какой юзернейм там?
[17:00:28] <valexey> ну, не важно, заменишь потом
[17:00:35] <valexey> щща волшебные строчки кину
[17:01:12] <valexey> при 200 Мб оно поработало, а потом убилось с сигналом 11
[17:01:29] <valexey> sudo apt-get install cgroup-bin
[17:01:38] <valexey> это чтобы утилиты получить и было удобней
[17:01:43] <vlad2> Это типа крэш?
[17:01:53] <valexey> угу
[17:02:14] <valexey> "A signal 11 error, commonly know as a segmentation fault, means that the program accessed a memory location that was not assigned to it. A signal 11 error may be due to a bug in one of the software programs that is installed, or faulty hardware."
[17:02:14] <vlad2> Таки намудрил чего-то с потоками.
[17:02:38] <vlad2> prospero одобояряет :)
[17:02:45] <valexey> запущу без ограничения, посмотрим крашнется ли :-)
[17:03:33] <valexey> такс, потом создаем эту самую controll group:
sudo cgcreate -a vladuser:vladuser -t vladuser:vladuser -g memory,cpu:bench128
[17:03:48] <valexey> тут vladuser поменяешь на свой актуальный юзернейм в убунте
[17:04:01] <valexey> имя группы, соответственно, тут bench128, можно поменять на любую
[17:04:28] <valexey> выставляем для cgroup ограничения по памяти:
echo 128M > /sys/fs/cgroup/memory/bench128/memory.limit_in_bytes
echo 128M > /sys/fs/cgroup/memory/bench128/memory.memsw.limit_in_bytes
[17:04:40] <valexey> вторая строчка может не сработать (скажет что нет доступа), но это не страшно.
[17:04:46] <valexey> в этом случае достаточно первой строчки
[17:04:58] <valexey> ну а запускать программу так:
time cgexec -g memory:bench128 ./a.out
[17:05:09] <valexey> ну, time понятно для чего ;-)
[17:05:12] <vlad2> OK, попробую.
[17:06:18] <valexey> да, потребление памяти у тебя в многопоточке до 169Мб подскакивает
[17:07:21] <vlad2> OK, поэксперементирую. Теоретический расчет разбился о суровую практику :)
[17:08:11] <valexey> да-а :-)
[17:08:41] <valexey> там еще может быть нюанс - у меня пока впечатление, что сигнал 11 приходит в дом тогда, когда оба потока уже обработали у тебя там мержинг их результатов в основном происходит.
[17:08:45] <vlad2> Могу сейчас по-быстрому константы сдвинуит, чтоб на 41Мб меньше было.
[17:08:59] <valexey> давай
[17:09:06] <valexey> но от сегфолта это может не спасти конечно.
[17:09:36] <vlad2> Сегфолт я подозреваю потому, что потоки как-то не так прибиваю.
[17:09:40] <valexey> хотя, у меня ощущение складывается, что этот signal 11 прилетает тоже только в условиях ограничения памяти
[17:09:56] <valexey> т.е. просто в этом случае тебе где-то маллок говорит - нишмогла и нуль возвращает
[17:10:05] <valexey> что довольно редкое явление в линухе, но возможно оно тут есть.
[17:10:29] <valexey> ща оно без ограничений отработает если успешно, еще раз с ограничениями запущу
[17:10:34] <valexey> с расширенными ограничениями
[17:11:36] <valexey> да, дооолго оно мержит (или что оно там делает, когда только главный поток остается?)
[17:11:51] <valexey> т.е. у тебя ж там только начальный участок многопоточный?
[17:13:08] <vlad2> Да, только начальный - я делал мердж многопоточным, но оно не показало никакого выигрыша на нетбуке.
[17:16:11] <vlad2> valexey: пушнул
[17:16:22] <valexey> ok
[17:16:55] <valexey> хыы. такое ощущение, что многопоточка без ограничений отработала медленней чем однопоточка :-)
[17:17:05] <vlad2> Гы.
[17:17:06] <valexey> real 9m25.388s
[17:17:16] <valexey> т.е. это под 600 секунд
[17:17:29] <vlad2> а сколько надо?
[17:17:51] <valexey> ну, однопоточка у тебя работает за 370 секунд
[17:18:05] <vlad2> Гы.
[17:18:19] <valexey> но это был криворукий запуск. может из за того, что кеш не сбросил на диск оно так было
[17:18:27] <valexey> ща еще потестим, только с крашем разберемся :-)
[17:19:00] <vlad2> Кстати, как на линуксе крэшдампы смотреть?
[17:20:33] <TOPICS_MAPS_MONSTER_SIMPLE> valexey: НИЧЕ ЕСЛИ Я 1 МЕССАГУ ДАМПА ПОТОКА СОЗНАНИЯ ПОСТАНУ? РОВНО ОДНУ =)
[17:21:31] <TOPICS_MAPS_MONSTER_SIMPLE> vlad2: man gdb

      -core=file
      -c file
          Use file file as a core dump to examine.

[17:21:45] <valexey> TOPICS_MAPS_MONSTER_SIMPLE: а давай ты постанешь в pastebin, а сюда ссылку кинешь?
[17:22:00] <TOPICS_MAPS_MONSTER_SIMPLE> vlad2: man gdb|grep core

[17:22:14] <valexey> ну, надо еще крешдамп сгенерить чтобы его смотреть
[17:22:20] <valexey> а как это делается, я забыл :-(
[17:22:23] <TOPICS_MAPS_MONSTER_SIMPLE> man ulimit
[17:22:45] <TRUE> а дамп не автоматом делается?
[17:22:56] <TOPICS_MAPS_MONSTER_SIMPLE> TRUE: он нонче запрещён обычно
[17:23:38] <valexey> потому, что дамп он жирный очень
[17:23:45] <valexey> все 100500 гигабайт ОЗУ же сдампится
[17:24:54] <TOPICS_MAPS_MONSTER_SIMPLE> valexey: http://stackoverflow.com/questions/17965/how-to-generate-a-core-dump-in-linux-when-a-process-gets-a-segmentation-fault
[17:25:18] <valexey> да я уже загуглил, да
[17:25:43] <valexey> да, по умолчанию размер корки видимо нуль
[17:25:51] <TOPICS_MAPS_MONSTER_SIMPLE> а я помнил только сомневался. ulimit -c unlimited
[17:26:19] <TOPICS_MAPS_MONSTER_SIMPLE> это в убунте
[17:26:27] <TOPICS_MAPS_MONSTER_SIMPLE> в баше
[17:26:33] <valexey> угу
[17:26:47] <valexey> vlad2: вроде пока не крашнулось
[17:28:14] <TOPICS_MAPS_MONSTER_SIMPLE> короче надо GHC. и GHC ЭТО OCHCHENN STRASHSHNO IN FULL IF; this is a pressing of that DUMP
[17:29:18] <valexey> глазго хаццкель цомпилер
[17:29:58] <TOPICS_MAPS_MONSTER_SIMPLE> ВСЕ ХАСКЕЛЬ КОМПИЛЕРЫ САЖРАТЬ И ВЗАРВАТЬСЯ =))))) ВЫБЕГАЛЬНУТЬСЯ
[17:30:59] <TOPICS_MAPS_MONSTER_SIMPLE> короче ИВАН ДУРАК НА ДРАКОНОГИДРУ ПОПЁР =)
[17:31:18] <vlad2> valexey: это уже новое, которое должно влезть в 128?
[17:31:28] <TOPICS_MAPS_MONSTER_SIMPLE> НА МНОГОГЛАВОГО ДРАКОНА НА ХОРДЫ ДРАКОНОВ HORDES
[17:31:28] <valexey> да
[17:31:59] <valexey> многопоточка закончилась. сейчас в один поток уже мержит
[17:32:10] <TOPICS_MAPS_MONSTER_SIMPLE> милипусики
[17:32:35] <TOPICS_MAPS_MONSTER_SIMPLE> сидите тут
[17:32:58] <vlad2> valexey: возможно имеет смысл таки сделать мердж многопоточным, если он у тебя существенное время занимает.
[17:33:03] <TOPICS_MAPS_MONSTER_SIMPLE> а мы на тренировочку =)
[17:33:07] <valexey> вот у студентов-астрономов сурово. у них там лабы вычислительные такие, что рассчет может занять месяц.
[17:33:13] <valexey> пишешь его сам
[17:33:21] <valexey> если ошибка, ну, то сам виноват :-)
[17:33:32] <TOPICS_MAPS_MONSTER_SIMPLE> у меня щас доступ к суперкомпу иркутскому появился =)
[17:33:32] <vlad2> Циклы неправильные :)
[17:33:41] <TOPICS_MAPS_MONSTER_SIMPLE> вузовскому
[17:33:44] <valexey> писать можно на чем угодно. но по факту больше всего шансов успеть к сроку, если пишешь на фортране
[17:33:52] <valexey> он быстр и там ошибку допустить сложнее чем в Си
[17:34:04] <valexey> любители писать на питоне каком-нибудь обычно просто в срок не укладываются.
[17:34:20] <TOPICS_MAPS_MONSTER_SIMPLE> да, фортран квантовики матричники когда то хвалили . в тч вроде емнип ms frtrn
[17:34:40] <vlad2> там обещали jit для питона мегабыстрый
[17:34:44] <valexey> и вот на таких задачах те жалкие "в 2-4 раза разница в скорости, т.е. один порядок!" выливаются в недели и месяцы работы программы.
[17:35:22] <TOPICS_MAPS_MONSTER_SIMPLE> питон фу
[17:35:45] <TOPICS_MAPS_MONSTER_SIMPLE> невоспитанная тварюшка
[17:35:48] <TOPICS_MAPS_MONSTER_SIMPLE> питон
[17:36:19] <TOPICS_MAPS_MONSTER_SIMPLE> когда вылазит питон версион хелл то вам ГИТЛЕР КАПУТ
[17:36:25] <TOPICS_MAPS_MONSTER_SIMPLE> маненько но капут
[17:37:48] <TOPICS_MAPS_MONSTER_SIMPLE> приходится писать длиннющие текстовики с длиннющими баш скриптами для укрощения питонишки
[17:40:26] <valexey> зачем на баше? лучше на питоне же! :-)
[17:45:07] <TOPICS_MAPS_MONSTER_SIMPLE> он невоспитанный. его надо по башке иначе не поймёт
[17:45:17] <TOPICS_MAPS_MONSTER_SIMPLE> злой я родитель мог бы быть =)
[17:45:27] <TOPICS_MAPS_MONSTER_SIMPLE> ну можна иначе поди да
[17:45:35] <TOPICS_MAPS_MONSTER_SIMPLE> некогда мне было
[17:45:41] <TOPICS_MAPS_MONSTER_SIMPLE> и неохота ;)
[17:46:32] <TOPICS_MAPS_MONSTER_SIMPLE> /me thinks ::: надо вырастать из SIMPLE в FULL_RANGE ;; интересно сколько твоих номадов потребуется чтоб освоить HORDES OF HASKELL COMPILERS ET AL TOPICS MAPS
[17:46:47] <TOPICS_MAPS_MONSTER_SIMPLE> жизней номадов
[17:47:51] <valexey> vlad2: отработало, но неверно
[17:48:01] <valexey> ответ не корректный
[17:49:28] <valexey> vlad2: размер файла не верный до кучи
[17:49:58] <valexey> например на 256 мб входного (268435456 байт) получается output размером в 251287624 байт
[17:52:05] <vlad2> Точно что-то с потоками :) Хотя у меня корректно работало.
[17:53:36] <valexey> многопоточка это сложность!
[17:53:41] <valexey> а сложность это уязвимость!
[17:54:03] <valexey> всем сортировать исключительно пузырьком на обероне!
[17:54:08] <valexey> в один поток!
[18:15:02] <vlad2> valexey: ну собственно это то, о чем я говорил prospero - полезно отвлечься и попробоваться что-то с чистого листа. Вот как я - налажал с потоками, фиксну, узнаю что-то новое.
[18:15:48] <valexey> ну да :-) я вот для себя открыл, что дешевый seek на ssd не такой уж и дешевый :-)
[18:16:09] <valexey> ну, плюс тонную навыков по bash-скриптингу, по организации cgroups, по кешам в линуксе и так далее.
[18:17:00] <valexey> надо будет вот еще докером обмазаться :-)
[18:26:31] <Kemet> valexey, А что с seek не так?
[18:30:23] <valexey> даже на SSD последовательно читать быстрее
[18:31:18] <valexey> время seek для ssd порядка 0.1ms, а это довольно много
[18:31:30] <valexey> то есть максимум 10000 сиков в секунду
[18:32:11] <valexey> хотя, надо детальней глянуть
[19:21:50] <geniepro> valexey> например trurl выдвигал гипотезу что самым быстрым решением будет комбинация mmap + quicksort
ну собственно это решение на текущий момент всё же лучшее, хоть и не самое быстрое -- зато самое концептуально простое и правильное )) а скорость его не сильно хуже других, так что можно пренебречь
[19:23:21] <valexey> geniepro: у нас нет решение в чистой комбинации mmap + quicksort
[19:23:32] <valexey> std::sort это не quicksort
[19:31:00] <valexey> его (в чистом виде) оттуда выкинули как только настали времена когда безопасность хоть кого-то волнует.
[19:31:02] <geniepro> ну не важно -- стдсорт или квиксорт -- это уже нюансы
[19:34:24] <valexey> ога, или радикссорт ;-)
[19:34:34] <valexey> еще еще какой алгоритм сортировки, действительно, какая разница? :-)
[19:34:46] <valexey> пузырек вот еще можно попробовать.
[19:35:06] <geniepro> стандартный? значит его все и используют
[19:36:23] <valexey> нет :-)
[19:37:00] <geniepro> ну кто не использует -- сам себе злой буратина
[19:39:13] <valexey> вот тут, кстати, проявляется готовность ЯП к продакшену.
[19:39:41] <valexey> по моему нормальная обобщенная сортировка есть в С++ и в java, возможно еще в Go. Ну и в сях есть какая-то но уже ниочень хорошая.
[19:39:47] <valexey> В хаскеле и ocaml'e её просто нет.
[19:41:51] <geniepro> в хаскелле для пользовательских контейнеров сортировка делается просто -- делаешь функции toList и fromList и комбинируешь их с функцией Data.List.sort:
customSort = fromList . sort . toList
[19:42:31] <geniepro> для хаскельных задач этого подхода достаточно
[19:46:06] <valexey> а будет ли это быстро?
[19:46:13] <valexey> нафига лишняя сущность?
[19:46:30] <valexey> или там сортировки такие какие были в нормальных языках 30 лет назад?
[19:46:36] <valexey> в смысле там 10к элементов, не более.
[19:47:02] <geniepro> я когда-то тестил сортировку списков в хаскелле -- вполне норм было по скорости
[19:47:52] <valexey> по сравнению с чем? :-)
[19:48:10] <valexey> так то сортировки можно и на компе вирта погонять. и тоже будет норм по скорости
[19:48:27] <geniepro> уже не помню по сравнению с чем, но помню что норм )
[19:49:41] <valexey> бгг
[19:49:49] <valexey> вот тебе реальная задачка, реши ка!
[19:49:59] <valexey> даже если будет медленно, интересно же НАСКОЛЬКО это будет медленно
[19:51:12] <geniepro> к сожалению, хаскель заточен на работу с чистыми данными, а файлы, да ещё бинарные -- это грязные данные, не хаскельная это тема
[19:52:47] <valexey> что такое чистые данные?
[19:53:02] <TRUE> напиши либу на си, которая читает-пишет файлы. Остальное сделай на хаскеле
[19:53:02] <valexey> и чем бинарь хуже текста? текст же медленнее и хуже всегда
[19:53:08] <valexey> его надо парсить. бинарь - не надо
[19:53:31] <valexey> ну и текст это частный случай бинаря ведь
[19:54:22] <geniepro> нету готовых функций типа "прочти_изфайла_слово_в_32_бит_без_знака" -- надо её делать
[19:57:51] <TRUE> сделай библиотеку с двумя функциями
прочитать_блок(размер_блока, номер_блока)
записать_блок(блок, позиция_в_файле)
[19:58:00] <TRUE> на си сделай
[19:58:07] <TRUE> и подключи к программе
[19:58:20] <TRUE> хаскель же с си дружит, верно?
[19:59:12] <geniepro> там эта дружба довольно медленная получается, как выяснилось на просто записи блока в файл
[19:59:47] <TRUE> запись делай сишной функцией.
[20:00:36] <geniepro> а смысл во всём этом гибриде? тогда уж сразу всё на сях сделать, а из хаскельной проги просто вызов сишной мегафункции
[20:02:04] <TRUE> смысл в алгоритме сортировки, насколько я понял
[20:02:16] <TRUE> есть набор данных, который не помещается в ОЗУ
[20:02:35] <TRUE> нужно получать порции данных из файла и сортировать их.
[20:02:52] <TRUE> сама запись-чтение - это смежная задача
[20:03:04] <TRUE> думаю, её можно сделать на сях.
[20:03:50] <TRUE> или ты знаешь несколько способов сохранения файлов, которые могут качественно сказаться на скорости именно сортировки?
[20:04:59] <geniepro> ну просто вот таже запись в файл -- если записывать мегабайтными блоками, посчему-то в три раза медленнее, чем если записывать 4-х байтными словами. почему -- хз
[20:07:22] <Kemet> ghzv ,zlf
[20:07:28] <Kemet> Прям бяда
[20:08:40] <Kemet> valexey: не запускаются бинари от а2 в 64 битном линупсе
[20:08:50] <valexey> :-\
[20:08:50] <Kemet> file oberon
oberon: ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), corrupted section header size
[20:09:16] <Kemet> о как - corrupted
[20:09:46] <Kemet> так шта починкой ФС дело не закончится
[20:10:40] <Kemet> а в 32 битной сюзе я запускал и работало
[20:18:41] <Kemet> открыл тикет, может Феликс поправит
[20:22:20] <valexey> жесть
[20:22:39] <valexey> ну, вот и еще одна пользова от теста :-) ловим баги
[20:25:59] <Kemet> не знаешь аналог time Под венду? он точно есть я натыкался на днях на сайте МС но закладки блин синхронизировались и на этом комне все поудалялось
[20:26:17] <geniepro> нету на винде искаропки аналога time
[20:26:40] <Kemet> не искаропки - инструмент от мс
[20:28:03] <geniepro> про какую-то timeit.exe пишут
[20:29:00] <geniepro> Use Powershell

Measure-Command {start-process whateveryouwantexecute -Wait}
[20:30:43] <Kemet> не то
[20:32:36] <geniepro> ну в принципе вроде работает, но секунду на какие-то свои павершелловские действия тратит
[20:34:57] <geniepro> Kemet: можешь установить cygwin -- там есть встроенный юниксовый time
[20:35:21] <geniepro> или ptime http://www.pc-tools.net/win32/ptime/
[20:35:31] <Kemet> ааа, видимо это былов в visual studio build tools но я не помню команду
[20:37:27] <geniepro> цигвиновский time вроде работает, но результаты странные выдаёт:
real    0m9.166s
user    0m0.015s
sys     0m0.000s
[20:39:36] <valexey> запустил тестироваться. по три прогона на каждого.
[20:41:22] <valexey> geniepro: это ты что такое пускал?
[20:41:45] <valexey> вроде реалистичные результаты то
[21:09:17] <geniepro> разве real не должен быть суммой user и sys?
[21:18:22] <Kemet> valexey: http://www.opennet.ru/man.shtml?topic=lseek&category=2&russian=2  и тут 32 бит штоле
[21:24:27] <Kemet> ага, lseek64
[21:27:49] <valexey> geniepro: нет, не должен
[21:28:39] <valexey> у тебя прога может просто спать, или там система отдаст время другой проге, реал будет расти, а юзер будет ни о чем
[21:28:56] <valexey> можно еще на io заблокироваться :-)
[21:29:03] <valexey> при этом юзер может быть и больше реала
[21:33:26] <Kemet> valexey: всё же будет ли int всегда 32 битным наЛинуксе 32\64
[21:33:46] <valexey> uint32_t - будет :-)
[21:34:01] <valexey> а ты про какой язык говоришь? и про какой компилятор?
[21:34:19] <Kemet> ну в линупсовых вызовах стоит int
[21:34:45] <Kemet> z ghj dspjds
[21:35:04] <Kemet> я про системные вызовы в линукс
[21:35:04] <valexey> на spark64 int будет 64бита
[21:35:18] <valexey> на линухах с испоьзованием gcc - будет 32бит
[21:35:30] <valexey> https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
[21:37:37] <valexey> тут ещё: http://en.cppreference.com/w/cpp/language/types
[21:37:44] <Kemet> ну на спарк нас не интересует, на интеле таки 32
[21:37:56] <valexey> и тут: http://www.unix.org/version2/whatsnew/lp64_wp.html
[22:03:43] <geniepro> кстати, там чо у Влада днюха сёдня что ли?
[22:14:54] <valexey> похоже на то ;-)
[22:15:00] <valexey> vlad2: с днюхой! :-)
[22:18:05] <valexey> кстати, скоро и в России: http://www.dw.com/ru/%D0%BA%D0%B0%D0%BA-%D0%B2-%D0%B1%D0%B5%D0%BB%D0%B0%D1%80%D1%83%D1%81%D0%B8-%D0%BE%D0%B1%D0%BE%D0%B9%D1%82%D0%B8-%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D1%83-tor-%D0%B8-%D0%B8%D0%B7%D0%B1%D0%B5%D0%B6%D0%B0%D1%82%D1%8C-%D1%86%D0%B5%D0%BD%D0%B7%D1%83%D1%80%D1%8B/a-36642600
[22:27:23] <vlad2> Да! Спасибо! :)