из этих ваших продакшенов

кстати интереснее всего будет вести себя -qm (или как там пин капабилити к тредам зовется) на amd

где топология не как у интела

а что именно в них плохое?

вообще в проектах, которые "тормозят" обычно достаточно настроить RTS, что ускорить в 2-3 раза, если не на порядок

причем Марлоу принимает фиксы, но оооочень медлено

вон -qb0 есть при больших A

и то хорошо

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

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

но потом сам же не делает такие настойки по умолчанию

ну он почему-то не считает, что это должно быть дефолтом

не знаю

аааа пользователи скажут что программа стала больше памяти занимать

я конечно понимаю, что у него в фейсбуке 128 процессоров на компе

и повышение -A64 приведет к 8Gb оперативки

точнее 16

но обычно пользователю пофиг

для машины со 128 ядрами это не очень большая трата памяти

а может у тебя xeon phi

там столько ядер, а памяти не то, чтобы много

но в любом случае, имхо люди со странными архитектурами уж могут опции поменять

это хотя бы ожидаемо

или если хочешь чтобы программа в 10мб работала

в 2018

смешно было, когда с 512k до 1m увеличили в 2016

ага

тяжело далось решение, наверняка

причем , к примеру, в clr размеры эфемерных поколений вот такие | | 32-bit | 64-bit | | ------------------ | ------ | ------ | | Workstation GC | 16 MB | 256 MB | | Server GC | 64 MB | 4 GB | | Server GC > 4 CPUs | 32 MB | 2 GB | | Server GC > 8 CPUs | 16 MB | 1 GB |

чет на l2 кеш пентиума 2 не ровняются

@lightgreen вот это изменение способно ускорить 95% программ минимум в 2 раза

наоборот, учёные не должны мешать продакшену учёные (и ресёрч-ребята в целом, даже если из продакшена) норовят — то компилятор медленнее сделать — то Data.List обобщить (от этого аж две беды — код менее читабельный + надо быть аккуратнее при рефакторинге, потому что добавишь где-нибудь тьюпл и у него length = 1 и всё как бы ок, НО ЗАТО ВЕДЬ ИНСТАНС ЛЕГАЛЬНЫЙ ой мда конечно) — то фичу какую-нибудь впилить, от которой ошибки становятся сильно хуже, потому что а вдруг юзер имел в виду эту вот фичу и код почти-валидный на самом деле — то линейные типы пропихнуть, которые они могут юзать для продакшена, но у обычных людей голова стопудов пухнуть будет

А как в чистом функциональном языке без линейных типов легально делать in place мутации? А как без них добиться перформанса?

Вот тут написано: https://kouzdra.livejournal.com/912059.html

Проще говоря, надо "отщепить" от мира массив, in-place мутировать его, потом влить обратно в мир.

При этом, как я понял, под капотом отщепление и вливание может тоже быть in-place

я от себя скажу, что читая чатик и коменты про разные фичи создается впечатление что хаскель жуть недопиленное нечто, с проблемными либами ? что меня лично останавливает от изучения. хотя почему-то все равно тянет вернуться и попробовать таки

неправильное впечатление. чтоб понять, что неправильное, надо ещё смотреть живое кодирование Kmett and McKenna on twitch or youtube.

При этом, как я понял, под капотом отщепление и вливание может тоже быть in-place

Ну это с линейными типами. А без линейных типов никак, ибо ссылочная прозрачность нарушается.

А, блин, протупил. Вопрос был про фп-БЕЗ-линейных типов :) Тогда не знаю. Могу только предложить книжку Окасаки про ФП, там предложено много приёмов, как можно без in-place жить.

Кстати, а компилятор не способен ли определить, что к какому-то объекту в памяти доступ только с одного места? Ну и заменить все операции на in-place.

Кстати, а компилятор не способен ли определить, что к какому-то объекту в памяти доступ только с одного места? Ну и заменить все операции на in-place.

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

если бы в котлине были HKT и тайпклассы, меня бы в скале не было.

Предположительно твоё отсутствие в скале привело бы к её уничтожению?

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

Без линейных типов тоже вполне можно оптимизировать хорошо на инплейс мутации

В статьях про секвенции об этом норм написано

Только не найду в каких

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

Он уже лучше для всех, кто в скале ради лучшей жавы

А будет ещё и лучше для тех, кто пишет фп

А как в чистом функциональном языке без линейных типов легально делать in place мутации? А как без них добиться перформанса?

runST

runST

А это точно легально? С ST не может быть ситуации когда ссылочная прозрачность будет утеряна? Ну например изменение чего-то в двух разных местах?

не может быть

А это точно легально? С ST не может быть ситуации когда ссылочная прозрачность будет утеряна? Ну например изменение чего-то в двух разных местах?

логически это просто оптимизированный State

логически это просто оптимизированный State

Так State a может быть спокойно скопирован. При этом ссылочную прозрачность гарантирует иммутабельность. Как гарантии ссылочной прозрачности достигаются в ST без линейности?

с помощью Rank2 polymorphism

Так State a может быть спокойно скопирован. При этом ссылочную прозрачность гарантирует иммутабельность. Как гарантии ссылочной прозрачности достигаются в ST без линейности?

внутри ST ты не можешь скопировать весь ST из-за лишнего фантомного типа

а на самом деле потому что это IO

http://homepages.dcc.ufmg.br/~camarao/fp/articles/lazy-state.pdf

2.4 Encapsulation

Спасибо за разъяснения, буду изучать.

А это точно легально? С ST не может быть ситуации когда ссылочная прозрачность будет утеряна? Ну например изменение чего-то в двух разных местах?

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

в векторе правда есть правила перезаписи для некоторых случаев, когда копирование можно выкинуть (когда массив новый создается прямо перед тем как растаивается, к примеру), но это только часть ненужных копирований устраняет

Так State a может быть спокойно скопирован. При этом ссылочную прозрачность гарантирует иммутабельность. Как гарантии ссылочной прозрачности достигаются в ST без линейности?

Ключевое отличие, что слой ST даёт тебе разрешение на мутабельные действия, включая создание и изменение ссылок и массивов разом. Разделить возможности: дать ридонли к этому, мутабельный к тому, возможность создать то и удалить сё, - довольно сложно. Имея только интуиционисткие типы крайне сложно отследить, что не протекают разрешения. Можно придумать коммутирующие слои ST монад, но вводить отдельный слой для каждой переменной - затруднительно. Если дать возможность удалять, после удаления ссылки массива запретить чтение/изменение опять же крайне сложно. С линейными ты можешь таскать изолированные капабилити для каждого действия с каждым мутабельным объектом.

с IndexedMonad можно сделать более хитрые правила

в общем-то с IndexedMonad вполне возможно можно эмулировать линейные типы

но писать код печально будет

т.е. в тайплевел состоянии будет лежать список (s и информации о типе)

но там будет такой ад, что мне даже представлять не хочется

в общем-то с IndexedMonad вполне возможно можно эмулировать линейные типы

Ну да, если ввести вообще вручную моноидальные категории любой формы и композить вручную. Это как будто пишешь вручную на IR

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

@graninas помню ты писал, что вы как-то стопали выполнение сценария на фри-монадах и сериализовывали список выполненных команд, а потом восстанавливали и продолжали?

@Racsicofalapatorius будет жить. Поприветствуем!

@graninas помню ты писал, что вы как-то стопали выполнение сценария на фри-монадах и сериализовывали список выполненных команд, а потом восстанавливали и продолжали?

Да, это было в рамках проекта resumable persistable workflows

а каким образом вообще это сериализировалось?

там же лямбды

Ну, сценарий-то выполняется по шагам, несмотря на то, что он является выражением. Там в стеке интерпретатора был RecorderT, который это позволяет делать. На каждом шагу он либо выполняет монадическую операцию сценария, либо берет ее результат, каковой он был при прошлом выполнении. Там можно "проиграть" записанные результаты в порядке появления. Это, кстати, использовалось еще и для правильного форкания дочерних workflow

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

хм, то есть хранились не команды, а результаты?

Да

А есть где посмотреть на код?

Код этого проекта приватный

Пример сценария:

@ArtemHlystov будет жить. Поприветствуем!

Описание языка:

@graninas пиши статью об этом подходе...

@graninas пиши статью об этом подходе...

Хотел...

Хотел...

так что останавило?

лень, хаскель же

время не пришло)