[00:00:37] <valexey> угу. но конкурента он срезал именно на больших данных которые в ОЗУ не вмещались
[00:56:29] <valexey> о, уже gcc 6.2.1 в системе
[00:56:31] <valexey> няшно
[00:59:52] <valexey> ой, ocaml уже 4.0.4
[01:19:35] <vlad2> А я как раз обломался когда на юбунте компилил - там 3.6 стоит.
[01:22:28] <valexey> оно не умеет 11ые плюсцы?
[01:22:34] <valexey> проапгрейдь бубунту!
[01:22:51] <valexey> о, началось в деревне утро - скайп отвалился в системе после обновления :-)
[01:44:54] <vlad2> Я ж говорю - старый ноут, бесполезно обновлять, там сейчас 12.04 стоит.
[01:45:20] <vlad2> Дажк недоноут. Как такие называются забыл.
[01:58:11] <valexey> netbook
[02:38:12] <Е.Г.Ф.> А меня глюк мыши убивает. Похоже на глюк с мышью в хорг и или линухе
[02:38:33] <Е.Г.Ф.> Приходится на этой хардвари переползать на винду
[02:44:59] <vlad2> Ага, нетбук.
[02:45:13] <vlad2> Таки пришлось для винды допилить напильником: https://github.com/valexey/bigbench/commit/c560db1f6348c73db960e877c94622fe33a80c57
[02:45:54] <vlad2> 2016 год, а они все не договорятся как читать текстовые файлы.
[02:46:08] <valexey> :-)
[02:46:20] <valexey> чертов мейнстрим!
[02:46:34] <vlad2> Хотя конечно само понятие "текстового" по умолчанию (!) зело зло.
[03:27:39] <vlad2> Зорко отказался :)
[03:36:27] <valexey> чо это он? ;-)
[03:37:27] <vlad2> Типа баловство все это, денег не дают и вообще вырос он уже :)
[03:37:49] <valexey> постарел...
[03:38:39] <vlad2> Видимо отстутствие базовой консоли и прстейшего файлового ввода/вывода создают высокий порог.
[03:39:08] <vlad2> Ну и выписать сортировку, когда нельзя ошибиться, а то зачморят :)
[03:41:06] <valexey> ну, у oo2c и всяких других ofrontов не должно же быть такой проблемы
[03:41:16] <valexey> они же в Си компилируют исходник обероновый
[03:41:48] <valexey> но отсутствие любопытства и желания ставить эксперименты - весьма прискорбно. с этого начинается деградация.
[03:46:15] <valexey> кстати, мне известно, что есть метод который в 4 раза быстрее чем сортировка через mmap (та что здесь).
[03:46:22] <valexey> или даже в 5 раз
[03:46:33] <valexey> что за метод - я не знаю. просто видел сравнения.
[03:46:51] <valexey> так что палюбому есть куда расти :-)
[03:59:15] <vlad2> Да, у меня тоже есть идейка, может заимплеменчу ее как второй вариант :) Правда она уже в стандартные алгеоритмы не укладвается.
[04:36:31] <_valexey_> Кстати, кроме всего прочего, эта задачка неплохой тест на то, что будет если ваш проект писан на обероне.
[04:37:03] <_valexey_> То есть насколько просто будет найти компетентных разработчиков.
[04:37:28] <_valexey_> Ну и насколько они будут компетентны :-)
[04:38:01] <_valexey_> Это при том, что у нас еще и выборка смещена в сторону оберона.
[08:16:32] <geniepro> чота жестокий какой-то кодинг-стайл у Влада о_О
[10:07:50] <geniepro> https://www.youtube.com/watch?v=byItl1Kl05Q
Функциональное программирование в продуктовой разработке (Алексей Фомкин) - TK Conf
[14:37:37] <valexey> geniepro: хлебушек и молочко чтобы производить? :-)
[14:38:27] <geniepro> программыне же продукты, не только хлеб-вода
[14:39:04] <valexey> не знай. вон хожу в продуктовый магазин - нет там никакого софта. только хлебушек да молочко.
[14:39:11] <valexey> оно наверно и к лучшему :-)
[14:40:00] <geniepro> примитивный у тебя там магазинчик ))
[14:43:40] <valexey> ну, мы люди простые, нам особых изысков не надо :-)
[17:38:51] <vlad2> geniepro: я говорю, на самом деле в продакшине еще жесче :)
[17:40:22] <valexey> милый артефакт прошлого?
[17:47:29] <valexey> http://oberspace.dyndns.org/index.php/topic,695.msg21821.html#msg21821
[17:47:31] <valexey> пичаль ;-(
[17:51:51] <vlad2> Угу, с эпла еще.
[17:52:08] <valexey> блин, какое же жуткое ШГ в ББ в вайне. жуть!
[17:52:24] <valexey> тот самый случай, когда лучше смотреть на это дело без очков.
[17:52:28] <vlad2> Да, я как раз хотел написать - годный троллинг про раземер файла :)
[17:53:01] <valexey> блин, 2016 год. в абстракции файла для размера файла используется 31бит. 31, Карл!
[17:53:01] <vlad2> Что такое ШГ?
[17:53:10] <valexey> ШГ - Шрифты Говно
[17:53:44] <valexey> блин, капец. сглаживания нет, буквы друг на друга налезают
[17:56:17] <valexey> да, то был дефолтный аццкий шрифт.
[17:56:19] <vlad2> Я так понмаю в оригинальной oberon system шрифтами тоже никто особо не заморачивался? :)
[17:56:30] <valexey> можно поменять на что-то более приличное
[17:56:47] <valexey> но, блин, в КАЖДОМ ББшном документе уже выставлен какой-то шрифт.
[17:56:52] <valexey> КАК МНЕ ИХ ПОМЕНЯТЬ ВЕЗДЕ?!
[17:58:06] <vlad2> У кого надо все поменяно! :)
[17:59:18] <valexey> это, кстати, одна из штук которая меня всегда в ББ раздражала
[18:00:27] <valexey> Вот выставил дефолтный шрифт - и да, он поменялся в итоге в некоторых окошках на нормальный. Но большинство системных документов как открывалось в ущербном ариале, так и открывается.
[18:01:16] <valexey> И это не лечится ведь. Берешь исходники у человека который любит скажем очень специфический мелкий или крупный шрифт, и они ВСЕ будут у тебя смотреться вот именно так. Нечитабельно для тебя на твоем мониторе.
[18:01:50] <valexey> Т.е. кроме форматирования кода (на тему чего часто воюют программеры) тут еще добавляется и война шрифтов/цветов/стилей
[18:02:13] <valexey> блин, чот у меня опять бомбануло с этого ББ.
[18:03:02] <vlad2> Ковырнул свое решение на предмет ускорить - типа читать не по одному, сортировать непосредственно std::uint32_t - особо не ускоряется, так что оставлю пока как есть, так красивше. А для ускорения попробую отдельное решение. Можно ж еще 2 ядро заиспользовать как я понимаю...
[18:03:48] <vlad2> Ну если бы все это развивалось и дошло до нормального продакшина - наверняка бы придумали что-то с переводом шрифтов.
[18:03:53] <valexey> можно, да
[18:04:01] <valexey> тем паче что в плюсах то теперь есть многопоточность искаропки!
[18:04:12] <vlad2> Типа каки-ни нибудь текстовых блоков.
[18:05:50] <vlad2> Уже добавили потоки? Надеюсь по аналогии с бустовскими?
[18:06:25] <valexey> http://en.cppreference.com/w/cpp/thread
[18:06:32] <valexey> да, давно уже
[18:06:35] <valexey> теперь расширяют
[18:07:04] <vlad2> Вроде похоже, хорошо.
[18:07:23] <vlad2> Может там и sleep нормальный есть.
[18:07:59] <valexey> кстати, вот самый косяк в этой задаче был бы, если бы в условиях задачи не было бы сказано сколько ОЗУ в системе. Т.е. вот тебе большой файл (в память не поместится) а памяти ну, столько сколько есть. Крутись как знаешь, но помни, OOM killer следит за тобой!
[18:08:41] <valexey> ведь хрен узнаешь из проги сколько тебе еще памяти можно зохавать
[18:08:59] <valexey> из плюсов то точно через стандартную либу никак не узнать.
[18:11:48] <vlad2> Это просто в силу дебилизма юниксового ;) В нормальных ОС тебе говорят, что памяти нет :)
[18:12:22] <vlad2> Какая вообще предыстория такого решения?
[18:12:45] <vlad2> Типа было дохрена прог, которые ели память, но не использовали ее?
[18:14:04] <valexey> а в виндах разве не так?
[18:14:24] <valexey> ну ваще, предыстория предыстория.. mmap - вот и вся предыстория :-)
[18:14:28] <valexey> по сути
[18:15:16] <vlad2> Нет конечно. malloc честно вернет NULL, а new бросит исключения. У нас в коде есть сколько-то мест, которые работают на этот - типа когда фиг знает, сколько данных выгребется.
[18:15:51] <valexey> хм. надо, кстати, посмотреть, может есть в линухе штука которая гарантированно даст или не даст память
[18:16:02] <valexey> понятно что это не через сишную либу будет
[18:17:56] <vlad2> Гарантированный способ юниксовый - это выделить, заполнить, поймать сигнад, перезапуститься, попросить меньше :)
[18:18:26] <vlad2> (не знаю, можно ли форкаться в сигнале)
[18:21:48] <valexey> а может ребенка форкнуть, пусть он развлекается, а потом доложит папе что вот за такое вот бьют, а за такое - нет? ;-)
[18:23:14] <vlad2> Да, OOM killer посылает SIGKILL, так что только через детей.
[18:24:18] <valexey> всё как в жизни - пущай салаги рискуют!
[18:24:19] <valexey> :-)
[18:28:34] <vlad2> Не пробовал: echo 2 > /proc/sys/vm/overcommit_memory?
[18:30:54] <valexey> нет исчо
[18:32:13] <valexey> кстати, там бывает суровая единичка, про которую написано:
Always overcommit. Appropriate for some scientific
applications. Classic example is code using sparse arrays
and just relying on the virtual memory consisting almost
entirely of zero pages.
[18:33:24] <valexey> короче, понятно зачем оно было сделано
[18:33:35] <valexey> если учесть университетские корни юникса
[18:34:36] <valexey> хм-хм. С учетом того, что для ББ никто еще не почесался сделать нормальные файлы, это означает что ни у кого не было таких задач. Т.е. никто большие объемы данных на ББ не обрабатывает.
[18:44:42] <vlad2> Ну в те времена 2Gb было большим объемом :)
[18:45:37] <valexey> в те - да. но сейчас то?
[18:45:44] <valexey> ведь и в 1.7 вроде как те же йайса
[18:46:00] <vlad2> Т.е. вместо того, чтобы заюзать библиотеку для sparse arrays - решили дать это на откуп операционке, да еще и сделали дефолтом. А потом стали с ним бороться - OOM killer и т.д.
[18:46:06] <valexey> да и обсуждений этой проблемы я не нашел
[18:46:42] <valexey> ну, это предположение. и учти, что математики они программы писать не умеют. и тем более тогда не умели :-)
[18:47:09] <vlad2> Да, предположение. Но причина так просто не гуглится.
[18:47:52] <valexey> тогда же только только всё начиналось, либ не было, но нужно было уже выдавать на гора результаты рассчетов и численного моделирования
[18:48:03] <valexey> время было суровое - холодная война :-)
[18:48:52] <valexey> это сейчас в отрасли десятки миллионов программистов и миллиарды компьютеров, а тогда один комп на круг, и два десятка программистов на страну.
[18:51:24] <valexey> ну да, как был INTEGER так и остался.
[18:51:33] <valexey> может на просторах сторонних компонент что-то есть?
[18:53:53] <vlad2> У кого надо конечно есть :)
[18:56:53] <valexey> не нашел у Zinn'a
[18:57:33] <valexey> ну, т.е. можно сделать вариант ББшный для файлов до 2Гб, но это ж конкретное попадалово :-)
[19:07:54] <valexey> блин, забитые намертво такие вот ограничения - это зло
[19:08:33] <valexey> вот кому-то может показаться, что уже 64бита для размера файла уже будет достаточно. Но на самом то деле нихрена. Лет через 50 этого будет точно мало.
[19:16:03] <geniepro> пусть обходят проблему как хотят ))) иначе незачёт ))
[19:17:09] <geniepro> valexey: вот кому-то может показаться, что уже 64бита для размера файла уже будет достаточно. Но на самом то деле нихрена. Лет через 50 этого будет точно мало.
верно говоришь! вот поэтому надо для размера файла использовать хаскельный Integer -- его на тыщу лет точно хватит )))
[19:17:46] <valexey> угу. либо абстракцию использовать. а не конкретный тип
[19:25:07] <vlad2> Просперо обещал попробовать.
[19:26:47] <valexey> хорошо
[19:27:05] <valexey> блин, а XDS (компилятор) не запускается просто потому, что ему на кой то хрен нужна либа libncurses.so.5
[19:27:09] <valexey> древняя, как говно мамонта
[19:27:25] <valexey> и естественно её уже никто в репозиторий не кладет
[19:27:32] <valexey> исходников xds тоже нет
[19:28:01] <valexey> с этими оберонами можно синдром Туретта заработать
[19:34:25] <valexey> в xds вообще нет ничего 64битного целого.
[19:36:04] <valexey> зато есть беззнаковое целое!
[19:52:42] <geniepro> юзай аду, люк!
[19:54:03] <valexey> ада это скучно. инфраструктура gcc, поддерживаемый компилятор и либы.. там всё будет на уровне.
[19:54:30] <valexey> ну и опять таки - жирный язык, жирные либы - никак его не противопоставить плюсам
[19:54:34] <valexey> нет там волшебства
[20:02:53] <Kemet> в А2 ФС тоже перерабатывать надо в плане поддержки 64 бит и производительности
[20:05:00] <valexey> выходит, что xds, BB, A2 - все они только файлы до 2 гиг держат?
[20:05:06] <valexey> точнее так, xds держит до 4 гиг
[20:05:14] <valexey> у него ибо есть беззнаковые
[20:06:50] <Kemet> ну встроенными стредствами да, а если напрямую хостовые функции то 64 норм, в ББ есть 64 битныые целы же
[20:10:44] <valexey> LONGINT?
[20:14:22] <Kemet> В ББ - LONGINT  В А2 - HUGEINT, SIGNED64, UNSIGNED64
[20:18:23] <Kemet> В принципе, в А2 перевести ФС на 64 бита не сложно, для теста можно сделать
[20:21:15] <valexey> дык, дополнительная польза от теста :-)
[20:24:55] <valexey> Vishap Oberon Compiler попробовать чтоли
[20:25:24] <valexey> "On x86_64 it supports 64bit LONGINT and 64bit SET types."
[20:30:02] <valexey> а, это ofront.. скучно :-)
[20:38:21] <Kemet> хотел сгенерить файл размера 1024*1024*1024 со случайными интами. Давно жду, файла нету
[20:40:42] <Kemet> а все почему?
[20:41:00] <Kemet> забыл перегрузить модуль
[20:41:01] <valexey> потому что зацыклилось
[20:41:04] <valexey> а-а
[20:41:05] <valexey> хы
[20:45:14] <valexey> это ж 4 гига файло должно получиться?
[20:45:25] <valexey> а оно точно сможет?
[20:50:30] <Kemet> не, я ж не совсем идиот, я ж помню что в UNSIGNED32  4 байта
[20:51:41] <Kemet> во, сгененрило рово 1Гб
[20:52:49] <Kemet> бдин, мне срочно нужно xnjnj dhjlt f.ReadBack !!!
[20:53:46] <Kemet> чтобы указатель двигало не вперед, а назад
[20:55:04] <valexey> ы? зачем?
[20:56:04] <Kemet> ну это ж SSD там воббще можно попробовать сортировать файл без всяких буферов, хотя бы ради интересу, а квиксорт с двух концов же работает
[20:56:34] <Kemet> а я не могу читать файл с конца к началу
[20:57:51] <valexey> кстати, зацените разницу в скорости mmap плюсатого решения когда есть ограничение на память (32 мегабайта):
real 1m47.929s
user 0m39.193s
sys 0m17.470s

[20:58:04] <valexey> и когда ограничений нет:
real 0m38.126s
user 0m34.353s
sys 0m1.933s

[20:58:32] <Kemet> что такое реал
[20:58:41] <valexey> Kemet: а seek/set_pos там нет?
[20:59:14] <valexey> real - календарное время прошедшее, user - время затраченное процессором (может быть больше real'a)
[20:59:16] <Kemet> е сть, но после каждлгл Read двигается указатель
[21:00:22] <Kemet> ну когда памяти мало мапинг свопирует много наверное
[21:01:12] <valexey> чаще сбрасывает на диск, да. а так почти все в кеше сидит
[23:59:50] <vlad2> интересно, они пропихнули в стандарт потоки, когда они далеко не на каждой платформе доступны...