Сейчас таких планов нет. Можно завести issue в нашем репозитории, в нем померять интерес сообщества.
В целом проблема в том, что Perforator использует команду Compiler.perfmap, в JDK 11 ее еще нет, нужны альтернативные источники данных. При этом текущее решение (на основе perf-map) мы рассматриваем как промежуточное. Удалять его мы не планируем (потому что оно еще и для других языков какой-то уровень поддержки создает), но поддержку Java хотим делать другую, более умную. И добавление старых версий JDK в текущий механизм не продвинет нас к этому новому миру.
Теоретически, можно попробовать на старую JVM https://github.com/jvm-profiling-tools/perf-map-agent, и на получившуюся конструкцию натравить Perforator без указания java=true (т.е. он не будет самостоятельно посылать команду Compiler.perfmap, а вместо этого будет ориентироваться на сгенерированную агентом мапу). Но это, конечно, довольно неудобное решение(
Тем не менее, если я правильно понимаю происходящее (а именно, что Spark application это набор обычных системных процессов, которые исполняются на нодах кластера спарка), то попробовать можно - опциями spark.executorEnv и spark.executor.extraJavaOptions можно выставить требуемые настройки JVM.
Еще важно, какая формируется иерархия контейнеров (насколько я понимаю, это зависит от режима развертывания самого Spark). Если приложения не запускаются в контейнерах с одинакаковыми для всех нод именами, то агрегированные флеймграфы не будут работать должным образом (но единичные профили это не затронет). Из трех предлагаемых систем оркестрации специальную нормализацию Perforator умеет делать только для Kubernetes (mesos и YARN, опять же, мы не пробовали). Думаю, проще всего это проверить на опыте - посмотреть, нормально ли агрегируются разные профили одного приложения, собранные с разных нод и запусков, или нет.
Так что в целом принципиальных препятствий не вижу, но есть риск упереться в нереализованные фичи. Думаю, можно попытаться и посмотреь на результат. Если возникнут проблемы - будем рады фидбеку, подумаем что можно улучшить.
Сама по себе библиотека проблемой не является: все лишние функции будут выкинуты при LTO. Да и содержимое libcore в основном - это либо широко используемые фичи, либо компиляторная магия. К тому же непонятно, зачем без веской причины отказываться от стандартной библиотеки языка, а потом руками ее куски переимплементировать: https://github.com/torvalds/linux/blob/e8f71f89236ef82d449991bfbc237e3cb6ea584f/include/linux/string.h#L22
Более того, стандартная библиотека Rust монолитна
Все эти претензии относятся к std - платформозависимой части стандартной библиотеки. Никто не предлагает тащить ее в ядро (хотя бы потому, что она не умеет работать в kernel mode), поэтому эти претензии нерелевантны.
Только это не "счетчик ссылок", а флаг. В коде на C точно такой же флаг (возможно, засунутый внутрь объекта) точно также придется поддерживать (чтобы понять в конце функции, надо ли делать очистку или нет). Так что нарушений принципа zero cost пока не видно.
Давно пора сделать стандарт для низкоуровневого байткода, описывающего отрисовку.
Такой байткод в сочетании с WebAssembly позволит писать быстрые веб-приложения на чем-угодно
Теорема Райса говорит, что существуют программы, для которых нельзя доказать интересующее вас свойство. Например, если мы попытаемся доказать что программа на питоне никогда не кидается TypeError, то:
Для каких-то программ мы сможем это сделать.
Но найдутся такие, для которых доказать это мы не сможем.
Сейчас вы уводите разговор в совершенно иную плоскость: мы все-таки про UB говорим а не про стандартизацию.
И да, reference — это то, что (в идеале) должно дорасти до стандарта.
По аналогии, на любом компиляторе c++ который вы сможете найти, ваш пример будет работать аналогично.
И где в документации clang, g++ и msvc написано, что они гарантируют, что чтение неактивного поля это не всегда UB?
Это используется в стандартной библиотеке.
Например тут и во многих других аналогичных местах делается что-то вроде transmute с помощью union.
https://doc.rust-lang.org/nightly/reference/items/unions.html#reading-and-writing-union-fields: Unions have no notion of an "active field". Instead, every union access just interprets the storage at the type of the field used for the access. Reading a union field reads the bits of the union at the field's type. (Конечно, если чтение породит невалидное значение, то поведение не определено).
Код с UB просто не является программой на расте.
Почему? Rustc не отклоняет ее, значит это корректная прогорамма (несмотря на то что ее поведение во всех случаях не определено).
Многообразие синтаксических форм для инициализации
std::vector foo (s.begin(), s.end());
vs
std::vector foo {s.begin(), s.end()};
Более того, НЯП в одной строке создается вектор интов на основе двух итераторов, а в другой вектор итераторов.
Сейчас таких планов нет. Можно завести issue в нашем репозитории, в нем померять интерес сообщества.
В целом проблема в том, что Perforator использует команду
Compiler.perfmap, в JDK 11 ее еще нет, нужны альтернативные источники данных.При этом текущее решение (на основе perf-map) мы рассматриваем как промежуточное. Удалять его мы не планируем (потому что оно еще и для других языков какой-то уровень поддержки создает), но поддержку Java хотим делать другую, более умную. И добавление старых версий JDK в текущий механизм не продвинет нас к этому новому миру.
Теоретически, можно попробовать на старую JVM https://github.com/jvm-profiling-tools/perf-map-agent, и на получившуюся конструкцию натравить Perforator без указания
java=true(т.е. он не будет самостоятельно посылать командуCompiler.perfmap, а вместо этого будет ориентироваться на сгенерированную агентом мапу). Но это, конечно, довольно неудобное решение(Мы не пробовали такую конфигурацию.
Тем не менее, если я правильно понимаю происходящее (а именно, что Spark application это набор обычных системных процессов, которые исполняются на нодах кластера спарка), то попробовать можно - опциями spark.executorEnv и spark.executor.extraJavaOptions можно выставить требуемые настройки JVM.
Еще важно, какая формируется иерархия контейнеров (насколько я понимаю, это зависит от режима развертывания самого Spark). Если приложения не запускаются в контейнерах с одинакаковыми для всех нод именами, то агрегированные флеймграфы не будут работать должным образом (но единичные профили это не затронет). Из трех предлагаемых систем оркестрации специальную нормализацию Perforator умеет делать только для Kubernetes (mesos и YARN, опять же, мы не пробовали). Думаю, проще всего это проверить на опыте - посмотреть, нормально ли агрегируются разные профили одного приложения, собранные с разных нод и запусков, или нет.
Так что в целом принципиальных препятствий не вижу, но есть риск упереться в нереализованные фичи. Думаю, можно попытаться и посмотреь на результат. Если возникнут проблемы - будем рады фидбеку, подумаем что можно улучшить.
Сама по себе библиотека проблемой не является: все лишние функции будут выкинуты при LTO. Да и содержимое libcore в основном - это либо широко используемые фичи, либо компиляторная магия. К тому же непонятно, зачем без веской причины отказываться от стандартной библиотеки языка, а потом руками ее куски переимплементировать: https://github.com/torvalds/linux/blob/e8f71f89236ef82d449991bfbc237e3cb6ea584f/include/linux/string.h#L22
Все эти претензии относятся к std - платформозависимой части стандартной библиотеки. Никто не предлагает тащить ее в ядро (хотя бы потому, что она не умеет работать в kernel mode), поэтому эти претензии нерелевантны.
Только это не "счетчик ссылок", а флаг. В коде на C точно такой же флаг (возможно, засунутый внутрь объекта) точно также придется поддерживать (чтобы понять в конце функции, надо ли делать очистку или нет). Так что нарушений принципа zero cost пока не видно.
Давно пора сделать стандарт для низкоуровневого байткода, описывающего отрисовку.
Такой байткод в сочетании с WebAssembly позволит писать быстрые веб-приложения на чем-угодно
Теорема Райса говорит, что существуют программы, для которых нельзя доказать интересующее вас свойство. Например, если мы попытаемся доказать что программа на питоне никогда не кидается TypeError, то:
Для каких-то программ мы сможем это сделать.
Но найдутся такие, для которых доказать это мы не сможем.
Хабрапарсер съел асимптотику.
Попытка номер 2: O(2^n * N^2), где ^ это возведение в степень.
Она разрешима за конечное время. Например есть довольно простой алгоритм время работы которого O((2*N) (N2)), где это возведение в степень
Но это же пространство имен вроде как.
Чем тогда является это:
?
А где в этом C++ коде используются области видимости?
Можете.
std::cell::Cell, смотрите функции get() и set() ЕМНИП
Силами сообщества уже делается, но кажется довольно сырое: https://github.com/shiftkey/desktop
Сейчас вы уводите разговор в совершенно иную плоскость: мы все-таки про UB говорим а не про стандартизацию.
И да, reference — это то, что (в идеале) должно дорасти до стандарта.
И где в документации clang, g++ и msvc написано, что они гарантируют, что чтение неактивного поля это не всегда UB?
Например тут и во многих других аналогичных местах делается что-то вроде transmute с помощью union.
Кажется, такого очень мало. Мне сходу в голову только одно приходит:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=5cadcaefcd6a2ca8f6d631b1f3a4ada2
Например корректность ссылок и невозможность выхода за границы массива.
Ну, проблема в том что вроде как в течение 3-4 месяцев AST borrowck должны полностью выпилить, и какой-то код все-таки сломается.
Ну например:
auto x = baz();
vs
decltype(auto) x = baz();
Многообразие синтаксических форм для инициализации
std::vector foo (s.begin(), s.end());
vs
std::vector foo {s.begin(), s.end()};
Более того, НЯП в одной строке создается вектор интов на основе двух итераторов, а в другой вектор итераторов.
Но далеко не убегает, потому что ноги прострелены.
Можно зашифровать им сервера террористов.