Category: архитектура

Category was added automatically. Read all entries about "архитектура".

with Cat The Cat

Про эффекты.

Наше текущее 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
Мой опыт говорит, что наибольший опыт приобретается после переписывания программы в третий раз. Не ленитесь, не будьте похожи на руководителя нашей группы.
with Cat The Cat

Про утечки памяти в Хаскеле.

Влад 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), но у Олега Киселева есть набор техник по использованию типов, параметризованных числами.

Соединив две эти статьи, можно получить то, что нужно - ФРП сервер, программа которого не содержит зацикливаний, блокировок и утечек памяти. Всё это с проверкой компилятором.

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

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

Дальше посмотрим.