3
Не секрет, что встраивание - это то, что позволяет реализовать множество сложных оптимизаций, которые может выполнять GHC. Если я связываю библиотеку динамически (и получаю фактический файл dll/so из нее), может ли GHC оставаться в очереди, где бы он был, как если бы ссылка была статической и зависела от dll для остальных? или я действительно получаю меньше оптимизаций?Может ли динамическое связывание повредить, таким образом, производительность в GHC?
У вас есть что предложить? Я имею в виду, что я знаю файлы интерфейса, но я не знаю, будет ли GHC использовать их для общей библиотеки. И как это будет? я поставляю путь общей библиотеки + путь для файлов интерфейса к аргументам компиляции для исполняемого файла? Я не смог найти много информации обо всем этом; это очень неопределенно для меня в данный момент. Спасибо за ваш ответ. – MasterMastic
Это было не в моей голове, но вы можете прочитать об этом в [GHC wiki] (https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/IfaceFiles). GHC не сможет проверить тип (и более того) _without_ файлов интерфейса. Вы можете прочитать, как [создавать общие объекты] (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using-shared-libs.html), но я бы просто let 'cabal' [справиться с этим] (https://www.haskell.org/cabal/users-guide/installing-packages.html). (Поиск 'shared'.) Вы не упомянули, почему вы хотели использовать общие библиотеки. Так почему? – liyang
О! ваше замечание о стиле должно было внезапно вызвать все это; очень умный из вас. Тогда, я полагаю, я действительно могу доверять, что он будет встроен, учитывая, что он должен иметь информацию, необходимую для этого. Я не хочу использовать общие библиотеки для чего-либо конкретного на данный момент, я просто не хотел исключать их из своего арсенала, когда важны показатели производительности (например, даже простой цикл, повторяющий небольшую функцию из общей библиотеки, может сильно укусить мне, если бы там не было инкрустации). Большое спасибо! – MasterMastic