Горе .NET

[ax_mct]

Горе .NET в изначальном презрении к интерпретационным языкам и восхвалении компиляции как таковой.

Интерпретируемые языки программирования

Цитата:

Есть ряд возможностей, которые значительно легче реализовать в интерпретаторе, чем в компиляторе:

• кроссплатформенность
• рефлексия и интроспекция
• динамическая типизация
• использование динамической области видимости и замыканий

https://ru.wikipedia.org/wiki/%D0%98...BD%D0%B8%D1%8F

Для выделения отдельной темы из
Первые впечатления от программирования в D365FO
где тема hotswapping и сравнения языков зашла слишком далеко

[ax_mct]

Сейчас хайп с WASM (готовый байт-код для браузера) который никогда не заменит JS.
Мечты засунуть .NET Core или MONO в WASM чтобы опять обойтись без изучения нативного web (а это интерпретация) это снова грабли на которые наступают любители делать все через back.

https://en.wikipedia.org/wiki/WebAssembly

https://habr.com/post/342180/

[belugin]

Надо сначала договориться про какую компиляцию мы ведём речь - jit aot или вообще байт-код.

Например в моно jit может быть недоступен из-за ограничений нижележащей платформы. Поэтому

Interpreted versus AOT
Which mode is best? We don’t know yet.

What we do know is that interpreted mode provides a much faster development cycle than AOT. When you change your code, you can rebuild it using the normal .NET compiler and have the updated application running in your browser in seconds. An AOT rebuild, on the other hand, might take minutes.

So one obvious thought is that interpreted mode might be for development, and AOT mode might be for production.

But that might not turn out to be the case, because interpreted mode is surprisingly much faster than you’d think, and we hear from Xamarin folks who use .NET for native mobile apps that regular (non-AOT) .NET assemblies are very small and compression-friendly compared with AOT-compiled assemblies. We’re keeping our options open until we can measure the differences objectively.

[ax_mct]

Скорее Ahead-of-Time. Так как думаю это основное отличие JIT в .NET и JIT в Java
которое влияет на кроссплатформенность.

И еще мне кажется что это вопрос Сишного высокомерного менталитета к интерпретаторам и скриптам. Потому как не могу понять почему .NET являясь дубляжом Java так налажал с кроссплатформенностью с самого начала.

Xamarin кстати хороший пример. Это вопрос что важнее мифическая важность сравнения производительности для конечного пользователя или удобство программирования.
Тот же React Native

Цитата:

React Native lets you build your app faster. Instead of recompiling, you can reload your app instantly. With Hot Reloading, you can even run new code while retaining your application state. Give it a try - it's a magical experience.

https://facebook.github.io/react-native/

Думаю что там где выбирают Mono, Xamarin выбирают в силу использования того же (.NET) code base. Единственная основная причина. Там где такой причины нет программисты должны быть больные на всю голову.

[belugin]

Цитата:

Сообщение от ax_mct

Скорее Ahead-of-Time. Так как думаю это основное отличие JIT в .NET и JIT в Java

JIT и AOT взаимоисключающие понятия.

[ax_mct]

Цитата:

Сообщение от belugin

JIT и AOT взаимоисключающие понятия.

Если брать Андроиды то да.
А если брать контекст дискуссии особенностей компиляторов в .NET и Java, то нет.
В разном контексте ширина толкования JIT компиляции - разная.

Цитата:

JIT compilation is a combination of the two traditional approaches to translation to machine code – ahead-of-time compilation (AOT), and interpretation – and combines some advantages and drawbacks of both.

https://en.wikipedia.org/wiki/Just-in-time_compilation

Стратегия компиляции .NET (не уверен насчет NET.Core) это AOT. Хотя по ходу этот термин может означать как минимут два подхода. Ngen.exe as Pre-JIT и собственно внутренняя реализация JIT.

Цитата:

CLR design mandates that the JIT happens before the relevant code executes,
JVM's in contrast would be free to interpret the code for a while while a separate thread creates a machine code representation.

При этом конечно то что кто-то пишет что

Цитата:

the CLR compiles all of the machine code once when it’s called at runtime

слишком упрощенно. Думаю что многое изменилось в .NET и тот же NET.Core скорее всего использует более продвинутую копмиляцию в стиле "мы еще более Java".

При этом процесс компиляции CLR называют JIT компиляцией. Но момент этой компиляции и необходимость ее перед запуском это AOT.
В отличие от интерпретации. То есть AOT снаружи JIT и есть AOT внутри JIT.

Цитата:

The Common Language Runtime (CLR), the virtual machine component of Microsoft's .NET framework, manages the execution of .NET programs. A process known as just-in-time compilation converts compiled code into machine instructions which the computer's CPU then executes.

https://en.wikipedia.org/wiki/Common_Language_Runtime

[belugin]

Насколько я понял, классифицируют по отношению к программе - если компилируется до запуска - это AOT, если в рантайме - это JIT

https://docs.microsoft.com/en-us/dot...to_native_code

Compilation by the JIT Compiler
JIT compilation converts MSIL to native code on demand at application run time, when the contents of an assembly are loaded and executed.
...
Instead of using time and memory to convert all the MSIL in a PE file to native code, it converts the MSIL as needed during execution and stores the resulting native code in memory so that it is accessible for subsequent calls in the context of that process. The loader creates and attaches a stub to each method in a type when the type is loaded and initialized. When a method is called for the first time, the stub passes control to the JIT compiler, which converts the MSIL for that method into native code and modifies the stub to point directly to the generated native code. Therefore, subsequent calls to the JIT-compiled method go directly to the native code

To allow the generated code to be shared across multiple invocations of an application or across multiple processes that share a set of assemblies, the common language runtime supports an ahead-of-time compilation mode. This ahead-of-time compilation mode uses the Ngen.exe (Native Image Generator)

В википедии собственно написано, почему это комбинация AOT и интепретации:

A common implementation of JIT compilation is to first have AOT compilation to bytecode (virtual machine code), known as bytecode compilation, and then have JIT compilation to machine code (dynamic compilation), rather than interpretation of the bytecode.

То есть, AOT в данном случае относится к компиляции в байткод.

То есть и в HotSpot и в CLR загруженная сборка может быть скомпилирована в машинный код частично, просто в CLR то, что выполняется, точно скомпилировано. Можно конечно, чисто назвать это пометодной AOT, но обычно под AOT понимают немного другое.

Про core clr не знаю, натыкался на то, что там внутри есть ограниченный интерпретатор, скорее всего используемый для теста на новых платформах.

А вот открытое issue, не сделать ли там jit с интерпретатором https://github.com/dotnet/coreclr/issues/4331

Говорят про startup time а не про hotswap.

[belugin]

В моно интепретатор появился для платформ в которых невозможен JIT (нужен либо полный AOT либо интерпретация) http://www.mono-project.com/news/201...o-interpreter/

The main downside of full static compilation is that a completely new executable has to be recreated every time that you update your code. This is a slow process and one that was not suitable for interactive development that is practiced by some.

For example, some game developers like to adjust and tweak their game code, without having to trigger a full recompilation. The static compilation makes this scenario impractical, so they resort to embedding a scripting language into their game code to quickly iterate and tune their projects.

[belugin]

Про JRebel - тут интерпретация похоже совсем не причем. Причем тут возхможность встроиться в загрузчик:

https://www.quora.com/How-does-JRebel-work


JRebel leverages the JVM's built-in instrumentation and hot swap to redefine the core libraries and to add an extra field to each object to make it appear as if the JVM is doing something it can't do.

• Adds a resizable layer of indirection to each object that's essentially an extra private field Map[String, Any], which holds references to new fields added to an object
• Adds a resizable layer of indirection to each class that's essentially Map[Signature, ImplementingClass], which holds references to anonymous classes with the actual method implementation for methods added to a class
• Modifies references in all loaded classes to fields and methods introduced after the class was loaded to account for the layers of indirection (either by referencing into the map for fields or by calling methods in anonymous classes instead of on the class itself)
• Instruments the java.lang.reflection and stack trace libraries to mask the above changes, making them appear as if direct access to new fields and methods were possible. For example, myClass.getField("x") may internally reference into the Map[String, Any] on the object

При этом, насколько я понял, с JIT ничего не делается - компиляция не отменяется. То есть вместо внутренних эффективных структур в байткод встраиваются мэпы. За счет этого можно как-то менять и одновременно тормоза.

Все дело в структуре данных и ссылках, а не в компиляторе или интерпретаторе.

Про tiered compilation - интересная статья про то, как там устроено внутри - фичу практически сделали, но вместо интерпретатора там неоптимизированный JIT в качестве первого звена. См Why not ‘Interpreted’? и Why not LLVM? в конце статьи.

[ax_mct]

Цитата:

Сообщение от belugin

То есть, AOT в данном случае относится к компиляции в байткод.

Согласен что общепринято понимать виды компиляции AOT vs JIT.
Внутри JIT cкорее всего другая терминология.

Цитата:

Сообщение от belugin

Про JRebel - тут интерпретация похоже совсем не причем.
...
Все дело в структуре данных и ссылках, а не в компиляторе или интерпретаторе.

То есть в хотсваппинге чистое мастерство Javа программистов которое можно применить в .NET? Без преимуществ интерпретатора?

То есть пора открывать тему что программисты MS не настолько исскусны как программисты Java?

[belugin]

Вот есть такое мнение.

https://stackoverflow.com/questions/...jrebel-for-net

There is no such thing in the .net world.. not so powerful.. there are some thing like Edit and Continue but this is like "Hot replace" in Java and nothing more. The problem is in .net you have the whole model of .dll(s) with their versions and dependencies between dlls pointing to specific version so it is not possible to replace dll without replacing all.

An workaround will be something like compiling the classes, adding tons of assembly redirects, somehow unloads and loads the old dll but it is hell of a hard.

Keep in mind that in java after the "module" JSR is implemented maybe in java 9 we will not have JRebel as well.

[ax_mct]

Цитата:

Сообщение от belugin

Вот есть такое мнение.
Keep in mind that in java after the "module" JSR is implemented maybe in java 9 we will not have JRebel as well.[/I]

С JRebel все хорошо и в версии Java 10.
Introducing JRebel 2018.1.0 – featuring Java 10 and Spring Boot 2
https://zeroturnaround.com/rebellabs...spring-boot-2/

JRebel changelog
https://zeroturnaround.com/software/...ngelog/2018-x/

При этом JRebel действительно крут.

Цитата:

JRebel fast tracks Java application development by skipping the time consuming build and redeploy steps in the development process. JRebel makes developers more productive since they can view code changes in real time.

https://zeroturnaround.com/software/jrebel/


Почему нет подобного продукта в .NET?

Я все же не понимаю в чем именно проблема. Может в способе организации метаданных?
Никто же не говорит что Java менее безопасна c точки зрения подмены кода.

Цитата:

Сообщение от belugin

The problem is in .net you have the whole model of .dll(s) with their versions and dependencies between dlls pointing to specific version so it is not possible to replace dll without replacing all.
An workaround will be something like compiling the classes, adding tons of assembly redirects, somehow unloads and loads the old dll but it is hell of a hard.

[belugin]

Цитата:

Сообщение от ax_mct

С JRebel все хорошо и в версии Java 10.

Либо чувак не прав, либо modules JSR не заимплементили, либо JRebel ухудшился.

Цитата:

Почему нет подобного продукта в .NET?

Я все же не понимаю в чем именно проблема. Может в способе организации метаданных?
Никто же не говорит что Java менее безопасна c точки зрения подмены кода.

Я не знаю.

Можно почитать, почему нет jrebel для Android

[ax_mct]

Есть такая попытка

Цитата:

Rebel.NET is a rebuilding tool for .NET assemblies which is capable of adding and replacing methods and streams.

http://www.ntcore.com/rebelnet.php

Это требует ребилдинга и вообще больше похоже на хакерский инструмент чем на рабочий.

Возможно горе .NET в том что
(1) минимальный файл байткода это файл cборки (.dll) (который может содержать файлы кода классов, ресурсов).
(2) Mанифест содержащий метаданные может быть встроен в сборку. Но однако никто не запрещает сделать его снаружи.
(3) Понятие версии относится к сборке (assembly). Подписывается сборка целиком.

Рантайм .NET проверяет на уровне assembly.

https://en.wikipedia.org/wiki/Assembly_(CLI)
https://en.wikipedia.org/wiki/Manifest_(CLI)

Java при этом
(1) минимальный файл байткода это .class, при том что аналог сборки это .jar который просто архив.
(2) Mанифест всегда отдельный файл в этом архиве.
(3) Понятие версии относится к байткоду класса в этом архиве. Подписывается не .jar, а классы индивидуально.

Цитата:

When the Java runtime loads signed JAR files, it can validate the signatures and refuse to load classes that do not match the signature.

Рантайм Джавы проверяет на уровне класса.
При этом никто не запрещает

Цитата:

A package might be sealed to ensure version consistency among the classes in the software or as a security measure.

https://en.wikipedia.org/wiki/JAR_(file_format)

[belugin]

Минимальный файл с байткодом, это .netmodule - см папку со сборками именно в аксапте

[belugin]

Цитата:

Сообщение от ax_mct

Есть такая попытка

http://www.ntcore.com/rebelnet.php

Это требует ребилдинга и вообще больше похоже на хакерский инструмент чем на рабочий.

Судя по описанию, к хотсваппингу он если и имеет отношение то очеь опосредованное.

[ax_mct]

Цитата:

Сообщение от belugin

Минимальный файл с байткодом, это .netmodule - см папку со сборками именно в аксапте

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

Но упоминание справедливо.

.netmodule не имеет своего манифеста и упоминается в манифесте нормальной сборки .dll (.exe) которая ссылается на .netmodule.

Есть интересное средство
MageUI.exe (средство создания и редактирования манифестов)
https://docs.microsoft.com/ru-ru/dot...aphical-client

И с учетом того что манифест может быть отдельнам файлом думаю что есть все признаки того что было бы желание реализовать что-то близкое к продукту JRebel таки можно.

Но Горе .NET в унылых программистах которых притягивает .NET.

Цитата:

At the start, .NET folks are quite happy with the technologies and tools they use, and their deployment processes. Unlike in Java, they do not complain about the need to redeploy and time it usually takes, right from the very start.

https://zeroturnaround.com/rebellabs...n-deployments/