Все так или иначе содержат утечки памяти либо имеют неработающие примитивы. Если, конечно, речь идет о там фрп которое Functional Reactive Programming.
Проблема не столько в самих утечках и непредсказуемости, а в том, что для их поиска/устранения некуда обратится. Не к Simon Peyton Jones жеж обращаться какому-нибудь корпоративному клиенту, если у них mission-critical приложение на хаскеле начнет глючить. Для распространненных языков хватает контор и людей, которые могут при надобности разобраться, а вот с экзотикой вроде хаскеля проблемы.
насколько я помню, они уже есть - недавно видел сайт компании, занимающейся консалтингом по хаскелю (они кажется были упомянуты в (пред?)последнем haskell weekly news)
Хм. Жесть конечно. Статически, на этапе компиляции, выводить объем занимаемой памяти и время отклика. Это конечно возможно (да и то, нужно как-то включить ось/железо/сторонние библиотеки), но что-то кажется, что для эрланга и прочих php/perl/mysql никто этого не делает.
Как обычно, все можно обойти на другом уровне. Есть сессия, есть БД. Вытащили данные, посчитали, запихнули обратно в БД. Сессия закончилась, невычисленных цепочек нет (вообще ничего нет, только БД осталась). Вот и все. Утечки страшны как раз в длинных вычислениях, а их в серверах нет.
Во-первых, не во время компиляции, а во время проектирования. Такое свойство, как расход памяти, должно быть легко доказуемым в случае систем, ограниченных ресурсами. Таковы не только embedded системы, но и высоконагруженные сервера.
Для Эрланга, С++, Java, и любого строгого языка, нет никаких проблем оценить расход памяти при проектировании. Это элементарно.
В случае Хаскеля, это сделать невозможно. И невычисленная цепочка - является по факту непредсказуемым багом с высоким severity, a-la crash.
Обойти это коротким временем жизни "сессии" - не вариант для всех случаев. Самые интересные сервера не пользуются внешней БД для сериализации и персистенса. Хотя, это уже более-менее внятный ответ на мой тезис. Действительно, короткое время "сессии" в какой-то степени гарантирует от подобных проблем. Осталось показать, как это делается, когда нет внешней БД, где хранится стейт.
Для Эрланга, С++, Java, и любого строгого языка, нет никаких проблем оценить расход памяти при проектировании. Это элементарно.
Не сказал бы. Хотя бы та же рекурсия, которая случайно оказалась не хвостовой и убивает стек. Просто утечка памяти (free не сделали, оставили ссылку на большую структуру). Это все такие же "глюки", как и накопившаяся невычисленная цепочка. И с ними также борются.
К тому же, в языках со сборщиком мусора есть свои дополнительные расходы на каждую структуру данных, каждый указатель. Так просто, как в Си, размер структуры не посчитаешь. Если нет огромных бинарных блобов, то все можно предсказывать только плюс-минус много процентов.
Действительно, короткое время "сессии" в какой-то степени гарантирует от подобных проблем. Осталось показать, как это делается, когда нет внешней БД, где хранится стейт.Думаю, какая-нить in-memory db все-таки присутствует и возможность скидывания данных на диск у нее все-таки есть. Т.е. данные в нее поступают в виде, пригодном для сериализации. Ну вот и отсериализуем результат
( ... )
Comments 49
А вот http://www.cis.upenn.edu/~stevez/papers/LZ07.ps
Reply
Читаю. ;)
Reply
Reply
Reply
Reply
И представьтесь, пожалуйста.
Reply
Reply
Reply
Reply
Я чтот не нашёл (кстати, чтот weekly у них не получается, наверное из-за НГ :) )
Reply
Как обычно, все можно обойти на другом уровне. Есть сессия, есть БД. Вытащили данные, посчитали, запихнули обратно в БД. Сессия закончилась, невычисленных цепочек нет (вообще ничего нет, только БД осталась). Вот и все. Утечки страшны как раз в длинных вычислениях, а их в серверах нет.
Reply
Я на случай длительной работы.
Reply
Для Эрланга, С++, Java, и любого строгого языка, нет никаких проблем оценить расход памяти при проектировании. Это элементарно.
В случае Хаскеля, это сделать невозможно. И невычисленная цепочка - является по факту непредсказуемым багом с высоким severity, a-la crash.
Обойти это коротким временем жизни "сессии" - не вариант для всех случаев. Самые интересные сервера не пользуются внешней БД для сериализации и персистенса. Хотя, это уже более-менее внятный ответ на мой тезис. Действительно, короткое время "сессии" в какой-то степени гарантирует от подобных проблем. Осталось показать, как это делается, когда нет внешней БД, где хранится стейт.
Reply
Не сказал бы. Хотя бы та же рекурсия, которая случайно оказалась не хвостовой и убивает стек. Просто утечка памяти (free не сделали, оставили ссылку на большую структуру). Это все такие же "глюки", как и накопившаяся невычисленная цепочка. И с ними также борются.
К тому же, в языках со сборщиком мусора есть свои дополнительные расходы на каждую структуру данных, каждый указатель. Так просто, как в Си, размер структуры не посчитаешь. Если нет огромных бинарных блобов, то все можно предсказывать только плюс-минус много процентов.
Действительно, короткое время "сессии" в какой-то степени гарантирует от подобных проблем. Осталось показать, как это делается, когда нет внешней БД, где хранится стейт.Думаю, какая-нить in-memory db все-таки присутствует и возможность скидывания данных на диск у нее все-таки есть. Т.е. данные в нее поступают в виде, пригодном для сериализации. Ну вот и отсериализуем результат ( ... )
Reply
(The comment has been removed)
Сложность алгоритма доказывается для любого способа вычислений, буде то ленивый или энергичный.
Reply
(The comment has been removed)
Но чтобы "невозможно" - не соглашусь.
Reply
Leave a comment