Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>Насколько я понимаю, в некоторой степени будет готов AOT для webasm с выходом .Net 6.0. S>>На самом то деле он есть. И я тебе уже ссылку давал https://devblogs.microsoft.com/dotnet/conversation-about-ready-to-run/ S>>Называется Ready to run (R2R).
V>Это не то. V>R2R идёт вместе с исходным IL и JIT.
V>Для Blazor обещали железобетонный АОТ, безо-всякого IL+JIT в нагрузку, чтобы уменьшить размер образа. V>С этой же целью для него уже сделали триммер.
Основное премущество манагед кода это не только сборка мусора, но и рефлексия и динамическая компиляция. Очень тяжело от этого отказаться особенно в больших проектах.
Поддержка плагинов итд. Да сейчас с SG можно часть динамической компилиции перенести на компиляцию в Il код. Но все равно куча кода использует и Деревья выражений и Il генератор и Microsoft.CodeAnalysis.CSharp.Scripting
Вместо того, чтобы запускать AOT-компиляцию каждого приложения на этапе установки, он запускает приложение под управлением виртуальной машины, используя JIT-компилятор (почти так же, как в Android < 5.0), но следит за тем, какие участки кода приложения выполняются чаще всего. Затем эта информация используется для AOT-компиляции данных участков кода. Последняя операция выполняется только во время бездействия смартфона, находящегося на зарядке.
Говоря простыми словами, теперь два совершенно разных подхода работают сообща, что дает свои плюсы:
более эффективная компиляция — при запуске приложения в реальном времени компилятор имеет возможность узнать о его работе гораздо больше, чем выполняя статический анализ, и, как следствие, применяются более подходящие методы оптимизации для каждой ситуации;
сохранение оперативной и постоянной памяти — байт-код компактнее машинного кода, а если выполнять AOT-компиляцию только отдельных участков приложения и не выполнять компиляцию приложений, которыми юзер не пользуется, можно существенно сэкономить пространство NAND-памяти;
резкое увеличение скорости установки и первой загрузки после обновления системы — нет AOT-компиляции, нет задержки.
Кстати в комментариях
В статье не говорится, почему вернулись к схеме Interpreter+JIT+AOT. Основная проблема с AOT была, что при любом изменении системы приходилось перекомпилировать все библиотеки и приложения, что могло занимать много времени. При переходе на Interpreter+JIT+AOT одним из критериев был не ухудшение времени запуска. После перехода выяснилось, что не весь код приложений нужно компилировать.
R2R как раз и решает эту проблему.
Ключевой характеристикой формата файла является устойчивость к версиям. Это означает, что обновление зависимости совместимым способом не приведет к аннулированию скомпилированного кода AOT. Это позволяет ему вести себя аналогично формату файла IL (ECMA-335) при составлении и обслуживании приложений, который является очень гибким и простым для понимания. Предыдущие версии .Форматы файлов NET AOT, такие как формат файла, используемый NGen в .NET Framework, не обладали этим свойством.
Существует также преимущество по сравнению с наиболее оптимальным скомпилированным кодом на C++ – возможность улучшать сгенерированный код во время выполнения с помощью JIT, например, путем оптимизации для конкретной архитектуры процессора или встроенного кода из других сборок, которые не были известны во время компиляции.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>>Кстати нет наследования структур. Сейчас с source generator упрощается расширение классов. S>Это палка о двух концах.
Это палка с одним концом. Наследование и из классов надо выкидывать, а не добавлять его огрызок еще и в структуры.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[61]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>>Кстати нет наследования структур. Сейчас с source generator упрощается расширение классов. S>>Это палка о двух концах.
НС>Это палка с одним концом. Наследование и из классов надо выкидывать, а не добавлять его огрызок еще и в структуры.
А как же ты будешь имплементить связь "A is B" ?
Re[61]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
НС>>Это палка с одним концом. Наследование и из классов надо выкидывать, а не добавлять его огрызок еще и в структуры. I>А как же ты будешь имплементить связь "A is B" ?
Интерфейсами. Если вообще буду, так как использование is для логики — та еще кака. ADT для этих целей обычно лучше и не требуют полиморфизма.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[61]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>А как же ты будешь имплементить связь "A is B" ?
НС>Интерфейсами. Если вообще буду, так как использование is для логики — та еще кака.
Интерфейсы это слабенько. ADT — абстрактные типы данных? Это метод проектирования, в яп он поддерживается только в каком нибудь Эйфеле.
Т.е. если взять интерфейсы, то всё это нужно делать вручную. Может трейты, может дефолтные реализации, но все равно это всё вручную.
is это просто связь, и это вообще говоря нормальный кейс.
Обычно проблемы возникают не с самой связью is, а с реализацией композиции через наследование, или расширение модуля через наследование, или управление зависимостями через наследование. То есть, вместо is или subtype, начинается абы что с известным результатом.
Более того, с наследованием интерфейсов ровно те же проблемы. Например, некто наследует иммутабельный интерфейс, и вводит в него мутабельный метод. или так — понареализовывает в классе целую кучу интерфейсов — мутебальных и иммутабельных. Вроде бы наследование нет, но проблемы ровно те же, как будто оно есть Отсюда ясно, что дело не в наследовании.
> ADT для этих целей обычно лучше и не требуют полиморфизма.
Не "полиморфизм для АДТ", а наоборот — "АДТ для полиморфизма". Это правила, следование которым позволяет делать полиморфный код безопасным. В отдельный момент времени у тебя может быть куча реализаций, у которых одна и та же спецификация АДТ, с минимальными отличиями в реализации.
Вот без такой спецификации полиморфизм это абы что, т.к. нет никаких гарантий.
Например такого — коллекции. Без АДТ ты не имеешь права полиморфно вызывать методы Add двух разных классов.
extends у классов стоило бы сузить до subtype + ввести предусловия, постусловия, инварианты и дефолтные реализации. В этом случае наследуешь сразу всё, а компилер поможет тебе обеспечить сохранение контрактов.
Re[64]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
I>Интерфейсы это слабенько.
Для полиморфизма — более чем достаточно.
I> ADT — абстрактные типы данных?
Алгебраические.
I>Обычно проблемы возникают не с самой связью is, а с реализацией композиции через наследование
Именно.
I>Более того, с наследованием интерфейсов ровно те же проблемы.
Проблем с высокой зависимостью наследника от предка там нет.
I> или так — понареализовывает в классе целую кучу интерфейсов — мутебальных и иммутабельных. Вроде бы наследование нет, но проблемы ровно те же
Какие?
I>, как будто оно есть Отсюда ясно, что дело не в наследовании.
Не знаю что тебе ясно, но логика "раз мы не можем отловить всех воров, то вообще их ловить не будем" так себе. Есть вполне кокретная проблема очень сильной связи между предком и потомком, и ее интерфейсы устраняют. А проблемы иерархического полиморфизма в ОО в целом, разумеется, можно устранить только отказом от такого полиморфизма.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[50]: MS забило на дотнет. Питону - да, сишарпу - нет?
V>Заодно тело метода станет маленьким, вероятность инлайна вырастет.
Тут в чём-то другом дело. V>Прерывания от сетевой карты всё-равно асинхронные, исполняются с т.з. потоков в другом потоке, и в момент обнаружения и забора новых пакетов данных при очередном вызове со стороны юзверя унутре без синхронизации никак. Хотя, синхронизация может быть выполнена на lock-free алгоритмах, но знать бы достоверно...
А у них сорцы не открыты?
V>В общем, при разработке требуется принимать актуальные решения, а не такие, которые потенциально могут сработать лет эдак через 20.
Ну так именно поэтому чудеса АОТ нас только ждут, а динамически порождать эффективный код я умею уже сейчас V>>>Вручную писаный сериализатор будет оптимизирован и в АОТ, S>>Каким образом? На основании чего АОТ будет выполнять спекулятивный инлайнинг? V>Вручную писанные сериализаторы обычно оперируют конкретными типами, в этом случае для AOT раздолье.
Я напомню, что в рассмотренном примере у нас два вручную писанных сериализатора, которые вызываются через IMySerializer _serializer. V>>>Например, "выпрямлять" в памяти банальный List<T>. S>>Что значит "выпрямлять"? Он же уже и так прямой. V>Он дважды косвенный.
Чтобы он стал единожды косвенным, его нужно превратить в структуру. Тот самый escape analysis, который делается в C2 или GraalVM.
Ну, и конечно ситуация должна быть подходящей — нужно ухитриться написать такой метод, где конструируется List<T> и никуда больше не передаётся. Ну, точнее, из транзитивного замыкания этого метода и всех проинлайненных в него методов V>Тебя интересует нынешнее положение дел или будущее гипотетическое?
Да, будущее гипотетическое. V>В гипотетическом спекулятивном оптимизаторе по фактически поданным типам он сможет убрать виртуальные вызовы, т.е. многое заинлайнить, в т.ч. исключить лишние выделения из кучи GC, но где-то на входе должна быть проверка, что поданные типы (рекурсивно по всем меберам, куда дотянулась спекулятивная оптимизация) — такие же.
Откуда этот гипотетический спекулятивный оптимизатор получит инфу о том, какой из типов инлайнить? V>И вот эта проверка — "природный" ограничитель возможности технологии спекулятивной оптимизации.
Эта проверка — один if, который к тому же прекрасно предсказывается процессорным предсказателем и большую часть времени вклада во время исполнения не даёт. V>Схема рекордсета каждый раз создаётся с 0-ля, это будут другие экземпляры схемы с другими экземплярами абстрактных дескрипторов полей.
Да при чём тут экземпляры-то? Речь о типах. У нас будет заинлайнен код конкретного MySqlDataset.GetInt32(2). В этом коде у нас ветвление типа if(_columns[2].StoreType == Int32), которое, как правило, оказывается верным. Это заставляет джит сделать эту ветку основной, а процессор — предсказывать отсутствие jmp. S>>А АОТ так и оставит косвенный вызов через VMT. V>Спекулятивный код с этой задачей тоже не справится. V>Слишком много вложенных друг в друга абстракций.
Пока не вижу никаких особых сложностей. Сам алгоритм достаточно прямолинейный. V>Первый VMT — это абстракция от провайдера БД. V>Прошли. V>Далее у нас массив абстрактных дескрипторов полей, вторая VMT.
Почему абстрактных-то? Дескрипторы все однотипные. Там работает не спекулятивный инлайнинг, а тупой анализ частоты переходов. Его делает даже процессор без помощи JIT. V>Полей десяток-другой, допустим. V>Для каждого поля надо убедиться, что тип дескриптора тот же. V>А оно точно будет эффективнее предложенной мною схемы вызова ф-ии-маппера по указателю на метод? V>Я думаю, что проверить можно уже прямо сейчас, т.е. написать гипотетический код, который сгенерировал бы спекулятивный оптимизатор со всеми предпроверками условий и сравнить с предложенной мною схемой.
Да, можно. V>Мы тут однажды серьезно бодались с коллегой '.' (ник такой), он приводил примеры — они примитивнейшие все.
Да, надо отложить эту дискуссию — времени проверять нету, а без проверок это всё кальянные разговоры. V>В данном случае — сколько читаемых полей в рекордсете. V>Пусть даже все поля одного типа, но дескриптор для каждого поля — это уникальный экземпляр наследника абстрактного класса.
Да, верно. В самом внутреннем цикле не должно быть слишком много guard-ов, иначе процессор перестанет предсказывать переходы. V>А в моей схеме на указателях на мемберы все дескрипторы полей любых типов имеют один и тот же тип (или как миниму не абстрактны). V>А для полей одинакового типа и вовсе будет один и тот же экземпляр дескриптора.
Применимость этой схемы не зависит от выбора между AOT и JIT. V>Ну да, просто минус одна косвенность. V>Если сделать дескрипторы структурами (всё-равно в массивах хранятся) — минус две косвенности. V>Если сделать часть массива inplace (как в std::string) — будет минус три косвенности.
Да, надо написать и замерить. V>После качественного AOT стираются типы. V>Я не представляю, как у нас должна будет работать спекулятивная оптимизация в этом случае. V>Это надо держать два варианта кода в бинарнике: скомпиллированный через АОТ и исходный IL.
Конечно. IL занимает копейки на фоне бинаря. V>При желании можно будет вернуться и продолжить или создать тему-продолжение. V>Обсуждение то было достаточно забавным, на мой взгляд. V>Хорошо раскрыло уровень рассмотрения происходящего в БД с т.з. ведущих базоводов этого сайта, для меня было откровением, что настолько с высоты птичьего полёта на это смотрят. Можно и вернуться. V>Но основное, что обсуждалось — это то, что находится м/у данными и "публичной" функциональностью, т.е. в какой вид компиллируются, собсно, запросы и как исполняются на уровне железа — тут у тебя чёрная дыра. V>"База вообще" и "база, к которой обращается одно специально разработанное приложение" — две большие разницы. V>Во втором случае кол-во join-ов может быть до смешного малым, например, в случае кеширования справочных данных приложением.
Это ваша типичная ошибка — вы съезжаете на то, что "вот я же могу взять вот такие таблицы регистров", забывая про то, что СУБД берутся обслуживать более-менее произвольные структуры.
И то, что в теории вы можете хранить одну таблицу на 10 записей и не иметь в ней индексов, не означает, что для любой реальной БД применимы те же алгоритмы, что и в вашем вырожденном случае. V>И рассуждения как раз шли в направлении того, сколько реальных вариантов запросов (за минусом параметров к ним) породит конкретное приложение. V>Сколько потенциальных планов породит такой запрос, с учётом отброшенных заведомо неудачных не в рантайме, а еще на этапе компиляции.
Да. V>Сколько запросов будут иметь общие части, например, в одном запросе where Field1=A, а в другом where Field1=A AND Field2=B. V>Например, в обоих случаях может получиться так, что лучшим вариантом будет сканить по Field1, бо по этому полю стоит более выгодный индекс (больше уникальных значений в индексе и распределение строк по индексу более равномерное). Это пример той самой "склейки" генерируемой функциональности, где план второго запроса целиком включает план первого — вот что имелось ввиду под "экономией", т.е. имелось ввиду повторное использование.
Это, конечно же, понятно. Но вы не понимаете простой штуки — план работает не так, что мы сначала "сканим по Field1", а потом "фильтруем по Field2".
Эти инструкции перемешаны во внутреннем цикле сканирования. Поэтому бинарь для этих двух запросов будет совершенно разный. V>Для произвольного анализа данных существует OLAP — используйте инструменты по назначению, как грится.
Нет, это называется "я не сумел написать эффективную СУБД, поэтому пожалуйста возьмите другой инструмент". V>Происходящее сейчас в индустрии очевидно — инструмент слишком общего назначения используют для слишком узких сценариев. V>В складе-бухгалтерии получается прилично.
Ну вот странно же получается — прикладная программа "понимает", что можно кэшировать, а СУБД типа тупая, и не понимает.
Несмотря на то, что у неё кэш получается локальным и гарантированно консистентным, а прикладная программа держит потенциально устаревшую копию без возможности обнаружить изменения, выполенные с других клиентов. S>>Ну, так это известный трюк, связанный не столько с хотспотом, сколько с отсутствием value-типов. А иногда — и с тем, что мы хотим получить автовекторизацию, которая не работает в случае int a; int b; int c. V>В плюсах работает, значит и в джите потенциально может работать.
Неа, не работает. V>И для векторизации надо хранить в одном массиве подряд, а не в 3-х.
Наоборот. Стандартный ответ на вопрос "как мне векторизовать операции над комплексными числами" — "храните отдельно double[] Re, double[] Im". V>Разве что запускаются неприёмлимо долго. V>И тормозят первые секунды.
Я не знаю, что там такое делает жава, что её VM стартует дольше, чем дотнетная программа (без АОТ) завершается. V>А мне в сообществе дотнета не нравился все годы пропагандируемый отказ от борьбы за перформанс как таковой.
Там не было никакого пропагандируемого отказа. Было вечное перекладывание ответственности, типа "это пусть делает джит" — "нет, пусть это улучшает компилятор". V>В джаве, не смотря на то, что в ней аналогичный перформанс достигается несравнимо большей трудоёмкостью, такого странного менталитета нет, народ к этим вещам относится спокойней.
В джаве сосуществует множество "школ" и направлений. Кто-то пилит приложения под JVM на котлине; кто-то пилит hi-performance c пулами байтовых буферов и реинтерпретацией; кто-то пилит кровавый энтерпрайз с менталитетом "у нас business flow, мы берём метод обработки одного шага, стартуем джава-машину, выполняем его, сохраняем результат в базу и глушим машину". V>Плохо, что так много времени было упущено, конечно...
Ну, я себя чувствую как футбольный болельщик. Типа я посмотрел матч. Что за полтора часа произошло с точки зрения игрока? "Я делал то-то и то-то; это кульминация моих изнурительных тренировок. Что-то я сделал хорошо, а где-то допустил ошибки. Что-то у меня получилось, что-то не получилось". Игрок внёс вклад как в позицию команды в турнирном рейтинге, так и в развитие команды в целом и себя как профессионала.
Что произошло с точки зрения тренера? Какие-то тактические наработки и схемы тренировок сработали, какие-то нет. Тренер получил информацию о наработках другой команды, внёс вклад как в позицию команды в турнирном рейтинге, так и в развитие команды в целом и себя как профессионала.
Что произошло с точки зрения болельщика? Выпит ящик пива, сорван голос, болят колени и ладони. Всё. Даже если это прямо тру фанат, который усовершенствовал свои знания достоинств и недостатков отдельных команд — это никак не поможет ни развитию команды, ни футбола как игры.
Так и мы — в основном пьём пиво, и спорим о том, кто как сыграл вчера и как сыграет завтра. Мы инвестируем свои усилия в пивные животы и сорванные глотки.
По крайней мере, пока мы не контрибутим в public domain.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[63]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
V>>>Кстате, и тут АОТ может помочь, бо если две структуры имеют одинаковый лейаут и функциональность, то и сгенерённый код под них мог бы бы одинаковый. S>>Так-то и джит мог бы "увидеть", что две структуры имеют одинаковый лэйаут, то можно сравнить MSIL методов и для совпадающих методов генерировать одну копию кода.
V>Да некогда джиту сравнивать IL всех методов.
Это однопроходному джиту некогда. А в подходе хотспота у него есть всё время мира.
V>Это на что ты отвечаешь в подветке: V>http://www.rsdn.org/forum/flame.comp/8086688.1
А. Не очень понял смысл вот этого вот Union, отдельно почитаю.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[61]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это палка с одним концом. Наследование и из классов надо выкидывать, а не добавлять его огрызок еще и в структуры.
Ну, тогда вообще написать сколь-нибудь полезный код станет невозможным.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[62]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
НС>>Это палка с одним концом. Наследование и из классов надо выкидывать, а не добавлять его огрызок еще и в структуры. S>Ну, тогда вообще написать сколь-нибудь полезный код станет невозможным.
Без наследования то? В текущем проекте, к примеру, его кот наплакал, и в большинстве случаев оно навязано внешним кодом. И ничего, живем как то.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[7]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
R>>А где можно запустить JavaScript, но получиться C? S>В браузере из-под пользователя без админских привилегий. К.О.
Эээ что? ) Как раз C/C++ был первым языком, компилируемым в WebAssembly, так что твой K.O. устарел лет так на 5 уже...
P.S. Более того, прямо в этой ветке форума я с тобой говорил о преимуществах перехода распространения ПО с множества нативных дистрибутивов на единый "дистрибутив" в браузере. И после этого ты тут пишешь такое? Может вас там две отдельные личности за этим эккаунтом или даже две личности в одной голове? )))
Re[50]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>>>Псевдокод давался. S>>Да, мной.
V>При желании можно будет вернуться и продолжить или создать тему-продолжение.
Да, можно продолжить прямо отсюда
.
Я написал код, написал вопрос по нему. Можете стартовать новую ветку прямо с объяснения того, каким волшебным образом статически скомпилированный бинарный код сможет повторно использовать фрагменты одного плана в другом.
Или можем обсудить код планов для вашего свежего примера, с "where Field1=A" и "where Field1=A AND Field2=B".
Для первого будет сгенерирован
IEnumerable<...> Plan1(fieldAType a)
{
foreach(var entry in DB.IndexA.RangeScan(a,a))
{
var r = Db.TableX.BookmarkLookup(entry.rowId));
yield return new ...(entry.a, r.field1, r.field2, ...);
}
}
Причём и сигнатура (то, что вместо ...), и то, что там внутри yield, будут определяться вышестояшими узлами физического плана.
Например, если нужная далее проекция полей случайно содержится в самом индексе по полю А, то строки с BookmarkLookup вообще не будет.
Для второго будет сгенерирован
IEnumerable<...> Plan2(fieldAType a, fieldBType b)
{
foreach(var entry in DB.IndexA.RangeScan(a,a))
{
var r = Db.TableX.BookmarkLookup(entry.rowId));
if(r.FieldB == b)yield return new ...(entry.a, r.field1, r.field2, ...);
}
}
То, что в теле Plan2 где-то будут байты, похожие на байты из Plan1, не даёт нам возможности что-либо "склеить". В рантайме мы не можем собирать план из "блоков".
Мы могли бы попытаться сделать как-то так:
IEnumerable<...> Plan2(fieldAType a, fieldBType b)
{
foreach(var resultLine in Plan1(a))
{
if(resultLine.FieldB == b)[/b]
yield return new ...(resultLine);
}
}
— типа, "позвали" Plan1 прямо в скомпилированном виде, и поехали как-то обрабатывать его результат. Ну так и перформанс этого плана будет не намного лучше того, что выдаёт SQL сейчас, в режиме интерпретации. Потому что — опять косвенные вызовы на каждой итерации.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, alex_public, Вы писали:
_>P.S. Более того, прямо в этой ветке форума я с тобой говорил о преимуществах перехода распространения ПО с множества нативных дистрибутивов на единый "дистрибутив" в браузере. И после этого ты тут пишешь такое? Может вас там две отдельные личности за этим эккаунтом или даже две личности в одной голове? )))
Это я просто ещё не до конца осознал все последствия wasm
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[62]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
НС>>Это палка с одним концом. Наследование и из классов надо выкидывать, а не добавлять его огрызок еще и в структуры. S>Ну, тогда вообще написать сколь-нибудь полезный код станет невозможным.
Например в Rust'е нет наследования в классическом его понимание. И при этом полезный код отлично пишется.
Наследование применяют для двух целей: полиморфизма и переиспользования кода. Для обеих этих целей в Rust'е есть отдельные инструменты.
Re[18]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Ну конкретно AOT в моно не плох — там за конечную оптимизацию, если я правильно понимаю, LVVM отвечает.
В виндах MS прикрутила оптимизатор от своего С++ компилятора-линкёра для LLVM как опцию.
Думается, не спроста.
ЕА>Там печаль в другом. Некоторые вещи из дотнетовской VM плохо на wasm ложатся и из-за необходимости их эмулировать тормоза возникают. ЕА>Сейчас блазорный код, даже с AOT, работает медленней jscript-го. Обычно в разы.
Что странно...
Re[62]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
V>>А при боксировании поданной по ссылке структуры боксировать только поданную "часть" структуры. I>А если первый филд структуры это её код или размер, то всё становится очень весело
Если такую структуру, действительно, придётся боксировать, то даже без наследования структур потребуются дополнительные телодвижения.
Например, объявить поле flexible-массива максимально-возможного для этой структуры размера.
В любом случае, в тех АПИ, где обслуживаются структуры неизвестного размера (в т.ч. простые массивы, куда АПИ должно что-то скопировать из своего нутра) — в случае недостаточного размера буфера АПИ не производит копирования или копирует только часть данных, но одним из возвращаемых параметров обязательно является требуемый размер подаваемого буфера или требуемое кол-во элементов в подаваемом массиве.
