Nano Hash - криптовалюты, майнинг, программирование

Почему Cabal загружает и компилирует из исходников?

Когда я делаю новый проект. Скажем, веб-приложение, использующее Snap. Я генерирую скелет с помощью snap init barebones, создаю новую песочницу и затем устанавливаю зависимости.

Это занимает вечность. Шутки в сторону. Если вы когда-либо работали практически с любым другим веб-фреймворком (например, node.js с экспрессом), процесс почти идентичен, но занимает немного времени. Я знаю, что большинство зависимостей узлов не требуют какой-либо компиляции, но мне кажется очень странным, что это не считается более серьезной проблемой. Например, я никогда не смогу запустить приложение Yesod на своем дешевом VPS, потому что VPS недостаточно мощный для его компиляции, и я не могу загрузить 500 МБ предварительно скомпилированных библиотек.

Вопрос в том, почему в репозитории не размещаются бинарные файлы, а не просто код? .NET также скомпилирован (в байт-код), но я могу использовать его библиотеки DLL без необходимости перекомпиляции.

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

  • Больше никаких ошибок компиляции
  • Более быстрая настройка для новых проектов
  • Требуется значительно меньше памяти
  • Знание того, что библиотека не поддерживает вашу ОС, ДО того, как вы это узнаете сами

Мне трудно понять, почему вообще существует ад клики. Если бы все библиотеки были доступны для динамической компоновки, разве необходимости в перекомпиляции просто не существовало бы?

В настоящее время нужно очень стараться придерживаться Haskell в этом отношении. Похоже, система наказывает меня за то, что я что-то пробую. Если я хочу добавить новую библиотеку в свой проект, я должен быть уверен, что готов ждать 15-45 (!!!) минут, пока она скомпилируется. Не говоря уже о том, что библиотека не компилируется чаще, чем мне удобно. Только после того, как я переживу этот процесс, я действительно смогу понять, является ли эта библиотека тем, что я хочу использовать, и совместима ли она с остальной частью моего проекта.

dynamic-linking haskell cabal
27.11.2014

  • @BartekBanachewicz Привет. Мой вопрос был исключительно вежливым, и каждая его часть, пусть и анекдотическая, является правдой. Если вам трудно сдерживать свой темперамент, не отвечайте, но нет причин ставить минусы или называть меня необразованным. Не стесняйтесь обучать меня или позвольте сделать это кому-то другому. 27.11.2014
  • Я думаю, что этот вопрос просто плохой, и, следовательно, мой отрицательный голос. Этого достаточно, согласно правилам сайта. 27.11.2014
  • .NET обычно не компилируется в байт-код, он компилируется в CIL, который представляет собой кроссплатформенный язык, похожий на ассемблер, вроде LLVM. Вы можете загружать библиотеки из NuGet относительно быстро, потому что он может получить то, что, в частности, может понять .NET. Попробуйте сделать это с C, вам будет трудно. Даже с DLL у вас должны быть разные двоичные файлы в зависимости от 32-битной, 64-битной, иногда архитектуры, и если вам нужна хорошая оптимизация, вы должны компилировать из исходного кода. Haskell выбрал путь производительности и поддержки нескольких операционных систем, в отличие от .NET. 27.11.2014
  • @bheklilr У вас есть статистические данные о приросте производительности? 27.11.2014
  • несколько двоичных файлов на библиотеку для нескольких ОС ... Зная, что библиотека не поддерживает вашу ОС, ДО того, как вы это узнаете сами, за исключением той части, где либо сопровождающие библиотеки, либо Hackage должны иметь возможность создавать для каждой отдельной платформы, ОС, архитектура и все их сочетания. Это означает несколько версий Windows, Ubuntu, OSX, Arch Linux, CentOS, RedHat, список можно продолжить. Это слишком сложная задача, чтобы ставить ее перед одной службой, когда у вас есть возможность создать ее самостоятельно. 27.11.2014
  • @LukaHorvat Сравнивать производительность языков и библиотек сложно (TLDR, измеряющий один вариант использования, дает вам данные об этом одном варианте использования и почти ничего больше). Хорошо известно, что Haskell является быстро, если вам это нужно, для языка такого высокого уровня. Но даже в этом случае производительность (точнее, возможность оптимизации) является лишь одной из проблем. 27.11.2014
  • @LukaHorvat .NET CIL на самом деле скомпилирован JIT, поэтому он может оказаться довольно быстрым, но всякий раз, когда вы говорите о производительности, есть определенные задачи, в которых почти любой язык превзойдет другие. Это сказал, есть случаи, когда Haskell может даже превзойти C на числовые вычисления. 27.11.2014
  • @bheklilr Это такая сложная задача для взлома, чтобы скомпилировать библиотеки? Я имею в виду, что если вы создаете библиотеку, которую хотите использовать другие, вам все равно придется убедиться, что она работает везде. Я бы сказал, что гораздо разумнее ожидать, что за кросс-компиляцию отвечает централизованная система. Это, конечно, не что иное, как чувство, поэтому я понимаю, что могу быть совершенно неправ. 27.11.2014
  • @LukaHorvat Да, это очень сложно. Сервер Hackage размещен на определенной ОС. Для каждого размещенного проекта, независимо от того, сколько у него загрузок, в некоторых случаях вы должны иметь возможность кросс-компиляции для любой другой платформы, ОС, битрейта и конкретного оборудования. Вы можете создать более общие версии для Linux, Windows и OSX в 32- и 64-разрядных версиях, но это не дает программисту большого контроля над профилированием, отладкой и оптимизацией. Гораздо сложнее сделать это на уже скомпилированном бинарнике. 27.11.2014
  • Помните, что Haskell — это не Microsoft или Oracle, у них нет больших денег, чтобы тратить их на решение подобных проблем, им в основном управляют добровольцы и члены сообщества. Ресурсы — огромная проблема, и хотя сообщество полно очень талантливых людей, оно все еще очень маленькое. Просто спросите себя, сколько людей используют Java, JS, C# или Python, и сравните это с количеством людей, использующих Haskell. Если вы считаете, что Hackage можно улучшить, лучшим путем для вас будет стать участником, исправить некоторые ошибки или внедрить новую функцию. 27.11.2014
  • @bheklilr Кажется, лучшим вкладом было бы разбогатеть и вложить деньги в Haskell :D 27.11.2014
  • @LukaHorvat Тогда удачи, и дай мне знать, как ты разбогател, чтобы я тоже мог. 27.11.2014

Ответы:


1

В двух словах: потому что нативный код сложен.

Если вы хотите размещать двоичные файлы для произвольных систем, вы должны сопоставить двоичные файлы с каждой системой, на которой вы хотите работать. Это может означать компиляцию десятков наборов двоичных файлов для поддержки всех систем, на которых будет компилироваться код.

С другой стороны, вы вполне можете обнаружить, что кто-то скомпилировал код, который вам нужен: ваш дистрибьютор вполне может предоставить пакеты для нужных вам библиотек Haskell.

27.11.2014

2

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

Это можно смягчить различными способами. Например, настройка CI использует CircleCI и Heroku. Узлы на обоих содержат предварительно кэшированные песочницы клики (на самом деле их очень легко настроить). Я создаю свой проект на Heroku, но нет никаких причин, по которым вы не можете взять готовые артефакты из своего CI и развернуть их напрямую.

Что касается динамической компоновки, то есть возможность динамически компоновать модули Haskell, но общие библиотеки чаще всего являются источником проблем. Одного взгляда на ад Windows DLL должно быть достаточно, чтобы увидеть это, и большинство коммерческих приложений просто поставляют библиотеки DLL, которые они все равно используют. Если библиотека меняется, библиотеки DLL все равно приходится заменять, и то, как это делает Cabal, упрощает получение последних и лучших версий всего.

27.11.2014

3

Во-первых, обратите внимание, что на некоторых платформах вы можете устанавливать двоичные библиотеки. Например, в моей системе OpenSUSE Linux YaST с удовольствием загрузит и установит определенные библиотеки Haskell без необходимости собирать что-либо из исходного кода.

Конечно, это касается лишь небольшого набора библиотек, и все пакеты RPM устареют на много месяцев. (Не имеет большого значения для X11, своего рода нарушение условий для чего-то вроде Yesod, которое находится в стадии активной разработки...)

Я думаю, что еще одна большая часть проблемы заключается в том, что если вы скомпилируете библиотеку Haskell с GHC 7.6.4, то вы не сможете использовать эту бинарно скомпилированную библиотеку с GHC 7.8.3. Так что мы говорим не просто об одном скомпилированном двоичном файле для каждой ОС; мы говорим об одном скомпилированном двоичном файле для каждой комбинации OS + GHC.

О, и я упоминал? Если вы скомпилируете Yesod 1.4.0 с ByteString 0.9.2.0, то этот скомпилированный двоичный файл бесполезен, если в вашей системе установлен ByteString 0.9.2.1. Таким образом, вам потенциально нужен один скомпилированный двоичный файл для каждой ОС, каждого выпуска GHC и каждого выпуска каждой библиотеки, от которой он транзитивно зависит.

... Отчасти поэтому была изобретена платформа Haskell. Это одна бинарная загрузка, которая дает вам большую кучу кода, который вам не нужно компилировать из исходного кода, и где все версии библиотек в нем взаимно совместимы. (Никакого ада зависимостей — разработчики платформы Haskell разберутся с этим за вас!)

Я согласен, что бинарные пакеты было бы очень приятно иметь. Но вышеперечисленные проблемы делают это маловероятным, ИМХО.

27.11.2014
  • Разве динамическое связывание не решит многие из них? Библиотека отправляет свои зависимости сама с собой. Если две библиотеки в дереве зависимостей используют одну и ту же версию одной и той же библиотеки, менеджер пакетов следит за тем, чтобы они использовали один и тот же файл, чтобы избежать дублирования. 27.11.2014
  • Мы говорим, это требует, чтобы кто-то сел и решил, какие версии всего использовать, чтобы все работало вместе. Скорее то, что должны делать сопровождающие дистрибутива Linux. Не знаю, есть ли у кого-нибудь время и силы на это. Принимая во внимание, что предоставление всех исходников позволяет людям решить проблему самостоятельно. (Медленно.) 28.11.2014
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..