Предложен (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-June/022028....) для реализации проект постоянного кеширующего сервиса Clang Server (https://docs.google.com/document/d/1kNv2jJK0I0JGnxJxU6w5lUOl...) (clangd) для обслуживания инфраструктуры из множества разнородных, сложных и интерактивных C++ инструментов. В частности этот сервисный слой позволяет обобщить и построить в рамках libclang удобное взаимодействие множества самых разнородных редакторов, интегрированных сред разработки (IDE) и популярных Unix-инструментов разработки. Этот сервис будет реализован строго в рамках Clang/LLVM (http://clang.llvm.org/) и будет поддерживать разработку для языков C, C++, Obj-C и Obj-C++.Сервис будет предоставлять функциональность, которая традиционно присуща для IDE, но при этом задумка заключается в том, чтобы в рамках единой среды дать возможность работать сразу с несколькими разными ”плохо интегрированными в систему” редакторами с одновременным обеспечением связности с такими слоями LLVM, как Tooling library, libclang и в потенциале этот сервис будет иметь свою собственную расширяемую через плагины структуру.
Сервис будет построен на базе уже традиционной клиент-серверной архитектуры, с тем единственным исключением, что у клиента будет реализована функциональность для запуска инициализирующей части сервера, если в процессе запуска клиента сервер окажется недоступен, при этом предполагается, что сам сервер будет находиться локально на одной машине с клиентом. Общий дизайн взаимодействия выбран таким, чтобы можно было реализовать socket-подобный обмен сообщениями, ориентированный на стандартный IPC-механизм организации взаимодействия между клиентом и сервером.
Поскольку взаимодействие планируется сделать унифицированным жестко в рамках фреймворка LLVM, коммуникационный протокол будет реализован в форме сериализированных сообщений, закодированных с помощью формата LLVM bitcode (http://llvm.org/docs/BitCodeFormat.html). Для всех наборов типов таких сообщений будут определены наборы возможных читателей и писателей подобных bitcode-сообщений. Главная роль сервера - это прием сообщений от клиента, совмещение разных конструкций в рамках Clang, ведение управляющей базы данных, а также результирующие ответы клиентам. Конечная цель – создание максимально упрощенного и эффективного IPC-механизма на базе LLVM, который будет давать следующие конечные преимущества:
- Обеспечение перезапускаемого, долгоживущего фонового процесса, который управляет кешированием, компиляцией, индексацией и бизнес-логикой;
- Определение канала и протокола межпроцессорного взаимодействия для создания возможности взаимодействия инструментов разработки друг с другом. В перспективе IPC-слой будет позволять и межмашинное взаимодействие, но это задача не для начальных релизов сервера;
- Возможность автоматически воспользоваться преимуществами многоядерных процессоров;
- Поддержка исполнения очень быстрых запросов в интерактивно-интерфейсных режимах, например автодополнение.
- Предоставление набора базовых инструментов для взаимодействия с сервером через IPC;
- Предоставление стабильного интерфейса Си API (в виде подмножества вызовов libclang API) для взаимодействия с сервером через IPC;- Обеспечение биндинга с Python на основе C API и протокола IPC;
- Полная совместимость и разделение ресурсов с libclang. Для этого планируется создание двух параллельных интерфейсов для одинаковой базовой функциональности;
- Эффективная интерфейсная стратегия для всех базовых OpenSource-редакторов. Как минимум должны хорошо поддерживаться VIM и Emacs, также планируется поддержка нескольких редакторов из Windows и Mac;
В настоящее время проект пока находится на стадии планирования и активного обсуждения. И хотя некоторые разработчики и заявили о том, что они уже преступили к работе над данным проектом, потребуется ощутимое время для согласования и реализации в полной мере как серверной, так и клиентской поддержки.
URL: http://www.phoronix.com/scan.php?page=news_item&px=MTEyMDQ
Новость: https://www.opennet.ru/opennews/art.shtml?num=34113
Вот он, убийца gcc!
>Вот он, убийца gcc!Подумал что-то похожее, только скромнее. И еще про вторую молодость плюсов. Наконец-то, возможно, будет реализовано то, о чем уже десятилетия мечтает Страуструтп.
>>Вот он, убийца gcc!
> Подумал что-то похожее, только скромнее.Жирный сервис генерации кешированных нативных сборок, жрущий сотни метров и генерящий десятки гигазов дряни в кеш. Где-то я это уже видел. А, дотнет!
Вот он, убийца llvm!
> Вот он, убийца gcc!Увы! Это всего лишь очередной дотнет походу :(. С сервисом генерации нативных ассемблей, кладущим проц в полку по полтора часа и генерящий в кеше 10Гб всякого барахла.
Ну это оно так выглядит когда выросло и прошло 4 мажорных версии. А это пока маленькое, но задатки "папаши" уже демонстрирует :(
Какой дотнет? хранить AST в кэше это уже дотнет получается?
> Какой дотнет?Ну вот такой. С сервисом который в фоне жрет сотни метров оперативы, грузит проц и вот так по полчаса.
> Вот он, убийца gcc!gcc не убийца. :)
>clangdХорошая попытка, Леннарт!
Браво анонимус! Лишь бы ляпнуть, не понимая о чем идет речь. Дизайн компиляторов по большому счету практически не изменился за последние 30 лет. Использование демона позволит достичь в первую очередь кэширования. Например несколько .cpp файлов делают #include одних и тех же хедеров - парсинг и какую-то часть семантического анализа для соответствующего фрагмента AST можно выполнить всего один раз. Второе, поскольку клиент будет только отправлять задания для компиляции в демон, это позволит задействовать multi-threading без всяких костылей типа make -j n.Судя по количеству плюсов у поста выше, красноглазые хотят остаться в 70х с тулзами не ушедшими далеко первоначального юникса.
> Дизайн компиляторов по большому счету практически не изменился за последние 30 лет.+1
Нужно срочно что-нибудь изменить. Неважно что. Главное - не упасть в грязь лицом на фоне постоянных революций во всех остальных областях современного IT. По традиции, нужно что-нибудь срочно задействовать из области кеширования и многопоточной обработки, ну и, конечно, написать свой сетевой демон.
Я бы предложил ещё, чтобы исходники демона были закрытыми, и для компиляции приходилось обращаться к облакам гугла/эппла/амазона, ибо зачем расходовать своё процессорное время на компиляцию.
> Нужно срочно что-нибудь изменить. Неважно что.+1 Иначе как оно будет работать с Wayland, Gnome3 и творениями Поттеринга?
Ну и правильно. Каждому веку - свои технологии.
Какой смысл тащить иксы с sysvinit в двадцать первом веке? Те, кому они нужны - застыли во времени, потому что не хотят никаких перемен и прогресса. А значит, прекрасно проживут на том, что уже давно написано и работает на текущий момент.
И никакой "поддержки" этого старья. Если говорят, что оно "работает" - значит, никаких дополнительных усилий не нужно.
> Ну и правильно. Каждому веку - свои технологии.Давайте теперь от колёс откажемся, бо некруто - много тысяч лет назад изобретены. :-)
> Какой смысл тащить иксы с sysvinit в двадцать первом веке?
Вы понимаете, что есть определённые задачи? И вот эти задачи лучше всего сейчас делаются на Х.
> Давайте теперь от колёс откажемся, бо некруто - много тысяч лет назад
> изобретены. :-)От тех колес, которые изобретены много тысяч лет назад, отказались уже почти везде.
Вместо них используют "кривые комбайноподелия" со - страшно сказать - надувными шинами.> Вы понимаете, что есть определённые задачи? И вот эти задачи лучше всего сейчас делаются на Х.
На самом деле, писать комментарии о том, какая фигня wayland, можно и из-под wayland. Но эта простая истина пока очевидна не всем.
> От тех колес, которые изобретены много тысяч лет назад, отказались уже почти
> везде. Вместо них используют "кривые комбайноподелия" со - страшно сказать -
> надувными шинами.Которые изобретены, страшно сказать, когда паровые котлы позволили разогнаться выше 30 км/ч.
Есть принцип и есть детали реализации. Апеллировать к последним, когда бухтёж о первом -- довольно странно.
Ну и да, некоторые в гробу видали этот ваш безудержный прогресс -- примерно по мотивам http://tobotras.livejournal.com/250173.html ;-) Потому как опять "станки ради станков".
> Есть принцип и есть детали реализации. Апеллировать к последним, когда бухтёж о первом -- довольно странно.Разумеется. Принцип: рисовать на экране картинки. А все остальные подробности - это уже детали.
Да ничего не надо менять. Лучше вообще софт не писать, пользоваться тем что написано уже.
> Нужно срочно что-нибудь изменить. Неважно что. Главное - не упасть в грязь лицом на фоне постоянных революций во всех остальных областях современного IT. По традиции, нужно что-нибудь срочно задействовать из области кеширования и многопоточной обработки, ну и, конечно, написать свой сетевой демон.И да, по существу есть что сказать?
Похудей. И для начала требуй инноваторов высказать по существу.
А вы в курсе, что distcc существует уже довольно давно?
> А вы в курсе, что distcc существует уже довольно давно?Это обычная билд-система, кэширования на уровне структур данных компилятора она дать не может.
А вы компилили им KDE под .. что-нибудь?
> Использование демона позволит достичь в первую очередь кэширования. Например несколько
> .cpp файлов делают #include одних и тех же хедеров - парсинг
> и какую-то часть семантического анализа для соответствующего фрагмента AST можно выполнить
> всего один раз.Вы знаете, когда придумали механизм прекомпилированных заголовков? А вы знаете, что время компиляции С++ - это проблема устаревшего механизма #include и сложного синтаксиса С++? И в других языках проблемы с компиляцией нет, т.к. в них просто добавлен механизм создания модулей?
> Второе, поскольку клиент будет только отправлять задания для
> компиляции в демон, это позволит задействовать multi-threading без всяких костылей типа
> make -j n.А чем плох make -j n?
> Вы знаете, когда придумали механизм прекомпилированных заголовков? А вы знаете, что время компиляции С++ - это проблема устаревшего механизма #include и сложного синтаксиса С++? И в других языках проблемы с компиляцией нет, т.к. в них просто добавлен механизм создания модулей?Знаю насчет #include и других языков - тот же самый D систему модулей а не текстового включения хедеров. Насчет прекомпилированных заголовков - тоже знаю, не подумал честно говоря. Но это хак в любом случае. По теме - идея с компилятором в качестве демона проскакивала в коммьюнити языка D http://astoriaseminar.com/sessions.html
С++ страшно устарел, оброс костылями. Поэтому любое действие выливается в хак. И здесь нужно просто менять С++ на что-то более новое. Это, собственно, люди и делают.
> С++ страшно устарел, оброс костылями. Поэтому любое действие выливается в хак. И
> здесь нужно просто менять С++ на что-то более новое. Это, собственно,
> люди и делают.Что-то не видно, что делают.
В 1995 году и предложили альтернативу C++ — ООП язык программирования и среду исполнения Java. Вот только много ли желающих её использовать на десктопах? Java работает на ~3 миллиардах устройств в мире (согласно рекламному слогану на сплеше установщика Oracle Java SE), но на десктопах пользователей она — редкий зверь. Большая часть пользователей настольных компьютеров и ноутбуков обходятся в основном программами, написанными на устаревших C/C++, мало приспособленных для написания пользовательских приложений. Необходимость в языке C чётко определена: написание переносимого системного программного обесечения. Ниша C++ же после появления Java не вполне ясна. Он что, нужен для написания одной лишь JVM? Однако это не так — C++ используется для написания вполне обыденных приложений и библиотек, неспмотря на доказанное усложнение увеличение сроков разработки на C++ по сравнению с Java в 3-4 раза. Так в чём причина такого?
В 1999 предложили другую альтернативу - D. За 13 лет существования этого языка на нем написано чуть более нуля софтин. Можно сопоставить сколько было нацарапано на C++ за 13 лет существования, а это 1996 год. Ну, например, Qt - 92 г.
> В 1995 году и предложили альтернативу C++ — ООП язык программирования и
> среду исполнения Java.Это не альтернатива плюсам, а способ впарить оказывающееся слишком быстрым железо (с одной стороны) и обеспечить манагеров на софтовых проектах хоть какой-то уверенностью в том, что стремительно падающая средняя компетенция средней команды всё-таки сможет выдать продухт (с другой). То есть создание совсем другой ниши.
> Ниша C++ же после появления Java не вполне ясна.
Когда выбрали императивщину, сложность задачи предполагает необходимость в объектах, objc/glib/kobject не было/не поняли/не сделали, а работать оно должно завтра и шустро, а не послезавтра вразвалочку.
Не, я очень люблю Freemind, только таких вещей и впрямь мало.
>> В 1995 году и предложили альтернативу C++ — ООП язык программирования и
>> среду исполнения Java.
> Это не альтернатива плюсам, а способ впарить оказывающееся слишком быстрым железо (с одной стороныну конечно же. особенно учитывая что жаба получила наибольшее распространение на мобилах
>и обеспечить манагеров на софтовых проектах хоть какой-то уверенностью
> в том, что стремительно падающая средняя компетенция средней команды всё-таки сможет
> выдать продухт (с другой). То есть создание совсем другой ниши.а еще надо заставлять писать комментарии к коду на китайском. это потребует от команды еще большей траты компетенции на пустом месте, и принесет вам еще больше удовлетворения
> ну конечно же. особенно учитывая что жаба получила наибольшее распространение на мобилахНадеюсь, путая J2ME с Java -- Вы хотя бы Java с JavaScript не путаете...
> а еще надо заставлять писать комментарии к коду на китайском.
Позвольте ограничиться вторым китайским.
> В 1995 году и предложили альтернативу C++ — ООП язык программирования и среду исполнения Java. Вот только много ли желающих её использовать на десктопах?
>Так в чём причина такого?Причина в том что сказки про суперэффективность джит за 20 лет так и не заменили обычного такого компилятора, который для жабы так и не доделали. Вот собственно и все. Язык есть, а средства разработки нет.
>> В 1995 году и предложили альтернативу C++ — ООП язык программирования и среду исполнения Java. Вот только много ли желающих её использовать на десктопах?
>>Так в чём причина такого?
> Причина в том что сказки про суперэффективность джит за 20 лет так
> и не заменили обычного такого компилятора, который для жабы так и
> не доделали. Вот собственно и все. Язык есть, а средства разработки
> нет.действительно - был бы компилятор в натив - с++ был бы куда менее популярен
а вообще я очень жду светлого будущего LLVM - на компиляторы вида Java->llvm-bitcode->native
и не вижу никаких минусов у такого подхода, видь проще написать линковщик и оптимизатор один раз чем писать его для каждого языка
> А вы знаете, что время компиляции С++ - это проблема устаревшего механизма #include и сложного синтаксиса С++?Нет, это не так. С++ интерпретаторы существуют и не требуют никакой компиляции.
> Нет, это не так. С++ интерпретаторы существуют и не требуют никакой компиляции.У них есть определённые ограничения. :-)
> Судя по количеству плюсов у поста выше, красноглазые хотят остаться в 70х
> с тулзами не ушедшими далеко первоначального юникса.Да, я не хочу сервис который кладет проц в полку на полтора часа и вываливает 10 гиг дряни на системный диск. Я это уже видел в винде. Если тебе нравится как это работает - тебе туда.
> Да, я не хочу сервис который кладет проц в полку на полтора
> часа и вываливает 10 гиг дряни на системный диск. Я это
> уже видел в винде. Если тебе нравится как это работает -
> тебе туда.Маководам нужен собственный аналог.
Интересно когда тролли выучат что llvm не виртуальная машина?
Браво, Толстый! Главное побольше букав и баззвордов - пипл сам наполнит их смыслом :)
> Браво анонимус! Лишь бы ляпнуть, не понимая о чем идет речь. Дизайн
> компиляторов по большому счету практически не изменился за последние 30 лет.
> Использование демона позволит достичь в первую очередь кэширования. Например несколько
> .cpp файлов делают #include одних и тех же хедеров - парсинг
> и какую-то часть семантического анализа для соответствующего фрагмента AST можно выполнить
> всего один раз. Второе, поскольку клиент будет только отправлять задания для
> компиляции в демон, это позволит задействовать multi-threading без всяких костылей типа
> make -j n.
> Судя по количеству плюсов у поста выше, красноглазые хотят остаться в 70х
> с тулзами не ушедшими далеко первоначального юникса.1. Precompiled headers уже давно решает задачу повторяющихся включений.
2. make -j n это естественное использование multi-threading без накладных расходов. А гонять задания между клиентом и сервером это как раз (или как два) - костыль.Хорошая попытка, Леннарт!
а если клиент - на arm или дохленьком geode или via? А сервер вполне себе толковая молотилка?
> а если клиент - на arm или дохленьком geode или via? А сервер вполне себе толковая молотилка?Раз сказали, что гонять по сети данные - костыль, значит, костыль.
Это, кстати, не только к компиляции относится.
>> а если клиент - на arm или дохленьком geode или via? А сервер вполне себе толковая молотилка?
> Раз сказали, что гонять по сети данные - костыль, значит, костыль.
> Это, кстати, не только к компиляции относится.предлагаю тем кто так считает вбить заглушки в ethernet, выкинуть wifi карточки и 3g модемы. им opennet нужен локальный, чтоб не гонять по сети.
>>clangd
> Хорошая попытка, Леннарт!Ну разумеется. Если программа работает в фоновом режиме, и ее название оканчивается на d - значит, без Леннарта не обошлось.
Создается впечатление, что разработкой clang тайно руководит Поттеринг.
Так и не понял: что это и зачем это нужно?
Сомневаюсь что те кто задумал всё это понимают больше
> Сомневаюсь что те кто задумал всё это понимают большеА я даже могу сказать как это будет выглядеть когда подрастет - посмотрите на дотнет 4 и его сервис генерации нативных сборок. Вот только мне что-то не нравится когда нечто полтора часа занимает проц и вываливает на диск 10Гб барахла.
Вам не нравится, а инженерам Эппла - нравится. Впрочем, они любят много странных вещей, недоступных пониманию обычных людей. Мальчиков, например.
> Вам не нравится, а инженерам Эппла - нравится. Впрочем, они любят много
> странных вещей, недоступных пониманию обычных людей. Мальчиков, например.Вы будете смеятся, или плакать, но инженеры Эппла здесь не при чем. Проект родился и реализуется в недрах вашей любимой "Корпорации добра" Гугл
> полтора часаИ 294 дубля, ох.
>бизнес-логикойНайти бы того уюдка который первым додумался окрестить алгоритм "бизнес-логикой"...
Знал бы ты английский, просто бы понял что это и почему именно так названо.
Ну так объясните нам, невеждам.
> Знал бы ты английский, просто бы понял что это и почему именно
> так названо.Хотелось бы вы слушать мнение анонима
> Знал бы ты английский, просто бы понял что это и почему именно так названо.Умел бы ты троллить - набрасывал бы потоньше :)
> Знал бы ты английский, просто бы понялЗнаю, не понимаю, излагайте.
По наблюдениям -- термины "бузинес-логика" и "бузинес-данные" нередко бросаются в бой тогда, когда надо пыли в глаза пустить на ровном месте.
> По наблюдениям -- термины "бузинес-логика" и "бузинес-данные" нередко бросаются в бой тогда, когда надо пыли в глаза пустить на ровном месте.примерно так же как и термины - свободный, открытый, сообщество и т.п.
> примерно так же как и термины - свободный, открытый, сообщество и т.п.Что Вы, куда чаще. По крайней мере в айтишных контекстах.
PS: #106 удалено по причине глупой попытки раздуть флейм -- подумайте внимательно, что с чем сравниваете, и поймёте, к кому именно относится данная Вами характеристика.
А если копнуть глубже, то можно же будет веб-страницы писать на С/С++,
а в браузёр встроить транслятор байткода для своей ахритектуры.Чёй-то мне это напоминает. :-/
А напоминает это Java аплеты которые полностью и окончательно провалились.
> А напоминает это Java аплеты которые полностью и окончательно провалились.А XUL это не напоминает?
а я вот всё мечтаю когда же апач и ллвм интегрируются )))
интегрируются в systemd ))
Какой еще systemd? Только launchd, только яблоки!
Какие "яблоки"? Launchd переводится как "запускающий демон", а systemd переводится как "захватить весь мир".
Не знаю, как переводится, но суть-то одна.
У кого-то истерика...
> А если копнуть глубже, то можно же будет веб-страницы писать на С/С++,Так их уже можно писать на нем :). С серверной стороны - есть и сервера и шаблонизаторы. С клиенской - народ допер до трансляции C -> llvm bytecode -> JS. Вплоть до того что SDL-гамезы некоторые работают. Дум примерно так портанули.
>А если копнуть глубже, то можно же будет веб-страницы писать на С/С++,см. emscripten
>а в браузёр встроить транслятор байткода для своей ахритектуры.
уже не нужно
>Чёй-то мне это напоминает. :-/
оно уже давно не нужно
Мне одному кажется что это полный бред
> Мне одному кажется что это полный бредЭто не бред, это дотнет :)
> Это не бред, это дотнет :)Теперь яблочный!
>> Это не бред, это дотнет :)
> Теперь яблочный!И когда люди выучат, что llvm не виртуальная машина?
> И когда люди выучат, что llvm не виртуальная машина?Особенно последние 2 буквы аббревиатуры :)
Еще раз повторю LLVM не виртуальная машина в том понимании в каком она понимается в JVM, .NET, Python, Parrot, Lua...Что это читайте на http://llvm.org/
>> Мне одному кажется что это полный бред
> Это не бред, это дотнет :)Llvm не виртуальная машина
> Llvm не виртуальная машинаМсье не осилил расшифровать 4 буквы? Бывает...
>> Llvm не виртуальная машина
> Мсье не осилил расшифровать 4 буквы? Бывает...из тех кто считает, что сырники из сыра, а голубцы из голубей?
>> Llvm не виртуальная машина
> Мсье не осилил расшифровать 4 буквы? Бывает...Да, по ссылкам не ходим, в предмете не разбираемся.
Моя ничего нипанимат. Кто-нибудь проясните, что это такое и как работает. Спасибо.
> Моя ничего нипанимат. Кто-нибудь проясните, что это такое и как работает. Спасибо.это просто компилятор реализованный как сервис, у которого будет кеш того что он накомпилял, чтоб не компилять 10 раз одно и тоже
чисто теоретически люди усматривают аналогии с компиляторм в .нет который из байткода .нет делает натив при каждом запуске приложения на .нет
>В настоящее время проект пока находится на стадии планирования и активного обсуждения.Ну и зачем делать новость про то, что даже ещё не придумано?
Roslyn
http://en.wikipedia.org/wiki/Microsoft_Roslyn
В итоге, как и пятнадцать лет назад с JVM, многие пришли к выводу, что в системе нужна ещё одна машина (не просто прослойка), абстрагирующая/изолирующая операционную систему от приложений. :)
> В итоге, как и пятнадцать лет назад с JVM, многие пришли к
> выводу, что в системе нужна ещё одна машина (не просто прослойка),
> абстрагирующая/изолирующая операционную систему от приложений. :)По-моему, тут скорее с InteliSence полезнее сравнение, а не с JVM. Никто не собирается интерпретировать байткод, он не предназначен для этого.
Да-да.
Все пришли к выводу что в КАЖДОЙ системе должна быть ещё одна (а лучше штук 5-10, как с жабой).
> В итоге, как и пятнадцать лет назад с JVM, многие пришли к
> выводу, что в системе нужна ещё одна машина (не просто прослойка),
> абстрагирующая/изолирующая операционную систему от приложений. :)Вот только трансляция производится не каждый раз в рантайме, а один раз заранее.
Поэтому есть шанс, что получится не такое тормозное жручее глюкалово, как жаба и сишарп :)
>> В итоге, как и пятнадцать лет назад с JVM, многие пришли к
>> выводу, что в системе нужна ещё одна машина (не просто прослойка),
>> абстрагирующая/изолирующая операционную систему от приложений. :)
> Вот только трансляция производится не каждый раз в рантайме, а один раз заранее.
> Поэтому есть шанс, что получится не такое тормозное жручее глюкалово, как жаба
> и сишарп :)Технология JIT, которой уже несколько лет, умеет кэшировать раз оттранслированный байткод в оперативной памяти и/или в специальной области на диске (см. GAC).
Зачем эти костыли, если оттранслированный байткод можно сохранить в виде бинарников и запустить без лишней прослойки?
> Зачем эти костыли, если оттранслированный байткод можно сохранить в виде бинарников и запустить без лишней прослойки?Динамическая трансляция выгоднее там, где не нужно трансливать весь исполняемый код, а нужно оттранслировать только тот, который реально востребован и точно выполнится. Какие-то ветви кода могут никогда не сработать, не все функции потребуются для выполнения, поэтому незачем тратить ресурсы CPU и памяти на статическую трансляцию фактически мёртвого кода, который никогда не будет работать.
Ещё JIT учитывает характеристики процессора, загруженность и ресурсы оперативной памяти. И на основе этих показателей строит более оптимальный нативный код.
> Динамическая трансляция выгоднее там, где не нужно трансливать весь исполняемый код, а
> нужно оттранслировать только тот, который реально востребован и точно выполнится. Какие-то
> ветви кода могут никогда не сработать, не все функции потребуются для
> выполнения, поэтому незачем тратить ресурсы CPU и памяти на статическую трансляцию
> фактически мёртвого кода, который никогда не будет работать.Создать трудности (динамическая трансляция), чтобы героически частично преодолеть их, и гордиться тем, что уже не так сильно отстаешь от нативных бинарников. Забавно.
>> Динамическая трансляция выгоднее там, где не нужно трансливать весь исполняемый код, а
>> нужно оттранслировать только тот, который реально востребован и точно выполнится. Какие-то
>> ветви кода могут никогда не сработать, не все функции потребуются для
>> выполнения, поэтому незачем тратить ресурсы CPU и памяти на статическую трансляцию
>> фактически мёртвого кода, который никогда не будет работать.
> Создать трудности (динамическая трансляция), чтобы героически частично преодолеть их,
> и гордиться тем, что уже не так сильно отстаешь от нативных
> бинарников. Забавно.Забавно выглядеть пользователем горы кода, из которой используешь, дай бог, лишь 5%, а остальное никогда не понадобится. Ну или понадобится в качестве субстрата для вирусов и поля деятельности антивирусов. ;)
не понял, ты за жабу или против?
> не понял, ты за жабу или против?Судя по тому, как яростно он над ней издевается в этом треде - сейчас против.
Видимо, "среда заела".
А что такого в том, что один раз оттранслировал код и забыл о нем причем даже не на пользовательской машинке?
> А что такого в том, что один раз оттранслировал код и забыл
> о нем причем даже не на пользовательской машинке?Суть в том, что этот код УЖЕ устарел. :)
> Динамическая трансляция выгоднее там, ... Ещё JIT учитывает характеристики процессора, загруженность и ресурсы оперативной памяти. И на основе этих показателей строит более оптимальный нативный код.Вот уже больше 10 лет слушу что jit всех порвал. Вот посмотреть бы еще на это.
А может проще: не писать ничего под ОС не отвечающих стандартам POSIX и все тут? Эй горе-форточко-программеры, это я вам, по-ходу!...
Вот ещё! Это же технологии 70-х! А тут крутотень: динамическая трансляция, интерпретаторы, виртуальные машины, облака...
> ещё одна машина (не просто прослойка), абстрагирующая/изолирующая операционную системуБрр, если я хоть что-то понимаю в колбасных обрезках -- то речь аж о persistence разобранных потрохов софта, разложенных по рабочему верстаку. Для языков с дважды увеличенным временем разбора может оказаться полезно.
Интересное наблюдение: практически каждый новый проект, предполагающий создание домена, опеннетовские/лоровские/хабровские/etc комментаторы встречают шквалом негодования.
Видимо, уже выросло поколение Ubuntu, считающее, что программы, не имеющие намертво приколоченного гуя, не нужны.
s/домена/демона/
> демона
> программы, не имеющие намертво приколоченного гуяВидимо, уже выросло поколение Ubuntu, считающее, что программы, не имеющие намертво приколоченного гуя, называются демонами. А консоль - адом.
Демоны — это джинны, которых бог сотворил на шестой день, но не дал тела. Их иногда называют дАемонами, чтобы не вводить в заблуждение религиозноверующих, потому что не все джинны злые. Они как люди, только без телесной оболочки. Имеют гендерные признаки, в отличие от "бесполых" ангелов.
> Их иногда называют дАемонамидобрых или злых?
>> Их иногда называют дАемонами
> добрых или злых?Встречный вопрос: люди добрые или злые? Так и тут. ;)
> Видимо, уже выросло поколение Ubuntu, считающее, что программы, не имеющие намертво приколоченного гуя, называются демонами. А консоль - адом.Не надо грязных инсинуаций. Ubuntu - это дружественная к пользователю ОС, в ней не может быть консолей и прочих поттероподелий.
Когда Clang/LLVM станет компилятором по умолчанию, тогда и можно будет к нему прикручивать разнообразные демоны. Ну а пока это все, попытка бежать впереди телеги
Это просто общесистемный сервис автодополнения в редакторах vim, emacs, и т.п. для сложных компилируемых языков типа C++, этой идеи десяток лет (см GCC-XML), но пожалуй впервые есть все задатки для её успешной реализации. Какой NET, какой JVM, вы все о чём пишете?!Надеюсь у авторов всё получится и можно будет не покупать Xrefactory.
Такое объяснение кажется разумным, если бы не одно "но" - условная компиляция. Методики программирования, основанные на отказе от макросов в пользу шаблонов (по Страуструпу), приводят к потреблению компилятором по ~300 Мб на обработку исходного файла.
Если это умножить на количество потоков, то сколько будет потреблять памяти этот сервис?
Итого. Пользоваться компиляцией для автодополнения С не возможно, а для С++ расточительно.
Вообще-то по Страуструпу макросы должны заменяться на константы и функции. И не только по нему (есть достаточно литературы, демонстрирующей проблемы от макросов). Шаблоны нужны для совершенно иных задач. Проблема в том, что сейчас модно писать вместо класса шаблон, хотя в прикладных программах они очень редко нужны (я о пользовательских шаблонах).
Не хочу рамках обсуждения данной новости переходить на выяснения о "правильном коде".
Считаю, что на "общесистемный сервис автодополнения в редакторах vim, emacs, и т.п. для сложных компилируемых языков типа C++" заявленное средство не подходит.
При использовании с языком С, ему не справиться с условной компиляцией. При использовании с C++, к предыдущему пункту добавится непомерное потребление памяти и, возможно, процессора.Идея полезная, но компилятора это дело. Здесь нужен специальный анализатор текста программ с обратной связью с разработчиком (чтобы разработчик пояснял правильную интерпретацию двусмысленного кода). Также понадобятся система экспорта (переноса) накопленных анализатором знаний и возможность ручной коррекции вменяемым для сознания способом. И вот здесь-то поле не пахано.
> Такое объяснение кажется разумным, если бы не одно "но" - условная компиляция.
> Методики программирования, основанные на отказе от макросов в пользу шаблонов (по
> Страуструпу), приводят к потреблению компилятором по ~300 Мб на обработку исходного
> файла.
> Если это умножить на количество потоков, то сколько будет потреблять памяти этот
> сервис?
> Итого. Пользоваться компиляцией для автодополнения С не возможно, а для С++
> расточительно.И что, предлагаешь жить без этих бонусов? и ручками все делать на глаз?
По мне, так это бесполезный бонус, побуждающий "наваять с колена" груды неосознанного кода, дабы засветиться "крутым прогрАммером".
В реальных проектах, да, придется делать ручками, но не на глаз, а по-уму.
Хм.. А не замахнулись ли они на Java?..
Оракел нынче слаб. Надо добить, подкинуть bsdl компилятор от Эппле.
Мне кажется, ребята чота перестарались с универсальностью... точнее, с "многоклиентностью". Зачем нужен на машине общий сервис компилляции?? Основная-то проблема - это дать IDE _некоторые_ сервисы из общей системы компилляции. Для этого достаточно сделать модульный компилер.
Текст с описанием это случайно не заявка на какой-нибудь грант? А то много воды и нифига не понять.