Discreet and not discrete.

Выясняем с коллегой причины проблем сборки некоей БД с несколько изменённым хранилищем. Оба смотрим на, вроде бы, один и тот же RPM - md5sum одинаковый, имена файлов тоже. В моей копии RPM некоторый файл отсутствует, у коллеги он присутствует. Качали из одного места, прошу прощения за каламбур.

Восхищённый ситуацией, я решил поделиться с ним Палкой с Резиновой Нахлобучкой, в котором подходящую к ситуации последнюю строчку имеет стих:

Туман поутру.
Вдалеке забивают сваю:
Бам-бам-бам-бам!
....
Бусон

Коллега в ответ говорит, что у него сейчас 11 утра (утро, то бишь), за окном туман и где-то, судя по звукам, забивают сваю.

Как выяснилось, я неправильно помню историю ParSci и Tweag.

Поэтому прошу не обращать внимание на мои замечания по поводу Tweag в предыдущем посте.

Если у вас есть алгоритм на графах, попробуйте сформулировать его в терминах линейной алгебры и матрицы смежности. Например, clustering coefficients вычисляются через третью степень матрицы смежности с небольшой обработкой. Включая и алгоритм вычисления обновлений для изменений матрицы смежности.

Это приводит к простой возможности разделить данные на несколько машин, а также к возможности использовать разные эффективные алгоритмы работы с матрицами, включая оптимизированные алгоритмы умножения матриц (см. hypersparse matrix multiplication и SUMMA).

Здесь мы подходим к необходимости распознавать алгоритмы, записанные пользователем в DSL на циклах, допустим. Ну, это уже было украдено до нас, неоднократно.

Вся индустрия ПО о-ши-ба-ет-ся, особенно, та часть которая "я _________ (датасайнтист/доктор/инженер/финансист - подчеркнуть или вписать), а не программист". Как я уже рассказывал, Amgen обратился в ParSci за решением задачи корректности анализа статистических данных - треть медицинских статей содержала ошибки типа "у эксперимента 1 p=0.04, у эксперимента 2 p=0.038, поэтому мы считаем доказанной гипотезу эксперимента 2" (прямое сравнение p-значений). По идее, отрубив возможность сравнивать p значения напрямую (нет реализации Ord), мы, типами, ограничивали бы возможность допущения ошибок такого типа, получая из Хаскельного кода структуру анализа эксперимента и получения выводов. Они заказали у ParSci библиотеку подключения к R, для использования уже отлаженных и оптимизированных алгоритмов с улучшенными типами, но, как известно, работа ушла на сторону и появился Tweag (если я правильно понимаю).

В дни моего использования Data.IntMap он не был завязан на конкретное представление целого, как ключа. Поэтому его можно было перепилить под меньшее целое (например, 32 бита) и это радикально увеличивало производительность - и мусора меньше, и с кешем получше и, если это кто ещё не знал, 64-битная платформа лучше работает с 32-битными значениями. Поэтому разреженные матрицы связности я хранил в IntMap (IntMap a), что, в сумме позволило обогнать код на Си (clustering coefficients) в десять (10) раз по скорости.

Почему так?

Потому, что IntMap уже сортированные. И их пересечение имеет сложность O(n). При анализе безмасштабных графов вы в обязательном порядке зайдёте на узел со связностью O(количество узлов графа) - так уж устроены эти графы.

Код на Си использовал несортированное представление связности узла - он сперва копировал в буфер, потом сортировал и после выполнял пересечение для сортированных представлений. То есть, при старте с пустого графа выполнялось O(N) сортировок сложностью O(NlogN) для пересечений и O(N) вставок. В сумме сложность была O(N^2logN). При использовании сортированного представления на IntMap мы получаем O(NlogN) сложность вставок и O(N^2) сложность пересечений. Разница на графе в 16 миллионов узлов получилась в десять раз - то есть, код на Хаскеле был медленный (должно было получиться 24 раза), но всё равно быстрее Си.

Что самое приятное, я всё это проделал "не приходя в сознание" - взял сперва Data.Map, потом Data.IntMap, потом поменял ключ в IntMap и вуаля! получил довольно быстро работающую программу.

Вот, вроде, и всё.

PS
История с Tweag уточняется. Может быть, я неправильно помню.

Которая Рамен Хаус на Толстого.

За неделю у них уменьшились порции и выросли цены процентов на пять, такого плана.

Не рекомендую.

Мне очень нравится, надо сказать.

Код получается разделить достаточно хорошо и защищённо, а также получить оптимальное размещение данных. Прямо сказка, по сравнению с Питоном (по модулю отсутствия подсказок, конечно).

Единственное, что мне не нравится, это отсутствие ограничений на параметры шаблонов, а-ля типы классов Хаскеля. Но сравнимых результатов можно добиться просто другой структурой кода.

Был упомянут в посте shadow_ru, по поводу чего имею вот, что сказать.

Как известно, ум коррелирует с IQ, типа, чем умнее человек, тем выше IQ. В жизни же IQ практически наилучшим образом коррелирует с доходами - чем выше IQ, тем выше доход, и наоборот. Соответственно, он коррелирует с карьерным ростом, ибо там доход выше.

Интересное здесь то, что для карьерного роста необходимо уметь врать. Вообще, убеждать, но эти две вещи связаны.

Наилучший лжец верит в то, о чем врет. Умеет убедить, в первую очередь, самого себя.

После того, как до меня это дошло, я стал ловить моменты, когда такое происходит. Например, это отлично видно в отношении западных интеллектуалов к Трампу - вместо разбирательства, почему они не смогли понять его победу, они ретранслируют мнения, совпадающие с их плохим к Трампа отношением.

Так вот, Левенчук находится ровно в этой же позиции - достаточно умён, чтобы обмануть себя, что я и вижу.

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

Для меня, впрочем, полезной информации у него маловато, а труд такой же, как и при чтении 17ur.

Smalltalk в его инкарнации конце 90-х. выполнял одно очень правильное преобразование кода в своём JIT - специализацию.

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

Что порождало возможность развернуть вызываемый код и, далее, устранить проверки.

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

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

Вон, в моём коде использовался Counter, в который я всегда добавлял положительные счётчики. Куски кода Counter, которые проверяют на ноль и/или отрицательные значения, могли бы быть выброшены вообще, поскольку никогда не сработают. Но они выброшены не были и в результате замена Counter на dict и расстановка условий и циклов там, где я использовал one_counter += other_counter, привела к ускорению выполнения более, чем в десять раз.

Smalltalk, очень не статический язык, в его инкарнации начала 90-х, имел JIT, который умел убирать обращение к VMT. Это, потом, попало в HotSpot, если что.

Как так получилось, что современный Питон, со всеми вложенными в него деньгами, не умеет так делать до сих пор и мне до сих пор надо делать if key in dict: dict[key] = f(dict[key], x) else: dict[key] = g(x)?

Для этого даже JIT не нужен, если что. Это можно в байткоде делать и всё равно выигрыш будет.

PS
Отхожу от замены всех Counter обратно на dict, что дало увеличение скорости в 100 раз.

Мне умудрились там подать совершенно холодный стейк, в отдельной его части. Холодный в степени "только что из холодильника", такого плана, а не "вы его долго ели и он остыл".

Официантка сказала, что "так по всей Москве, везде готовят плохо", вместо того, чтобы извиниться или сказать, что они исправятся (я не просил ничего возместить, если что).

Главные по залу несколько женщин, три из четырёх (и ещё пара официанток) носят часы на правой руке, что я наблюдал у активной части лесбиянок.

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

В общем и целом, не могу рекомендовать сие заведение. Наверное, в другом его филиале творится то же самое.

Несмотря на его умеренную бюджетность, я туда сам ходить не буду.

Наше текущее AST в трансляторе VHDL спроектировано изменяемым. Сперва создаётся объект через new ASTObject(tree и тп) и заполняется через вызовы методов и установку свойств. Обоснование изначально было "если мы не сможем создать объект полностью, так хоть частично его заполним и вернём".

Поскольку надо сигнализировать об ошибке, практически всюду и везде возвращается null. Частично созданный объект никогда не возвращается.

VHDL язык с недетерминизмом в проверке типов - если у нас есть "оператор" function "AND"(a,b:integer) return integer и function "AND" (a,b:integer) return bit_vector, то проверка типов должна попробовать оба-два варианта для выражения 1 AND x. Большую часть времени возвращаемый тип ограничен сверху, но иногда не ограничен - при преобразовании подтипов-массивов (подробности, право слово, ещё ужасней). Поэтому естественным подходом к проверке типов был бы "создаём все варианты, а потом отбросим ненужные", однако проверка типов сопряжена с созданием объектов AST (и это верно, ибо x(a) может быть вызовом функции или взятием элемента массива), а они, как я уже объяснил, сперва создаются, потом заполняются и меняются в процессе. Поэтому правильный подход затруднён, если учесть размер функций преобразования - в районе 50-600 строк, медиана сотня строк.

Но и это ещё не всё.

В данный момент все файлы транслируются каждый раз перед запуском. Причина проста - запомнить состояние проекта невозможно, ибо, бахама мама, AST может быть изменено! Да и система поиска прошита в AST так, что отделить её от самой AST труднее, чем сиамских близнецов, сросшихся сердцами. А при компиляции изменённых файлов надо же ещё перекомпилировать файлы, которые зависели от содержимого изменившихся!

Опять же, если бы 1) использовались неизменные данные (readonly на все поля) и 2) система поиска была бы отвязана от AST и делалась бы атрибутными грамматиками (точнее, атрибутными деревьями - деревья AST, дополненные атрибутами), то обе вышеописанные проблемы были бы не то, что решаемы, а имели бы тривиальное решение.

Но я живу в мире, который мне дан в ощущениях (а не выбран мной), поэтому я буду лопатить тонны кода, преобразуя сие чудо техники в нечто нормальное, пока ответственный за всё это рисует платы в нашем CAD.

А вот мои читатели, надеюсь, учтут эти ошибки и смогут их обойти.

PS
Мой опыт говорит, что наибольший опыт приобретается после переписывания программы в третий раз. Не ленитесь, не будьте похожи на руководителя нашей группы.