Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение  Обсуждение из раздела Школа ОБЕРОНА
№ 6116 19-12-2007 15:15 |  |
Ответ на »сообщение 6112« (Jack Of Shadows)
___________________________
Ответ на »сообщение 6110« (Стэн)
___________________________
Меньше. скомпилированная exe тестовой программки hello world на хаскеле весит примерно 500 kb, это вместе со всем runtime запихнутым в него.
А поскольку рантайм написан на Си, не содержит символьной и метаинформации, структур поддержки модульности, которые в случае рантайма ББ (он ведь написан на самом ББ/КП) отжирают процентов 20 места, то коэффициент по объёму исходных текстов где-то 10 для Хаскеля к 1 для Оберона. Т.е. вместо 3 тыс. строк исходного текста - 30 тыс. Прозрачная "глыба", нечего сказать. Внушающая уверенность... :-)
№ 6115 19-12-2007 15:10 |  |
Ответ на »сообщение 6112« (Jack Of Shadows)
___________________________
Ответ на »сообщение 6110« (Стэн)
___________________________
А вот сколько весит тот же оберон, без которого я так понимаю ни одна программа написанная на нем работать не будет ? :))
Рантайм Блэкбокса, необходимый для старта приложений на Компонентном Паскале, сборки мусора, динамической загрузки/выгрузки, метапрограммирования (в смысле - доступа из программы ко всем сущностям, описанным в ней, и их изменение) будет весить ~ 80 Кб. Практически как весит BlackBox.exe.
№ 6114 19-12-2007 15:08 |  |
Ответ на »сообщение 6112« (Jack Of Shadows)
___________________________
Ответ на »сообщение 6110« (Стэн)
___________________________
Меньше. скомпилированная exe тестовой программки hello world на хаскеле весит примерно 500 kb, это вместе со всем runtime запихнутым в него.
А вот сколько весит тот же оберон, без которого я так понимаю ни одна программа написанная на нем работать не
Ну что за манера про бузину сразу... Где меня интересовал объём "скопилированной exe"? Меня интересовал объём исходных текстов рантайма и то, насколько устройство этого рантайма доступно для использующего его программиста. Предположим, меня не устраивает конкретный механизм "замены на лету процедур в системе", я хочу докрутить что-то своё? Или немного подкорректировать стратегию управления памятью. Сколько дней/недель/месяцев мне потребуется на то, чтобы уверенно влезть в рантайм и его "переконструировать" под себя?
Беда в том, что большинство сегодняшних "компонентных платформ" не компонентны внутри себя. Все игры "в конструктор" - сверху. А внизу - чугунная плита. С наглухо заваренными люками. Только Оберон этого избежал, а мы и дальше идём уже :-)
№ 6113 19-12-2007 15:03 |  |
Ответ на »сообщение 6112« (Jack Of Shadows)
___________________________
>>>А вот сколько весит тот же оберон, без которого я так понимаю ни одна программа написанная на нем работать не будет ? :))
Для компилятора XDS программа "Hello world!" со всем рантаймом весит меньше 70K. :)
№ 6112 19-12-2007 14:46 |  |
Ответ на »сообщение 6110« (Стэн)
___________________________
Вы бы скачали для приличия этот runtime и посмотрели сколько он там весит - 1.53 МБ (ghc-6.8.1)...
Меньше. скомпилированная exe тестовой программки hello world на хаскеле весит примерно 500 kb, это вместе со всем runtime запихнутым в него.
А вот сколько весит тот же оберон, без которого я так понимаю ни одна программа написанная на нем работать не будет ? :))
№ 6111 19-12-2007 14:45 |  |
Ответ на »сообщение 6110« (Стэн)
___________________________
Ответ на »сообщение 6109« (Илья Ермаков)
___________________________
>>> А вот вы, уважаемые хаскеллёры, сделаете только то, что вам позволят разработчики рантайма, ибо десяток мегабайт исходников рантайма на Си - это далеко не конструктор :-)
Вы бы скачали для приличия этот runtime и посмотрели сколько он там весит - 1.53 МБ (ghc-6.8.1)...
Пардон, я сужу со слов самих функциональщиков. Они тут как-то рассказывали, какой объём имеет рантайм Хаскелла.. Если в цифрах ошибся - прощении просим...
№ 6110 19-12-2007 14:36 |  |
Ответ на »сообщение 6109« (Илья Ермаков)
___________________________
>>> А вот вы, уважаемые хаскеллёры, сделаете только то, что вам позволят разработчики рантайма, ибо десяток мегабайт исходников рантайма на Си - это далеко не конструктор :-)
Вы бы скачали для приличия этот runtime и посмотрели сколько он там весит - 1.53 МБ (ghc-6.8.1)...
№ 6109 19-12-2007 14:20 |  |
Ответ на »сообщение 6104« (Geniepro)
___________________________
Ответ на »сообщение 6102« (AVC)
___________________________
Интересно, как исправляют эти процедурки в ПО к бразильской электростанции? Неужели тоже перезагружают сотни модулей после мелких исправлений? :о))
Нет, просто система строится с минимумом статических связей - с максимумом динамических разъёмов. Тогда всё дело сводится к отключению разъёма, изъятию нужного модуля и замене его. Я считаю неукоснительным правилом компонентного программирования - расширять и заменять можно только так, по тем "трассам расширения", которые заложены разработчиком. И никак иначе. Вы можете заменить в серверной стойке "на горячую" SCSI-накопитель, но ни один разработчик серверов не позволит Вам менять "на горячую" ферритовый диск этого накопителя...
А реализовать замену отдельной процедуры в модуле, если это нужно - легко. Полдня работы - и будет механизм для такой замены. Никаких особых технических проблем к этому нет. Только зачем оно надо?
Если будет нужно, реализовать выгрузку модуля даже из дерева статических связей возможно. Механизм изъятия-эмиссии объектов модуля. Типа сборщика мусора, но немного по-другому: заменяем все ссылки в памяти на объекты старого модуля на объекты нового модуля. Осуществляем восстановление состояния через сериализацию старых-новых объектов на основе какого-общего формата. Конструктор Лего - что будет надо, то и сделаем. А вот вы, уважаемые хаскеллёры, сделаете только то, что вам позволят разработчики рантайма, ибо десяток мегабайт исходников рантайма на Си - это далеко не конструктор :-)
№ 6108 19-12-2007 11:14 |  |
Ответ на »сообщение 6107« (info21)
И еще добавление: ни для каких серьезных целей, где требуется надежный и хорошо соптимизированный код, я лично никогда не возьму с++ (в моем тесте о нем шла речь). "Через мой труп."
№ 6107 19-12-2007 11:08 |  |
Ответ на »сообщение 6070« (QR)
___________________________
Ответ на »сообщение 6037« (info21)
Поскольку ссылки на код в указанном докладе не приводятся, сделать на его основе какое-то осмысленное заключение о быстроте ББ не представляется возможным. ...
Вам -- нет. Мне -- да. Есть и другие люди, которым такое свидетельство интересно. Делайте с моим свидетельством что хотите. Это реальный код из реальной работы, решающий относительно самостоятельную реальную задачу. Публиковать код нет возможности.
Насчет Вашего "бенчмарка" -- в реальной живой развивающейся программе, спроектированной на эволюцию, такого кода я в жизни ни разу не видел.
Оптимизируют подобные вещи, когда делают софт, который будет типа обслуживать детектор и на лету делать пред-процессинг данных, и делать это годы. К примеру.
Но тогда я сначала отображу данные на статическую память -- и перепишу не на С++ (что я, больной), а на фортране, и возьму какой-нибудь вылизанный за 40 лет оптимизирующий компилятор, который вобьет любой компилятор с++ в землю по макушку.
Добавить свое сообщение
Отслеживать это обсуждение 
Дополнительная навигация: |
|