3 ms·

[disclaimer: I'm a member of the Dart project working on the VM] These two benchmarks are publicly tracked at http://www.dartlang.org/performance/ http://www.d

by mraleph 14y ago

[disclaimer: I'm a member of the Dart project working on the VM] These two benchmarks are publicly tracked at http://www.dartlang.org/performance/ http://www.dartlang.org/performance/ Dart VM is used to provide smooth developer experience and can operate standalone on the server side (there is dart:io library) which makes its raw performance quite important, from my point of view.

kibwen 14y ago
Thanks, this graph is perfect. (For everyone else, note that you can click and drag on the graph to go back in time.) > Dart VM is used to provide smooth developer experience and > can operate standalone on the server side (there is dart:io > library) which makes its raw performance quite important, > from my point of view. The server side is a bit irrelevant here; nobody's pretending that Dart's ever going to get traction on the server side if it doesn't first have a strong stake on the client side. And if I'm pitching to my team that we should use Dart for our web applications, I need to know that my performance won't be dreadful on the majority of installed browsers in the world. One more question: is there a reason you only run two of the Octane benchmarks, rather than the entire suite? More data points would make for a more convincing argument.
- mraleph 14y ago
  > is there a reason you only run two of the Octane benchmarks As the FAQ states at the very bottom of the page: Porting benchmarks correctly takes time. As more benchmarks become ready, we will publish more charts. Some Octane benchmarks are quite hard to port either because they are very big (PDF.js), generated by some sort of compiler (e.g. Mandreel and EarleyBoyer) or exercise things that might not necessarily have any direct translation to Dart (RayTrace is using class emulation code take from prototype.js).
  - kibwen 14y ago
    Ah yes, thanks. I'm so used to benchmarks being trivial that I keep forgetting that Octane contains full-fledged applications!
maga 14y ago
>...Dart’s structure lets the VM take a snapshot that’s stored in the browser, which can be booted up in one-tenth of the time it takes to load the full code from scratch. “That’s hard to do in JavaScript because in setting up the program you have to execute the source code; that source code has side effects and those side effects cannot be snapshotted,” Bak said. Vyacheslav, I bet everybody and their dog would be most grateful if somebody pointed out those side effects that prevent JS from being snapshotted.
- mraleph 14y ago
  Let me sketch out my own interpretation of the problem. JavaScript programs lack declarative structure. There is no way to declare a class with a fixed set of fields and methods. Instead JavaScript program creates functions and sets up their prototype property as it executes. No way to declare a module. Instead developers create and immediately invoke a nameless closure. One can say that the structure (things that people view as "classes" and "modules") behind JavaScript program is the side-effect of this very program executing. There is no clear border between "structure initialization" and execution. So the first issue arises: to snapshot something you need to guarantee that deserialized snapshot will result in the very same "structure" that would arise from executing this code from scratch. This imposes certain restrictions on the way the JavaScript code should be written and how its initialization should be laid out. If for example application starts interacting with DOM early in its "initialization" phase then this is hard to snapshot correctly. But an opposite is true as well: other programs (scripts) executing in the same environment might affect the structure that JavaScript program weavers as it runs. Consider for example the following code: function Point() { } Point.prototype.distance = function () { /* ... */ }; It might look like we could snapshot it and then unconditionally deserialize it into a Point function with a distance property on an object in its prototype property. But this is not true. If our deserialization does not happen in the clean environment (e.g. we are not the very first thing that is running on the page) then somebody can install "distance" property with a setter on the Object.prototype thus altering execution of our initialization entirely. This means that deserialization code must account for that. So we have two points to care about: (a) JS code must be written in a special way to benefit from snapshotting, serializer must bail out from the attempt to snapshot "unsound" initialization code; (b) deserializer must ensure correctness when unpacking. If you ensure that both hold then you can actually snapshot your JS code and benefit from it. V8 in fact does this internally: some JavaScript builtins are written in JavaScript and "snapshotted" to speed up their initialization. But V8 snapshots are cutting corners: - Point (a) is ensured manually. "Unsound" initialization code in builtins just leads to mysterious bugs. There is no verification, toolchain does not reject any code. - Point (b) is guaranteed because deserializer is applied when the world is empty and untouched by the user code. This is not something you can use for an arbitrary JS code AS IS... and filling up the gaps requires hard efforts on both VM and application side. Dart does not have any problems like that because the structure behind the program is static. So snapshotting is simple to implement and it works for any application, not requiring any "restructuring" from the app developer.

by mraleph 14y ago

kibwen 14y ago

Thanks, this graph is perfect. (For everyone else, note that you can click and drag on the graph to go back in time.) > Dart VM is used to provide smooth developer experience and > can operate standalone on the server side (there is dart:io > library) which makes its raw performance quite important, > from my point of view. The server side is a bit irrelevant here; nobody's pretending that Dart's ever going to get traction on the server side if it doesn't first have a strong stake on the client side. And if I'm pitching to my team that we should use Dart for our web applications, I need to know that my performance won't be dreadful on the majority of installed browsers in the world. One more question: is there a reason you only run two of the Octane benchmarks, rather than the entire suite? More data points would make for a more convincing argument.

mraleph 14y ago
> is there a reason you only run two of the Octane benchmarks As the FAQ states at the very bottom of the page: Porting benchmarks correctly takes time. As more benchmarks become ready, we will publish more charts. Some Octane benchmarks are quite hard to port either because they are very big (PDF.js), generated by some sort of compiler (e.g. Mandreel and EarleyBoyer) or exercise things that might not necessarily have any direct translation to Dart (RayTrace is using class emulation code take from prototype.js).
- kibwen 14y ago
  Ah yes, thanks. I'm so used to benchmarks being trivial that I keep forgetting that Octane contains full-fledged applications!

maga 14y ago

>...Dart’s structure lets the VM take a snapshot that’s stored in the browser, which can be booted up in one-tenth of the time it takes to load the full code from scratch. “That’s hard to do in JavaScript because in setting up the program you have to execute the source code; that source code has side effects and those side effects cannot be snapshotted,” Bak said. Vyacheslav, I bet everybody and their dog would be most grateful if somebody pointed out those side effects that prevent JS from being snapshotted.

mraleph 14y ago
Let me sketch out my own interpretation of the problem. JavaScript programs lack declarative structure. There is no way to declare a class with a fixed set of fields and methods. Instead JavaScript program creates functions and sets up their prototype property as it executes. No way to declare a module. Instead developers create and immediately invoke a nameless closure. One can say that the structure (things that people view as "classes" and "modules") behind JavaScript program is the side-effect of this very program executing. There is no clear border between "structure initialization" and execution. So the first issue arises: to snapshot something you need to guarantee that deserialized snapshot will result in the very same "structure" that would arise from executing this code from scratch. This imposes certain restrictions on the way the JavaScript code should be written and how its initialization should be laid out. If for example application starts interacting with DOM early in its "initialization" phase then this is hard to snapshot correctly. But an opposite is true as well: other programs (scripts) executing in the same environment might affect the structure that JavaScript program weavers as it runs. Consider for example the following code: function Point() { } Point.prototype.distance = function () { /* ... */ }; It might look like we could snapshot it and then unconditionally deserialize it into a Point function with a distance property on an object in its prototype property. But this is not true. If our deserialization does not happen in the clean environment (e.g. we are not the very first thing that is running on the page) then somebody can install "distance" property with a setter on the Object.prototype thus altering execution of our initialization entirely. This means that deserialization code must account for that. So we have two points to care about: (a) JS code must be written in a special way to benefit from snapshotting, serializer must bail out from the attempt to snapshot "unsound" initialization code; (b) deserializer must ensure correctness when unpacking. If you ensure that both hold then you can actually snapshot your JS code and benefit from it. V8 in fact does this internally: some JavaScript builtins are written in JavaScript and "snapshotted" to speed up their initialization. But V8 snapshots are cutting corners: - Point (a) is ensured manually. "Unsound" initialization code in builtins just leads to mysterious bugs. There is no verification, toolchain does not reject any code. - Point (b) is guaranteed because deserializer is applied when the world is empty and untouched by the user code. This is not something you can use for an arbitrary JS code AS IS... and filling up the gaps requires hard efforts on both VM and application side. Dart does not have any problems like that because the structure behind the program is static. So snapshotting is simple to implement and it works for any application, not requiring any "restructuring" from the app developer.