Про утечки памяти в Хаскеле.
Влад gaperton на RSDN всё пеняет мне и остальным Хаскельщикам утечкой памяти, что была в нашей модели процессора (по ссылке не надо обращать внимание на опрос;).
Она возникла "ниоткуда" и была неприятным сюрпризом.
Он упирает на непредсказуемость Хаскеля в этом отношении.
Но буквально пять минут назад до меня дошло, что тогда мы и не пытались предсказывать или как-то планировать его поведение!
Даже мысли такой не было. Мы просто написали модель, она заработала, выдала результаты и на этом мы успокоились.
Мой основной тезис состоит в принятии модели вычислений за ещё одну архитектуру.
С любой непривычной архитектурой необходимо мучаться. Что SMP/NUMA, что просто SMP, что Cell BE, не в ночи будь помянут.
Что ленивые вычисления.
И мучаться приходится на этапе оптимизации. В случае Cell - так вообще программу переписывать, радикальным образом.
Итак, мучения у нас везде. Всюду надо учиться предсказывать поведение системы. И если люди научаются справляться с не в ночи поминаемым этим самым, то с ленивыми вычислениями точно должны справится. Их, в конце концов, не инженеры IBM придумывали.
gaperton утверждает, что написание устойчивых программ наподобие сильно нагруженного сервера на Хаскеле невозможно в принципе, или значительно затруднено по сравнению с энергичными языками. Напрямую этот выпад пока отразить невозможно, даже с учётом идеи "модель вычислений - архитектура процессора", поэтому я отступлю для перегруппировки сил и выставлю заслон из всякой разной теории.
Для функциональных реагирующих программ (FRP) я случайно отыскал интересную статью - проверка правильности работы ФРП с помощью "размерных типов" (sized types). Эти типы позволяют... Цитата: Sized types are useful for detecting deadlocks, nontermination, and other errors in embedded programs.
Я не пытался реализовать это дело на Хаскеле (type system hackery ain't my strong side), но у Олега Киселева есть набор техник по использованию типов, параметризованных числами.
Соединив две эти статьи, можно получить то, что нужно - ФРП сервер, программа которого не содержит зацикливаний, блокировок и утечек памяти. Всё это с проверкой компилятором.
В принципе, это увеличит время написания программы. Ну, и ладно. Мы можем получить первый прототип обычным способом, а потом преобразовать его в вид с нужными ограничениями отдельным шагом.
Я не думаю, что указав на пару статей, я закрыл тему Хаскеля в районе серверов, но, по крайней мере, если мне теперь снова зададут этот вопрос, я смогу указать на путь получения ответа или, если столкнусь с этим в жизни, смогу решить эту проблему самостоятельно.
Дальше посмотрим.
Она возникла "ниоткуда" и была неприятным сюрпризом.
Он упирает на непредсказуемость Хаскеля в этом отношении.
Но буквально пять минут назад до меня дошло, что тогда мы и не пытались предсказывать или как-то планировать его поведение!
Даже мысли такой не было. Мы просто написали модель, она заработала, выдала результаты и на этом мы успокоились.
Мой основной тезис состоит в принятии модели вычислений за ещё одну архитектуру.
С любой непривычной архитектурой необходимо мучаться. Что SMP/NUMA, что просто SMP, что Cell BE, не в ночи будь помянут.
Что ленивые вычисления.
И мучаться приходится на этапе оптимизации. В случае Cell - так вообще программу переписывать, радикальным образом.
Итак, мучения у нас везде. Всюду надо учиться предсказывать поведение системы. И если люди научаются справляться с не в ночи поминаемым этим самым, то с ленивыми вычислениями точно должны справится. Их, в конце концов, не инженеры IBM придумывали.
gaperton утверждает, что написание устойчивых программ наподобие сильно нагруженного сервера на Хаскеле невозможно в принципе, или значительно затруднено по сравнению с энергичными языками. Напрямую этот выпад пока отразить невозможно, даже с учётом идеи "модель вычислений - архитектура процессора", поэтому я отступлю для перегруппировки сил и выставлю заслон из всякой разной теории.
Для функциональных реагирующих программ (FRP) я случайно отыскал интересную статью - проверка правильности работы ФРП с помощью "размерных типов" (sized types). Эти типы позволяют... Цитата: Sized types are useful for detecting deadlocks, nontermination, and other errors in embedded programs.
Я не пытался реализовать это дело на Хаскеле (type system hackery ain't my strong side), но у Олега Киселева есть набор техник по использованию типов, параметризованных числами.
Соединив две эти статьи, можно получить то, что нужно - ФРП сервер, программа которого не содержит зацикливаний, блокировок и утечек памяти. Всё это с проверкой компилятором.
В принципе, это увеличит время написания программы. Ну, и ладно. Мы можем получить первый прототип обычным способом, а потом преобразовать его в вид с нужными ограничениями отдельным шагом.
Я не думаю, что указав на пару статей, я закрыл тему Хаскеля в районе серверов, но, по крайней мере, если мне теперь снова зададут этот вопрос, я смогу указать на путь получения ответа или, если столкнусь с этим в жизни, смогу решить эту проблему самостоятельно.
Дальше посмотрим.