3 ms·

> If Dart VM can use "patch class" declarations then why this "@inline" should be considered as a bad? Annotation like that is not enough for intrinsics. You w

by mraleph 12y ago

> If Dart VM can use "patch class" declarations then why this "@inline" should be considered as a bad? Annotation like that is not enough for intrinsics. You would still need to provide some way of detecting in the compilation pipeline and intrinsifier that method you are looking at is indeed `Integer_bitAndFromInteger`. In this particular case you could look at the name of the native, but that does not work with those intrinsified methods that have Dart bodies. In those cases it would have to be @intrinsic("name of the intrinsic"). Right now we can write C++ code like this: switch (recognized_kind()) { case MethodRecognizer::kSmth: case MethodRecognizer::kSmthElse: break; } If we start to relying on strings - this code will become less readable (or alternatively you would have to map strings into C++ enumeration which would require a list quite list one of the above). To be honest aesthetically I like annotations, so I would like to use them to replace these lists, but that does not really solve anything or improve much. Even more: there is really no fundamental difference between having an annotation and a list like that, so I don't really understand what bothers you about these lists. > (dynamism is better, determine everything at runtime or from magic lists) Annotation would be no less magic (and not available to the user code anyways).

mezoni 12y ago
>> so I don't really understand what bothers you about these lists. This approach does not allow me to use annotations (or other way) for specifying that my own "native" methods in "native extension" are required some attention. You use for such attention these lists. Eg. I have the following methods (via macro defs) in my "native extension": ========================= UNSAFE_READ_INT(8, int8_t) UNSAFE_READ_INT(16, int16_t) UNSAFE_READ_INT(32, int32_t) UNSAFE_READ_INT(64, int64_t) // Skipped UNSAFE_READ_FLOAT(32, float) UNSAFE_READ_FLOAT(64, double) // Skipped ========================= These methods are very fast (in C++) but in fact Dart VM executes them (native methods) very SLOOOOOOOOOOOWWWWWWWWWWWW... See my question on stack overflow: ========================= Why native wrapped functions in Dart are such heavyweight in comparison with “DEFINE NATIVE ENTRY” functions that are very lightweight? http://stackoverflow.com/questions/21363429/why-native-wrapped-functions-in-dart-are-such-heavyweight-in-comparison-with-de http://stackoverflow.com/questions/21363429/why-native-wrapp... ========================= - Dart developers does not like annotation - Dart VM does not uses annotation - Dart VM does not uses type annotation - Dart VM executes custom "native (which in fact are very fast)" methods very slow This is what is means for me that Dart VM is not a very well balanced for high performance. P.S. This is why "I bothers you about these lists". Because they are in some cases the only way to improve performance.
- mraleph 12y ago
  > I have the following methods (via macro defs) in my "native extension": Can't you just expose the data you are reading as an external typed data array to the Dart code? That would remove any need for those methods. > - Dart developers does not like annotation I like annotations! > - Dart VM executes custom "native (which in fact are very fast)" methods very slow This concern is very valid: it is true that transition between Dart code and native methods is too heavyweight and as a developer you have no way to fix it yourself. We had plans to fix it eventually - but they never been very high on the list of things. Did you file a bug for the slowness of your native extension?
  - mezoni 12y ago
    >> Can't you just expose the data you are reading as an external typed data array to the Dart code? That would remove any need for those methods. I work on integrating into Dart ecosysem "foreign functions interface" (ffi). External typed data is not suitable in many cases: - Does not provide physical storage address to use code (binary interop requires that) - I don't need it because it heavyweight if use it with C pointers and references - It has limit in size (specified in Dart VM on max array length) - I need malloc and typed data does not help here in any way - I access data (by physical address) allocated externally >> Did you file a bug for the slowness of your native extension? This is useless. A long time ago we already did not come to a consensus.
    - mraleph 12y ago
      > I work on integrating into Dart ecosysem "foreign functions interface" (ffi). Truly efficient FFI has to be part of the VM, you can't implement efficient FFI from outside. > - I access data (by physical address) allocated externally Do you really mean "physical address" here? External data is created precisely to efficiently access data allocated externally, because it allows direct raw access to a given region of memory (sans bounds checking).
      - mezoni 12y ago
mezoni 12y ago
>> Annotation would be no less magic (and not available to the user code anyways). Magic of annotations in that the they are only annotates but a real magic goes elsewhere... They can be ignored and this is not a magic because they are only a metadata (data about data). I think that Dart VM and Dart developers does not like annotations because they thinking that VM cannot use them effectively (even if they written by humans). But Dart VM are more complex than V8 VM and a ways that uses developers to tell VM about how specify metadata about critical methods is not a very good. ======================== Are there attributes that affect how the CLR optimizes during a JIT compile? http://stackoverflow.com/questions/2367094/are-there-attributes-that-affect-how-the-clr-optimizes-during-a-jit-compile http://stackoverflow.com/questions/2367094/are-there-attribu... ======================== Also ======================== MethodImplOptions Enumeration http://msdn.microsoft.com/ru-ru/library/system.runtime.compilerservices.methodimploptions(v=vs.110).aspx http://msdn.microsoft.com/ru-ru/library/system.runtime.compi... - Unmanaged - ForwardRef - PreserveSig - InternalCall - Synchronized - NoInlining - AggressiveInlining - NoOptimization ======================== This is from: "The System.Runtime.CompilerServices namespace provides functionality for compiler writers who use managed code to specify attributes in metadata that affect the run-time behavior of the common language runtime." The fact that Dart is not a multi-layer VM does not means that it are simple this is good for optimizations. Do you use such a layer as a "Well structured intermediate language" in Dart VM?
- mraleph 12y ago
  > I think that Dart VM and Dart developers does not like annotations because they thinking that VM cannot use them effectively (even if they written by humans). The fear is actually completely opposite: people would misuse these annotations without understanding what they do and then complain that Dart VM "is slow". As I said: I'd love to convert these lists to annotations. Don't tell anyone but we actually have inlining annotations[1] which we use when writing tests. > Do you use such a layer as a "Well structured intermediate language" in Dart VM? I don't understand the question. Dart VM uses intermediate representation when compiling, which is an implementation detail (unlike CLR IL - which well specified input to the VM essentially) [1] https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/tests/language/vm/load_elimination_two_redefinitions_test.dart?spec=svn41735&r=41713#20 https://code.google.com/p/dart/source/browse/branches/bleedi...)

by mraleph 12y ago

mezoni 12y ago

>> so I don't really understand what bothers you about these lists. This approach does not allow me to use annotations (or other way) for specifying that my own "native" methods in "native extension" are required some attention. You use for such attention these lists. Eg. I have the following methods (via macro defs) in my "native extension": ========================= UNSAFE_READ_INT(8, int8_t) UNSAFE_READ_INT(16, int16_t) UNSAFE_READ_INT(32, int32_t) UNSAFE_READ_INT(64, int64_t) // Skipped UNSAFE_READ_FLOAT(32, float) UNSAFE_READ_FLOAT(64, double) // Skipped ========================= These methods are very fast (in C++) but in fact Dart VM executes them (native methods) very SLOOOOOOOOOOOWWWWWWWWWWWW... See my question on stack overflow: ========================= Why native wrapped functions in Dart are such heavyweight in comparison with “DEFINE NATIVE ENTRY” functions that are very lightweight? http://stackoverflow.com/questions/21363429/why-native-wrapped-functions-in-dart-are-such-heavyweight-in-comparison-with-de http://stackoverflow.com/questions/21363429/why-native-wrapp... ========================= - Dart developers does not like annotation - Dart VM does not uses annotation - Dart VM does not uses type annotation - Dart VM executes custom "native (which in fact are very fast)" methods very slow This is what is means for me that Dart VM is not a very well balanced for high performance. P.S. This is why "I bothers you about these lists". Because they are in some cases the only way to improve performance.

mraleph 12y ago
> I have the following methods (via macro defs) in my "native extension": Can't you just expose the data you are reading as an external typed data array to the Dart code? That would remove any need for those methods. > - Dart developers does not like annotation I like annotations! > - Dart VM executes custom "native (which in fact are very fast)" methods very slow This concern is very valid: it is true that transition between Dart code and native methods is too heavyweight and as a developer you have no way to fix it yourself. We had plans to fix it eventually - but they never been very high on the list of things. Did you file a bug for the slowness of your native extension?
- mezoni 12y ago
  >> Can't you just expose the data you are reading as an external typed data array to the Dart code? That would remove any need for those methods. I work on integrating into Dart ecosysem "foreign functions interface" (ffi). External typed data is not suitable in many cases: - Does not provide physical storage address to use code (binary interop requires that) - I don't need it because it heavyweight if use it with C pointers and references - It has limit in size (specified in Dart VM on max array length) - I need malloc and typed data does not help here in any way - I access data (by physical address) allocated externally >> Did you file a bug for the slowness of your native extension? This is useless. A long time ago we already did not come to a consensus.
  - mraleph 12y ago
    > I work on integrating into Dart ecosysem "foreign functions interface" (ffi). Truly efficient FFI has to be part of the VM, you can't implement efficient FFI from outside. > - I access data (by physical address) allocated externally Do you really mean "physical address" here? External data is created precisely to efficiently access data allocated externally, because it allows direct raw access to a given region of memory (sans bounds checking).
    - mezoni 12y ago

mezoni 12y ago

>> Annotation would be no less magic (and not available to the user code anyways). Magic of annotations in that the they are only annotates but a real magic goes elsewhere... They can be ignored and this is not a magic because they are only a metadata (data about data). I think that Dart VM and Dart developers does not like annotations because they thinking that VM cannot use them effectively (even if they written by humans). But Dart VM are more complex than V8 VM and a ways that uses developers to tell VM about how specify metadata about critical methods is not a very good. ======================== Are there attributes that affect how the CLR optimizes during a JIT compile? http://stackoverflow.com/questions/2367094/are-there-attributes-that-affect-how-the-clr-optimizes-during-a-jit-compile http://stackoverflow.com/questions/2367094/are-there-attribu... ======================== Also ======================== MethodImplOptions Enumeration http://msdn.microsoft.com/ru-ru/library/system.runtime.compilerservices.methodimploptions(v=vs.110).aspx http://msdn.microsoft.com/ru-ru/library/system.runtime.compi... - Unmanaged - ForwardRef - PreserveSig - InternalCall - Synchronized - NoInlining - AggressiveInlining - NoOptimization ======================== This is from: "The System.Runtime.CompilerServices namespace provides functionality for compiler writers who use managed code to specify attributes in metadata that affect the run-time behavior of the common language runtime." The fact that Dart is not a multi-layer VM does not means that it are simple this is good for optimizations. Do you use such a layer as a "Well structured intermediate language" in Dart VM?

mraleph 12y ago
> I think that Dart VM and Dart developers does not like annotations because they thinking that VM cannot use them effectively (even if they written by humans). The fear is actually completely opposite: people would misuse these annotations without understanding what they do and then complain that Dart VM "is slow". As I said: I'd love to convert these lists to annotations. Don't tell anyone but we actually have inlining annotations[1] which we use when writing tests. > Do you use such a layer as a "Well structured intermediate language" in Dart VM? I don't understand the question. Dart VM uses intermediate representation when compiling, which is an implementation detail (unlike CLR IL - which well specified input to the VM essentially) [1] https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/tests/language/vm/load_elimination_two_redefinitions_test.dart?spec=svn41735&r=41713#20 https://code.google.com/p/dart/source/browse/branches/bleedi...)